【イベントレポート】JAWS-UG東京 IaC Night 〜入門から上級まで！AWSをコードで構築しよう〜 #jawsug_tokyo

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.03.13（木）に開催した**JAWS-UG東京 IaC Night 〜入門から上級まで！AWSをコードで構築しよう〜**へ参加しましたのでアウトプットとしてイベントレポートを執筆しました。

初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。

目次

• セッション
  • マネコン操作いらず！ TerraformでAWSインフラのコーディングに入門しよう
  • いまから始めるAWS CDK 〜モダンなインフラ構築入門〜
  • Enhancing AXA Data Platform with Terraform
  • 知っておきたい！保守性を高める AWS CDK のセオリー・ベストプラクティス
  • Best practices for using the AWS & AWSCC provider in parallel
  • AWS CDKにおけるL2 Constructの仕組み
• まとめ

セッション

マネコン操作いらず！ TerraformでAWSインフラのコーディングに入門しよう

参考サイト

• 自己紹介
  • KAG所属のテックエバンジェリスト
• IaCツールとは
  • コンソール上で行っているインフラ構築作業をコードで管理すること
  • Ansible、Terraform、AWS CDKが有名
  • コードで実行できる理由はAPIで処理しているから
  • AWS CDKはYAMLで構成ファイルを設定する
• Terraform 設定方法
  • AWS側設定：アカウント設定、IAM Identity Centerの設定
  • ローカル側設定：アクセスキー登録
  • コンフィグファイルを書くときは公式ドキュメントを見ればいい
  • terraform init→terraform plan→terraform applyで実行可能
  • terraform planを実行すれば差分チェックができる
• より便利に使うために
  • TFファイルを分割すると余計な処理を少なくさせることができる
  • local変数を利用すればいい感じでループ処理も行える
  • モジュールを利用すればよい高度な開発も行える

いまから始めるAWS CDK 〜モダンなインフラ構築入門〜

登壇資料

参考サイト

• 自己紹介
  • クラスメソッド所属のエンジニアの方
  • CDK支部運営の方
  • CDKチョットデキルの方
• CDKの種類
  • AWS CDK、TerraformやCDK K8sがある
• AWS CDKの利点
  • プログラミング言語でインフラを定義したいので学習コストが少ない
  • 型安全性によるコード補完ができる
• AWS CDKの欠点
  • プログラミング言語を利用するため未経験は学習コストがかかる
  • コードのこだわりが生まれやすい
• L1～L3について
  • L1レベル：パラメータをハードコーディングしている
  • L2レベル：パラメータを抽象化している
  • L3レベル：アーキテクチャパターン全体を抽象化している
    • メンテナンスを考えたらL2レベルがベター
  • （個人的考察）CDK関連は興味深いですからね～

Enhancing AXA Data Platform with Terraform

• アクサ生命でのTerraform利用背景
  • 開発生産性の向上
  • Terraform導入前もEventBridgeを通じて管理していたが、予期せぬアップデートが発生していた
  • 構成イメージとしてシムリンクを利用していた
• 予期せぬアップデート対応
  • TerraformのDiffチェック機能を活用している
  • use_lockfile = Trueを利用すれば勝手に更新されない
• まとめ
  • Terraformを利用することで運用改善を実現できた
  • 差分チェックや予期せぬアップデートなど
  • 引き続きコントリビュート活動を行っていきたい

知っておきたい！保守性を高める AWS CDK のセオリー・ベストプラクティス

参考サイト

• 自己紹介
  • バックエンド/フロントエンドエンジニアの方
  • CDKコントリビュートも行っている方
• AWS CDKとは
  • プログラミング言語でAWSインフラを構築できるツール
    • ロジックを持ち込めるため複雑化しやすくなる
    • ロジックが複雑化しないようにするための取り組みが必要
• 保守性とは
  • システムを修正する有効性を示す
  • 保守性が低いコードだと変更内容が他リソースへ影響してしまう
• ベストプラクティス
  • Construct IDに変数を使用しない
    • 外的要因によって変数が変わってしまう
    • ループ処理であればその限りではない
  • Construct Property/propsはClass型にしない
    • 外的要因によって処理が影響を受ける（≒密結合状態）
    • Interface型を利用することで疎結合が実現できる
  • 外部に公開しないモジュールはprivateディレクトリに
    • 不要なインポート処理が少なくなる
    • Type Scriptの場合、ESLintを利用すれば制御可能
  • 環境ごとに異なる設定値を外部化させる
    • 環境ごとに異なるのであれば外部から受け取るのがベター
    • Constructごとに環境変数を入れておくとめんどくさくなる
  • 命名規則を統一する
    • 可読性の向上、学習リソースの削減などにつながる
    • TSスタイルガイドに基づいて設定するのが吉

