はじめに

「APサーバはインターネットに公開しつつ、DBサーバはインターネットから完全に隔離したい」——これが実際のAWSシステム設計でよく使われる AP+DB 2層構成 です。

この記事では、AWSコンソール（GUI）のみを使って、カスタムVPCを設計し、パブリックサブネット（APサーバ）とプライベートサブネット（DBサーバ）に分離した2層アーキテクチャをゼロから手動構築するハンズオンを紹介します。

インターネット
  ↓ HTTP(80) / SSH(22)  ← 自分のIPのみ
[インターネットゲートウェイ（my-igw）]
  ↓
[VPC: my-vpc（10.0.0.0/16）]
  │
  ├─ [パブリックサブネット: 10.0.1.0/24]
  │    └── APサーバEC2（my-ap-instance）
  │          ├── Apache（ポート80）   ← インターネットから直接アクセス可
  │          └── my-ap-sg
  │                ↓ SSH(22) / MySQL(3306) ← APサーバSGのみ許可（SG参照）
  └─ [プライベートサブネット: 10.0.2.0/24]
       └── DBサーバEC2（my-db-instance）
             ├── MariaDB（ポート3306）
             ├── パブリックIPなし       ← インターネットから隔離
             └── my-db-sg

このハンズオンで体験できること：

• カスタムVPC・サブネット・インターネットゲートウェイ・ルートテーブルを一から設計・構築
• パブリックサブネット（APサーバ）とプライベートサブネット（DBサーバ）の分離
• DBサーバにパブリックIPを付与せずインターネットから隔離する設計
• APサーバを踏み台（Bastion）としてDBサーバにSSH接続する方法
• S3 VPC Gateway Endpointでプライベートサブネットからパッケージをインストールする方法

このハンズオンのポイント：

Phase 1-3（MySQL）まではデフォルトVPCを使っていましたが、今回はカスタムVPCを一から設計します。実際のAWS本番環境に近いネットワーク設計を体験できます。

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でVPCリソースの依存関係・設定手順を視覚的に学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

前フェーズとの違い

使用するAWSサービス

注意: EC2を2台同時に稼働させるため、無料枠の消費が2倍になります。ハンズオン後は必ず2台とも削除してください。

構築するリソース一覧

全体の作業順序

ネットワーク系リソースはEC2より先に作成する必要があります。

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ VPCを作成する
      ↓
④ インターネットゲートウェイを作成・アタッチする
      ↓
⑤ サブネットを作成する（パブリック・プライベート）
      ↓
⑥ ルートテーブルを設定する（S3 VPC Endpoint作成を含む）
      ↓
⑦ セキュリティグループを作成する（APサーバSG → DBサーバSGの順）
      ↓
⑧ APサーバEC2を起動する（パブリックサブネット）
      ↓
⑨ DBサーバEC2を起動する（プライベートサブネット）
      ↓
⑩ 動作確認
      ↓
⑪ リソースを削除する

【重要】⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

またはルーター管理画面（http://192.168.0.1 など）の「WAN IPアドレス」で確認します。

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

APサーバとDBサーバの両方で使用します。1つのキーペアを共用します。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

② IAMロールの作成

AWSコンソール → IAM → ロール → 「ロールを作成」

「ロールを作成」をクリック。

③ VPCの作成

AWSコンソール → VPC → 仮想プライベートクラウド → 「お使いのVPC」→ 「VPCを作成」

VPCとは: AWS上に作るプライベートなネットワーク空間。この中にEC2などを置きます。CIDR（サイダー）でIPアドレスの範囲を指定します。10.0.0.0/16 は 10.0.0.0 〜 10.0.255.255 の65536個のIPアドレスを表します。

「VPCを作成」をクリック。

控えておく情報: 作成された VPC ID（vpc-xxxxxxxxxx）

④ インターネットゲートウェイの作成・アタッチ

インターネットゲートウェイ（IGW）とは: VPCとインターネットを接続する出入り口です。これをVPCにアタッチすることで、VPC内のEC2がインターネットと通信できるようになります。

4-1. インターネットゲートウェイを作成する

AWSコンソール → VPC → インターネットゲートウェイ → 「インターネットゲートウェイの作成」

「インターネットゲートウェイの作成」をクリック。

4-2. VPCにアタッチする

作成直後の画面から「アクション」→「VPCにアタッチ」をクリック。

「インターネットゲートウェイのアタッチ」をクリック。

ステータスが 「Attached」 になることを確認します。

⑤ サブネットの作成

サブネットとは: VPC内をさらに分割したネットワークです。パブリックサブネットはインターネットと通信でき、プライベートサブネットはVPC内部とのみ通信します。

AWSコンソール → VPC → サブネット → 「サブネットを作成」

VPC ID で my-vpc を選択します。

5-1. パブリックサブネット

5-2. プライベートサブネット

「新しいサブネットを追加」をクリックして2つ目のサブネットを設定します。

「サブネットを作成」をクリック。

5-3. パブリックサブネットのパブリックIP自動割り当てを有効化

サブネット一覧 → my-public-subnet を選択 → 「アクション」→「サブネットの設定を編集」

「パブリック IPv4 アドレスの自動割り当てを有効化」にチェックを入れる → 「保存」。

APサーバEC2を起動したときに自動でパブリックIPが割り当てられるようになります。プライベートサブネットはこの設定をしません（DBサーバにパブリックIPを付与しない）。

⑥ ルートテーブルの設定

ルートテーブルとは: サブネット内のEC2がパケットを送るときの「経路表」です。パブリックサブネットはインターネット向けのルート（→IGW）を持ち、プライベートサブネットは持ちません。

6-1. パブリックルートテーブルを作成する

AWSコンソール → VPC → ルートテーブル → 「ルートテーブルを作成」

「ルートテーブルを作成」をクリック。

インターネット向けルートを追加します:

my-public-rt を選択 → 「ルート」タブ → 「ルートを編集」→「ルートを追加」

「変更を保存」をクリック。

0.0.0.0/0 とは: 「それ以外のすべての宛先」を意味します。VPC内向けのルートはデフォルトで存在するため、インターネット向けのルートだけ追加すれば OKです。

パブリックサブネットを関連付けます:

my-public-rt の「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ my-public-subnet にチェック → 「関連付けを保存」。

6-2. プライベートルートテーブルを作成する

