Infrastructureチーム)エンジニアの北見です。CDKを触っておりました。いう結論に辿り着きました。今回はそのように考えるようになった理由について説明していこうと思います。走りとして様々な現場に導入実績があり、それに対するリスペクトは持つべきです。AWS初学者にとってむしろ混乱のもとなので、個人的見解として言い切ります。インフラのコード・バージョン管理は可能です。「これは設定ファイルの管理を頑張っているんじゃないか?」という感が拭えませんでした。IDE)でメソッドやプロパティがサジェストされるので、編集時のストレス少ないといった恩恵を受けられます。「とあるCodeBuildにS3のBucketへのアップロード権限を付与する」というリソース構成を書く場合を考えてみましょう。.grantPut(project);となります。明らかに少ない記述量でやりたいことを実現できている。「S3へのアップロード権限をCodeBuildに与える」という「やりたいことの本質」を簡潔に表現できます。文字列を代入してしまうこともありません。アプリケーションエンジニアにオーナーシップが生まれるある程度規模が大きくなったWeb系企業においては、インフラチームとアプリケーション開発チームに分業することは珍しくありません。弊社でもSREチームが存在し、開発者体験の向上や安定したサービス提供のために日々仕事をしています。個々のドメインを担当するメンバーは、基本的にそのアプリケーションが動作するインフラにも責任を持っています。断言しますが、CDKなしに、今のNewsPicksは存在してません。楽ができるからエンジニアのリソースの空きが生まれ、その空きが改善への投資とオーナーシップを生んでいっていると良いでしょう。少ない労力で本質的なことに注力している感があり、実際その通りなのです。我々エンジニアも人間ですし、体力も忍耐も限度があります。本質的に向かい合う必要のないエラーに時間を使いすぎるのは嫌ですし、逆に自分なりに構成を考えてインフラ構築するのは楽しいです。利点を紹介してきましたが、実際にやってみて体感した落とし穴も存在するので、いくつか紹介させて頂きます。関するサービスに対する基本的な知識は必要とされます。何?という状態で、例えばコンテナを利用したWebアプリケーション開発をするのは難しいでしょう。便利である反面、内部でよしなにやってくれている部分も多いです。(特にPolicyを自動生成してくれているケースが多い印象)その「よしなに」が影響で意図しない挙動となった場合、CDKのコードを追ってみる必要があります。「スタック」という概念が登場します。リソースは各スタック内で作成され、例えば「ネットワークスタック」内部でVPNやSecurityGroup、「データベーススタック」の内部でRDSが作成されることになります。なると当然、とあるスタックに所属するリソースを別のスタックから参照したい場合がでてきます。リソースそのものの削除をしようとすると、高確率でエラーとなります。これを回避するには、ルールベースの命名規則を採用するのが1つの回答です。リソースへの参照をする際、シンボルを直接渡さず名前でリソースの解決を行うようする方法になります。利用する方法もあるようです。触れなくなってしまいました。便利さを体感して欲しいです。ありがとうございました。reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。