Best practices for using the AWS & AWSCC provider in parallel

参考サイト

• 自己紹介
  • AWSヒーローの方
  • CLIのコアコントリビューターとして活動してきた方
• Terraform Provider
  • ローカル環境とAWSコンソールをつなぐ接着剤みたいなもの
  • AWSプロバイダーにはEC2などのリソースを構築するビジネスロジックが存在する
  • もともとはTerraform Coreのコードの一部だった
• コントリビュート活動
  • 12名のエンジニアを中心にメンテナンス活動を行っている
  • バックグラウンドはAWS Cloud Control APIを通じて実行
  • 現在、約12000種類のコンストラクトやリソースを構築可能
  • （個人的考察）クラウドベンダがAPIを公開しているのはうれしすぎますね
• 統一インターフェース
  • 仕様変更によってコードとの不整合が起きる場合がある
  • 属性追加や引数設定に関してはBotなどを用いて自動的にメンテナンスできるようにしている
• 実際にリソース構築してみる
  • すでにterraform applyしたTFファイルを修正してリソースの設定変更を行う
    • 同じリソースがコンソール上に存在する場合、エラーになってしまう
    • 完全に環境をクリアにしないと構築エラーが出てしまう
  • （個人的考察）この厳密さがTerraformの奥深さなのではと思ってしまいますね

AWS CDKにおけるL2 Constructの仕組み

参考サイト

• 自己紹介
  • AWS DevTools Heroの方
  • CDKトップコントリビュータの方
• AWS CDK L2 Constructについて
  • L2 Constructの概要についてつかんでもらう
  • AWS CDKはOSSの取扱い
    • 開発言語はType Scriptを利用
  • 業務や個人開発で利用している方向けの話
• L2　Constructとは
  • ざっくり言えば、いい感じの抽象化している
  • めんどくさいVPC設定を簡単にに生成できる
    • grantメソッドを利用すればいい感じのIAM権限を生成してくれる
  • CDKレイヤーでDocker Builde・ECRもできる
• なぜL2 Constructの話が
  • L3 Constructは汎用性が低い
  • そもそも本家からあまり出ていない
    • ユーザ側で自作L3を作るのが主流
  • その結果からL2がよく利用されるようになった
  • （個人的考察）やっぱりそうなりますよね
• L2　Constructの中身
  • L1 Constructをいい感じで継承していく
  • 全てのコードを生成する必要はない
• 構成要素
  • IExample
    • スタック外のリソースを疑似的にスタック管理下に取り込む読み込み用の方
    • （個人的考察）import的なニュアンスなんでしょうね
    • プロパティもとれる、メソッドもとれる
    • （個人的考察）オブジェクト指向の動き方と一緒なのかしら
    • 実際の処理に関しては別のクラスで執筆する必要がある
      • 変更を加えないリソースのみしか指定できない
  • ExampleAttributes
    • 全てのプロパティは読み取り専用
  • ExampleBase
    • 1つのリソースに対して複数のConstructを実装するための共通クラス
    • Constructを複数作らない場合でも拡張性を考えて作ったほうがいい
    • Base側で初期化処理が不要な場合、Consstructがない場合もある
    • grant系メソッドやmetric系メソッドは大体Baseで定義している
  • ExampleProps
    • 特定のプロパティ群をネストしてもいいがフラットにしたほうが可読性が上がる
    • 振る舞いを持たせることでユーザが行うめんどくさい処理をいい感じにしてくれる
  • Example（L2 Construct）
    • L1 Constructを生成するのが一番重要
    • AWSサービスとして推奨すべき設定がなければCDK側で定義せず、CloudFormation側で定義するようにしている
    • バリデーションはCDK側で実装したほうが吉
      • CloudFormationで実装すると予期せぬリソース構築が発生する
    • addメソッドなどを活用すればメソッド呼出し後に遅延実行できる
    • （個人的考察）やはりマニアックな話は興味深い

まとめ

今回はTerraform・AWS CDKに関してキャッチアップすることができました。直近でAWS CDKのコントリビュートもチャレンジしてみたので、今後キャッチアップしていきたいと思いました。

また、Terraformに関してもプロジェクトで利用しているので、まだまだキャッチアップしていきたいと思いました！！

最後まで記事をお読みいただきありがとうございました！！