VPC → ルートテーブル → 「ルートテーブルを作成」

「ルートテーブルを作成」をクリック。

インターネット向けルートは追加しません。プライベートサブネットからインターネットへの経路を意図的に持たせないことで、DBサーバをインターネットから完全に隔離します。

プライベートサブネットを関連付けます:

my-private-rt の「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ my-private-subnet にチェック → 「関連付けを保存」。

6-3. S3 VPC Gateway Endpointを作成する（重要）

なぜ必要か: プライベートサブネットはインターネットに出られないため、EC2起動時の dnf install でパッケージをダウンロードできません。Amazon Linux 2023のパッケージリポジトリはS3上にあるため、S3だけインターネットを経由せずアクセスできるGateway Endpointを作成することで解決します。Gateway Endpointは無料です。

AWSコンソール → VPC → エンドポイント → 「エンドポイントを作成」

「エンドポイントを作成」をクリック。

確認: my-private-rt の「ルート」タブを開くと、S3向けのルートが自動追加されていることを確認します。

⑦ セキュリティグループの作成

注意: APサーバSGを先に作成します。DBサーバSGがAPサーバSGをSG参照するためです。

7-1. APサーバSGの作成

EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール:

アウトバウンドルール: 「すべてのトラフィック / 0.0.0.0/0」があることを確認します。

「セキュリティグループを作成」をクリック。

7-2. DBサーバSGの作成

EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール（「ルールを追加」で2つ追加します）:

ルール1: SSH（APサーバ経由の踏み台接続）

ルール2: MySQL（APサーバからのDB接続）

アウトバウンドルール: 「すべてのトラフィック / 0.0.0.0/0」があることを確認します。

「セキュリティグループを作成」をクリック。

⑧ APサーバEC2の起動（パブリックサブネット）

EC2 → インスタンス → 「インスタンスを起動」

8-1. 基本設定

8-2. ネットワーク設定

「ネットワーク設定」→「編集」をクリックして以下を設定します。

8-3. IAMロール・UserDataの設定

「高度な詳細」を開きます。

「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y httpd
systemctl start httpd
systemctl enable httpd
cat > /var/www/html/index.html << 'HTMLEOF'
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>AP Server - Phase 1-4</title></head>
<body>
<h1>AP Server (Public Subnet)</h1>
<p>This AP server is in the PUBLIC subnet and can reach the DB server in the PRIVATE subnet.</p>
</body>
</html>
HTMLEOF

「インスタンスを起動」をクリック。

控えておく情報: APサーバのパブリックIPアドレス

⑨ DBサーバEC2の起動（プライベートサブネット）

EC2 → インスタンス → 「インスタンスを起動」

9-1. 基本設定

9-2. ネットワーク設定

パブリックIPを付与しない: DBサーバはインターネットから直接アクセスされる必要がありません。プライベートサブネットに置き、パブリックIPを持たせないことで、インターネットから完全に隔離します。

9-3. IAMロール・UserDataの設定

「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y mariadb105-server mariadb105
systemctl start mariadb
systemctl enable mariadb
sudo mysql -u root << 'SQLEOF'
SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
FLUSH PRIVILEGES;
SQLEOF

⑥-3でS3 VPC Endpointを作成済みの場合: dnf install はS3経由で正常に動作します。Endpointを作成せずにEC2を起動した場合はMariaDBがインストールされないため、踏み台SSH接続後に手動で sudo dnf install -y mariadb105-server mariadb105 を実行してください。

「インスタンスを起動」をクリック。

控えておく情報: DBサーバのプライベートIPアドレス（パブリックIPはありません）

インスタンス詳細 → 「プライベート IPv4 アドレス」（例: 10.0.2.xxx）を確認してメモします。

⑩ 動作確認

待機時間: EC2起動後、UserDataの完了まで数分かかります。APサーバは2〜3分、DBサーバは5〜8分待ちます。

10-1. APサーバのWeb確認

ブラウザで以下にアクセスします。

http://（APサーバのパブリックIP）

AP Server (Public Subnet) が表示されれば成功です。

10-2. APサーバへのSSH接続

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ec2-user@（APパブリックIP）

10-3. キーペアをAPサーバにコピーする（踏み台SSH準備）

APサーバを踏み台としてDBサーバにSSH接続するために、ローカルPCからAPサーバにキーペアをコピーします。

ローカルPCの別ターミナルで実行します:

scp -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  ec2-user@（APパブリックIP）:~/.ssh/

APサーバ上でキーペアのパーミッションを設定します。

chmod 400 ~/.ssh/my-ec2-2tier-key.pem

10-4. APサーバ経由でDBサーバにSSH接続（踏み台接続）

APサーバのSSHセッションから実行します:

ssh -i ~/.ssh/my-ec2-2tier-key.pem ec2-user@（DBプライベートIP）

[ec2-user@ip-10-0-2-xxx ~]$ のプロンプトが表示されれば踏み台接続成功です。

sudo systemctl status mariadb

# MariaDBに接続
mysql -u root -pAdmin1234!

MariaDBのプロンプトで確認します。

SHOW DATABASES;
EXIT;

DBサーバから切断します。

exit

10-5. APサーバからMySQLに接続（AP→DB通信確認）

APサーバのSSHセッションで実行します。

# mysqlクライアントのインストール
sudo dnf install -y mariadb105

# DBサーバのプライベートIPにMySQL接続
mysql -h （DBプライベートIP） -u handson -pHandson1234! sampledb

接続成功すれば MariaDB [sampledb]> が表示されます。

CREATE TABLE IF NOT EXISTS messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(100));
INSERT INTO messages (text) VALUES ('Hello from AP server!');
SELECT * FROM messages;
EXIT;

APサーバから切断します。

exit

⑪ リソースの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。削除する順番が重要です。

CloudFormation版と比較: コンソール版はリソースの依存関係を意識して手動で削除する必要があります。CloudFormation版は delete-stack 1本で全て自動削除できます。

削除順序

1. EC2インスタンスを終了する（2台）

EC2 → インスタンス → my-ap-instance と my-db-instance を選択 → 「インスタンスを終了」

「終了済み」になるまで待ちます（2〜5分）。

2. セキュリティグループを削除する（DBサーバSG → APサーバSGの順）

