AWS Application Composerとは？Infrastructure Composerへの改称と使い方・料金を実装者目線で解説

AWS Application Composerは、2024年10月4日にAWS Infrastructure Composerへ名称が変わりました。サービスが終了したわけではありません。対象がサーバーレス構成から全CloudFormationリソースへ広がったことに合わせた改称です。この記事では、改称で何が変わり何が変わらなかったのか、4つあるアクセス経路のどれを選ぶべきか、そしてドラッグ&ドロップの自動配線が効くカードと効かないカードの境界を、AWS公式ドキュメントの記述に沿って整理します。旧名で書かれた解説記事を読んで手が止まった方が、そのまま現在の画面に接続できる状態を目指します。

まとめ

• AWS Application Composerは2024年10月4日にAWS Infrastructure Composerへ改称されました。機能の廃止ではなく、対象範囲の拡大に伴う名称変更です。
• 2023年9月26日に全CloudFormationリソースへの対応が入り、実態が名前を追い越した状態が約1年続いたのちの改称でした。
• アクセス経路はInfrastructure Composerコンソール、CloudFormationコンソールモード、Lambdaコンソールからのインポート、AWS Toolkit for VS Codeの4つです。用途で選び分けます。
• カードには拡張コンポーネントカードと標準IaCリソースカードの2種類があり、接続ポートによる自動配線が効くのは拡張カードだけです。公式が案内する拡張リソースは13種で、「全CloudFormationリソース対応」と自動配線の範囲は一致しません。
• 利用に追加料金はかかりません。課金対象はデプロイしたリソースです。
• local syncモードはFile System Access APIに依存するため、Google ChromeとMicrosoft Edgeの最近のバージョンが前提です。WSLのLinuxディレクトリは対象外になります。
• CloudFormationコンソールモードは、AWSがCloudFormationテンプレートの可視化に推奨するツールとして位置づけられています。

AWS Application Composerの現在地：2024年10月のInfrastructure Composerへの改称

改称の時期と背景

AWSは2024年10月4日付の告知で、AWS Application ComposerをAWS Infrastructure Composerへ改称しました。告知は、新しい名前が「インフラストラクチャアーキテクチャを構築する能力を強調する」ものであり、サーバーレスアプリケーションだけに焦点を絞るのではなく、CloudFormationであらゆるインフラを構築する顧客を支援する姿勢を反映したものだと説明しています。

この改称は機能の縮小や提供終了ではありません。同じ告知では、全CloudFormationリソースへの対応と、全商用リージョンおよびAWS GovCloud (US) での提供が併せて示されています。名前が「Application（アプリケーション）」から「Infrastructure（インフラ）」へ移ったのは、2023年9月26日に全CloudFormationリソースを設計対象に加えた時点から実態が先行しており、名前が後から追いついた形です。

旧名が残る場所と読み替えの目安

改称後も、旧名を目にする場面は残ります。開発者ガイドの旧パス（application-composer）を開くと、現在のガイド（infrastructure-composer）の内容が表示されます。旧記事に貼られたリンクからでも現行のドキュメントに到達できる状態です。一方、AWS Compute Blogのカテゴリページは旧名のまま残っています。2023年から2024年前半の日本語解説記事も、ほぼすべてが旧名表記です。

読み替えの判断はシンプルです。2024年10月4日より前の記述にあるApplication Composerは、現在のInfrastructure Composerと同じサービスを指します。画面上のラベルとマネジメントコンソールの検索窓では、現在の名称であるInfrastructure Composerを使ってください。旧名で書かれた手順書の操作そのものは、カードの配置と接続という基本部分については現在も通用します。

Infrastructure Composerの機能：カード配置からIaCテンプレート生成までの流れ

拡張コンポーネントカードと標準IaCリソースカードの違い

キャンバスに置くカードは2種類に分かれます。この違いが、ドラッグ&ドロップだけで済む範囲を決めます。

拡張コンポーネントカードは、少なくとも1つのコネクタポートを持ちます。ポートを別のカードのポートへドラッグすると、Infrastructure Composerが2つのリソースを接続するか、その構成がサポートされない場合はメッセージを表示します。接続は実線で描画されます。公式は拡張リソースを13種と案内しており、AWS Lambda関数、Amazon Kinesisストリーム、EventBridgeスケジュール、API Gateway、Amazon SQSキュー、AWS Step Functionsステートマシンなどが該当します。対応範囲は追加されるため、実際の可否はリソースパレットのEnhanced componentsセクションで確認してください。

