wan0ri Lab

AWS IaCナレッジ共有LT会 参加メモ【イベント感想】

· wan0ri· Category: Event

TL;DR

  • 2025 年 12 月 5 日（金）開催の「【アジアクエスト × シスラボ】現場で活きる！AWS IaC ナレッジ共有 LT 会」を視聴。
  • 個人的ハイライトは「③IaC Analyzer」「④Amazon Connect × GUI と IaC の両立」。現場での“人と運用を巻き込む IaC”の解像度が上がった。
  • ①CDK は開発体験の良さと組織スケールのバランス設計が肝。② サーバレスは境界設計（責務分割）と観測性の IaC 化が要点。
  • 直近アクション：既存 Terraform/CFN へ静的検査を組み込み、GUI 変更 →IaC 反映の小さな実験を回す。

参加イベント

2025 年 12 月 5 日（金）開催の「【アジアクエスト × シスラボ】現場で活きる！AWS IaC ナレッジ共有 LT 会」を視聴しました。
以下のページで案内されています。

connpass
【アジアクエスト×シスラボ】現場で活きる！AWS IaCナレッジ共有LT会 (2025/12/05 19:00〜)

### イベント概要 アジアクエスト クラウドインテグレーション部は、AWS、Azure、Google Cloudを中心にマルチクラウドを軸としたインフラ事業支援を展開しています。 現在、オフラインで出向かずとも、どこでも勉強/知識向上ができる環境が整ってきました。 私達 …

asiaquest.connpass.com/event/376064/

免責

本記事は当時のイベント視聴に基づく私的メモであり、登壇資料の直接引用・転載は行っていません。

当日のアジェンダ

  • ①LT1 使って感じた CDK のリアル
  • ②LT2 AWS サーバレスにおける IaC の活用
  • ③LT3 IaC Analyzer で始める Well-Architected なインフラづくり
  • ④LT4 Amazon Connect で考える GUI と IaC の両立

視聴メモ

①LT1 使って感じた CDK のリアル

  • 良かった点：型安全（TypeScript）とコンストラクト再利用で“実装 → 標準化”の循環を回しやすい。小さく始めて段階的に抽象化できる。
  • つまずきがちな点：
    • bootstrap 周りの権限とアセット公開（S3/ECR）を正しく設計しないと多環境で詰まりがち。
    • 命令的ロジックを詰め込みすぎるとテンプレートの可読性が低下（CloudFormation の diff が追いづらい）。
    • チーム内でコンストラクトの抽象度が揃わないと、拡張しづらい“島”ができる。
  • 運用のコツ：
    • cdk synth の成果物（CFN）をレビュー対象に入れる。CI で cdk diff を必ず回す。
    • 共有コンストラクトに既定（タグ/暗号化/ログ保持）を強制するラッパーを用意。
    • 併用前提の判断基準を明文化（例：ガバナンス強い基盤は Terraform、アプリチームは CDK）。
  • 所感：個人/小規模では “速さ” が圧倒的メリット。組織スケールでは“テンプレートの見える化”とガードレール設計が先に必要。

②LT2 AWS サーバレスにおける IaC の活用

  • PDF で掲載されていたサーバーレスのサービス（Lambda， DynamoDB， Step Functions）を、実務扱ったことが無かったため新鮮な気持ちで臨めることが出来た
  • 本項では CloudFormation で半自動化する手法を紹介されていたが、Terraform でさらなる自動化を推進できるのではと感じた。
  • 境界設計が最重要（関数の責務、Step Functions での“オーケストレーション vs コレオグラフィ”）。
  • 観測性は最初から IaC に同梱（ログ保持期間、分散トレーシング、メトリクス/ダッシュボード）。後付けは高コストになりやすい。
  • 権限は最小化をテンプレ化（Lambda 毎の IAM ポリシー、DynamoDB の条件付き権限、S3 バケット暗号化/ブロック Public）。
  • デプロイ単位は“変更頻度”基準で分割（テーブルと関数のライフサイクルを切り離す）。
  • ツール選定の指針：CloudFormation/SAM（ネイティブ連携）、CDK（開発速度/抽象化）、Terraform（マルチアカウント一元管理）。
  • 所感：まずは PoC で“1 フロー + 1 DB + 監視”の最小構成を IaC 化し、運用の痛みを早めに洗い出すのが良さそう。

③LT3 IaC Analyzer で始める Well-Architected なインフラづくり

  • AWS Well-Architected フレームワークに関する紹介（AWS SAA でも出題される）
      1. セキュリティ
      1. 信頼性
      1. パフォーマンス効率
      1. コスト最適化
      1. 運用上の優秀性
      1. サステナビリティ（持続可能性）
  • 私も存じ上げなかった IaC Analyzer の説明があった
    • 対応コードは Terraform, CloudFormation, CDK
  • 参考になりそうな資料を探してみたところ、以下がヒットした
GitHub
GitHub - aws-samples/well-architected-iac-analyzer: Sample Generative AI tool for evaluating Infrastructure as Code and architecture diagrams against AWS Well-Architected best practices.