DBサーバSGがAPサーバSGを参照しているため、DBサーバSGを先に削除します。

① my-db-sg を選択 → 「アクション」→「セキュリティグループを削除」

② my-ap-sg を選択 → 「アクション」→「セキュリティグループを削除」

3. S3 VPC Endpointを削除する

VPC → エンドポイント → my-s3-endpoint を選択 → 「アクション」→「エンドポイントを削除」

4. ルートテーブルの関連付けを解除・削除する

① my-public-rt を選択 → 「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ チェックを外す → 「保存」

② my-private-rt も同様に関連付けを解除する

③ my-public-rt を選択 → 「ルート」タブ → 「ルートを編集」→ 0.0.0.0/0 のルートを削除 → 「保存」

④ my-public-rt を選択 → 「アクション」→「ルートテーブルの削除」

⑤ my-private-rt も同様に削除する

5. サブネットを削除する（2つ）

VPC → サブネット → my-public-subnet → 「アクション」→「サブネットを削除」

同様に my-private-subnet も削除します。

6. インターネットゲートウェイをデタッチ・削除する

VPC → インターネットゲートウェイ → my-igw → 「アクション」→「VPCからデタッチ」

デタッチ完了後、「アクション」→「インターネットゲートウェイの削除」。

7. VPCを削除する

VPC → お使いのVPC → my-vpc → 「アクション」→「VPCを削除」

8. IAMロールを削除する

IAM → ロール → my-ec2-2tier-role → 「削除」

9. キーペアを削除する（任意）

EC2 → キーペア → my-ec2-2tier-key → 「削除」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

CloudFormation版との比較

コンソール版で実感できたポイント:

• VPC・IGW・サブネット・ルートテーブルの依存関係が視覚的に理解できる
• プライベートサブネットにEC2を置くとパブリックIPが付かないことを実感できる
• 踏み台接続（APサーバ経由でDBサーバにSSH）の意味と手順が身につく
• S3 VPC Endpointがなければ dnf install が失敗することを体験できる

CloudFormation版でも試してみる: CloudFormationでAP+DB 2層構成（VPC設計）を自動デプロイする手順

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

20ステップ以上の手動作業でリソースを一つひとつ作ると、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 でコマンド1本の差を体感してみてください。

関連記事

-->

The post AWSコンソールでVPC設計からAP+DB 2層構成を構築する手順【踏み台SSH / CloudFormation版との比較付き】 first appeared on CayTech Lab.

はじめに

「コンソールで20ステップかかったVPC設計をコードで再現したい」——それを実現するのが AWS CloudFormation です。

この記事では、template.yaml 1ファイルにVPC・サブネット・ルートテーブル・セキュリティグループ・EC2（2台）を定義し、コマンド1本でAP+DB 2層構成を一括構築するハンズオンを紹介します。コンソール版（AWSコンソール版ハンズオン）と全く同じ構成を、CloudFormationで自動化します。

ローカル環境（VSCode）
  └── template.yaml + AWS CLI
        ↓ スタック作成（コマンド1本）
AWS環境
  └── VPC（10.0.0.0/16）
        ├── インターネットゲートウェイ
        │
        ├── [パブリックサブネット 10.0.1.0/24]
        │     ├── パブリックルートテーブル（0.0.0.0/0 → IGW）
        │     └── APサーバEC2（Apache / パブリックIP あり）
        │
        └── [プライベートサブネット 10.0.2.0/24]
              ├── プライベートルートテーブル（VPC内のみ）
              ├── S3 VPC Gateway Endpoint（dnf用・無料）
              └── DBサーバEC2（MariaDB / パブリックIP なし）

このハンズオンで体験できること：

• VPC・サブネット・IGW・ルートテーブルを template.yaml 1ファイルで定義する方法
• S3 VPC Gateway Endpoint の DependsOn による起動順序制御
• SubnetId でEC2の配置サブネットを明示する方法
• aws cloudformation create-stack コマンド1本での17リソース一括デプロイ
• delete-stack による複雑な依存関係を持つVPCリソースの一括削除

このハンズオンの特徴：

• コンソール版では20ステップ以上・30〜40分かかった作業が、コマンド1本（8〜12分）で完了
• delete-stack 1本でVPC・サブネット・IGW・RTの依存関係を自動解決して削除

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

AWS認証確認:

aws sts get-caller-identity

template.yaml の全文

以下が今回使用する template.yaml の全文です（17リソース）。プロジェクトフォルダ（ec2-2tier-web/）直下に配置します。

⚠️ コピー前に確認: Default: '123.456.78.901/32' の箇所はダミーIPです。このまま使うとスタック作成は成功しますが、SSHもWebもアクセスできません。--parameters でIPを上書きするか（推奨）、Defaultを自分のIPに書き換えてから使ってください。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EC2 2-tier Architecture (AP + DB) with VPC public/private subnet separation (Phase 1-4)'

Parameters:
  KeyName:
    Type: String
    Default: 'my-ec2-2tier-key'
    Description: Name of an existing EC2 KeyPair

  MyIP:
    Type: String
    Default: '123.456.78.901/32'
    Description: Your IP address to allow SSH and HTTP access (CIDR format e.g. 203.0.113.1/32)