標準IaCリソースカードはコネクタポートを持ちません。リソースパレットから全CloudFormationリソースを標準IaCリソースカードとして利用できますが、イベント駆動の関係はテンプレートに自分で記述する必要があります。記述するとInfrastructure Composerがその関係を自動検出し、カード間を点線で可視化します。標準カードをキャンバスへドラッグした時点で生成されるのは、そのリソースの出発点となるテンプレートだけです。

「全CloudFormationリソースに対応」という説明を、すべてのリソースが線でつなげば設定まで済むという意味に読むと期待が外れます。ポートによる自動配線は拡張カードの範囲に限られます。

接続が自動生成するIAMポリシー・環境変数・イベント

拡張カード同士を接続したとき、Infrastructure Composerは必要に応じて次の3つをテンプレートに書き込みます。

• IAMポリシー：あるリソースが別のリソースを呼び出す権限を必要とする場合、AWS SAMのポリシーテンプレートを使ってポリシーを生成します（公式ドキュメントの表記はresource-based policies）。SAMテンプレート上は関数のPoliciesに展開され、デプロイ時に実行ロールへ反映されます。
• 環境変数：リソース間で値を受け渡す必要がある場合、環境変数を利用するインフラコードを定義します。
• イベント：リソースが別のリソースをイベント経由で呼び出す場合、その相互作用に必要なインフラコードを定義します。

手書きだと粒度を外しやすいのがIAMポリシーです。ここをSAMのポリシーテンプレート経由で埋めてくれる点が、視覚的な設計ツールという表層の説明より実務上の価値が大きい部分です。逆に言えば、標準カード中心の構成ではこの恩恵が働きません。

既存テンプレートのインポートとStep Functions Workflow Studio連携

既存のCloudFormationテンプレートとAWS SAMテンプレートをインポートすると、構成を可視化して設計を変更できます。Infrastructure Composerで作成したテンプレートのエクスポートも可能で、既存のデプロイ手順へそのまま組み込めます。キャンバスとテンプレートコードの変更は自動的に同期され、テンプレートビューから直接コードを編集できる仕組みです。

特定サービス向けの追加機能として、キャンバスから直接Step Functions Workflow Studioを起動する統合が用意されています。AWSはこの連携について、220以上のAWSサービスまたはパブリックHTTPエンドポイントをStep Functionsワークフローで視覚的にオーケストレーションできると説明しています。ステートマシンの構造そのものの設計判断は、AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説で扱っています。

4つのアクセス経路と選び分けの基準

Infrastructure Composerは単一の画面ではなく、4つの入り口から起動します。どこから入るかで前提条件と向く場面が変わります。

Infrastructure Composerコンソールとlocal syncモード

マネジメントコンソールから開く経路が最短です。加えてlocal syncモードを有効にすると、設計中のテンプレートファイルとプロジェクトフォルダがローカルマシンへ自動的に同期・保存されます。権限の範囲は、許可したプロジェクトフォルダとその配下の子フォルダに対する読み書きまで。用途はテンプレートファイル・プロジェクトフォルダ・バックアップディレクトリの作成と更新に限られます。アクセスしたデータが他の目的に使われることはなく、ローカルファイルシステムの外部に保存されることもない、と公式ドキュメントに明記されています。

CloudFormationコンソールモード：Designerの後継

CloudFormationコンソールモードは、旧来のCloudFormation Designerを改良したもので、CloudFormationスタックのワークフローと統合されています。公式ドキュメントは、これがCloudFormationテンプレートを可視化する推奨ツールであると明示しています。

Designerを今も使っている場合、乗り換えの判断材料はここで揃います。可視化目的でDesignerを開く運用を続ける理由は、AWS自身の推奨が移った時点で乏しくなりました。既存スタックの構成を読み解く作業から始めるなら、この経路を選んでください。

LambdaコンソールとAWS Toolkit for VS Code

Lambdaコンソールからは、既存のLambda関数をInfrastructure Composerへインポートできます。すでに動いている関数の周辺構成を図に起こしたいときに使う入り口です。関数単体の設計判断はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説を参照してください。

