AWS Infrastructure ComposerビジュアルIaC入門〜本番運用 Vol1

1. この記事について

1-1. 本記事のゴール

AWS Infrastructure Composerは、ビジュアルキャンバス上でAWSリソースをドラッグ＆ドロップしながらCloudFormation/SAMテンプレートを自動生成できるツールです。本記事ではその基本操作から、VS Code Toolkit統合によるローカルGitワークフロー連携、AI生成IaC活用、さらにCI/CDパイプラインへのテンプレート投入まで、本番運用に必要な一連のプロセスを体系的に解説します。

読み終えた段階で、次の成果が得られます。

• Infrastructure Composerのビジュアルキャンバスでリソース設計からテンプレート生成まで完結できる
• Amazon Q Developer連携によるAI生成IaCを実務に取り込み、設計スピードを向上できる
• 生成テンプレートをCodePipeline/GitHub ActionsのCI/CDパイプラインへ組み込んで継続デプロイができる
• Terraform/CDK/CloudFormation直接編集との使い分け基準を自分のプロジェクトに当てはめられる
• 既存IaC資産との共存パターンを理解し、段階的な移行戦略を立てられる

本記事はVol1として、Infrastructure Composerの概要・基本操作・VS Code統合・AI生成IaC・CI/CD投入・既存IaC資産との共存まで、本番運用の入口から実践レベルまでをカバーします。

1-2. 読者像

本記事は以下のような方を主な読者として想定しています。

IaC学習コストに悩むチーム・個人

CloudFormationやTerraformのYAML/HCL記法を習得するまでの壁に直面しており、「まずアーキテクチャを視覚的に設計してからコードを確認したい」というニーズがある方です。
Infrastructure Composerはキャンバス操作でテンプレートのひな型を生成できるため、IaC入門の障壁を大幅に下げられます。

アーキテクチャ図とテンプレートの乖離に悩む運用者

設計段階のダイアグラムと実際のIaCコードが別管理になっており、変更のたびに二重メンテナンスが発生している現場向けです。
Infrastructure Composerはキャンバスとテンプレートの双方向同期によって、設計図とコードを常に一致させます。

CloudFormation入門者・テンプレート可読性向上を図りたい開発者

既存の大規模CloudFormationテンプレートを読み解くのが難しく、視覚的に構造を把握したい方や、チームで共有しやすいテンプレートの標準化を進めたい方にも有用です。

前提知識として、AWSコンソールの基本操作とCloudFormationの概念（スタック・リソース・テンプレートの関係）を理解していることを想定しています。TerraformやCDKの知識は不要ですが、IaCの概念（インフラをコードで定義・管理する考え方）は押さえておくとスムーズに読み進められます。

Infrastructure Composerはグラフィカルな操作が中心のため、コマンドライン操作の熟練度は問いません。ただし、CI/CDパイプラインへの投入（§6）やVS Code統合（§4）を活用する場合は、基本的なターミナル操作と git コマンドの知識があると作業がスムーズです。

1-3. IaC設計の課題とInfrastructure Composerの登場背景

IaC（Infrastructure as Code）は現代のクラウド運用に欠かせない手法です。しかし、実務での普及に際してはいくつかの課題が繰り返し指摘されてきました。

テンプレート可読性の低さ

CloudFormationのYAMLテンプレートは数百〜数千行規模になることがあります。リソース間の依存関係や権限設定をコードだけで追うのは認知負荷が高く、レビュー品質も下がりやすい傾向があります。
DependsOn や !Sub / !Ref の参照チェーンを追うだけで相当な時間を要することも珍しくありません。

チーム間の標準化困難

インフラの命名規則やモジュール設計はチームによってまちまちになりがちです。テキストベースのテンプレート管理では設計意図を伝えるのが難しく、新メンバーのオンボーディングにも時間がかかります。
アーキテクチャの「なぜそうなっているか」を伝えるためには、テンプレートとは別に設計ドキュメントや構成図を用意する必要がありました。

ビジュアル化の欠如

アーキテクチャの全体像を把握するには、テンプレートを読み解いた後に別途図を描く必要がありました。設計変更のたびに図とコードを手動で同期させる作業は誤りの温床であり、「コードは最新だが図は古い」という状況が多くの現場で慢性的に発生していました。

こうした課題に対応するため、AWSは2022年12月にAWS Application Composerをプレビューとして公開しました。その後2023年3月にGA（一般公開）となり、2024年10月4日にはインフラ全般への焦点シフトを示す名称変更としてAWS Infrastructure Composerへ改称しました。改称に伴い対応リソースが拡張され、現在はCloudFormationがサポートする1,000超のリソースタイプすべてをビジュアルキャンバスで扱えます。

料金は追加課金なし（デプロイしたAWSリソースのみ課金）で、全商用リージョンおよびGovCloud（US）で利用できます。AWSコンソール、CloudFormationコンソール、Lambdaコンソール、VS Code拡張機能の4経路からアクセス可能です。

1-4. コード記述IaCとの使い分けナビ

Infrastructure Composerと既存のコード記述IaC手法は競合せず、役割が異なります。下表を参考に用途を選択してください。

Infrastructure Composerが特に力を発揮するのは次のシーンです。

• プロトタイピング・アーキテクチャ検討: 素早くリソース構成をキャンバス上で試行錯誤し、構成が固まったらテンプレートを出力します
• チームへの設計共有・説明: キャンバスを画面共有または共有URLで表示することで、非エンジニアも含めた設計レビューが可能です
• CloudFormation入門・学習: ビジュアル操作でリソースを追加しながら生成されるYAMLを見ることでCloudFormationの構造を体得できます
• 既存テンプレートの可視化: 手書きのYAMLをインポートしてキャンバスで表示することで、複雑な構成を把握しやすくなります

本記事はビジュアル設計層の入門〜本番運用を扱います。TerraformやCDKを用いたコード記述層については関連記事をご参照ください。

一方、次のような用途にはInfrastructure Composerは不向きです。選択の際は正直に評価してください。

• 大規模マルチスタック管理・モジュール設計: TerraformのモジュールやCDKのコンストラクトライブラリが適しています
• カスタムロジックを伴うインフラ生成: プログラミング言語の条件分岐・ループが必要な場合はCDKが向いています
• 既存TerraformコードのCloudFormation移行: Composerは移行ツールではなく設計ツールです

1-5. 本記事の構成と読み進め方

本記事は全8章で構成されています。最初から通読することも、興味のある章から始めることもできますが、Infrastructure Composerを初めて使う場合は§2〜§3を先に読んでおくと、以降の章がスムーズに理解できます。

初めてInfrastructure Composerを使う方へ: §2からキャンバスの基本操作を体験し、§3でリソース設計の勘所を掴んでから、§4のVS Code統合に進むと学習効率が高まります。

既存のIaC担当者・チームリーダーへ: §1の使い分けナビ→§6のCI/CD投入→§7の既存資産との共存パターンという順序で読むと、導入判断に必要な情報を素早く把握できます。

開発チームメンバーへ: §4のVS Code統合とGitワークフロー、§5のAI生成IaC機能から読み始めると、日常の開発作業にすぐ組み込める知識を先に得られます。

2. Infrastructure Composer基礎 — ビジュアルキャンバスと双方向テンプレート同期

2-1. Infrastructure Composerとは・Application Composer改称経緯

AWS Infrastructure Composer (以下、Infrastructure Composer) は、AWSリソースの設計をビジュアルキャンバス上で行い、CloudFormation/SAMテンプレートを自動生成するマネージドサービスです。ドラッグ&ドロップによる直感的な操作でアーキテクチャを設計でき、IaC (Infrastructure as Code) の学習コストを大幅に低減します。

誕生から現在までの歴史

Infrastructure Composerは以下の段階を経て現在に至ります。

• 2022年12月1日: AWS Application Composerとしてプレビュー公開。主にサーバーレスアーキテクチャ (Lambda・API Gateway・DynamoDB) を対象としたビジュアル設計ツールとして登場しました。
• 2023年3月7日: GA (Generally Available) として正式リリース。パブリックプレビュー期間中のフィードバックを反映し、安定性と対応リソース範囲が強化されました。
• 2024年10月4日: AWS Infrastructure Composerに改称。対象リソースを任意のCloudFormationリソース (1,000超のリソースタイプ) に拡大し、サーバーレス特化から「インフラ全般」をカバーするビジュアルIaCツールへと進化しました。

改称の背景

当初の「Application Composer」という名称は、Lambdaを中心としたサーバーレスアプリケーションの設計に特化していた時代を反映しています。その後、EC2・VPC・RDS・ECS・EKSなど従来型インフラリソースへの対応が拡大し、CloudFormation registryを通じたサードパーティリソースにも対応するようになりました。この範囲拡大に合わせ、「Infrastructure Composer」という名称がより実態を正確に表すとして採用されました。

「インフラ全般をビジュアルで設計できる」というコンセプトは、従来のCloudFormation Designerの後継として位置づけられ、より直感的で高機能なIaC設計体験を提供しています。

ドキュメントURLについての注意点

公式ドキュメントのURLには現在も application-composer という文字列が含まれています。これはURLの変更がサービス改称後も保留されているためです。ブックマーク管理や検索時に混乱しやすい点なので、URLにかかわらず製品名はAWS Infrastructure Composerと覚えておきましょう。

2-2. ビジュアルキャンバスの基本操作

Infrastructure Composerのキャンバスは、左側のリソースパレット・中央のキャンバスエリア・右側のプロパティパネルで構成されています。それぞれの機能を理解することで、素早く正確なアーキテクチャ設計が可能になります。

カード (リソース) の種類と配置

リソースはキャンバス上に「カード」として表示されます。左側のパレットからカードをドラッグ&ドロップするか、パレット内の検索ボックスでリソース名を検索して配置します。配置したカードはキャンバス上で自由に移動できます。

カードには2種類あります (§3で詳述)。

• standard resource card: CloudFormationがサポートする1,000超のリソースタイプを網羅する汎用カードです。プロパティパネルでYAML形式のプロパティを直接編集します。設定の柔軟性が高い反面、UI上での入力補助は最小限です。
• enhanced component card: Lambda・API Gateway・DynamoDB・SQS・SNS・S3・EventBridgeなど、特定のAWSサービスに特化した入力フォームを持つカードです。ドロップダウンやチェックボックスなどのGUI要素でプロパティを設定でき、初学者でも直感的に操作できます。2024年10月時点で13種類の拡張コンポーネントが提供されています。

どちらのカードも最終的にはCloudFormation/SAMテンプレートのリソース定義として出力されます。プロトタイプ段階では enhanced component card を優先し、細かなプロパティ調整が必要な場面では standard resource card に切り替える使い方が効率的です。

コネクタ (接続) による関係定義

カード間をコネクタで接続することで、リソース間の関係を定義します。例えば、Lambdaカードから DynamoDBカードにコネクタを引くと、LambdaのIAMロールにDynamoDB読み書き権限ポリシーが自動生成されます。イベントソース (SQS→Lambda、EventBridge→Lambda) のコネクタも同様に、接続するだけでイベントソースマッピングが自動設定されます。手動でYAMLを記述する手間を大幅に省けます。

プロパティパネル

カードを選択すると右側にプロパティパネルが開きます。enhanced component cardの場合はフォーム形式、standard resource cardの場合はYAML/JSONエディタ形式でプロパティを編集できます。変更はリアルタイムでキャンバスとテンプレートの両方へ即座に反映されます。

Change Inspector (変更インスペクター)