Resources:

  # VPC and Network
  # ============================================================

  # VPC: isolated network space for this hands-on
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: 'my-vpc'

  # Internet Gateway: connects the VPC to the internet
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: 'my-igw'

  # Attach Internet Gateway to VPC
  IGWAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway

  # Public Subnet: AP server goes here (internet accessible)
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: 'my-public-subnet'

  # Private Subnet: DB server goes here (no direct internet access)
  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.2.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: 'my-private-subnet'

  # Public Route Table: routes internet traffic via Internet Gateway
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: 'my-public-rt'

  # Default route for public subnet: all traffic -> Internet Gateway
  PublicRoute:
    Type: AWS::EC2::Route
    DependsOn: IGWAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  # Associate public subnet with public route table
  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

  # Private Route Table: no internet route (local traffic only)
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: 'my-private-rt'

  # Associate private subnet with private route table
  PrivateSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable

  # S3 VPC Gateway Endpoint: allows private subnet to reach S3 (for dnf package downloads)
  # Gateway endpoints are FREE - no hourly charge
  S3VPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId: !Ref VPC
      ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
      VpcEndpointType: Gateway
      RouteTableIds:
        - !Ref PrivateRouteTable

  # ============================================================
  # IAM
  # ============================================================

  # IAM Role: allows EC2 to use Session Manager
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'my-ec2-2tier-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Tags:
        - Key: Name
          Value: 'my-ec2-2tier-role'

  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: 'my-ec2-2tier-profile'
      Roles:
        - !Ref EC2Role

  # ============================================================
  # Security Groups
  # ============================================================

  # AP Server Security Group: SSH and HTTP from MyIP
  APSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my AP server SG (public subnet)'
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH from my IP
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref MyIP
          Description: HTTP from my IP
      Tags:
        - Key: Name
          Value: 'my-ap-sg'

  # DB Server Security Group: MySQL from AP SG only, SSH from AP SG (via bastion)
  DBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my DB server SG (private subnet)'
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId
          Description: SSH from AP server only (bastion access)
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId
          Description: MySQL from AP server only (SG-to-SG control)
      Tags:
        - Key: Name
          Value: 'my-db-sg'

  # ============================================================
  # EC2 Instances
  # ============================================================

  # AP Server: Apache in public subnet
  APInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !GetAtt APSecurityGroup.GroupId
      IamInstanceProfile: !Ref EC2InstanceProfile
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y httpd
          systemctl start httpd
          systemctl enable httpd
          cat > /var/www/html/index.html << 'HTMLEOF'
          <!DOCTYPE html>
          <html>
          <head><meta charset="UTF-8"><title>AP Server - Phase 1-4</title></head>
          <body>
          <h1>AP Server (Public Subnet)</h1>
          <p>This AP server is in the PUBLIC subnet and can reach the DB server in the PRIVATE subnet.</p>
          </body>
          </html>
          HTMLEOF
      Tags:
        - Key: Name
          Value: 'my-ap-instance'

  # DB Server: MariaDB in private subnet (no public IP)
  DBInstance:
    Type: AWS::EC2::Instance
    DependsOn:
      - S3VPCEndpoint
      - PrivateSubnetRouteTableAssociation
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SubnetId: !Ref PrivateSubnet
      SecurityGroupIds:
        - !GetAtt DBSecurityGroup.GroupId
      IamInstanceProfile: !Ref EC2InstanceProfile
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y mariadb105-server mariadb105
          systemctl start mariadb
          systemctl enable mariadb
          sudo mysql -u root << 'SQLEOF'
          SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
          CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
          GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
          CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
          FLUSH PRIVILEGES;
          SQLEOF
      Tags:
        - Key: Name
          Value: 'my-db-instance'

Outputs:
  VPCId:
    Description: VPC ID
    Value: !Ref VPC

  APPublicIP:
    Description: AP server public IP (open in browser or SSH)
    Value: !GetAtt APInstance.PublicIp

  DBPrivateIP:
    Description: DB server private IP (connect via AP server bastion)
    Value: !GetAtt DBInstance.PrivateIp

  WebsiteURL:
    Description: AP server website URL
    Value: !Sub 'http://${APInstance.PublicIp}'

  APSSHCommand:
    Description: SSH command to AP server
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${APInstance.PublicIp}'

  DBSSHCommand:
    Description: SSH command to DB server (run this FROM the AP server)
    Value: !Sub 'ssh -i ~/.ssh/${KeyName}.pem ec2-user@${DBInstance.PrivateIp}'

  MySQLConnectCommand:
    Description: MySQL connect command (run this FROM the AP server)
    Value: !Sub 'mysql -h ${DBInstance.PrivateIp} -u handson -pHandson1234! sampledb'

template.yaml の重要ポイント:

1. VpcId を指定した SecurityGroup

カスタムVPCを使う場合は VpcId を明示します。VpcId を指定することで !GetAtt APSecurityGroup.GroupId が確実にSG IDを返します。

APSecurityGroup:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !Ref VPC      # ← カスタムVPCを指定（必須）

DBSecurityGroup:
  SecurityGroupIngress:
    - SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId  # ← !Refではなく!GetAtt

2. S3 VPC Gateway Endpoint（無料）

プライベートサブネットのEC2は直接インターネットに出られませんが、Amazon Linux 2023のパッケージリポジトリはS3上にあります。S3 VPC Gateway EndpointをプライベートルートテーブルにアタッチするとS3経由で dnf install が動作します。

S3VPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Gateway     # Gatewayタイプは無料
    ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
    RouteTableIds:
      - !Ref PrivateRouteTable   # プライベートRTにS3ルートが追加される

3. DBInstance の DependsOn

DBサーバEC2のUserDataが dnf install を実行するとき、S3 VPC Endpointが有効になっている必要があります。

DBInstance:
  DependsOn:
    - S3VPCEndpoint
    - PrivateSubnetRouteTableAssociation

4. SubnetId でサブネットを指定

EC2インスタンスがどのサブネットに配置されるかを明示します。

APInstance:
  SubnetId: !Ref PublicSubnet   # パブリックサブネットに配置

DBInstance:
  SubnetId: !Ref PrivateSubnet  # プライベートサブネットに配置

構築されるリソース一覧（17個）:

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② プロジェクトフォルダに移動する
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成完了・Outputsを確認する
      ↓
⑤ 動作確認（Web・踏み台SSH・MySQL接続）
      ↓
⑥ スタックを削除する（aws cloudformation delete-stack）

⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

キーペアのみコンソールで作成します。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

② プロジェクトフォルダに移動する

cd C:\my-aws\aws-learning-projects\ec2-2tier-web

dir template.yaml

③ スタックの作成

203.0.113.1 は⓪で確認した自分のIPアドレスに置き換えてください。

aws cloudformation create-stack ^
  --stack-name my-ec2-2tier-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-ec2-2tier-key ^
    ParameterKey=MyIP,ParameterValue=203.0.113.1/32

各オプションの説明:

成功するとStackIdが表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-ec2-2tier-stack/xxxxx"
}

④ 作成完了・Outputsの確認

スタック作成完了まで約8〜12分かかります（VPCリソース×10個 + EC2×2台 + MariaDBインストールの時間）。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

以下のような出力が表示されます。

