BLOGベアサポートブログ

AWS Infrastructure Composerで行うVPC・EC2構築完全ガイド：可視化とIaCで脱・手動運用

システム運用において、AWSコンソールから手動でリソースを作成する「手動運用（設定のブラックボックス化）」は、環境の再現性を失わせ、予期せぬ設定ミスや障害を引き起こす最大の原因となります。

本記事では、AWS Infrastructure Composer（旧 Application Composer）を活用して視覚的にインフラを設計し、CloudFormationのCLIコマンドを用いてAWS上に安全にデプロイする一連の手順を解説します。可視化（ビジュアル）とコード化（IaC）を組み合わせることで、運用の標準化と属人化の排除を同時に実現します。

前提条件

1. 環境構築

本環境を構築・デプロイするにあたり、以下の前提条件を事前に満たしている必要があります。

① ローカル開発環境の準備

  • AWS CLIのインストールと認証設定
    ローカルPCにAWS CLI（v2推奨）がインストールされており、適切なIAM権限（AdministratorAccess、またはCloudFormation/EC2/S3の操作権限）を持つ認証情報が設定されていること。
  • 適切なAWSプロファイルの選択
    複数アカウントを運用している場合、対象のAWS環境に対して環境変数 AWS_PROFILE が正しく設定されているか、または各種コマンドで –profile オプションが指定できる状態であること。
  • シェル環境（PowerShell / ターミナル）の準備
    コマンド操作を行うためのシェルが利用可能であること。※Windows環境の場合はPowerShell 7以上、またはコマンドプロンプト。
  • テキストエディタの用意
    ローカルの template.yaml を直接編集・確認するため、VS Codeなどのテキストエディタが用意されていること（「CloudFormation」や「YAML」の拡張機能を入れておくと便利です）。

② AWS側のリソース・リージョンの前提

  • デプロイ先リージョンの決定
    本ガイドでは東京リージョン（ap-northeast-1）を基準としています。
  • Amazon S3バケットの確保
    CloudFormationのテンプレートファイルを一時的に格納するためのS3バケット（例: infrastructurecomposer）が、デプロイを実行するAWSアカウント内に事前に作成されていること。

③ EC2インスタンスに関する前提条件（最重要）

  • EC2キーペアの事前存在
    テンプレート内で指定するSSH接続用のキーペア（例: my-ssh-key）が、デプロイ先リージョン（東京リージョン）に必ず事前に作成されていること。これが存在しない場合、スタックの作成はエラー（CREATE_FAILED）となり、自動的にロールバックされます。
  • AMI（Amazonマシンイメージ）IDの整合性
    仮想マシン（EC2）のプロパティで指定しているAMI ID（例: ami-0d71b1617df761282）が、東京リージョンで有効かつ提供中のイメージであること。

2. インフラ構成の概要

本手順で構築するインフラ構成は以下の通りです。

  • VPC: 10.0.0.0/16 のCIDRを持つ仮想ネットワーク空間。
  • パブリックサブネット: 10.0.1.0/24 のCIDRを持ち、インターネットからアクセス可能なエリア。
  • セキュリティグループ: HTTP（80番ポート）およびHTTPS（443番ポート）のインバウンド通信をフルオープン（0.0.0.0/0）で許可する設定。
  • EC2インスタンス: サブネット内に配置されるWebサーバー（t3.micro）。

Infrastructure Composerのメリット・デメリット

AWS Infrastructure Composerを採用するにあたって、把握しておくべきメリットとデメリットを解説します。

メリット（強み）

  • 完全に無料で利用可能
    ツール自体の利用料金は一切かかりません。追加コストなしで導入できます（※デプロイ後に作成されるEC2などのリソース利用料は通常通り発生します）。
  • 「構成図」を別途作成・メンテナンスする必要がない
    画面上でインフラを配置するだけで、自動的に視覚的な構成図が生成されます。「作図ツールで構成図を描き、それとは別にコードを書く」という二度手間が完全にゼロになります。コードを直せば構成図も自動で変わるため、「ドキュメントと実環境の乖離」が根本的に発生しません。
  • 直感的な操作とリアルタイム同期
    リソース間の関係性（RefやDependsOnなど）を自動で計算してくれるほか、「Local sync」機能により、ブラウザ上の操作がローカルPCの template.yaml に瞬時に書き込まれます。