AWS Toolkit for Visual Studio Codeの拡張を入れると、Infrastructure Composerをローカルの開発環境へ持ち込めます。CloudFormationテンプレートやAWS SAMテンプレートを開いた状態のInfrastructure Composerボタン、テンプレートを右クリックしたコンテキストメニュー、VS Codeのコマンドパレットのいずれからでも起動できます。公式はこのIDE拡張の差別化要素として、生成AIによるコード提案を挙げており、リソース設定画面から構成を生成させることもできます。ブラウザとエディタを往復せずに済むため、日常の開発ループに乗せるならこの経路が現実的です。

始め方の手順とテンプレート出力

コンソールとVS Codeでの開始手順

コンソールから始める場合の流れは次のとおりです。

• マネジメントコンソールでInfrastructure Composerを開き、新規プロジェクトを作成する
• ローカルにファイルを残すならlocal syncモードを有効にし、対象のプロジェクトフォルダへのアクセスをブラウザのプロンプトで許可する（保存先に既存のアプリケーションテンプレートがあると選べません）
• リソースパレットからカードをキャンバスへドラッグし、プロパティパネルで設定を詰める
• 拡張カード同士はコネクタポートをドラッグして接続する
• テンプレートビューで生成されたコードを確認し、必要に応じて直接編集する

VS Codeから始める場合は、AWS Toolkit拡張を導入したうえで、既存のCloudFormationテンプレートまたはSAMテンプレートを開き、Infrastructure Composerボタン、テンプレートの右クリックメニュー、コマンドパレットのいずれかからキャンバスを開きます。local syncはInfrastructure Composerコンソール側の機能のため、VS Code経路では設定しません。

デプロイまでの導線も押さえておきます。local syncで書き出したテンプレートとプロジェクトディレクトリは、AWS SAM CLIでそのままテスト・デプロイできます。CloudFormationコンソールモードから入った場合は、スタックの作成・更新フローへ直接乗ります。

SAMテンプレートに現れる3つの自動生成箇所

Infrastructure Composerは、設計を進めるのに合わせてCloudFormationテンプレートとAWS SAMテンプレートをAWSのベストプラクティスに沿って自動生成します。API Gateway・Lambda関数・DynamoDBテーブルを接続した構成では、SAMテンプレートの骨格は次の形になります。接続によって追加されるのが、EventsのPath指定、EnvironmentのVariables、Policiesの3箇所です。

Transform: AWS::Serverless-2016-10-31
Resources:
  Api:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod
  Function:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/Function
      Handler: index.handler
      Runtime: nodejs22.x
      Events:
        ApiGET:
          Type: Api
          Properties:
            Path: /items
            Method: GET
            RestApiId: !Ref Api
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref Table
  Table:
    Type: AWS::DynamoDB::Table
    Properties:
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST

DynamoDBテーブルが AWS::Serverless::SimpleTable ではなく AWS::DynamoDB::Table で出力される点は、公式チュートリアルの生成物の説明と一致します。実際の出力には、これに加えてキャンバス上のリソースグループ情報を持つMetadataセクションも含まれます。

Policies配下のDynamoDBCrudPolicyがSAMのポリシーテンプレートです。ここを手書きするとIAMアクションの過不足が出やすく、権限を広く取りすぎる原因になります。Environment配下のTABLE_NAMEも同様に、接続の副産物として入ります。

ランタイムのバージョンやステージ名は構成によって変わるため（既定のランタイム値は時期によって変わります）、生成後のテンプレートを必ず確認してください。イベント駆動の連携をAPI Gateway以外へ広げる場合の選択肢は、Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説で整理しています。

料金体系と提供リージョン

Infrastructure Composerの利用に追加料金はかかりません。AWSは2023年3月7日のGA告知で「追加料金なしで一般提供を開始した」と明示しています。課金が発生するのは、設計したテンプレートからデプロイしたリソースの利用分です。設計ツールそのものにコストがかからないため、テンプレートを試作して捨てる使い方でも費用面の制約を受けません。

提供リージョンはGA当初、北米・アジアパシフィック・欧州の各3拠点の計9リージョンに限られていました（東京を含む）。2024年10月4日の改称告知の時点では、全商用リージョンとAWS GovCloud (US) の各リージョンへ拡大しています。

公式ページでは、1,000以上のAWSリソースからモダンアプリケーションを視覚的に構成できると案内されています。対応リソースは継続的に増えるため、特定リソースの可否は実際のリソースパレットで確認してください。

採用を見送るべき場面とハマりどころ

local syncのブラウザ制約とWSLの除外