--------------------------------------------------------------------------------------
|                                  DescribeStacks                                    |
+--------------------+---------------------------------------------------------------+
|  OutputKey         |  OutputValue                                                  |
+--------------------+---------------------------------------------------------------+
|  VPCId             |  vpc-xxxxxxxxxx                                              |
|  APPublicIP        |  x.x.x.x                                                    |
|  DBPrivateIP       |  10.0.2.xxx   ← APサーバからの接続に使用                    |
|  WebsiteURL        |  http://x.x.x.x                                             |
|  APSSHCommand      |  ssh -i ...pem ec2-user@x.x.x.x                            |
|  DBSSHCommand      |  ssh -i ~/.ssh/...pem ec2-user@10.0.2.xxx                  |
|  MySQLConnectCommand| mysql -h 10.0.2.xxx -u handson -pHandson1234! sampledb     |
+--------------------+---------------------------------------------------------------+

控えておく情報:

• APPublicIP: APサーバのパブリックIP
• DBPrivateIP: DBサーバのプライベートIP（10.0.2.xxx 形式）
• APSSHCommand: APサーバへのSSHコマンド
• DBSSHCommand: APサーバからDBサーバへのSSHコマンド
• MySQLConnectCommand: APサーバから実行するMySQL接続コマンド

⑤ 動作確認

5-1. APサーバのWeb確認

WebsiteURL をブラウザで開きます。AP Server (Public Subnet) が表示されれば成功です。

5-2. APサーバへのSSH接続

APSSHCommand を実行します（パスを実際のパスに修正します）。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ec2-user@（APPublicIP）

5-3. キーペアをAPサーバにコピーする（踏み台SSH準備）

ローカルPCの別ターミナルで実行します:

scp -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  ec2-user@（APPublicIP）:~/.ssh/

APサーバのSSHセッションでパーミッションを設定します。

chmod 400 ~/.ssh/my-ec2-2tier-key.pem

5-4. APサーバ経由でDBサーバにSSH接続（踏み台接続）

APサーバのSSHセッションから実行します:

ssh -i ~/.ssh/my-ec2-2tier-key.pem ec2-user@（DBPrivateIP）

[ec2-user@ip-10-0-2-xxx ~]$ が表示されれば踏み台接続成功です。

# DBサーバ上でMariaDBの状態を確認
sudo systemctl status mariadb

# MariaDBに接続
mysql -u root -pAdmin1234! -e "SHOW DATABASES;"

exit

5-5. APサーバからMySQLに接続（AP→DB通信確認）

APサーバのSSHセッションに戻り、MySQLConnectCommand をそのまま実行します。

# mysqlクライアントをインストール
sudo dnf install -y mariadb105

# OutputsのMySQLConnectCommandをそのまま使う
mysql -h （DBPrivateIP） -u handson -pHandson1234! sampledb

CREATE TABLE IF NOT EXISTS messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(100));
INSERT INTO messages (text) VALUES ('Hello from AP server!');
SELECT * FROM messages;
EXIT;

exit

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。

CloudFormationはVPC・サブネット・IGW・RT・SG・EC2の依存関係を自動解決して正しい順序で削除します。

aws cloudformation delete-stack ^
  --stack-name my-ec2-2tier-stack ^
  --region ap-northeast-1

削除完了まで約8〜12分かかります。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --region ap-northeast-1

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-ec2-2tier-stack does not exist

キーペアは手動で削除します。

EC2 → キーペア → my-ec2-2tier-key → 「削除」

コンソール版との比較

コンソール版で20ステップ以上かかった作業が、CloudFormationでは template.yaml に定義されています。

トラブルシューティング

まとめ

今回のハンズオンで実現できたこと：

CloudFormationのメリットを実感できたポイント

• コンソール版では20ステップ以上・30〜40分かかった作業がコマンド1本（8〜12分）で完了
• VPC・サブネット・RT・SGの複雑な削除順序をCloudFormationが自動管理
• template.yaml をGitで管理することで、ネットワーク設計の変更履歴が残せる

コンソール版と比較してみる

CloudFormationが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。VPCリソースの作成・削除順序や依存関係を視覚的に確認できます。

AWSコンソールでVPC設計からAP+DB 2層構成を構築する手順

関連記事

-->

The post CloudFormationでAP+DB 2層構成（VPC設計）を自動デプロイする手順【踏み台SSH / コンソール版との比較付き】 first appeared on CayTech Lab.

はじめに

「EC2インスタンスを立ち上げてWebサーバーを動かしたい」——AWSを学ぶうえで避けて通れない基本中の基本です。

この記事では、AWSコンソール（GUI）のみを使って、Apacheウェブサーバーが動作するEC2インスタンスをゼロから手動で構築するハンズオンを紹介します。

インターネット
  ↓ HTTP（ポート80）    ← ブラウザでアクセス
  ↓ SSH（ポート22）     ← ターミナルで接続
セキュリティグループ（ファイアウォール）
  ↓ 自分のIPのみ通過させる
EC2インスタンス（t2.micro / Amazon Linux 2023）
  ├── Apache httpd（UserDataで自動インストール）
  │     └── /var/www/html/index.html を返す
  └── IAMロール（Session Manager接続用）

このハンズオンで体験できること：

• EC2インスタンスの基本操作（起動・設定・終了）
• セキュリティグループによるポートアクセス制御（SSH:22 / HTTP:80）
• UserData を使った初回起動時の Apache 自動インストール
• IAMロールによる EC2 への権限付与の仕組み

このハンズオンの特徴：

• キーペア・IAMロール・セキュリティグループ・EC2インスタンスを画面操作で1つずつ作成する
• 手動操作を通じて、各リソースの役割と依存関係を視覚的に理解できる

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でEC2・Apache・セキュリティグループの連携を視覚的に学び、CloudFormationと何が違うのかを比較したい方向けです。

-->

キーワード解説

使用するAWSサービス

注意: 無料枠はAWSアカウント開設から12ヶ月間です。期間終了後はEC2インスタンス稼働時間に課金されます。ハンズオン後は必ずリソースを削除してください。

構築するリソース

全体の作業順序

依存関係があるため、必ずこの順番で作成します。

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ EC2インスタンスを起動する
  （セキュリティグループ・UserDataも同時に設定）
      ↓
④ 動作確認（Web・SSH）
      ↓
⑤ リソースを削除する

【重要】⓪ 自分のIPアドレスを確認する

セキュリティグループで自分のIPだけを許可するために、正確なIPアドレスを事前に確認します。