デメリット（注意点）

  • すべての設定をビジュアル編集できるわけではない
    複雑なプロパティや一部の高度なリソース設定を行う場合、ビジュアル（Canvas）画面だけでは対応しきれないケースがあります。その際は「Templateビュー」を開いて直接コードで補う必要があります。
  • 既存の巨大なテンプレートでは画面が混雑する
    何千行もあるような大規模テンプレートを読み込ませると、キャンバス上に無数のカードと線が溢れかえり、かえって視覚的な把握が難しくなることがあります。

すでに構築されている「既存環境」に対して有効か？

結論から言うと、「既存のCloudFormationテンプレート（コード）がある場合は非常に有効」ですが、「コンソールなどで手動構築した環境（未コード化リソース）を直接読み込ませることはできない」という制限があります。

有効なケース：すでにCloudFormationなどの「コード」がある場合

すでに他のプロジェクトや過去の資産として template.yaml（またはJSON）が存在する場合、それをInfrastructure Composerに読み込ませることで、瞬時にリソース構成を可視化（グラフィカルな構成図に変換）できます。 既存のコードをベースに、「新しくEC2やサブネットを視覚的に追加・変更したい」という場合には絶大な効果を発揮します。

そのままでは使えないケース：手動で作った「未コード化」環境の場合

AWSコンソールから手動で作成したVPCやEC2など、インフラのコード化（IaC化）がされていないリソースをInfrastructure Composerが直接スキャンして画面に取り込む機能は備わっていません。

手動構築された既存環境を可視化・連動させるアプローチ

手動で構築済みの環境に対してInfrastructure Composerを使いたい場合は、以下のステップを踏むことで有効活用できます。

  1. AWSコンソールの 「CloudFormation Gitの同期（旧：IaCジェネレーター）」 などの機能、または Former2 などのサードパーティツールを使い、既存の手動リソースを一度 template.yaml に逆生成（エクスポート）する。
  2. 出力された template.yaml をInfrastructure Composerに読み込ませて可視化・追加編集を行う。

Infrastructure Composerでの構築手順

AWSコンソールのInfrastructure Composer画面を使い、インフラを構築していきます。

本手順では、より確実に、かつ細かなパラメータ指定を直感的に行える「Template（リソース構成・コード）ビュー」からの編集・構築手順を解説します。

ステップ1：初期設定とローカル同期

AWSコンソール「Infrastructure Composer」の画面キャプチャ。初期設定とローカル同期を行う。

  1. AWSコンソールで「Infrastructure Composer」にアクセスし、「Create project（プロジェクトの作成）」をクリックします。
  2. 「Local sync（ローカル同期）」モードを選択し、ローカルPC上の作業ディレクトリ（例: C:\Users\…\sample）を指定してブラウザからのファイルアクセス権限を許可します。
    1. これにより、画面上の操作がローカルの template.yaml にリアルタイムで自動保存されます。

ステップ2：Templateビューからのリソース構成編集

AWSコンソール「Infrastructure Composer」の画面キャプチャ。Templateビューからリソース構成を編集する。

  1. 画面上部のトグルスイッチを切り替え、「Template」（または画面を2分割する「Split」）表示を選択します。
  2. 画面上のエディタに以下のリソース構成（YAMLコード）を記述するか、必要なパラメータ（キーペア名など）を直接編集します。
YAML
AWSTemplateFormatVersion: '2010-09-09'
Description: EC2 and VPC template generated by Infrastructure Composer Sample.
Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: IC-Sample-VPC
  PublicSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select
        - 0
        - !GetAZs ''
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: IC-Sample-PublicSubnet
  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Enable HTTP and HTTPS access
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
  MyWebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0d71b1617df761282 # 東京リージョンのAMI
      KeyName: my-ssh-key           # <-- ※ここが前提条件のキーペア名と一致している必要があります
      SubnetId: !Ref PublicSubnetA
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      Tags:
        - Key: Name
          Value: IC-Sample-WebServer
  • 双方向同期のメリット
    コード側の「リソース構成」を編集して保存すると、「Canvas」タブの視覚表示（VPCの中にサブネットがあり、そこにEC2が配置され、セキュリティグループと接続されているグラフィカルなマップ）にも即座に自動反映されます。