Change Inspectorは、キャンバス上での操作がテンプレートにどのような変更を加えるかをリアルタイムで表示する機能です。カードを追加・削除・コネクタ接続するたびに、追加・変更・削除されるプロパティが差分表示されるため、意図しない変更を事前に確認できます。設計ミスの早期発見に役立ちます。

その他の主要操作

• undo/redo: Ctrl+Z / Ctrl+Shift+Z (Windows) または Command+Z / Command+Shift+Z (Mac) で操作を取り消し・やり直しできます。
• グループ化: 複数のカードを選択してグループ化し、論理的な単位 (ネットワーク層・アプリ層など) で管理できます。複雑なアーキテクチャを整理するのに有効です。
• キャンバスエクスポート: キャンバス上のアーキテクチャをPNG画像としてエクスポートできます。アーキテクチャ図のドキュメンテーション作成やチームへの共有資料として活用できます。
• フィット表示: ツールバーの「Fit to view」ボタンでキャンバス全体を画面に収めて表示できます。リソース数が多い複雑なアーキテクチャでも全体像を俯瞰できます。
• ズームイン/アウト: マウスホイールまたはツールバーのズームコントロールでキャンバスのズームレベルを調整できます。詳細確認と全体確認を素早く切り替えられます。

2-3. 双方向テンプレート同期

Infrastructure Composerの中核をなす機能が「双方向テンプレート同期」です。キャンバスとCloudFormation/SAMテンプレートは常にリアルタイムで同期されており、どちらを編集しても即座に他方へ反映されます。

キャンバス → テンプレート方向

キャンバス上でカードを配置・接続・プロパティ設定すると、画面右側のテンプレートエディタにCloudFormationまたはSAM形式のYAMLが自動生成されます。生成されたテンプレートはそのままCloudFormation/SAMで利用できる有効なIaCコードです。手動でYAMLを一から記述する必要がなく、設計とコードを同時に作成できます。

テンプレート → キャンバス方向 (インポート)

既存のCloudFormation/SAMテンプレートをInfrastructure Composerにインポートすると、テンプレートの定義内容がキャンバス上にビジュアル化されます。インポートは以下の方法で行えます。

• コンソールからアップロード: ローカルのYAML/JSONファイルをドラッグ&ドロップまたはファイル選択でアップロードします。
• S3からロード: S3バケットに保存したテンプレートをS3 URIで指定してインポートします。
• CloudFormationスタックからのインポート: 既存スタックのテンプレートを直接読み込み、現状のアーキテクチャをキャンバス上に可視化します。

インポート時の注意点として、すべてのリソースが完全にビジュアル化されるわけではありません。Conditions / Mappings / Fn::If を多用した複雑な条件分岐構造や、対応外リソースタイプは一部省略される場合があります。詳細は§8の詰まりポイントで解説します。

テンプレートエディタでの直接編集

コンソール画面の右半分にはテンプレートエディタが表示されており、YAML/JSONを直接編集できます。テンプレートを直接編集すると、その変更がリアルタイムでキャンバスに反映されます。例えば、テンプレートエディタにYAMLブロックを追加すると、対応するカードがキャンバスに自動的に出現します。キャンバス操作とテキスト編集を状況に応じて使い分けながら効率的に設計できます。

エクスポート形式

設計したテンプレートは以下の形式でエクスポートできます。

• CloudFormation YAML: 標準のCloudFormationテンプレート形式。aws cloudformation deploy コマンドでそのままデプロイできます。
• SAM YAML: AWS SAM (Serverless Application Model) テンプレート形式。Transform: AWS::Serverless-2016-10-31 を含み、sam deploy コマンドでデプロイできます。
• ローカルファイルへのダウンロード: テンプレートをYAMLファイルとしてダウンロードしてGit管理できます。
• S3へのアップロード: S3バケットへ直接保存し、CloudFormationパイプラインへの連携に活用できます。

2-4. 利用経路 (コンソール / CloudFormationコンソールモード / Lambdaコンソール / VS Code)

Infrastructure Composerには4つの利用経路があります。目的と開発環境に応じて使い分けましょう。

1. Infrastructure Composerコンソール (独立した専用UI)

AWSマネジメントコンソールからInfrastructure Composerを検索するか、Infrastructure Composerのサービスページから直接アクセスできる専用UIです。キャンバスとテンプレートエディタが並列表示されており、Infrastructure Composerの全機能をフルに活用できます。新規アーキテクチャの設計・プロトタイピング・学習に最も適した利用形態です。

2. CloudFormationコンソール内モード (2024年3月28日追加)

CloudFormationコンソールの「Designer」機能が廃止され、その後継として組み込まれたモードです。CloudFormationコンソールのスタック作成・更新フローの中でInfrastructure Composerを呼び出せます。既存のCloudFormation運用フローへ組み込みたい場合に便利です。CloudFormation Designerからの移行もこのモードから自然に行えます。

3. Lambdaコンソールからのimport

Lambda関数の設定画面から、その関数が関係するリソース群をInfrastructure Composerキャンバスにインポートできます。既存のLambda関数を中心としたサーバーレスアーキテクチャを素早く可視化したい場合に有効です。Lambda関数に紐づくAPI Gateway・DynamoDB・SQSなどのリソースがキャンバス上に自動配置されます。運用中のサーバーレスアーキテクチャのドキュメンテーション作成に活用できます。

4. VS Code Toolkit (ローカルモード)

AWS Toolkit for VS Code拡張機能を通じてInfrastructure Composerをローカル環境で利用できます。2023年11月30日にリリースされたこの機能は、ローカルのCloudFormation/SAMテンプレートファイルを編集しながら、VS Code内のパネルでキャンバス表示を確認できる「ローカルモード」を提供します。Gitワークフローへの統合が自然に行え、チーム開発での活用に最適です。詳細は§4で解説します。

利用経路の使い分けガイド

2-5. 料金・リージョン

料金

Infrastructure Composer自体の利用に追加料金はかかりません。キャンバスで設計してテンプレートを生成するだけであれば完全無料です。課金が発生するのは、生成したテンプレートをデプロイして実際にAWSリソースを起動した場合のみです。各リソース (Lambda・DynamoDB・EC2など) は通常通りのAWS料金が適用されます。設計・プロトタイピング・学習の段階では費用を心配せず使い倒せます。

対応リージョン

Infrastructure Composerは全商用リージョンおよびAWS GovCloud (US) でご利用いただけます。ただし、リージョンによってサポートされるリソースタイプは異なる場合があります。特定のリージョンでのみ利用可能なAWSサービスについては、そのリージョンのInfrastructure Composerからのみ設計・デプロイできます。東京リージョン (ap-northeast-1) を含む主要リージョンでは全機能が利用可能です。

Infrastructure Composerが提供する価値のまとめ

§2で学んだInfrastructure Composerの基礎を整理します。

• IaC学習コストの低減: YAMLを直接書かずともビジュアル操作でCloudFormationテンプレートを生成できます。IaCの入門段階でも取り組みやすい環境です。
• 既存テンプレートの可視化: 長年運用してきた複雑なCloudFormationテンプレートをインポートし、アーキテクチャ図として可視化することで、ドキュメントとしての活用も可能です。
• ビジュアルとコードの同期: キャンバスとテンプレートが常にリアルタイム同期されており、「図を描いてコードを書く」という従来の分断を解消します。
• 段階的な移行: 既存のCloudFormation運用フローに自然に統合でき、チームへの導入障壁が低いです。
• 追加コストゼロ: Composer自体は無償で、デプロイしたリソース分のみ課金されます。プロトタイプを気軽に試せる環境です。

2-6. よくある初期設定ミスと確認ポイント

Infrastructure Composerを初めて使用する際に遭遇しやすい設定ミスと、その確認ポイントを整理します。

AWSリージョンの確認

Infrastructure Composerはリージョンごとに独立しています。意図したリージョンで作業しているかをコンソール右上のリージョン表示で必ず確認してください。東京リージョン (ap-northeast-1) で設計したテンプレートを別リージョンにデプロイする場合は、リソースのARNや設定値にリージョン依存の記述がないかを確認します。

IAMアクセス権限の確認

Infrastructure Composerコンソールへのアクセスには、最低限以下のIAMアクションが必要です。

• cloudformation:*
• s3:GetObject (S3からテンプレートをロードする場合)
• lambda:GetFunction (Lambdaコンソールからインポートする場合)

権限不足でキャンバスが正常に動作しない場合は、IAMポリシーを確認します。AWSマネジメントコンソールの「最終アクセス日時」機能を使って、どのアクションが実際に使用されているかを確認するのも有効です。

テンプレートの文字コードと改行コード

テンプレートYAMLのファイルエンコーディングはUTF-8を使用します。Windowsで作成したファイルはCRLF改行になることもあり、一部のYAMLパーサーで不具合につながります。VS Codeのステータスバーで改行コードを確認し、必要に応じてLFに変換します。

サポートされるテンプレートバージョン

Infrastructure ComposerはAWSTemplateFormatVersion ‘2010-09-09’ のCloudFormationテンプレートをサポートします。古いバージョンのテンプレートの動作は保証されない場合があります。また、SAMテンプレートの場合は Transform: AWS::Serverless-2016-10-31 の記述が必要です。

コンソールのブラウザ互換性

Infrastructure Composerコンソールは最新版のChrome・Firefox・Safariで動作します。古いブラウザや企業プロキシ環境ではキャンバスの描画が正常に行われない場合があります。問題が発生した場合はブラウザのキャッシュをクリアするか、別のブラウザで試してみましょう。

ローカルファイルの保存タイミング

VS Code Toolkitのローカルモードでは、キャンバスの変更がローカルファイルへ自動保存されます。ただし、保存のタイミングはリアルタイムではなく、操作から数秒後の場合があります。Gitコミット前に必ずファイルを保存済みであることを確認します (Ctrl+S での明示的保存も有効です)。

Infrastructure ComposerとCloudFormation Designerとの移行

以前のCloudFormation Designerで作成したDraw.io形式のビジュアルは、Infrastructure Composerには直接インポートできません。Infrastructure Composerへ移行するには、既存のテンプレートYAMLをインポートして再ビジュアル化する必要があります。テンプレートYAMLは引き続き使用できるため、デプロイフローへの影響はありません。

複数リージョンへのデプロイ戦略

グローバルに展開するサービスでは、複数リージョンに同一のアーキテクチャをデプロイする必要があります。Infrastructure Composerで設計したテンプレートは、aws cloudformation deploy --region <region> コマンドでリージョンを指定するだけで任意のリージョンにデプロイできます。ただし、リソースのAMI ID・Secrets Manager ARN・S3バケット名などリージョン固有の値はパラメータ化しておくことが重要です。CloudFormationパラメータ (Parameters セクション) を活用して環境差分を吸収する設計を取り入れましょう。

CloudFormation StackSetsを活用すると、単一の操作で複数リージョン・複数アカウントへの一括デプロイが可能です。Infrastructure Composerで設計したテンプレートをStackSetsと組み合わせることで、グローバルインフラの一元管理を実現できます。
StackSets設定はInfrastructure Composerのテンプレートとは別に定義しますが、デプロイ対象のテンプレートとして生成済みのYAMLをそのまま指定できます。

3. リソース設計 — 1,000超のCloudFormationリソース対応とIAM権限自動生成

3-1. standard resource card と enhanced component card の違い

Infrastructure Composerのキャンバスには、2種類のカードが存在します。まずその違いを整理しておくと、以降の設計作業がスムーズになります。