注意: curl https://checkip.amazonaws.com で表示されるIPと、EC2への実際の接続元IPが一致しない場合があります（ISPやプロキシの経路の違いによる）。最も確実な方法はルーター管理画面での確認です。

方法A: ルーター管理画面で確認（推奨）

1. ブラウザで以下のURLにアクセスします（ルーターによって異なります）

   http://192.168.0.1  または  http://192.168.1.1

2. 「ネットワークマップ」または「インターネット」項目を開く
3. **「インターネットIPアドレス」または「WAN IPアドレス」**の値を控えます

方法B: コマンドで確認

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

キーペアはSSHでEC2に接続するための鍵です。EC2起動時に指定する必要があるため、最初に作成します。

AWSコンソール → EC2 → ネットワーク＆セキュリティ → キーペア → 「キーペアを作成」

「キーペアを作成」をクリックすると、自動的に my-ec2-apache-key.pem がダウンロードされます。

ダウンロードしたキーペアを保存する

ダウンロードされた my-ec2-apache-key.pem を以下の場所に移動します。

C:\Users\ユーザー名\.ssh\my-ec2-apache-key.pem

注意: .pem ファイルは再ダウンロードできません。紛失した場合は新しいキーペアを作成する必要があります。

② IAMロールの作成

Session Manager（ブラウザからEC2に接続できるAWS機能）を使えるようにするためのIAMロールを作成します。

なぜIAMロールが必要か: EC2がAWSのサービス（Session Manager）を利用するには、そのEC2自身に「このサービスを使う権限」を付与する必要があります。この権限の設定がIAMロールです。

AWSコンソール → IAM → ロール → 「ロールを作成」

ステップ1: エンティティタイプとユースケースの選択

「次へ」をクリック。

ステップ2: 許可ポリシーのアタッチ

検索ボックスに AmazonSSMManagedInstanceCore と入力してチェックを入れます。

「次へ」をクリック。

ステップ3: ロール名の設定

「ロールを作成」をクリック。

③ EC2インスタンスの起動

キーペアとIAMロールを作成したあと、EC2インスタンスを起動します。
セキュリティグループとUserData（Apache自動インストール）も同時に設定します。

AWSコンソール → EC2 → インスタンス → 「インスタンスを起動」

3-1. 基本設定

3-2. セキュリティグループの設定

「ネットワーク設定」→「セキュリティグループを作成する」を選択します。

セキュリティグループ名と説明を設定:

「インバウンドセキュリティグループのルールを追加」ボタンで以下の2ルールを追加します。

ルール1: SSH接続の許可

ルール2: HTTPアクセスの許可

/32 とは: 「このIPアドレス1つだけ」という意味のCIDR表記です。0.0.0.0/0 は全世界に開放することになりセキュリティリスクが高いため、必ず自分のIPのみに制限します。

3-3. IAMロールの設定

「高度な詳細」を開く → 「IAM インスタンスプロファイル」→ my-ec2-apache-role を選択します。

3-4. UserDataの設定（Apacheの自動インストール）

「高度な詳細」の一番下にある「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from Amazon Linux 2023!</h1>" > /var/www/html/index.html
echo "<p>Instance ID: $(ec2-metadata --instance-id | cut -d ' ' -f 2)</p>" >> /var/www/html/index.html
echo "<p>Availability Zone: $(ec2-metadata --availability-zone | cut -d ' ' -f 2)</p>" >> /var/www/html/index.html

各コマンドの説明:

UserDataとは: インスタンスの初回起動時のみ自動実行されるシェルスクリプトです。この仕組みを使うことで、EC2起動と同時にApacheのインストールまで自動化できます。

3-5. インスタンスを起動する

「インスタンスを起動」ボタンをクリック。

起動完了まで約2〜3分待ちます。インスタンスの「状態」が「実行中」になったことを確認します。

控えておく情報: インスタンスのパブリックIPアドレス

インスタンス一覧 → 作成したインスタンスをクリック → 「パブリック IPv4 アドレス」を確認してメモします。

④ 動作確認

Webブラウザで確認

ブラウザで以下のURLにアクセスします。

http://（パブリックIPアドレス）

以下のように表示されれば成功です。

Hello from Amazon Linux 2023!
Instance ID: i-0123456789abcdef0
Availability Zone: ap-northeast-1a

表示されない場合: UserDataのApacheインストールが完了するまで2〜3分かかります。少し待ってからリロードしてください。

SSHで接続して確認

ローカルPCのターミナル（VSCode CMD）で実行します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-apache-key.pem ec2-user@（パブリックIPアドレス）

初回接続時に以下の確認が出ます。yes を入力します。

Are you sure you want to continue connecting (yes/no)? yes

接続成功するとAmazon Linux 2023のプロンプトが表示されます。以下で動作確認をします。

sudo systemctl status httpd

# Apacheが返しているHTMLファイルを確認
cat /var/www/html/index.html

# ApacheのドキュメントルートをApacheの設定ファイルで確認
cat /etc/httpd/conf/httpd.conf | grep DocumentRoot

# EC2から切断
exit

Apacheのディレクトリ構成:

【接続できない場合】IPアドレスが異なる可能性

curl で確認したIPを設定したが接続できない場合、実際の接続元IPが異なる可能性があります。

一時的に全開放して真のIPを確認する方法:

コンソール → EC2 → セキュリティグループ → my-ec2-apache-sg → 「インバウンドルールを編集」

SSHのルールを一時的に 0.0.0.0/0 に変更してSSH接続し、以下を実行します。

echo $SSH_CLIENT
# 出力例: 203.0.113.1 17508 22
# 先頭の値が真の接続元IP

このIPをメモしてSSH接続を切断し、セキュリティグループのSSHルールを 真のIP/32 に戻します。

⑤ リソースの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。削除する順番が重要です。

1. EC2インスタンスを終了する

EC2 → インスタンス → my-ec2-apache-instance を選択 → 「インスタンスの状態」→「インスタンスを終了」

確認ダイアログで「終了」をクリック。状態が「終了済み」になるまで待ちます（2〜5分）。

「停止」と「終了」の違い: 「停止」は一時停止（EBSストレージ課金は続く）。「終了」は完全削除（課金停止）。学習後は「終了」を選びます。

2. セキュリティグループを削除する