local syncモードとLambdaコンソールからのインポートは、File System Access APIに依存します。このAPIの全機能をサポートするのはGoogle ChromeとMicrosoft Edgeの最近のバージョンだ、というのが公式ドキュメントの記述です。FirefoxやSafariを標準ブラウザにしている環境では、local syncモードは選択肢から外れます。その場合はlocal syncを無効にしたデフォルトモードで使うか、VS Code経由へ切り替えてください。

WSL利用時の制約は回避策の手数が増えます。File System Access APIは、WindowsシステムのなかでのLinuxディレクトリの位置づけを理由に、Linuxディレクトリ全体へのアクセスを除外するためです。取れる手は、WSLディレクトリからWindows側の作業ディレクトリへプロジェクトファイルを同期する仕組みを組むか、local syncを無効にして使うかの二択。WSLで開発しているなら、この点の確認が導入前の必須項目になります。

加えて、File System Access APIは機密データを含む可能性のある特定のディレクトリへのアクセスを除外または制限します。そうしたディレクトリをlocal syncの対象に選ぶとエラーになるため、プロジェクト専用のフォルダを切って使うのが安全です。

標準カード中心の構成で自動配線が効かない場面

設計対象がサーバーレス以外のリソース、たとえばVPCやEC2、ネットワーク周辺のCloudFormationリソース中心になるほど、標準IaCリソースカードの比率が上がります。標準カードにはコネクタポートがないため、関係はテンプレートに自分で書く必要があり、Infrastructure Composerの役割は「書いた関係を点線で可視化する」ところに縮みます。

この構成では、ドラッグ&ドロップで組み立てる体験は得られません。テンプレートを手で書ける前提で、構成レビュー用のビューアとして使うのが現実的な位置づけです。可視化の価値自体は残るので、使わない理由にはなりません。ただし「コードを書かずに済む」という期待で導入すると評価が合いません。

CDK・Terraform中心のチームでの位置づけ

プログラミング言語でインフラを定義するAWS CDKや、マルチクラウドを前提としたTerraformを主軸に据えているチームでは、Infrastructure Composerを設計の中心に置く判断は避けてください。Infrastructure Composerが生成・同期するのはCloudFormationテンプレートとSAMテンプレートであり、CDKやTerraformのコードではありません。主軸のツールチェーンと二重管理になります。

この場合の使いどころは、CDKが合成したCloudFormationテンプレートをインポートして構成を目視確認する用途に絞られます。設計はコードで行い、レビュー時だけ図にする、という分担です。CDKと同様にコードでバックエンドを定義する別アプローチとしては、AWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断を実装者目線で解説が比較対象になります。

組織横断でテンプレートを標準化して配布したい要件がある場合は、設計ツールではなく配布の仕組みの検討が先です。AWS Service Catalogとは？仕組み・ポートフォリオ設計と組織展開の判断を実装者目線で解説で扱っている領域が該当します。

よくある質問

AWS Application Composerは廃止されたのですか？

廃止されていません。2024年10月4日にAWS Infrastructure Composerへ改称されただけで、サービスは継続しています。対象範囲はむしろ広がり、全CloudFormationリソースを扱えるようになっています。

AWS Infrastructure Composerの利用に追加料金はかかりますか？

かかりません。AWSはGA告知で追加料金なしと明示しています。課金対象は、作成したテンプレートからデプロイしたリソースの利用分です。

local syncモードがFirefoxやSafariで使えないのはなぜですか？

local syncモードがFile System Access APIに依存しているためです。公式ドキュメントは、このAPIの全機能をサポートするブラウザとしてGoogle ChromeとMicrosoft Edgeの最近のバージョンを挙げています。対象外のブラウザではlocal syncを無効にして使うか、AWS Toolkit for VS Code経由に切り替えてください。

CloudFormation Designerとどちらを使うべきですか？

Infrastructure ComposerのCloudFormationコンソールモードです。公式ドキュメントはこれをDesignerの改良版と位置づけ、CloudFormationテンプレートを可視化する推奨ツールだと記しています。

生成されるのはCloudFormationとSAMのどちらのテンプレートですか？

両方です。設計内容に応じてCloudFormationテンプレートとAWS SAMテンプレートをAWSのベストプラクティスに沿って生成します。キャンバスとテンプレートコードは自動的に同期され、テンプレートビューから直接編集できます。

関連記事

• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説
• AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説
• Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説
• AWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断を実装者目線で解説
• AWS Service Catalogとは？仕組み・ポートフォリオ設計と組織展開の判断を実装者目線で解説