standard resource card は、CloudFormationがサポートするリソース型を1対1で表現するカードです。AWS::Lambda::Function や AWS::S3::Bucket など、CloudFormationのリソース型と完全に対応しており、設定パネルから各プロパティを直接編集できます。キャンバスに配置したカードは、そのままCloudFormationテンプレートの Resources セクションに反映されます。

enhanced component card は、よく使われるアーキテクチャパターンを高レベルで抽象化したカードです。たとえば「Lambda Function」の enhanced component を配置すると、Lambda関数本体に加えて実行ロール（IAMロール）と関連するログ出力設定（CloudWatch Logs）が内部でセットとして展開されます。個別リソースを一つひとつ配置する手間を省き、ベストプラクティスに沿った構成をワンクリックで配置できます。

2つのカード種別の使い分けの基本方針は次のとおりです。

• プロトタイプや初回設計段階では enhanced component card を優先し、定型パターンを素早く配置します。
• 細かなプロパティ調整や既存テンプレートとの整合が必要な場面では standard resource card に切り替えて、個別のリソース型を直接操作します。
• enhanced component card で配置したリソースは、その後 standard resource card として個別編集も可能です。

3-2. 1,000超のCloudFormationリソースをキャンバスへ配置する

standard resource card の最大の特徴は、CloudFormationがサポートする1,000超のリソース型すべてに対応している点です。S3やLambdaといったメジャーサービスだけでなく、AWS::AppSync::GraphQLApi や AWS::Glue::Job、AWS::Macie::FindingsFilter など、AWSの各サービスの詳細なリソース型もキャンバスに配置できます。

配置手順は次のとおりです。

1. キャンバス左側の Resource palette を開きます。
2. 検索ボックスにリソース型名またはサービス名を入力します（例: DynamoDB, AppSync, Glue）。
3. 一覧から目的のリソース型を選択してキャンバスにドラッグ&ドロップします。
4. 配置後、カードをクリックすると右側に Resource properties パネルが表示されます。

Resource properties パネルでは、CloudFormationのスキーマに基づいて各プロパティが入力フィールドとして表示されます。必須プロパティは明示的にマークされており、設定漏れをビジュアルで確認できます。また、入力値はリアルタイムでテンプレートコードに反映されるため、設定内容が正しいかどうかをテンプレートビューで即座に確認できます。

リソース型の検索と絞り込み

Resource palette の検索は部分一致に対応しています。AWS::EC2:: と入力すれば EC2 ファミリーのリソース一覧が表示され、必要なものを素早く見つけられます。サービス名（例: Lambda, RDS, ECS）での検索も有効です。

3-3. CloudFormation registry 拡張リソースの扱い

CloudFormation registry は、AWSが管理するリソース型に加えて、サードパーティが提供するリソース型（third-party resource type）、モジュール（module）、フック（hooks）を登録・管理する仕組みです。

Infrastructure Composer では、registry で activate 済みのリソース型を standard resource card として記述できます。たとえば、MongoDB Atlas や Datadog など、AWSパートナーが公開しているリソース型を registry で有効化した状態であれば、それらをキャンバスに配置して設定できます。

注意点として、registry で activate していない拡張リソースはキャンバスに表示されません。事前にCloudFormation コンソールの registry から対象のリソース型を有効化しておく必要があります。また、拡張リソースのプロパティスキーマはリソース型ごとに異なるため、Resource properties パネルに表示される入力フィールドも異なります。

registry 拡張リソース利用時の注意点

• サードパーティリソース型によっては、activate に追加の認証情報設定を必要とする場合があります。
• registry 経由のリソースは CloudFormation による実行ロールとハンドラー処理を経由するため、デプロイ時間が AWS ネイティブリソースより長くなる場合があります。
• モジュール（module）は、複数リソースのテンプレート断片を再利用可能な形でパッケージ化したものです。Composer では、registry で activate 済みのモジュールを参照する形で記述できます。

3-4. コネクタによるリソース間連携

リソース間の関係性を定義するのが コネクタ です。コネクタは単なる視覚的な矢印ではなく、リソース間のイベント連携やデータフローを明示し、必要な設定（IAMポリシーなど）を自動生成する機能を持ちます。

コネクタの引き方は次のとおりです。

1. 接続元カード（例: S3バケット）にマウスオーバーすると、カードの縁にコネクタ開始点が表示されます。
2. コネクタ開始点をドラッグして接続先カード（例: Lambda関数）にドロップします。
3. Connect resources ダイアログが開き、接続タイプ（イベント通知、ポリシー付与など）を選択します。
4. 選択に応じて必要なプロパティ（通知設定、IAMポリシーなど）が自動生成されます。

一般的なコネクタ接続パターンを以下に示します。

コネクタを引くことで、手動でのIAMポリシー記述やイベント通知設定の記述が大幅に削減されます。

3-5. IAM権限自動生成の実態とレビュー方法

IAM権限自動生成はInfrastructure Composerの中でも特に実用的な機能です。コネクタを設定すると、そのリソース間連携に必要なIAMポリシーが 最小権限の原則 に基づいて自動生成されます。

自動生成の仕組み

たとえば Lambda関数からDynamoDBテーブルへのコネクタを引くと、Composerは次のような処理を行います。

1. 接続パターン（Lambda → DynamoDB 書き込み）を解析します。
2. 必要な権限のリスト（dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem など）を決定します。
3. Lambda関数の実行ロールに該当するIAMポリシー文書を生成し、CloudFormationテンプレートに追記します。
4. リソースARN（DynamoDBテーブルのARN）を対象リソースとして自動設定します。

生成されるポリシーはインラインポリシーとして実行ロールに付与される形式が一般的です。テンプレートビューで Properties.Policies を確認すると、具体的な権限セットを確認できます。

自動生成ポリシーのレビューとカスタマイズ

自動生成は便利ですが、そのまま本番環境に投入することは推奨しません。以下の観点でレビューしてください。

• 過剰権限の確認: 自動生成ポリシーが想定より広い権限を付与していないか確認します。読み取り専用のユースケースであれば PutItem/UpdateItem は不要なことがあります。
• リソーススコープの確認: Resource: "*" になっていないかを確認します。特定のテーブルやバケットに限定したARNが設定されているか検証します。
• 条件キーの追加: VPCエンドポイント経由のアクセスのみ許可するなど、条件キー（Condition）が必要な場合は手動で追記します。

カスタマイズはテンプレートビューを直接編集する形で行います。キャンバスとテンプレートは双方向同期しているため、テンプレートを編集した内容はキャンバス表示にも反映されます。ただし、自動生成したポリシーの一部を削除すると、次回コネクタ再設定時に上書きされる場合があるため、カスタマイズ後はコネクタの再操作を避けるかどうかをチームで決めておくことを推奨します。

3-6. 設定パネルでの高度な設定

Resource properties パネルでは、リソース固有の詳細プロパティを視覚的に設定できます。

Lambda関数の設定例

Lambda関数カードを選択すると、次のプロパティを設定パネルから操作できます。

• Runtime: Node.js 22.x / Python 3.13 / Java 21 などのランタイムを選択します。
• MemorySize: 128MB〜10,240MBの範囲をスライダーまたは数値入力で設定します。
• Timeout: 1秒〜900秒の範囲で設定します。
• Environment Variables: キーと値のペアを追加します。Systems Manager Parameter Store や Secrets Manager の参照形式（{{resolve:ssm:/path/to/param}}）も入力できます。
• Tags: コスト配分タグや運用管理タグを付与します。

テンプレートへの反映と確認

設定パネルで変更した内容は即座にテンプレートビューへ反映されます。右上の Template ボタンをクリックすると、YAML形式またはJSON形式のテンプレートが表示され、設定内容が正しく記述されているか確認できます。

複雑なプロパティ（ネストされたオブジェクト、配列形式のプロパティなど）はテンプレートビューを直接編集する方が効率的な場合もあります。キャンバスとテンプレートのどちらからでも編集できる双方向同期の特性を活用して、状況に応じて使い分けてください。

外部パラメータとの連携

CloudFormation Parametersを定義することで、環境（dev/stg/prod）ごとに異なる値を外部から注入できます。設定パネルの値フィールドに !Ref ParameterName や !Sub ${ParameterName}-suffix といったCloudFormation組み込み関数を記述することで、パラメータ参照を設定に組み込めます。

Composerはパラメータ参照を含む設定値もテンプレートに正しく書き出すため、テンプレートの可搬性と環境分離を維持したまま視覚的な設計が可能です。ただし、パラメータ定義自体（Parameters セクション）はテンプレートビューで直接記述する必要があります。

3-7. enhanced component cardの主要パターンと活用法

enhanced component cardは、ベストプラクティスに沿った構成をワンクリックで配置できる高レベルカードです。代表的なパターンを以下に示します。

enhanced component cardで配置したリソースは、設定パネルで基本プロパティを変更できます。さらに細かな設定が必要な場合はテンプレートビューで直接編集します。内部展開されたリソース間のコネクタはComposerが自動的に設定するため、IAMポリシーやイベント設定の手動記述が最小限に抑えられます。

enhanced componentとstandard cardの組み合わせ設計

実際の設計では、enhanced componentとstandard resource cardを組み合わせて使うことが多くなります。たとえば、API Gateway + Lambda の enhanced component を配置してバックエンドのたたき台を作り、その後 standard cardで AWS::DynamoDB::Table や AWS::ElastiCache::CacheCluster を追加してコネクタでつなぐ、という流れが典型的です。

この組み合わせにより、スピードと精度の両立が可能です。enhanced componentで全体像を素早く配置し、standard cardで必要なリソースを細かく追加・調整するという2段階設計が、Infrastructure Composerを使いこなす上での基本スタイルとなります。

Change Inspectorによる変更差分の確認

キャンバスで変更を加えると、Change Inspector パネルに差分が表示されます。どのリソースにどのプロパティが追加・変更・削除されたかが一目で確認できるため、意図しない変更を早期に発見できます。

特にコネクタを引いた際のIAMポリシー生成や、enhanced componentを配置した際の複数リソース展開では、Change InspectorでCloudFormationテンプレートへの影響を確認することを習慣づけることを推奨します。

4. VS Code Toolkit統合 — ローカルモードとGitワークフロー連携

4-1. AWS Toolkit for VS Code の概要とインストール

AWS Toolkit for VS Code は、VS Code からAWSサービスを直接操作できる公式拡張機能です。2023年11月30日のアップデートで Infrastructure Composer のビジュアルキャンバス機能が統合され、ローカル開発環境でそのまま Infrastructure Composer を利用できるようになりました。

インストール手順

VS Code の拡張機能マーケットプレイスから「AWS Toolkit」を検索してインストールします。

VS Code コマンドパレット (Ctrl+Shift+P / Cmd+Shift+P) から実行:
> Extensions: Install Extensions
> 検索: "AWS Toolkit"
> "AWS Toolkit" (Amazon Web Services 公式) をインストール

インストール後、VS Code を再起動するとサイドバーに「AWS Explorer」パネルが追加されます。AWSアカウントへのサインインには、IAM Identity Center (SSO) または IAM ユーザーの認証情報を使用します。

Infrastructure Composer機能の有効化

AWS Toolkit インストール後、CloudFormation または SAM テンプレートYAMLファイルを開くと、エディタ右上に「Open in Infrastructure Composer」ボタンが表示されます。このボタンをクリックするとビジュアルキャンバスが起動します。ファイルを右クリックして「Open with Infrastructure Composer」を選択する方法でも同様に起動できます。

テンプレートファイルの拡張子が .yaml または .json であり、かつ CloudFormation/SAM の形式であれば自動認識されます。AWS SAM CLI と組み合わせることで、ビジュアル設計からデプロイまでをVS Code上で完結させられます。