EC2 → セキュリティグループ → my-ec2-apache-sg を選択 → 「アクション」→「セキュリティグループを削除」

インスタンス終了が完了している必要があります。「使用中」エラーが出る場合はインスタンスが「終了済み」状態になるまで待ってください。

3. IAMロールを削除する

IAM → ロール → my-ec2-apache-role を選択 → 「削除」→ ロール名を入力して確認

4. キーペアを削除する（任意）

他のEC2でも使い回す場合は残してよいです。不要な場合は削除します。

EC2 → キーペア → my-ec2-apache-key を選択 → 「アクション」→「削除」→ 確認テキストを入力

ローカルの .pem ファイルも手動で削除します。

C:\Users\ユーザー名\.ssh\my-ec2-apache-key.pem

CloudFormation版との比較

コンソール版を体験したら、次は同じ構成を CloudFormation（コード）で再現してみましょう。何が自動化されるのかがよくわかります。

コンソール版で実感できたポイント:

• キーペア・IAMロール・セキュリティグループ・EC2の依存関係が視覚的に理解できる
• セキュリティグループのインバウンドルールを手動設定することで、ポートとCIDRの意味が身につく
• UserData の仕組みを実際に設定することで、EC2の初期化フローが理解できる

CloudFormation版でも試してみる: AWS CloudFormationでEC2 + ApacheウェブサーバーをIaC化しよう

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

手動操作でひとつひとつ作ると、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 で同じ構成をコードで再現してみてください。

関連記事

-->

The post AWSコンソールでEC2 + Apacheウェブサーバーを構築する手順【EC2ハンズオン / CloudFormation版との比較付き】 first appeared on CayTech Lab.

はじめに

「コンソールで手動構築できた構成を、コードで再現したい」——それを実現するのが AWS CloudFormation です。

この記事では、template.yaml 1ファイルにリソース構成を定義し、コマンド1本でEC2 + Apache環境を一括構築するハンズオンを紹介します。コンソール版（AWSコンソール版ハンズオン）と全く同じ構成を、CloudFormationで自動化します。

ローカル環境（VSCode）
  ├── template.yaml（CloudFormationテンプレート）
  └── AWS CLI コマンド
        ↓ スタック作成（コマンド1本）
AWS環境
  ├── IAMロール（SSM接続用）         ← template.yamlで定義
  ├── セキュリティグループ（SSH22・HTTP80）← template.yamlで定義
  └── EC2インスタンス（t2.micro / Amazon Linux 2023 + Apache）← template.yamlで定義

このハンズオンで体験できること：

• template.yaml へのリソース定義（IAMロール・セキュリティグループ・EC2インスタンス）
• !Ref / !Sub / !GetAtt を使ったリソース間参照
• aws cloudformation create-stack コマンド1本での全リソース一括デプロイ
• aws cloudformation delete-stack コマンド1本での全リソース一括削除

このハンズオンの特徴：

• コンソール版では15〜20分かかった手動作業が、コマンド1本（約5分）で完了する
• delete-stack 1本で依存関係を考慮した順番で全リソースを自動削除できる

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

AWS認証確認:

aws sts get-caller-identity

アカウントIDが表示されれば認証設定済みです。

template.yaml の全文

以下が今回使用する template.yaml の全文です。プロジェクトフォルダ（ec2-apache-web/）直下に配置します。

⚠️ コピー前に確認: Default: '123.456.78.901/32' の箇所はダミーIPです。このまま使うとスタック作成は成功しますが、SSHもWebもアクセスできません。--parameters でIPを上書きするか（推奨）、Defaultを自分のIPに書き換えてから使ってください。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EC2 + Apache Web Server Hands-on (Phase 1-1)'

Parameters:
  KeyName:
    Type: String
    Default: 'my-ec2-apache-key'
    Description: Name of an existing EC2 KeyPair

  MyIP:
    Type: String
    Default: '123.456.78.901/32'
    Description: Your IP address to allow SSH and HTTP access (CIDR format e.g. 203.0.113.1/32)

Resources:
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'my-ec2-apache-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Tags:
        - Key: Name
          Value: 'my-ec2-apache-role'

  # Instance Profile: wrapper that attaches the IAM role to EC2
  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: 'my-ec2-apache-profile'
      Roles:
        - !Ref EC2Role

  # Security Group: allow SSH(22) and HTTP(80) from MyIP only
  EC2SecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my EC2 Apache hands-on SG'
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH access from my IP
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref MyIP
          Description: HTTP access from my IP
      Tags:
        - Key: Name
          Value: 'my-ec2-apache-sg'

  # EC2 Instance: Amazon Linux 2023 + Apache (installed via UserData)
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      # Automatically fetches the latest Amazon Linux 2023 AMI ID from SSM Parameter Store
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref EC2SecurityGroup
      IamInstanceProfile: !Ref EC2InstanceProfile
      # UserData: shell script executed automatically on first boot
      UserData:
        Fn::Base64: |
          #!/bin/bash
          yum update -y
          yum install -y httpd
          systemctl start httpd
          systemctl enable httpd
          echo "<h1>Hello from Amazon Linux 2023!</h1>" > /var/www/html/index.html
          echo "<p>Instance ID: $(ec2-metadata --instance-id | cut -d ' ' -f 2)</p>" >> /var/www/html/index.html
          echo "<p>Availability Zone: $(ec2-metadata --availability-zone | cut -d ' ' -f 2)</p>" >> /var/www/html/index.html
      Tags:
        - Key: Name
          Value: 'my-ec2-apache-instance'

Outputs:
  InstanceId:
    Description: EC2 Instance ID
    Value: !Ref EC2Instance

  PublicIP:
    Description: Public IP Address
    Value: !GetAtt EC2Instance.PublicIp

  WebsiteURL:
    Description: Website URL (open in browser)
    Value: !Sub 'http://${EC2Instance.PublicIp}'

  SSHCommand:
    Description: SSH command (update the .pem path as needed)
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${EC2Instance.PublicIp}'

!Ref と !Sub の使い分け:

構築されるリソースと論理ID:

作業順序

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② プロジェクトフォルダに移動する
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成状況・Outputsを確認する
      ↓
⑤ 動作確認（Web・SSH）
      ↓
⑥ スタックを削除する（aws cloudformation delete-stack）

【重要】⓪ 自分のIPアドレスを確認する

