Zenn
Closed16

初心者がおさえておきたいAWS CDKのベストプラクティス 2024 スクラップ

AWS
AWS CDK
M.K Tech k.masachikaM.K Tech k.masachika

Tenetsに共感する

Tenetsとは
意思決定のための組織や製品の信条。何に価値を置くのかを明らかにする

M.K Tech k.masachikaM.K Tech k.masachika

Gitでバージョン管理する

Gitリポジトリにすべてを保存する

依存関係のロック

  • package-lock.json,poetry.lock等もコミットする

  • コンテキスト情報の一貫性を保つ

  • cdk.context.json

Gitリポジトリとチームの境界を合わせる

  • 1 GItリポジトリ = 1CDK Appを原則にする
  • コンウェイの法則を念頭におく
M.K Tech k.masachikaM.K Tech k.masachika

IDEの機能を利用する

VSCOde + TypeScriptは設定不要

  • Linter / Formatterは下記を参考に

    • BLEA
    • Projen

  • スニペット

    • CDK App
    • Stack
    • Construct
      上記の雛形をつくってみる
M.K Tech k.masachikaM.K Tech k.masachika

はじめから標準化しない

Platform as a Product

エンジニアを顧客としてエンジニアの認知負荷を削減する取り組みをする

M.K Tech k.masachikaM.K Tech k.masachika

リソースの置き換えに注意

  • cdk diffでセット変更を確認
  • Constract IDの変更
    コンストラクタの第2引数に指定する文字列
  • SSM Parameterなど CDK外部で変更される値にちゅい
  • キャッシュ指定の有無などを確認
M.K Tech k.masachikaM.K Tech k.masachika

ハイレベルなコンストラクトを使う

  • エスケープパッチでL1コンストラクトが取得可能
  • 設定値をすべて明示的に指定するとレビューが困難
M.K Tech k.masachikaM.K Tech k.masachika

スタックは必要になるまでわけない

分けるメリットが具等になるまでわけない

コンストラクトで分割する

たとえば、認証、ストレージ、ラムダ、APIのように分ける

ベタ書きから始める

  • アプリと異なり、動的に振る舞いを帰る必要が低い
  • 必要になるまでパラメーター化しない

パラメータはAppレベルから注入する

  • クラスがテストできなくなるため
  • main.tsやapp.tsなど。エントリーポイントから参照し、スタックに渡す。
M.K Tech k.masachikaM.K Tech k.masachika

スナップショットテストを書く

  • CloudFormationテンプレートの比較から始める。
  • 条件分岐などロジックやパラメーターが必要になったらユニットテストを書く
M.K Tech k.masachikaM.K Tech k.masachika

リソース名ではなくConstract IDにこだわる

  • Constract IDはPascalCaseで命名
  • 短くシンプルに
    • 共通のprefixをつけない
    • リソースごとの制約によって切り詰めめられて末尾が失われない用意する
  • StageのConstract IDには環境名をつける。dev、prod
  • StackのConstratct IDにはサービス名をつける、awsomePhotos
  • リソースのConstract IDにはシンプルなまま絵をつける。itemTable
    例:
  • Dev-AwsamePhotos
  • Dev-AAwsomePhotos-Itemtablexxxxxxx
  • prod-awsamphotos-userphotslogbuket
このスクラップは5ヶ月前にクローズされました