4-2. ローカルモード (local sync mode) の詳細

Infrastructure Composer を VS Code 上で使用するときの最大の特長は「ローカルモード (local sync mode)」です。コンソール版のInfrastructure Composerはブラウザ上でテンプレートを操作しますが、VS Code統合ではローカルのYAMLファイルをソースとして扱います。

ローカルファイルとキャンバスの双方向自動同期

ローカルモードでは、VS Code のファイルシステム上にある CloudFormation / SAM テンプレートYAML と、ビジュアルキャンバスが常に同期されます。同期の方向は双方向です。

• ファイルを保存すると、キャンバスが即時更新されます
• キャンバス上でリソースを追加・編集・削除すると、YAMLファイルが自動保存されます

この双方向同期により、手動でのコピー&ペーストが不要になります。テキストエディタでYAMLを手書き修正した内容が即座にキャンバスへ反映されるため、コード記述とビジュアル設計を状況に応じて使い分けられます。

コンソール版との主な違い

コンソール版はブラウザさえあれば即座に使えるため初学者向けですが、チーム開発や継続的なIaC管理には VS Code 統合のローカルモードが適しています。ローカルファイルがソースとなるため、クラウドストレージへの依存がなく、ネットワーク障害時でもファイル編集・キャンバス閲覧が可能です（デプロイのみオンライン必須）。

4-3. VS Code内でのキャンバス⇔エディタ切替

VS Code統合では、ビジュアルキャンバスとYAMLテキストエディタを同一ウィンドウ内で並列表示できます。

スプリットペイン表示

「Open in Infrastructure Composer」で開いたキャンバスをVS Code のタブとして扱い、元のYAMLエディタタブと並べて表示します。VS Code のドラッグ&ドロップでタブを左右に分割すると、左ペインにYAMLエディタ、右ペインにビジュアルキャンバスを同時表示できます。

[VS Code ウィンドウ — スプリットペイン構成]
┌─────────────────────┬─────────────────────┐
│  template.yaml│  Infrastructure  │
│  (テキストエディタ) │  Composer キャンバス │
│││
│  Resources:│  [Lambda]──[DDB] │
│ MyFunction:││  │
│Type: AWS::│  [API GW]  │
│...││
└─────────────────────┴─────────────────────┘

左側のYAMLを編集して保存すると、右側のキャンバスが即時更新されます。右側でリソースカードを移動・接続すると、左側のYAMLが自動的に書き換わります。

双方向即時反映の実用例

リソースのプロパティを細かく調整したいときはYAMLエディタで直接編集し、全体のアーキテクチャ構成を把握したいときはキャンバスを参照するという使い方が自然な流れです。コードとビジュアルのどちらが優先されるかではなく、常に同一ファイルを異なる視点で見ている状態になります。

キャンバス上でのリソース追加は右クリックメニューまたはリソースパネルからドラッグ&ドロップで行います。追加したリソースはYAMLへ即座に追記されます。既存テンプレートを開いた場合、キャンバスはYAMLを解析してリソースカードを自動配置します。

4-4. sam sync / sam deploy 統合

AWS Toolkit for VS Code は AWS SAM CLI との連携機能を内蔵しており、VS Code内から直接デプロイを実行できます。

「Deploy SAM Application」コマンド

キャンバスまたはSAMテンプレートYAMLを開いた状態で、コマンドパレットから「AWS: Deploy SAM Application」を実行します。初回実行時はウィザード形式でデプロイ設定を入力します。

設定項目:

• デプロイ先リージョン
• スタック名
• S3バケット（SAMパッケージの格納先）
• パラメータオーバーライド（任意）
• デプロイ確認フラグ

設定後、VS Code の出力ペインに sam deploy の進行ログが表示されます。デプロイ完了後はCloudFormationスタックの出力値（Outputs）も出力ペインに表示されます。

sam sync によるホットスワップデプロイ

sam sync コマンドは、CloudFormationスタック全体を再デプロイするのではなく、変更されたリソースのみを高速に更新する仕組みです。Lambda関数コードやAPI Gatewayの設定変更に対して、スタックの全更新なしに直接リソースを更新するホットスワップ（hot swap）を活用します。

# 通常デプロイ (スタック全更新・変更量によっては数分かかる)
sam deploy

# ホットスワップデプロイ (Lambda/API GWなど対象リソースのみ即時更新)
sam sync --stack-name my-stack --watch

VS Code Toolkit の「AWS: Sync SAM Application」コマンドからも sam sync を起動できます。--watch オプションを付けると、ローカルファイルの変更を監視して自動的に再同期します。開発中のイテレーション速度が大幅に向上します。

デプロイ先設定の管理 (samconfig.toml)

複数環境（dev/stg/prod）を扱う場合は、samconfig.toml に環境ごとの設定を記述します。VS Code からデプロイ実行時に samconfig.toml が存在すれば設定を読み込むため、毎回ウィザードを入力せずに済みます。

[default.deploy.parameters]
stack_name = "my-app-dev"
region = "ap-northeast-1"
s3_bucket = "my-sam-artifacts-dev"

[prod.deploy.parameters]
stack_name = "my-app-prod"
region = "ap-northeast-1"
s3_bucket = "my-sam-artifacts-prod"

環境を切り替えてデプロイする場合は --config-env prod を付けることで [prod.*] ブロックの設定を使用できます。

4-5. Gitワークフロー連携

ローカルモードの最大の利点は、CloudFormation/SAMテンプレートYAMLをそのままGitリポジトリで管理できる点です。コンソール版のようにエクスポート操作が不要で、ファイルが常にローカルに存在します。

ローカルファイルのGit管理

テンプレートYAMLは通常のテキストファイルとして存在するため、git add → git commit → git push の標準ワークフローで管理します。Infrastructure Composerが生成・更新するのはあくまでYAMLファイルであり、独自フォーマットはありません。

# テンプレートを変更後の典型的な操作
git add template.yaml
git commit -m "feat: Lambda関数にDynamoDB読み取り権限を追加"
git push origin feature/add-dynamodb-policy

キャンバスで行った変更はローカルファイルへ即座に保存されるため、git diff でキャンバス上の変更内容をテキストとして確認できます。レビュアーがInfrastructure Composerを持っていなくても、標準のYAML差分としてレビューできます。

Pull Requestでのテンプレートレビューフロー

チーム開発では、テンプレートYAMLをPRとして提出することが推奨されます。レビュアーはYAMLのコード差分に加えて、Infrastructure Composerのキャンバスでアーキテクチャ全体像を視覚的に確認できます。

典型的なPRレビューフロー:

1. 開発者がVS CodeでキャンバスまたはYAMLを編集
2. 変更をコミットしてPRを作成
3. レビュアーがブランチをチェックアウトし、VS Code でキャンバスを開いて変更点を確認
4. YAMLのコードレビューとキャンバスの構成確認を並行実施
5. 承認後にマージ → CI/CDが自動デプロイ

YAMLの差分だけではリソース間の接続関係が把握しづらい場合でも、キャンバスを開くことで追加・変更されたリソースのつながりを視覚的に確認できます。この可視化がレビューの品質向上につながります。

ブランチ戦略との組み合わせ