セキュリティグループで自分のIPのみを許可するために、正確なIPアドレスを事前に確認します。

注意: curl https://checkip.amazonaws.com で表示されるIPと、EC2への実際の接続元IPが一致しない場合があります（ISPやプロキシの経路の違いによる）。

方法A: ルーター管理画面で確認（推奨）

1. ブラウザで以下のURLにアクセスします

   http://192.168.0.1  または  http://192.168.1.1

2. 「ネットワークマップ」または「インターネット」項目を開く
3. **「インターネットIPアドレス」または「WAN IPアドレス」**の値を控えます

方法B: コマンドで確認

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

キーペアのみコンソールで作成します。CloudFormationではキーペアのダウンロードが行えないためです。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

ダウンロードされた my-ec2-apache-key.pem を保存します。

C:\Users\ユーザー名\.ssh\my-ec2-apache-key.pem

② プロジェクトフォルダに移動する

VSCodeのターミナル（CMD）を開き、プロジェクトフォルダに移動します。

cd C:\my-aws\aws-learning-projects\ec2-apache-web

template.yaml があることを確認します。

dir template.yaml

③ スタックの作成

以下のコマンドを実行します。203.0.113.1 は⓪で確認した自分のIPアドレスに置き換えてください。

aws cloudformation create-stack ^
  --stack-name my-ec2-apache-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-ec2-apache-key ^
    ParameterKey=MyIP,ParameterValue=203.0.113.1/32

各オプションの説明:

^ について: Windowsのコマンドプロンプトで長いコマンドを複数行に分けるための改行エスケープ文字です。1行で書いても動作します。

成功すると以下のようなStackIdが表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-ec2-apache-stack/xxxxx"
}

④ 作成完了・Outputsの確認

スタック作成は完了まで約3〜5分かかります。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-apache-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs（接続情報）の確認

CREATE_COMPLETE になったら以下を実行します。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-apache-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

以下のような出力が表示されます。

------------------------------------------------------------------------------------
|                              DescribeStacks                                      |
+----------------+-----------------------------------------------------------------+
|  OutputKey     |  OutputValue                                                    |
+----------------+-----------------------------------------------------------------+
|  InstanceId    |  i-0123456789abcdef0                                           |
|  PublicIP      |  x.x.x.x                                                       |
|  WebsiteURL    |  http://x.x.x.x                                                |
|  SSHCommand    |  ssh -i C:\Users\...\.ssh\my-ec2-apache-key.pem ec2-user@x.x.x.x |
+----------------+-----------------------------------------------------------------+

控えておく情報: PublicIP と WebsiteURL

⑤ 動作確認

Webブラウザで確認

Outputsに表示された WebsiteURL（http://x.x.x.x）をブラウザで開きます。

Hello from Amazon Linux 2023!
Instance ID: i-0123456789abcdef0
Availability Zone: ap-northeast-1a

が表示されれば成功です。

表示されない場合: UserDataのApacheインストールが完了するまで2〜3分かかります。少し待ってからリロードしてください。

SSHで接続して確認

Outputsに表示された SSHCommand のコマンドを実行します（パスは実際のパスに修正します）。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-apache-key.pem ec2-user@（PublicIP）

初回接続時の確認には yes を入力します。

# Apacheの動作状態を確認（active (running) と表示されれば正常）
sudo systemctl status httpd

# ApacheのHTMLファイルを確認
cat /var/www/html/index.html

# EC2から切断
exit

【接続できない場合】真のIPアドレスを確認する

curl で確認したIPを設定したが接続できない場合、実際の接続元IPが異なる可能性があります。

セキュリティグループIDを取得:

aws cloudformation describe-stack-resources ^
  --stack-name my-ec2-apache-stack ^
  --query "StackResources[?ResourceType=='AWS::EC2::SecurityGroup'].PhysicalResourceId" ^
  --output text

SSH全開放（一時的・テスト用）:

aws ec2 authorize-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 0.0.0.0/0 ^
  --region ap-northeast-1

SSH接続して真のIPを確認します。

echo $SSH_CLIENT
# 出力例: 203.0.113.1 17508 22
# 先頭の値が真の接続元IP
exit

確認後、全開放を削除して真のIPで制限し直します。

rem 全開放を削除
aws ec2 revoke-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 0.0.0.0/0 ^
  --region ap-northeast-1

rem 真のIPで再制限
aws ec2 authorize-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 真のIP/32 ^
  --region ap-northeast-1

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。

CloudFormationはスタック削除で全リソースを一括削除できます。手動でリソースを1つ1つ削除する必要はありません。

aws cloudformation delete-stack ^
  --stack-name my-ec2-apache-stack ^
  --region ap-northeast-1

削除の進行状況を確認します（完了まで約3〜5分）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-apache-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-apache-stack ^
  --region ap-northeast-1

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-ec2-apache-stack does not exist

このメッセージが表示されれば削除完了です。キーペアはCloudFormationで管理していないため、手動で削除します。

EC2 → キーペア → my-ec2-apache-key を選択 → 「アクション」→「削除」

ローカルの .pem ファイルも削除します。

コンソール版との比較

コンソール版でIAMロール・セキュリティグループ・EC2を手動作成した手順が、CloudFormationではすべて template.yaml に定義されています。

コンソール版で詰まりやすいポイント:
セキュリティグループ削除時に「使用中」エラーが出るのは、EC2インスタンスが「終了済み」になっていないためです。
CloudFormationなら削除順序を自動で解決してくれるので、このエラーは発生しません。

トラブルシューティング

まとめ

今回のハンズオンで実現できたこと：

CloudFormationのメリットを実感できたポイント

• コンソール版では15〜20分かかった作業がコマンド1本（5分）で完了した
• delete-stack で依存関係を気にせず全リソースを一括削除できた
• template.yaml をGitで管理することで、環境構成の変更履歴が残せる

コンソール版と比較してみる

CloudFormationが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。コンソール版ではキーペア・IAMロール・セキュリティグループ・EC2を依存関係順に手動で作成する必要があり、各リソースの役割と繋がりが視覚的に理解できます。

関連記事

-->

The post AWS CloudFormationでEC2 + ApacheウェブサーバーをIaC化しよう【EC2ハンズオン / コンソール版との比較付き】 first appeared on CayTech Lab.