Sample Generative AI tool for evaluating Infrastructure as Code and architecture diagrams against AWS Well-Architected best practices. - …

github.com/aws-samples/well-architected-iac-analyzer?utm_source=chatgpt.com
qiita.com
AWS Well-Architected IaC Analyzer による BLEAテンプレート の自動レビュー結果を検証する - Qiita

AWS 上でワークロードを構築する際には AWS Well-Architected フレームワーク を利用してベストプラクティスに沿った対応ができているかレビューを実施し、改善ポイントを洗い出して対応します。 ただし、レビューするための準備には時間を要するため、部分的にでも...

qiita.com/Masayuki-Goto/items/198f744d2d547ccb0493?utm_source=chatgpt.com
docs.aws.amazon.com
docs.aws.amazon.com
docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/best-practices-cdk-typescript-iac.pdf?utm_source=chatgpt.com
Spacelift
How to Use AWS for Infrastructure as Code (IaC)

Learn how to implement Infrastructure as Code on AWS with different IaC tools - CloudFormation, AWS CDK, Terraform and Pulumi.

spacelift.io/blog/aws-infrastructure-as-code?utm_source=chatgpt.com

④LT4 Amazon Connect で考える GUI と IaC の両立

  • Amazon Connect の概要紹介
  • 本サービスは GUI が前提のサービスで、JSON ベースでの開発が困難である旨も併せて紹介あり。
  • Amazon Connect の GUI と IaC の両立方法として、以下課題と解決策、実践例の紹介あり。
    • 課題 ①：GUI と IaC の環境同期問題
      • IaC を利用して環境を作成しても GUI 経由で更新してしまうと、IaC 側と環境の同期が外れてしまう。
      • 解決 ①：GUI 運用を IaC に取り戻す
        • GUI で作られた設定を AWS API 経由で取得し、CloudFormation に取り戻す。
        • GUI での開発の容易さと、IaC での統一された管理両方を実現させる。
      • 実践 ①：AWS API で構成をコード化する
        • GUI で作ったコンタクトフローを、AWS SDK/CLI で JSON として取得し、CloudFormation テンプレートに組み込める形へ変換する。
    • 課題 ②：手動 IaC 化の限界
      • 一度 GUI を元に環境に反映させてから IaC に落としこまなければいけない。もし手動で IaC 化を行うと環境と資産に差異が生じてしまう可能性がある。
        • 資産の更新忘れ
        • 環境更新から資産更新までのラグ
      • 解決 ②：CloudTrail AWS アカウント内の API アクティビティを監視し、記録するためのツール で自動化
        • GUI 操作を CloudTrail で検知し、IaC 更新を自動化することで GUI とコードの動機を保つ
      • 実践 ②：GUI 変更を IaC に自動反映
        • GUI で設定を変更したら、そのイベントを CloudTrail が検知
        • 変更内容を Lambda が取得し、Git リポジトリへ反映する
  • 他サービスにも、同じ仕組みで応用可能との紹介あり。（EC2 など）

後に試してみたいこと （自分向け）

（コピペ可）
[ ] IaC Analyzer を既存リポジトリに適用し、W-A 観点の検知結果を CI に出す - 対象：`infra/terraform` と `cfn/` - 成果物：PR コメントでの違反一覧、修正ガイドの雛形

[ ] CDK パイプライン雛形を用意（`cdk synth/diff/deploy` + セキュリティ検査） - 共有コンストラクトに既定（暗号化/タグ/ログ保持）を強制するラッパーを作成

[ ] GUI 変更 → IaC 自動反映のミニ PoC（Amazon Connect 以外でも可） - 例：EventBridge + CloudTrail で検知 → Lambda で差分抽出 → GitHub PR 作成

[ ] サーバレス最小構成の IaC（Lambda + DynamoDB + Step Functions） - 観測性（ログ保持 365d、X-Ray、ダッシュボード）をテンプレ化 - 権限はリソースレベルで最小化、デプロイ単位は関数/DB を分離

[ ] 既存環境のドリフト検出を定期実行 - CloudFormation Drift / Terraform Plan（`-detailed-exitcode`）を週次ジョブ化

[ ] “テンプレートを見るレビュー”の運用整備 - `cdk synth` 産物 or `terraform show -json` を Artifact 化してレビューに添付

まとめ（現時点の所感）

  • ③ と ④ が特に刺さった理由は、「IaC をコードだけで完結させない」という視点が明確だったから。GUI の使いやすさ・人のオペレーション・既存文化を前提にしつつ、最終的な“単一の真実”を IaC に戻す発想は、自分の現場にも適用できる。
  • 一方で ①② の示唆から、スピードだけでなく“見える化”と“ガードレール”が同じくらい重要だと再認識。まずは小さな自動化と検査の導入から始め、成果物（テンプレート）をレビュー対象にする運用へ寄せていく。
  • イベント資料はアンケート回答者向け配布のため、本記事では引用・添付なし。自分用の補助資料として参照しつつ、公開範囲は守っていく。
Topへ戻る