Infrastructure Composer はローカルファイルを直接編集するため、機能ブランチ（feature branch）やGitFlowとの相性が良好です。本番環境向けのテンプレートは main ブランチ、開発中の変更は feature/* ブランチで管理し、PRマージをトリガーにCI/CDを起動するパターンが定石です。

4-6. チーム開発でのユースケース例

VS Code統合とGitワークフローを組み合わせた、チーム開発における実践的な活用フローを示します。

フロー概要

① 設計者がキャンバスで構成設計
 ↓
② YAMLがローカルに自動保存
 ↓
③ git push → PR作成
 ↓
④ チームがYAML+キャンバスでレビュー
 ↓
⑤ 承認・マージ → CI/CDが自動デプロイ

各ステップの詳細

① 設計フェーズ

設計者がVS Codeを開き、template.yaml を新規作成またはブランチチェックアウト後に「Open in Infrastructure Composer」でキャンバスを起動します。リソースカードをドラッグ&ドロップで配置し、コネクタで接続します。このとき自動生成されたIAMポリシーをプロパティパネルで確認・調整します。

② ローカル保存とバージョン管理

キャンバス操作のたびにYAMLが自動保存されるため、作業中断・再開が容易です。こまめにコミットしておくと、キャンバス上の誤操作を git checkout で即座に戻せます。

③ PRレビューの効率化

レビュアーは git diff のYAML差分に加えて、キャンバスを開いてリソース接続の変更点を視覚的に確認できます。新たに追加されたリソース間の接続関係や、削除されたリソースをキャンバス上で直感的に把握できます。

④ CI/CD連携

GitHub Actions または AWS CodePipeline と組み合わせることで、main ブランチへのマージをトリガーに sam deploy を自動実行します。Infrastructure Composerが生成するのは標準のCloudFormation/SAMテンプレートであるため、既存のCI/CDパイプラインをそのまま利用できます。追加のビルドステップや専用ランナーは不要です。

# GitHub Actions の例 (.github/workflows/deploy.yml 抜粋)
- name: SAM Deploy
  run: |
 sam deploy \
--stack-name my-app-prod \
--region ap-northeast-1 \
--s3-bucket ${{ secrets.SAM_ARTIFACTS_BUCKET }} \
--no-confirm-changeset \
--no-fail-on-empty-changeset

ポイント整理

• Infrastructure Composerが出力するのは標準のCloudFormation/SAM YAMLであり、プラットフォーム固有のメタデータはありません
• VS Code 上でのキャンバス操作がすべてローカルファイルへ反映されるため、設計→コードレビュー→デプロイのサイクルを単一ツールチェーンで回せます
• Amazon Q Developer（§5で詳述）はVS Code Toolkit統合時のみ利用可能なため、AI支援でリソース設定を生成したい場合はVS Code環境が必須です

5. AI生成IaCとチーム協調・標準化

5-1. Amazon Q Developer統合 — VS Code Toolkit内でのAI支援IaC

Amazon Q DeveloperはAWS Toolkit for VS Codeに統合されたAIコーディングアシスタントです。Infrastructure Composerとの統合により、CloudFormationリソースのプロパティ値をAIが自動提案する機能を利用できます。

重要な制限: この機能はVS Code Toolkit内のInfrastructure Composerでのみ利用可能です。AWSマネジメントコンソールのInfrastructure Composer（コンソール版）には搭載されていません。AI生成IaC機能を活用したい場合は、必ずVS Code Toolkitからキャンバスを開いてください。

2023年11月30日、AWS Toolkit for VS Codeにローカルモードが導入されたタイミングで、Amazon Q Developer（当時はAmazon CodeWhisperer名義）との統合も実装されました。現在はAmazon Q Developerとして統合・強化されており、正式なGA機能として利用できます。

Amazon Q DeveloperはAWSのAIアシスタントで、コード補完・コード生成・セキュリティスキャン・ドキュメント生成などの機能を提供します。Infrastructure Composerとの統合においては、CloudFormationリソースのプロパティ値生成に特化した用途で活用します。

5-2. Generate suggestions機能の使い方

「Generate suggestions」機能は、standard resource cardおよびstandard component cardのResource propertiesパネルから起動します。以下の手順で利用します。

手順1: VS CodeからInfrastructure Composerを起動する

AWS Toolkitのサイドバーから「Infrastructure Composer」を選択し、対象のCloudFormationテンプレートファイル（template.yamlなど）を開きます。キャンバスが表示されたら、リソース設計を開始してください。

手順2: standard resource cardをキャンバスに配置する

左側のリソースパネルからAWSリソースを検索し、キャンバスにドラッグ&ドロップします。enhanced componentではなく、standard resource cardを選択してください。enhanced componentはあらかじめ設定が最適化されたコンポーネントのため、Generate suggestions機能の主な対象はstandard resource cardになります。

手順3: Resource propertiesパネルを開く

キャンバス上のカードをクリックし、右側に表示されるResource propertiesパネルを確認します。パネル内に「Generate suggestions」ボタンが表示されていることを確認してください。

手順4: Generate suggestionsをクリックする

「Generate suggestions」ボタンをクリックすると、Amazon Q Developerがそのリソースタイプに応じたCloudFormationスキーマを参照し、プロパティ値の候補を生成します。生成には数秒かかる場合があります。

手順5: 提案内容を確認・採択・拒否する

Amazon Q Developerが生成した提案は、Resource propertiesパネル内に表示されます。各プロパティについて個別に採択（Accept）または拒否（Reject）を選択できます。採択したプロパティはテンプレートYAMLへ即座に反映されます。拒否した場合は変更されません。

5-3. Amazon Q認証の設定

Generate suggestions機能を利用するには、Amazon Q Developerの認証が必要です。未認証の状態では「Generate suggestions」ボタンが表示されない、または非活性化されます。

認証方法: IAM Identity Center（旧AWS SSO）経由

1. VS Codeのコマンドパレット（Cmd+Shift+P）を開く
2. 「AWS: Connect to AWS」を実行する
3. 「IAM Identity Center（Recommended）」を選択する
4. 組織のSSO URLを入力し、ブラウザで認証を完了する

IAM Identity Centerでの認証後、Amazon Q Developer無料枠または有料プランの範囲でGenerate suggestions機能を利用できます。無料枠では月間のコード生成回数に制限がある点に注意してください。

IAMユーザーの長期認証情報（アクセスキー）でもAWS Toolkitへの接続は可能ですが、Amazon Q DeveloperのAI生成機能にはIAM Identity Center認証が推奨されています。セキュリティ上の観点からも、長期アクセスキーの使用は避け、IAM Identity Center経由の短期認証情報を利用してください。

5-4. Console-to-Codeとの違い

Amazon Q DeveloperにはConsole-to-Codeという別機能があります。Infrastructure ComposerのGenerate suggestions機能と混同しやすいため、違いを明確にしておきます。

Console-to-Codeは「コンソールで行った操作をCloudFormationテンプレートへ変換したい」というユースケースに対応します。一方、Generate suggestionsは「既にキャンバスに配置したリソースのプロパティ値をAIに提案してもらいたい」というユースケースに対応します。両機能は補完的な関係にあり、状況に応じて使い分けてください。

5-5. AI提案の限界と注意点

Generate suggestions機能は強力なアシスタントですが、いくつかの制限と注意点があります。

スキーマ準拠と業務ロジックの分離

Amazon Q DeveloperはCloudFormationのJSONスキーマを参照してプロパティ値を提案します。型の正確性や必須項目の充足といった点ではスキーマ準拠の提案が生成されます。しかし、業務固有の要件（セキュリティポリシー・ネットワーク設計・命名規則など）はスキーマには含まれていないため、AIが適切に判断できません。生成された提案は必ず人間がレビューし、業務要件を反映させてください。

セキュリティ設定は必ず人間が確認する

IAMポリシーのResource指定、S3バケットのPublicAccessBlock設定、セキュリティグループのインバウンドルールなど、セキュリティに関わるプロパティはAIの提案を採用する前に必ず手動で確認してください。AIはサンプルとして機能する値を提案する場合があり、本番環境向けのセキュリティ設定としては不十分な場合があります。

リージョン依存リソースへの対応

一部のCloudFormationリソースはリージョンによって利用可能なプロパティ値が異なります。Generate suggestionsはリージョンを考慮した提案を必ずしも生成しない場合があります。デプロイ先リージョンの制約をYAMLへ反映させるため、提案内容をcfn-lintなどのツールで検証することを推奨します。

反復利用による精度向上

Generate suggestionsの出力はコンテキスト（テンプレート内の他リソース設定）を参照して生成されます。関連リソースをキャンバスに配置・接続してからGenerate suggestionsを実行すると、より整合性の取れた提案を得られる場合があります。

5-6. テンプレート標準化の実践

Infrastructure Composerで設計したテンプレートをチーム共有の標準資産として活用する方法を説明します。

enhanced componentによる社内標準テンプレートの作成

enhanced componentは既存のCloudFormation/SAMテンプレートをキャンバスコンポーネントとして登録し、チーム内で再利用できる仕組みです。組織のセキュリティ要件（暗号化設定・タグ付けポリシー・ログ設定など）をあらかじめ組み込んだテンプレートをenhanced componentとして定義し、全チームが共有できる標準コンポーネントライブラリを構築できます。

enhanced componentの作成手順：

1. 標準化するリソース設定をCloudFormationテンプレートとして記述する
2. VS Code Toolkit内のInfrastructure ComposerでそのテンプレートをenhancedComponent設定として登録する
3. キャンバスで利用可能なコンポーネントとして表示されることを確認する
4. S3バケットまたはGitリポジトリにテンプレートファイルを配置し、チームで共有する

AWS CloudFormation Guard（cfn-guard）との組み合わせ

cfn-guardはポリシーをコードとして記述しCloudFormationテンプレートへ適用できるツールです。Infrastructure Composerで設計したテンプレートをCI/CDパイプラインへ投入する前にcfn-guardのルールセットで自動検証することで、セキュリティ・コンプライアンス要件からの逸脱を早期に検出できます。

# cfn-guard ルール例: S3バケットの暗号化必須
rule s3_bucket_encryption_required {
  AWS::S3::Bucket {
 Properties.BucketEncryption EXISTS
 Properties.BucketEncryption.ServerSideEncryptionConfiguration[*].ServerSideEncryptionByDefault.SSEAlgorithm IN ["aws:kms", "AES256"]
  }
}

このルールをCIパイプラインに組み込むことで、すべてのInfrastructure Composer生成テンプレートが暗号化設定を含んでいることを自動的に保証できます。

5-7. チームレビューのワークフロー

Infrastructure Composerのビジュアルキャンバスは、IaC専門家と非専門家が協働するレビュープロセスを大幅に改善します。

設計者からレビュアーへのキャンバス共有

従来のIaCレビューでは、レビュアーがYAMLコードを読んでアーキテクチャを理解する必要がありました。Infrastructure Composerを使うと、設計者はキャンバスのスクリーンショットまたはテンプレートファイルをレビュアーに共有できます。レビュアーは自分のVS Codeでそのテンプレートを開くと、キャンバス上でビジュアルなアーキテクチャ図を確認しながら同時にYAMLも確認できます。

非IaC専門家によるアーキテクチャレビュー

セキュリティチーム・コンプライアンスチーム・アーキテクチャレビューボードなど、IaC記述に詳しくないメンバーでも、キャンバス上のリソース接続図を見ることで、ネットワーク境界・リソース間の権限関係・データフローを直感的に理解できます。これにより、YAMLの読解コストなしにアーキテクチャレベルの意見を出しやすくなります。

PRレビューとの統合

GitリポジトリにCloudFormationテンプレートをコミットし、Pull Requestでレビューする際にテンプレートのdiffと合わせてキャンバスのスクリーンショットをPRに添付するワークフローが効果的です。変更前後のアーキテクチャを視覚的に比較でき、レビュー品質が向上します。

5-8. 再利用パターンとテンプレートライブラリ化

共通アーキテクチャパターンをテンプレートライブラリとして管理し、プロジェクト間で再利用する手法を説明します。

共通パターンのテンプレートライブラリ化

組織内で頻繁に利用するアーキテクチャパターン（例: VPC + Public/Private Subnet + NAT Gateway + Security Group、API Gateway + Lambda + DynamoDB、S3 + CloudFront + WAF）を標準テンプレートとしてGitリポジトリで管理します。新規プロジェクト開始時にこれらのテンプレートをベースとして使用することで、設計の一貫性を保ちつつ開発速度を向上できます。

テンプレートライブラリのディレクトリ構成例：

templates/
├── networking/
│├── vpc-standard.yaml
│└── vpc-with-nat.yaml
├── compute/
│├── lambda-api.yaml
│└── ecs-fargate.yaml
└── storage/
 ├── s3-static-site.yaml
 └── rds-aurora.yaml

AWS Service Catalogとの連携

AWS Service Catalogを使用すると、承認済みのInfrastructure Composerテンプレートをカタログ製品として登録し、開発チームがセルフサービスでデプロイできる仕組みを構築できます。インフラ管理チームが標準テンプレートをService Catalogに登録し、開発チームはService Catalogから製品を選択してデプロイするだけという運用が可能になります。Infrastructure Composerで設計した標準テンプレートをService Catalog製品の定義として活用することで、ビジュアル設計の成果物を直接セルフサービスプラットフォームに展開できます。

5-9. 組織全体への展開とオンボーディング活用

IaC習熟度の低いチームへの導入ファーストステップ

CloudFormationやCDKのYAML/TypeScript記述に慣れていない開発チームへのIaC導入において、Infrastructure Composerのビジュアルキャンバスは学習曲線を大幅に下げる効果があります。まずキャンバス操作でアーキテクチャを設計し、生成されたYAMLを読んでCloudFormationの構造を理解するという順序で学習を進めることで、コード記述IaCへの移行もスムーズになります。

トレーニング・オンボーディングでの活用

新メンバーのオンボーディング研修においてInfrastructure Composerを使用することで、以下の効果が得られます。

• AWSアーキテクチャの概念をビジュアルで理解させやすい
• CloudFormationテンプレートの構造（Resources・Properties・Ref・!Sub等）をビジュアルと対応させて教えられる
• Generate suggestionsでAIが生成したプロパティ値を見ることでCloudFormationスキーマへの理解が深まる
• 既存システムのテンプレートをキャンバスで可視化し、オンボーディング資料として活用できる

導入ロードマップの例

このロードマップに沿って段階的に導入することで、チーム全体のIaC活用レベルを無理なく底上げできます。

6. CI/CD統合・運用・制約

6-1. 生成テンプレートのCI/CDパイプライン投入フロー

Infrastructure Composerが出力するCloudFormation/SAMテンプレートは、標準的なYAMLファイルです。専用のビルドツールや変換ステップは不要であり、既存のCI/CDパイプラインにそのまま投入できます。ここでは代表的な2つのパターン（AWS CodePipeline/CodeBuild連携とGitHub Actions連携）を解説します。

CodePipeline/CodeBuild連携パターン

以下の流れで、Infrastructure Composerで設計したSAMテンプレートをAWSネイティブのCI/CDパイプラインへ組み込みます。

[Composer] → template.yaml → [git push] → [CodeCommit/S3] → [CodePipeline]
 ↓
  [CodeBuild: sam build]
 ↓
  [CodeBuild: sam deploy]
 ↓
  [CloudFormation スタック更新]

CodeBuildのビルドスペック例（buildspec.yml）：

version: 0.2
phases:
  install:
 runtime-versions:
python: 3.13
 commands:
- pip install aws-sam-cli
  build:
 commands:
- sam build --template template.yaml
  post_build:
 commands:
- sam deploy
 --stack-name my-app-prod
 --region ap-northeast-1
 --s3-bucket $SAM_ARTIFACTS_BUCKET
 --no-confirm-changeset
 --no-fail-on-empty-changeset
 --capabilities CAPABILITY_IAM CAPABILITY_AUTO_EXPAND

CodePipelineは以下のステージ構成が基本です。

sam deploy --no-confirm-changeset を付けることで、変更セットの手動承認なしに自動デプロイが進みます。本番環境では --no-confirm-changeset を外し、変更セットを手動承認するステージを挟む運用も検討してください。

GitHub Actions連携パターン

VS Code Toolkitのローカルモードで編集したテンプレートをGitリポジトリで管理し、GitHub Actionsでデプロイする構成です。

name: Deploy Infrastructure

on:
  push:
 branches: [main]
 paths:
- 'infra/template.yaml'
- 'src/**'

jobs:
  deploy:
 runs-on: ubuntu-latest
 permissions:
id-token: write
contents: read
 steps:
- uses: actions/checkout@v4

- name: Configure AWS Credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
 role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
 aws-region: ap-northeast-1

- name: Setup SAM CLI
  uses: aws-actions/setup-sam@v2

- name: SAM Build
  run: sam build --template infra/template.yaml

- name: SAM Deploy
  run: |
 sam deploy --stack-name my-app-prod --region ap-northeast-1 --s3-bucket ${{ secrets.SAM_ARTIFACTS_BUCKET }} --no-confirm-changeset --no-fail-on-empty-changeset --capabilities CAPABILITY_IAM CAPABILITY_AUTO_EXPAND

OIDCを使ったIAMロール引き受け（role-to-assume）を利用することで、長期アクセスキーをGitHubシークレットへ保存せずに済みます。これはセキュリティ上の推奨事項です。

6-2. sam deploy / sam sync の使い分け

Infrastructure Composerで生成したSAMテンプレートをデプロイする際、sam deploy と sam sync の2つのコマンドを使い分けます。

sam sync --watch オプションを使うと、ローカルファイルの変更を自動検出して即座に同期します。Lambda関数コードの変更はスタック全更新を経ずに直接デプロイされるため、デプロイ時間が数秒〜十数秒に短縮されます。

# 開発中: ファイル変更を監視して自動同期
sam sync --stack-name my-app-dev --watch

# 本番デプロイ: スタック全更新
sam deploy --config-env prod --no-confirm-changeset

sam sync は開発環境のみに使用し、本番デプロイは必ず sam deploy を使うことを推奨します。ホットスワップはCloudFormationの変更セット管理を経ないため、ドリフト検出と整合しない場合があります。

6-3. ドリフト検出とスタック運用

Infrastructure Composerで設計したテンプレートからデプロイしたCloudFormationスタックは、コンソールや他ツールでリソースを手動変更するとドリフトが発生します。

ドリフト検出の実行

# ドリフト検出を開始
aws cloudformation detect-stack-drift --stack-name my-app-prod

# 結果の確認 (数秒〜数十秒後)
aws cloudformation describe-stack-drift-detection-status--stack-drift-detection-id <detection-id>

# リソースごとのドリフト詳細
aws cloudformation describe-stack-resource-drifts--stack-name my-app-prod--stack-resource-drift-filter-statuses MODIFIED DELETED

ドリフトが検出された場合の対処方法は2つです。

1. テンプレートに反映: コンソールで行った変更をInfrastructure ComposerまたはYAMLで記述し、テンプレートを更新してデプロイします（Infrastructure as Codeの原則に従った対処）。
2. 手動変更を元に戻す: sam deploy で最新のテンプレートを再デプロイして、スタックをテンプレート定義の状態に戻します。

Infrastructure Composerで管理するテンプレートはGitで管理されているため、「テンプレートに反映する」対処がトレーサビリティの観点から推奨されます。

運用のベストプラクティス

• コンソール手動操作を禁止するSCP設定: AWS Organizationsを使用している場合、Service Control Policy（SCP）でCloudFormationスタック管理対象リソースへの直接変更を禁止することで、ドリフト発生を防止できます。
• 定期的なドリフト検出の自動化: EventBridgeルールとLambdaを使って、毎日ドリフト検出を実行し結果をSlack通知するパターンが実用的です。
• スタックポリシーの設定: 重要リソース（RDSインスタンス、S3バケットなど）への意図しない変更を防ぐため、スタックポリシーで更新を制限します。

6-4. Infrastructure Composerの制約・非対応事項

Infrastructure Composerを本番運用へ採用する前に、以下の制約と非対応事項を把握しておくことが重要です。

出力フォーマットの制約

Infrastructure Composerが出力できるのはCloudFormation/SAMテンプレート（YAML/JSON）のみです。以下のフォーマットへの直接変換は非対応です。

• Terraform HCL: Infrastructure Composerの出力をTerraformコードに自動変換する機能は存在しません。Terraformで管理したい場合は、ComposerのYAMLを参考にTerraformコードを手書きする必要があります。
• AWS CDK（TypeScript/Python/Java）: CDKのコンストラクトコードを生成する機能はありません。CDKプロジェクトへの移行は、ComposerのYAMLをCDKの CfnInclude で取り込む段階移行パターン（§7参照）を活用してください。
• Pulumi / Ansible / Chef / Puppet: これらのツール向けフォーマットへの変換機能はありません。

テンプレート可視化の限界

既存の複雑なCloudFormationテンプレートをインポートしてキャンバスで可視化する際、以下のケースでキャンバス表示が不完全になることがあります。

• ネストスタック（AWS::CloudFormation::Stack）を多用した構成
• !If / !FindInMap / !Select などの複雑な条件・マッピング関数を含む設定
• Composerがプロパティマッピングを持たないリソース型のプロパティ

これらのリソースはテンプレートビューで確認できますが、キャンバス上では「不明なプロパティ」として表示されるか、リソースカードとして配置されない場合があります。

ビジュアルキャンバスでの設計制限

• カスタムリソース（AWS::CloudFormation::CustomResource）のキャンバス設計: カスタムリソースはキャンバス上のカードとして配置できますが、カスタムロジック（Lambda関数内の処理）自体はビジュアル設計の対象外です。
• CloudFormation Macros: Macroを使ったテンプレート変換はキャンバスでプレビューできません。
• SAM特有のグローバル設定（Globalsセクション）: キャンバス上では個別リソースのプロパティとして表示されるため、Globalsの一括設定効果が視覚化されません。

Amazon Q Developer（Generate suggestions）の制限

• VS Code Toolkitのみ対応: コンソール版のInfrastructure ComposerではGenerate suggestions機能は利用できません。
• スキーマ準拠のみ保証: 生成されるプロパティ値はCloudFormationのJSONスキーマに準拠しますが、組織固有のセキュリティ要件・命名規則・タグ付けポリシーは反映されません。必ず人間がレビューしてください。

6-5. コストと料金体系

Infrastructure Composer自体の利用料金は無料です。追加コストが発生するのは以下の場合のみです。

Amazon Q Developerの料金

• 無料枠（Individual Free Tier）: 月間のコード生成・チャット利用に制限あり（AWSアカウントに付随）
• Q Developer Pro（月額$19/ユーザー）: 無制限利用・エンタープライズ機能・セキュリティスキャン強化

Generate suggestions機能のみであれば無料枠で十分なケースが多いですが、チーム全体で積極的に活用する場合はQ Developer Proを検討してください。

6-6. 運用ベストプラクティス

バージョン管理（テンプレートファイルのGit管理）

Infrastructure ComposerのVS Code統合（ローカルモード）では、テンプレートファイルがローカルディスクに直接保存されます。このファイルを必ずGitリポジトリで管理してください。コンソール版でテンプレートを変更した場合も、変更内容をYAMLとしてエクスポートしGitにコミットする習慣を徹底します。

チームレビューフロー

1. 設計者: VS CodeでComposerのキャンバスを使って設計し、YAMLをfeatureブランチにコミット
2. レビュアー: キャンバス+YAMLのdiffでアーキテクチャとプロパティを確認
3. cfn-guard/cfn-lint検証: CI/CDパイプラインでポリシー適合と文法チェックを自動実行
4. 承認・マージ: PRマージ後にCI/CDが自動デプロイ

テンプレート標準化

組織共通のセキュリティ設定（暗号化・タグ・ログ出力）をenhanced componentとしてライブラリ化し、全プロジェクトで再利用します。Infrastructure Composerで設計したテンプレートをAWS Service Catalogに登録することで、承認済みの標準構成をセルフサービスで展開できるようになります。

インフラ変更の記録

sam deploy の --no-confirm-changeset フラグは自動化に便利ですが、変更セットの内容をCloudWatchログやCI/CDのビルドログに記録しておくことを推奨します。CloudFormationのスタックイベントはマネジメントコンソールやCLIで後から確認できますが、デプロイ日時・担当者・変更内容のトレーサビリティはGitのコミット履歴と合わせて管理します。

7. 実戦統合パターン — 既存IaC資産との共存

7-1. ビジュアル設計→CloudFormation/CDK/Terraformへの橋渡しパターン

Infrastructure Composerで作成したテンプレートを、どのようにチームの既存IaCワークフローに組み込むか。これが本番運用での核心的な問いです。Composerが出力するのはCloudFormation/SAMテンプレートのYAML形式であり、TerraformのHCLやCDKのTypeScript/Pythonコードに直接変換する機能は持ちません。しかし、ツールの特性を理解した上で役割を明確に分担すれば、既存のIaC資産と無理なく共存できます。

パターン1: Composerでプロトタイプ設計→CloudFormationテンプレート出力→チームレビュー

最もシンプルな橋渡しパターンです。設計フェーズではComposerのビジュアルキャンバスを使い、アーキテクチャの全体像を素早く作成します。プロトタイプが固まったら、生成されたCloudFormation/SAMテンプレートをGitリポジトリにコミットし、通常のPRレビュープロセスに乗せます。

このパターンのメリットは、非エンジニア（アーキテクト、プロダクトマネージャーなど）がキャンバスを使ってアーキテクチャの意図を視覚的に共有できる点です。レビュアーはキャンバス表示でリソース構成を確認し、詳細なプロパティはテンプレートファイルで確認するという役割分担が自然に生まれます。

# Composerが出力するSAMテンプレートの例（一部抜粋）
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  OrderProcessor:
 Type: AWS::Serverless::Function
 Properties:
Runtime: python3.13
Handler: app.handler
MemorySize: 512
Timeout: 30
Policies:
  - DynamoDBCrudPolicy:
TableName: !Ref OrderTable
  OrderTable:
 Type: AWS::DynamoDB::Table
 Properties:
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
  - AttributeName: orderId
 AttributeType: S
KeySchema:
  - AttributeName: orderId
 KeyType: HASH

パターン2: ComposerのSAMテンプレート→CDKへの段階移行

CDKを採用しているチームでは、ComposerのSAMテンプレートをCDKのL1コンストラクト経由でインポートする段階的移行が有効です。

CfnInclude を使うと、既存のCloudFormation/SAMテンプレートをCDKスタックの一部として取り込めます。

import { CfnInclude } from 'aws-cdk-lib/cloudformation-include';

const composerTemplate = new CfnInclude(this, 'ComposerTemplate', {
  templateFile: 'composer-output.yaml',
});

// Composerテンプレートのリソースを参照
const orderTable = composerTemplate.getResource('OrderTable') as dynamodb.CfnTable;

このアプローチにより、チームはComposerで設計した構成をCDKコードとして徐々に書き直す移行期間を設けつつ、デプロイパイプラインをCDKに統一できます。完全移行が完了したら、CfnInclude の参照を外してネイティブのL2コンストラクトに置き換えます。

パターン3: Composerを「設計・可視化ツール」として位置づけ、Terraform/CDKと役割分担

TerraformやCDKを主軸とするチームでの推奨パターンです。Composerは「コードを書かずにアーキテクチャを設計・可視化するツール」と位置づけ、最終的な実装はTerraformまたはCDKで行うという役割分担を明示します。

具体的なフローは次のとおりです。

1. 設計フェーズ: Composerでアーキテクチャの全体像を設計し、スクリーンショットや共有URLをドキュメントに添付します。
2. 実装フェーズ: Composerのキャンバスを参照しながら、TerraformまたはCDKでコードを記述します。Composerが生成するYAMLはリソース型とプロパティの参考資料として活用します。
3. レビューフェーズ: Composerのキャンバス表示を使って設計意図を説明し、Terraform/CDKコードの正確性をレビューします。

このパターンでは、ComposerとTerraform/CDKを同じリソースに対して二重管理するリスクを避けられます。Composerはあくまで設計・説明ツールとして使い、デプロイはTerraform/CDKに一元化します。

7-2. 既存IaC資産との共存設計

既存CloudFormationスタックのインポートと可視化

既存のCloudFormationスタックをComposerで可視化することで、複雑な既存構成の理解とドキュメンテーションに活用できます。インポート手順は次のとおりです。

1. CloudFormationコンソールで対象のスタックを開きます。
2. Infrastructure Composer タブを選択します。
3. スタックのリソース構成がキャンバスに自動展開されます。

ただし、複雑なネスト構成（ネストスタック）や一部の組み込み関数（!If, !FindInMap）を多用したテンプレートは、キャンバスで一部が不可視化されることもあります。Composerがサポートしていないプロパティや関数参照を含むリソースは、キャンバス上で「不明なプロパティ」として表示されることがあります。この点を踏まえ、可視化の完全性を前提とせず、あくまで既存構成の概要把握として活用することを推奨します。

Terraform管理リソースとの共存

Terraformで管理されているリソースとComposer（CloudFormation）を混在させる場合の基本原則は、同一リソースを両方で管理しないことです。管理対象を明確に分離します。

推奨する分離パターンの例を示します。

Terraformで管理するVPC IDやサブネットIDをCloudFormationのParametersで受け取る形にすることで、両者の境界を明確にできます。CloudFormationテンプレートのParametersセクションに VpcId や SubnetIds を定義し、Terraformの aws_cloudformation_stack リソースの parameters で値を渡す構成が一般的です。

resource "aws_cloudformation_stack" "app" {
  name = "app-stack"
  template_body = file("${path.module}/composer-output.yaml")
  parameters = {
 VpcId  = aws_vpc.main.id
 SubnetIds = join(",", aws_subnet.private[*].id)
  }
  capabilities = ["CAPABILITY_IAM"]
}

チームの移行戦略: 新規はComposer、既存はTerraformで管理

段階的に移行する際の現実的な戦略として、新規リソースはComposerで設計してCloudFormationによりデプロイし、既存リソースはTerraformによる管理を継続するという並走期間を設けるアプローチがあります。

この戦略の利点は次のとおりです。

• 既存のTerraform資産を書き直すリスクとコストを負わずに新機能開発を進められます。
• 新規メンバーはComposerのビジュアルツールで学習コストを抑えてIaCに入門できます。
• 将来的にTerraformを全廃する判断をする際も、新規リソースがCloudFormationに揃っているため移行の見通しが立てやすくなります。

7-3. マルチリージョン/マルチアカウント設計での活用

AWS Organizations + StackSets連携での展開パターン

複数リージョンや複数アカウントへの展開が必要な場合、ComposerのテンプレートをCloudFormation StackSetsと組み合わせることで、効率的な展開が可能です。

設計の流れは次のとおりです。

1. Composerで共通インフラのベーステンプレートを設計します。
2. リージョンやアカウントごとに異なる値はParametersで外部化します。
3. 生成されたテンプレートをCloudFormation StackSetsのテンプレートとして使用します。
4. AWS Organizations の OU（組織単位）をターゲットに指定して一括デプロイします。

Composerによる設計の段階でParametersを適切に外部化しておくことが重要です。ハードコードされた値（特定のリージョン名やアカウントIDなど）が紛れ込まないよう、テンプレートビューで Parameters セクションを意識的に整備します。

環境（dev/stg/prod）別パラメータファイルとの組み合わせ

環境ごとに異なる設定を管理するには、Composerのテンプレートをベースにして、環境別パラメータファイル（parameters-dev.json, parameters-stg.json, parameters-prod.json）を用意するパターンが効果的です。

[
  { "ParameterKey": "Environment", "ParameterValue": "dev" },
  { "ParameterKey": "LambdaMemorySize", "ParameterValue": "256" },
  { "ParameterKey": "DynamoDBBillingMode", "ParameterValue": "PAY_PER_REQUEST" }
]

prod環境では同じテンプレートに対して別のパラメータファイルを適用します。

[
  { "ParameterKey": "Environment", "ParameterValue": "prod" },
  { "ParameterKey": "LambdaMemorySize", "ParameterValue": "1024" },
  { "ParameterKey": "DynamoDBBillingMode", "ParameterValue": "PROVISIONED" }
]

CI/CDパイプラインでデプロイ先環境に応じてパラメータファイルを切り替えることで、1つのComposerテンプレートから複数環境への展開を管理できます。

7-4. 小規模チームでの実践的導入パターン

設計→レビュー→デプロイのワークフロー

3〜5名の小規模チームでComposerを中心に据えた設計ワークフローの例を示します。

Week 1: 設計フェーズ

• アーキテクト/リードエンジニアがComposerでアーキテクチャのたたき台を作成します。
• Composerのキャンバスを画面共有しながらチームでレビューを実施します。コネクタで表現されたリソース間の関係性がビジュアルで確認できるため、議論が具体的になります。
• レビューフィードバックをキャンバスで即座に修正し、テンプレートに反映します。

Week 2: 実装フェーズ

• 確定したテンプレートをGitリポジトリにコミットします。
• 各エンジニアがLambdaコードなどのアプリケーション実装を並行して進めます。
• Composerのテンプレートとアプリケーションコードを合わせてPRレビューを実施します。

Week 3: デプロイフェーズ

• dev環境へのデプロイ（sam deploy --config-env dev）と動作確認を実施します。
• 問題があればComposerでテンプレートを修正し、変更をPRとして再提出します。
• stg/prod環境へのデプロイはCI/CDパイプラインを通じて実施します。

テンプレートのGit管理とComposerキャンバスの同期

Composerで設計したテンプレートをGit管理するにあたり、以下の運用ルールを推奨します。

• テンプレートファイルのGit管理: Composerが生成したYAMLファイルはソースコードとして扱い、必ずGitで管理します。キャンバスの状態はテンプレートファイルに集約されるため、ファイルさえあれば誰でもキャンバス表示を復元できます。
• 設計変更は必ずPR経由: キャンバスでの変更はテンプレートファイルの変更として現れます。main/masterブランチへの直接コミットを禁止し、必ずブランチ+PRのフローを経ます。
• PRの説明にキャンバスのスクリーンショットを添付: テキストだけのPR説明より、キャンバスのビフォー/アフターのスクリーンショットを添付することで、変更の意図が一目で伝わります。
• テンプレートファイルのパスをチームで統一: infra/template.yaml や cloudformation/main.yaml など、プロジェクト内でテンプレートファイルの配置場所を統一します。VS Code ローカルモードでの自動保存先と一致させるとシームレスに運用できます。

CI/CDへの組み込み

小規模チームでもGitHub Actions等でCI/CDを整備することを推奨します。最低限のパイプライン構成例を示します。

on:
  push:
 branches: [main]
 paths:
- 'infra/**'
- 'src/**'

jobs:
  deploy:
 runs-on: ubuntu-latest
 steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
  with:
 role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
 aws-region: ap-northeast-1
- name: SAM build and deploy
  run: |
 sam build
 sam deploy --config-env prod --no-confirm-changeset

Composerが生成するSAMテンプレートはそのまま sam build / sam deploy のインプットとして使用できます。アプリケーションコードの変更とインフラ変更を同一PRで管理し、同一パイプラインでデプロイする一貫したフローが実現できます。

8. 詰まりポイントとアンチパターン・まとめ

8-1. 詰まりポイント

詰まりポイント1: テンプレートインポート時に一部リソースが可視化されない

既存のCloudFormationテンプレートをインポートすると、一部のリソースが「Unsupported resource」として表示されるか、キャンバスに配置されない場合があります。

原因として以下が考えられます。

• AWS::CloudFormation::CustomResource や Custom::* などのカスタムリソースが対応外
• AWS::CloudFormation::WaitCondition など一部の特殊リソースタイプが未対応
• Conditions / Mappings / Fn::If を多用した複雑な条件分岐構造が一部省略される

解決策: 対応外リソースはテンプレートエディタで直接確認・編集します。キャンバスに表示されなくてもテンプレート自体は保持されており、デプロイには影響しません。可視化目的のドキュメンテーションには、対応リソースのみを含む小さなテンプレートに分割する方法も有効です。

詰まりポイント2: VS Code Toolkitのローカル同期が機能しない

VS Code Toolkit のInfrastructure Composerパネルを開いても、テンプレートファイルへの変更がキャンバスに反映されない場合があります。

原因:

• 対象ファイルが .yaml または .json 拡張子でない
• ファイルが CloudFormation/SAM の形式として認識されていない (AWSTemplateFormatVersion が欠如など)
• AWS Toolkitの拡張機能バージョンが古い

解決策: ファイルの先頭に AWSTemplateFormatVersion: '2010-09-09' を追加するか、SAMの場合は Transform: AWS::Serverless-2016-10-31 を記述します。拡張機能を最新バージョンにアップデートすることも有効です。

詰まりポイント3: 複雑な既存スタックのテンプレートでキャンバスが崩れる

大規模な既存スタック (50リソース以上) をインポートすると、カードが重なり合い、コネクタが交差して判読困難な表示になる場合があります。

解決策: インポート後にカードを手動で整理します。論理的なサービス層 (ネットワーク層・アプリケーション層・データ層) ごとにカードをグループ化し、縦または横に整列させると見やすくなります。また、Infrastructure Composerのキャンバスビューを「全体表示」から「部分表示」に切り替えて、注目リソースに絞って確認する方法も有効です。

詰まりポイント4: CloudFormationデプロイ後にキャンバスとの乖離が生じる

Infrastructure Composerでテンプレートを設計しCloudFormationでデプロイした後、AWSコンソールから直接リソースの設定を変更すると、テンプレート (Infrastructure Composerのキャンバス) と実際のリソース状態が乖離します (ドリフト)。

解決策: リソース設定の変更は必ずテンプレートを経由して行います。AWSコンソールからの直接変更はドリフトの原因となります。CloudFormationの「ドリフト検出」機能でズレを検知し、テンプレートに反映させる運用を徹底します。

詰まりポイント5: IAM権限自動生成のポリシーが過剰になる

コネクタ接続でIAM権限を自動生成すると、最小権限原則 (Least Privilege) に反した過剰な権限が付与されかねません。例えば、Lambda→DynamoDBのコネクタを接続すると、DynamoDB全アクションを許可する広範なポリシーが生成されることもあります。

解決策: 自動生成されたIAMポリシーは出発点として活用し、本番環境へのデプロイ前に必ず手動でレビューします。テンプレートエディタで該当のIAMポリシーブロックを確認し、実際に必要なアクション (dynamodb:GetItem・dynamodb:PutItemなど) のみに絞り込みます。

詰まりポイント6: Terraform / CDKのコードが出力できない

Infrastructure ComposerはCloudFormation/SAMテンプレートの生成に特化したツールです。TerraformのHCL形式やCDK (TypeScript/Python/Java) のコード出力には対応していません。

Terraform や CDK を使用したい場合は、Infrastructure Composerで設計したCloudFormationテンプレートを以下の方法で変換することが一般的です。

• CDK: cdk migrate コマンドを使用して既存のCloudFormationスタックからCDKコードを生成します。
• Terraform: コミュニティツールを使用してCloudFormationテンプレートからHCLに変換します (完全自動変換は難しく手作業が伴います)。

これらの変換作業はInfrastructure Composerの範囲外となります。プロジェクト開始時にIaCツールの選定を確定させておくことが重要です。

詰まりポイント7: SAMテンプレートでデプロイ時にバリデーションエラーが発生する

Infrastructure ComposerでSAMテンプレートとしてエクスポートしたファイルには、Transform: AWS::Serverless-2016-10-31 が付与されます。しかし、SAMトランスフォーム未対応のリソースタイプを含む場合、sam deploy 時にバリデーションエラーが発生します。

解決策: SAMテンプレートとしてエクスポートする場合は、SAMがネイティブサポートするリソース (AWS::Serverless::Function・AWS::Serverless::Api・AWS::Serverless::SimpleTableなど) を中心に設計します。VPC・EC2・RDSなど従来型インフラリソースが多い場合はCloudFormation形式でエクスポートする方が安全です。

詰まりポイント8: 大量のリソースを持つテンプレートのパフォーマンス問題

50リソースを超えるテンプレートをInfrastructure Composerに読み込むと、キャンバスの描画が遅くなったり、操作のレスポンスが低下したりする場合があります。特にコネクタ数が多い複雑なアーキテクチャでは顕著です。

解決策: テンプレートをネストされたスタック構成に分割して、各テンプレートを20〜30リソース程度に収めます。また、ブラウザのメモリを解放するためにタブを再読み込みしてから作業することも有効です。VS Code Toolkitのローカルモードでは、コンソール版より軽快に動作する場合があるので、パフォーマンス問題が発生した場合はVS Codeでの作業に切り替えることを検討してください。

8-2. アンチパターン → 正解

アンチパターン1: キャンバスとテンプレートを別々に管理する

❌ Infrastructure Composerでテンプレートを生成した後、テンプレートをGit管理しながらキャンバス設計をアドホックに更新する。その結果、Gitのテンプレートとキャンバスのビジュアルがずれてしまい、「どちらが最新か」がわからなくなる。

✅ テンプレートファイルを唯一の真実 (Single Source of Truth) として管理します。VS Code Toolkitのローカルモードを使用し、Gitコミット対象のテンプレートファイルとキャンバスを常に同期させます。テンプレートファイルをコミットする際はキャンバスでの最終確認を必ず実施します。

アンチパターン2: AWSコンソールからリソース設定を直接変更する

❌ Infrastructure Composerで設計しデプロイしたリソースの設定を、後からAWSマネジメントコンソールで直接変更する。例: Lambda関数のタイムアウトをコンソールから60秒に変更するが、テンプレートは3秒のまま放置する。

✅ リソース設定の変更はすべてテンプレート経由で行います。テンプレートを更新してから sam deploy を実行するか、CloudFormationスタックを更新します。コンソールからの直接変更はドリフトを生み、次のデプロイ時に設定が上書きされる事故の原因となります。

アンチパターン3: IAM自動生成ポリシーをそのまま本番に使う

❌ コネクタ接続で自動生成されたIAMポリシーをレビューせず本番環境にデプロイする。過剰な権限が付与された状態でサービスが稼働し、セキュリティリスクが残存する。

✅ 自動生成ポリシーはプロトタイプ用の出発点として活用します。テンプレートエディタで AWS::IAM::Policy や AWS::IAM::Role ブロックを開き、実際の利用パターンに合わせて最小権限へ絞り込みます。本番デプロイ前にIAMポリシーのレビューをチェックリスト化します。

アンチパターン4: Terraform/CDKプロジェクトにInfrastructure Composerを強引に組み込む

❌ すでにTerraformやCDKで管理しているプロジェクトに「ビジュアル確認だけのため」にInfrastructure Composerを導入し、CloudFormation/Terraform/CDKの3種類のIaCが混在する状態を作る。

✅ Infrastructure ComposerはCloudFormation/SAMのビジュアルフロントエンドとして使用します。Terraformプロジェクトでは、設計のスケッチ・ドキュメント化用途に限定します (エクスポートしたCloudFormationテンプレートをそのまま使うのではなく、参考設計図として活用)。IaCツールは1プロジェクト1種類に統一することを原則とします。

アンチパターン5: 大規模テンプレートを1ファイルで管理する

❌ Infrastructure Composerで設計した全リソース (50超) を1つのCloudFormationテンプレートに詰め込んでキャンバス管理する。テンプレートが複雑になり、キャンバスが判読困難になるだけでなく、CloudFormationのスタックリソース上限 (500リソース) に近づくリスクが生じる。

✅ CloudFormationのネストされたスタック (AWS::CloudFormation::Stack) を活用してテンプレートを分割します。ネットワーク層・共有リソース層・アプリケーション層などに分けてそれぞれをInfrastructure Composerで管理し、親テンプレートから子スタックを参照する構成にします。各テンプレートのキャンバスが見やすい規模に収まり、変更影響範囲も限定できます。

アンチパターン6: Change Inspectorを確認せずに操作を進める

❌ カードの接続・削除などの操作を素早く行い、Change Inspectorのパネルを確認しないままテンプレートをエクスポートする。意図しないリソース変更 (不要なIAMポリシーの追加、既存リソースプロパティの上書き) が混入したままデプロイされてしまう。

✅ キャンバス操作のたびに Change Inspector の差分を確認します。特にコネクタを引いた後は、自動生成されたIAMポリシーとイベント設定の内容を必ず確認してからエクスポートします。差分が想定外の場合はキャンバスの操作を undo (Ctrl+Z) してやり直します。

8-3. まとめ

AWS Infrastructure Composerは、「IaCのビジュアルフロントエンド」として、CloudFormation/SAMテンプレートの作成・管理の敷居を大幅に下げるサービスです。

本記事で解説した主なポイントを振り返ります。

• ビジュアルキャンバスと双方向同期 (§2): カードとコネクタで直感的にリソースを設計し、テンプレートとのリアルタイム双方向同期によりIaC管理を容易にします。Application Composerとして2022年12月に登場し、2024年10月、Infrastructure Composerへ改称されて対応リソースが大幅拡張されました。
• 1,000超のリソース対応 (§3): CloudFormationが対応する全リソースタイプをキャンバスで設計できます。IAM権限の自動生成により、コネクタを引くだけでリソース間の接続設定が完了します。
• VS Code Toolkit統合 (§4): ローカルモードにより、Gitワークフローに組み込んだチーム開発が可能です。ローカルファイルがソースとなるため、コミット・PR・CI/CDへの連携が自然に行えます。
• AI生成IaCの活用 (§5): Amazon Q DeveloperとのAI連携で、リソース設定の提案・自動生成を活用できます。
• CI/CD統合 (§6): エクスポートしたテンプレートをそのままCloudFormation/SAMパイプラインに投入できます。追加のビルドステップは不要です。
• 既存IaC資産との共存 (§7): 既存テンプレートのインポートと可視化により、ドキュメンテーションや段階的なIaC移行に活用できます。

Infrastructure Composerは「ビジュアル設計してコードを書く」という従来の分断を解消し、設計図とIaCテンプレートを常に同期させるアプローチを提供します。IaC学習の入口として、あるいは既存アーキテクチャの可視化ツールとして、ぜひ本番運用に取り入れてみてください。

Infrastructure Composerを導入する際の推奨ステップ

1. まず専用コンソールで試す: 既存のシンプルなテンプレート (10リソース以下) をインポートし、キャンバス表示と双方向同期を体験します。
2. VS Code Toolkitを導入する: チーム開発や継続的な運用を見据えて、早めにVS Codeローカルモードへ移行します。
3. IAMポリシーレビューを習慣化する: コネクタで自動生成されたIAMポリシーを毎回レビューする習慣を付け、デプロイ前チェックリストに組み込みます。
4. テンプレートを適切な規模に分割する: スタック設計の段階からネストされたスタック構成を意識し、各テンプレートを管理しやすい規模に保ちます。
5. CI/CDパイプラインに組み込む: Infrastructure Composerが出力する標準テンプレートは、既存のCloudFormation/SAMパイプラインにそのまま統合できます。
6. Change Inspectorを活用する習慣を付ける: キャンバス操作後は必ずChange Inspectorで差分を確認し、意図しない変更の混入を防ぎます。テンプレートエクスポート前の最終確認にも使用します。
7. IAM権限を定期的に棚卸しする: Infrastructure Composerで自動生成したIAMポリシーは、運用の中で不要になった権限が残ることもあります。AWS IAM Access Analyzerを活用して未使用の権限を定期的に検出・削除します。

Infrastructure Composerを活用すべき場面・使用に注意が必要な場面

活用すべき場面:

• IaC初学者がCloudFormationの文法を学ぶ入門段階
• 既存のCloudFormationテンプレートをドキュメント化・可視化したい場面
• チームメンバーがIaCに不慣れで、設計内容を視覚的に共有したい場面
• サーバーレスアーキテクチャのプロトタイプを素早く設計したい場面

使用に注意が必要な場面:

• TerraformやCDKを主なIaCツールとして採用しているプロジェクト (テンプレート変換が必要)
• 数百リソースを超える大規模なモノリシックスタック (パフォーマンス・可読性の問題)
• 複雑なConditionsやカスタムリソースを多用するテンプレート (一部非対応)

Infrastructure Composerは「ビジュアル設計でIaCを加速する」というシンプルな価値提供に特化しています。その強みを理解した上で、プロジェクトの適切な場面で積極的に活用することで、チーム全体のIaC品質と生産性の向上が期待できます。

最後に、本記事で取り上げた関連技術の記事も合わせてご覧ください。SAM・CDK・Terraformなどコード記述型のIaCツールと組み合わせることで、ビジュアル設計とコードの両方のメリットを最大限に活かした本番運用が実現します。Infrastructure Composerはその出発点として、確かな価値を発揮します。

次のステップ

Infrastructure Composerを習得したら、次のステップとして以下をご検討ください。

• AWS SAM CLI: Infrastructure Composerで生成したSAMテンプレートをローカルでテスト・デプロイするCLIツールです。sam local invoke コマンドでLambda関数をローカル実行できます。
• AWS CDK: CloudFormationテンプレートをTypeScript/Python/Javaなどのプログラミング言語で定義する高レベルIaCフレームワークです。再利用可能なConstruct (コンストラクト) で共通パターンをライブラリ化できます。
• AWS CloudFormation Guard: ポリシー・アズ・コードでCloudFormationテンプレートのコンプライアンスを検証するツールです。Infrastructure Composerで生成したテンプレートにGuardルールを適用することで、セキュリティポリシー違反を自動検出できます。

8-4. 関連記事

Terraformモジュール設計のベストプラクティス

CDK Pipelines / GitOps 実践ガイド

SAM / Amplify による開発効率化

サーバーレス本番運用 Lambda / APIGW / Step Functions

CI/CD基礎 — パイプライン構築からデプロイ自動化まで