AWSコンソール「Infrastructure Composer」の画面キャプチャ。リソース構成がキャンパスに反映される。

CLIによるデプロイ手順

画面での配置、またはリソース構成の記述が完了すると、ローカルフォルダ内の template.yaml が自動更新されています。ここからはターミナルを使ってAWS上の環境に反映させます。

ステップ1：AWS側での事前準備（キーペアの作成）

テンプレート内で指定した my-ssh-key がAWS側にまだない場合は、以下のコマンドで事前に作成します。

Bash
aws ec2 create-key-pair --key-name my-ssh-key --region ap-northeast-1 --query "KeyMaterial" --output text > my-ssh-key.pem

ステップ2：CloudFormationによるデプロイの実行

template.yaml が配置されているディレクトリで、以下のデプロイコマンドを実行します。

Bash
aws cloudformation deploy --template-file template.yaml --stack-name ec2-vpc-visual-stack --s3-bucket infrastructurecomposer --capabilities CAPABILITY_IAM
  • –template-file: ローカルの原本設計図（template.yaml）を指定。
  • –s3-bucket: テンプレートを一時配置するAWS上のバケットを指定。
  • –capabilities CAPABILITY_IAM: テンプレート内でIAMリソースが自動生成される場合に、その作成を明示的に許可。

トラブルシューティング（失敗時の対応フロー）

デプロイが途中で止まったり、失敗して ROLLBACK_COMPLETE になってしまったりした場合は、以下のステップで「原因の特定」と「環境のクリーンアップ」を行います。

ステップ1：スタックのイベントログからエラー原因を特定する

デプロイが失敗した正確な理由（どの設定が間違っていたか）を調べるため、以下のコマンドを実行してエラーログを書き出します。

Bash
aws cloudformation describe-stack-events --stack-name ec2-vpc-visual-stack

出力されるJSONログの中から、ステータスが CREATE_FAILED になっているリソースを探し、その ResourceStatusReason（エラー理由）を確認します。

よくあるエラー理由の例

  • “ResourceStatusReason”: “The key pair ‘my-ssh-key’ does not exist…” （原因：指定した名前のEC2キーペアがAWS側に作られていない、またはリージョン違い）
  • “ResourceStatusReason”: “AMI ami-xxxxxxx の指定が不正です…” （原因：テンプレート内のImageIdが古くなっているか、別のリージョンのAMIを指定している）

ステップ2：失敗したスタックを一度削除する

AWSの仕様上、初回のデプロイで作成失敗（ROLLBACK_COMPLETE）になったスタックは、そのまま同じ名前で上書きデプロイ（更新）をかけることができません。 エラー原因を特定・修正したら、一度以下のコマンドで失敗したスタックを完全に削除します。

Bash
aws cloudformation delete-stack --stack-name ec2-vpc-visual-stack

※削除には1〜2分かかります。AWSコンソール上、または再度コマンドを実行して、スタックが削除されたことを確認してください。

ステップ3：修正して再デプロイ

手元の template.yaml（またはキーペアなどの設定）の修正が完了したら、再度通常のデプロイコマンドを実行します。

Bash
aws cloudformation deploy --template-file template.yaml --stack-name ec2-vpc-visual-stack --s3-bucket infrastructurecomposer --capabilities CAPABILITY_IAM

まとめ

AWS Infrastructure Composerの強みは、複雑なリソース構成（コード）とトポロジー（ビジュアル）を双方向で同期しながらインフラコード（IaC）を組み立てられる点にあります。追加コストなしで「構成図がそのまま動くコードになる」ため、ドキュメント修正の二度手間を省きつつ、設計の品質を担保できます。

新規構築はもちろん、既存のテンプレートを読み込ませて拡張していくフェーズでも非常に強力な相棒となります。運用の大原則は「修正は必ずローカルの template.yaml で行い、aws cloudformation deploy でAWS側へ適用する」ことです。もしエラーが起きても、describe-stack-events で原因のログを正確に読み解くことで、スムーズにトラブルを解決し、安全なインフラ管理を維持できます。

このエントリーをはてなブックマークに追加

RELATED関連記事