はじめに

「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.

はじめに

「EC2サーバでデータベースを動かしたい」「EC2同士の通信をセキュアに制御したい」——そのステップがこのハンズオンです。

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

インターネット
  ↓ SSH(22)              ← 自分のIPのみ
  ↓ MySQL(3306)          ← 自分のIPのみ（初期テスト用）
my-ec2-mysql-db-sg（DBサーバSG）
  ↓ MySQL(3306)          ← my-ec2-mysql-client-sg に属するEC2のみ ★SG参照
EC2インスタンス（DBサーバ）       EC2インスタンス（クライアント）
  └── MariaDB 10.5              └── mysqlコマンド（接続テスト用）
        └── sampledb（DB）             ↑
                           my-ec2-mysql-client-sg（クライアントSG）
                             ↓ SSH(22) ← 自分のIPのみ
                           インターネット

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

• セキュリティグループの SG参照（SG-to-SG） による EC2間通信制御
• EC2サーバへの MariaDB（MySQL互換）インストールと初期設定
• 2台のEC2（DBサーバ + クライアント）を使った実際のDB接続確認
• IPアドレス指定 vs SG参照の違いを体感

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

DBサーバのMySQLポート（3306）を「特定のIPアドレス」ではなく「特定のセキュリティグループに属するEC2」だけに開放します。これが SG参照（SG-to-SG） と呼ばれる設定方法で、IPが変わっても自動的に制御できる、本番環境でも使われるセキュアな設計です。

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でSG参照の仕組みを視覚的に学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

IPアドレス指定 vs SG参照

今回のハンズオンで学ぶ「SG参照」がなぜ重要かを確認します。

前フェーズとの比較

使用するAWSサービス

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

構築するリソース

全体の作業順序

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

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ クライアントSGを作成する（先に作成する必要がある）
      ↓
④ DBサーバSGを作成する（③のSGを参照する）
      ↓
⑤ DBサーバEC2を起動する
      ↓
⑥ クライアントEC2を起動する
      ↓
⑦ 動作確認（DBサーバ・クライアント）
      ↓
⑧ リソースを削除する

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

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

方法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）

① キーペアの作成

DBサーバとクライアントEC2の両方のSSH接続に使います。1つのキーペアを共用します。

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

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

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

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

② IAMロールの作成

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

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

③ クライアントSGの作成

なぜ先に作るか: DBサーバSGの設定でクライアントSGを「参照先」として指定する必要があるため、先に作成しておく必要があります。

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

インバウンドルール（「ルールを追加」）:

アウトバウンドルールを確認します:

SG作成画面の「アウトバウンドルール」欄に以下のルールが自動設定されていることを確認します。

重要: このアウトバウンドルールがないとEC2がインターネットに出られず、dnf install でパッケージをダウンロードできなくなります。自動設定されていない場合は「ルールを追加」で追加してください。

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

④ DBサーバSGの作成（SG参照の設定）

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

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

ルール1: SSH（管理用）

ルール2: MySQL（クライアントSGからの接続）← このハンズオンの核心

ここがSG参照: ソースとして「IPアドレス」ではなく「セキュリティグループ」を指定しています。my-ec2-mysql-client-sg に属するEC2からのMySQL接続のみを許可し、インターネットからは接続できません。

ルール3: MySQL（自分のIPからの接続）← 初期テスト・確認用

アウトバウンドルールを確認します:

「アウトバウンドルール」欄に「すべてのトラフィック / 0.0.0.0/0」が設定されていることを確認します（クライアントSGと同様）。

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

⑤ DBサーバEC2の起動

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

5-1. 基本設定

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

「ネットワーク設定」→「既存のセキュリティグループを選択する」→ my-ec2-mysql-db-sg を選択します。

注意: 「セキュリティグループを作成する」ではなく「既存のセキュリティグループを選択する」を選びます。④で作成済みの my-ec2-mysql-db-sg を指定します。

5-3. IAMロールの設定

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

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

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

#!/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

各コマンドの説明:

sudo mysql -u root について: MariaDB インストール直後の root は unix_socket 認証（OSのrootユーザーとして接続）が有効になっています。-p でパスワードを指定すると ERROR 1698 Access denied になるため、初回設定は sudo mysql -u root（パスワードなし）で接続します。

パスワードについて: このハンズオンでは学習用として Admin1234! / Handson1234! を使用しています。本番環境では必ず強力なパスワードに変更してください。

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

「インスタンスを起動」をクリック。起動後2〜3分待ちます。

控えておく情報:

• DBサーバのパブリックIPアドレス
• DBサーバのプライベートIPアドレス（クライアントEC2からの接続に使用）

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

⑥ クライアントEC2の起動

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

6-1. 基本設定

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

「ネットワーク設定」→「既存のセキュリティグループを選択する」→ my-ec2-mysql-client-sg を選択します。

6-3. IAMロールの設定

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

6-4. UserDataの設定（mysqlクライアントのインストール）

#!/bin/bash
dnf update -y
dnf install -y mariadb105

mysqlコマンド（クライアントツール）のみをインストールします。DBサーバ機能（mariadb105-server）はインストールしません。

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

「インスタンスを起動」をクリック。起動完了まで約2〜3分待ちます。

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

⑦ 動作確認

7-1. DBサーバの動作確認

DBサーバにSSH接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（DBサーバのパブリックIP）

接続後に以下を実行します。

sudo systemctl status mariadb

# MariaDBのバージョン確認
mysql --version

# rootでログイン（パスワード: Admin1234!）
mysql -u root -pAdmin1234!

MariaDBのプロンプト（MariaDB [(none)]>）が表示されたら以下を実行します。

-- ユーザー一覧を確認
SELECT User, Host FROM mysql.user;

-- データベース一覧を確認（sampledb が存在することを確認）
SHOW DATABASES;

-- sampledbに接続
USE sampledb;

-- テスト用のテーブルを作成
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- データを挿入
INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

-- データを確認
SELECT * FROM users;

-- MariaDBから切断
EXIT;

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

exit

7-2. SG参照の確認：クライアントEC2からMySQL接続

クライアントEC2に接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（クライアントのパブリックIP）

クライアントEC2からDBサーバのプライベートIPに向けてMySQL接続します。

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

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

-- DBサーバで作成したデータが見えることを確認
SELECT * FROM users;

EXIT;

exit

プライベートIPを使う理由: EC2間の通信は同じVPC内なのでプライベートIPで通信できます。パブリックIPを使うとインターネットを経由してしまい、セキュリティ上も効率上も好ましくありません。

7-3. SG参照の効果を確認する（任意・スキップ可）

前提: ローカルPCに mysql クライアントがインストールされている場合のみ実施します。7-2でクライアントEC2からの接続が成功していれば、このハンズオンの学習目的（SG参照によるEC2間通信制御）は達成済みです。

ローカルPCに mysql コマンドがある場合、ローカルターミナルで以下を実行します。

mysql -h （DBサーバのパブリックIP） -u handson -pHandson1234! sampledb

補足: 今回のSGにはルール3（自分のIPからのMySQL許可）を追加しているため接続できます。ルール3を削除すると、インターネットからの接続は完全に遮断されます。本番環境ではルール3を削除し、クライアントSG参照のみにするのがベストプラクティスです。

⑧ リソースの削除

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

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

EC2 → インスタンス → my-ec2-mysql-db-instance と my-ec2-mysql-client-instance を両方選択 → 「インスタンスの状態」→「インスタンスを終了」

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

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

注意: 先にDBサーバSGを削除します。クライアントSGはDBサーバSGから参照されているため、先にDBサーバSGを削除しないとエラーになります。

① DBサーバSGを先に削除します:

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

② クライアントSGを削除します:

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

3. IAMロールを削除する

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

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

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

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

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

CloudFormation版との比較

コンソール版を体験したら、次は同じ構成をCloudFormation（コード）で再現してみましょう。特にSGの依存関係管理が自動化される点を体験できます。

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

• SGを削除する際にDBサーバSG → クライアントSGの順番が必要なことを体験できる
• SG参照の設定でソースにIPではなくSGを指定する操作の意味が視覚的に理解できる
• プライベートIPで通信している様子を直接確認できる

CloudFormation版でも試してみる: EC2サーバ構築をIaC化：CloudFormationでEC2 MySQLのDBサーバを自動デプロイする手順

トラブルシューティング

まとめ

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

SG参照を手動で設定・確認することで、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 で同じ構成をコードで再現してみてください。

関連記事

-->

The post EC2サーバ構築ハンズオン：AWSコンソールでEC2 MySQLのDBサーバを構築する手順【SG参照 / CloudFormation版との比較付き】 first appeared on CayTech Lab.

はじめに

「EC2サーバ上でJavaアプリを動かしたい」——ApacheでHTMLを返せるようになったら、次はJavaが実行できるAPサーバー（Tomcat）に挑戦しましょう。

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

インターネット
  ↓ TCP 8080（Tomcat HTTP）← ブラウザでアクセス
  ↓ TCP 22（SSH）          ← ターミナルで接続
セキュリティグループ（ファイアウォール）
  ↓ 自分のIPのみ通過させる
EC2インスタンス（t2.micro / Amazon Linux 2023）
  ├── Java 17（Amazon Corretto）← Tomcatの実行基盤
  ├── Tomcat 10.1（APサーバー）← UserDataで自動インストール
  │     └── /opt/tomcat/latest/webapps/ROOT/index.jsp を返す
  └── IAMロール（Session Manager接続用）

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

• EC2サーバーへのJava 17（Amazon Corretto）とTomcat 10のインストール
• セキュリティグループによるポートアクセス制御（SSH:22 / Tomcat:8080）
• UserDataを使ったJava + Tomcatの初回起動時自動インストール
• JSPが実行されていることをブラウザで確認（Apacheの静的HTMLとの違い）

このハンズオンの特徴：

• Apache版（Phase 1-1）の次のステップとして、APサーバーとWebサーバーの違いを体験できる
• 手動操作を通じて、各リソースの役割と依存関係を視覚的に理解できる

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でEC2 Tomcatサーバー構築の全体像を学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

Apache（Webサーバー）と Tomcat（APサーバー）の違い

使用するAWSサービス

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

構築するリソース

全体の作業順序

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

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ EC2インスタンスを起動する
  （セキュリティグループ・UserDataも同時に設定）
      ↓
④ 動作確認（ブラウザ・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-tomcat-key.pem がダウンロードされます。

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

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

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

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

前回のキーペアの流用について: EC2 + Apacheハンズオンで作成した my-ec2-apache-key を流用しても動作します。その場合この手順はスキップします。

② IAMロールの作成

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

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

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

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

「次へ」をクリック。

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

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

「次へ」をクリック。

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

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

③ EC2インスタンスの起動

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

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

3-1. 基本設定

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

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

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

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

ルール1: SSH接続の許可

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

ポート8080について: TomcatはデフォルトでHTTP 8080番ポートをListenします。Apacheの80番とは異なるため、セキュリティグループでも8080を明示的に開ける必要があります。

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

3-3. IAMロールの設定

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

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

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

#!/bin/bash
dnf update -y
dnf install -y java-17-amazon-corretto

useradd -m -d /opt/tomcat -U -s /bin/false tomcat

TOMCAT_VERSION="10.1.25"
cd /tmp
wget -q "https://archive.apache.org/dist/tomcat/tomcat-10/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz" \
  -O apache-tomcat.tar.gz
tar xzf apache-tomcat.tar.gz
mv "apache-tomcat-${TOMCAT_VERSION}" /opt/tomcat/latest
chown -R tomcat:tomcat /opt/tomcat
chmod -R u+x /opt/tomcat/latest/bin

cat > /etc/systemd/system/tomcat.service << 'SVCEOF'
[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto"
Environment="CATALINA_HOME=/opt/tomcat/latest"
Environment="CATALINA_BASE=/opt/tomcat/latest"
Environment="CATALINA_PID=/opt/tomcat/latest/temp/tomcat.pid"
Environment="JAVA_OPTS=-Xms256m -Xmx512m"
ExecStart=/opt/tomcat/latest/bin/startup.sh
ExecStop=/opt/tomcat/latest/bin/shutdown.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target
SVCEOF

systemctl daemon-reload
systemctl enable tomcat
systemctl start tomcat

cat > /opt/tomcat/latest/webapps/ROOT/index.jsp << 'JSPEOF'
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>Tomcat on EC2</title></head>
<body>
<h1>Hello from Tomcat on Amazon Linux 2023!</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
<p>Tomcat Version: <%= application.getServerInfo() %></p>
</body>
</html>
JSPEOF
chown tomcat:tomcat /opt/tomcat/latest/webapps/ROOT/index.jsp

各コマンドの説明:

Amazon Corretto（コレット）とは: AWSが提供するOpenJDKのディストリビューション。無償・本番利用可能で、Amazon Linux 2023のパッケージリポジトリから直接インストールできます。

JAVA_OPTS=-Xms256m -Xmx512m: Javaの使用メモリを制限する設定です。t2.microは1GBのメモリしかないため、最小256MB・最大512MBに制限して他のプロセスと共存できるようにしています。

UserDataはインスタンスの初回起動時のみ実行されます。Tomcatのダウンロードを含むため、完了まで約5〜10分かかります。

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

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

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

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

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

④ 動作確認

重要: UserDataでのJava + Tomcatインストールが完了するまで約5〜10分かかります。インスタンスが「実行中」になってもすぐには接続できません。

ブラウザで確認

ブラウザで以下のURLにアクセスします。ポート番号 8080 を忘れずに入力してください。

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

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

Hello from Tomcat on Amazon Linux 2023!
Java Version: 17.x.x
Tomcat Version: Apache Tomcat/10.1.25

JSPが実行されている証拠: Java Version や Tomcat Version はJavaコード（<%= ... %>）がサーバー側で実行されて表示されています。ApacheのHTMLと違い、TomcatがJavaを動かして動的にページを生成しています。

表示されない場合: UserDataのインストールが完了していない可能性があります。5〜10分待ってからリロードしてください。それでも表示されない場合はSSHで接続してログを確認します。

SSHで接続して確認

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

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

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

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

接続できたら以下を実行します。

java -version

# Tomcatサービスの動作状態を確認（active (running) と表示されれば正常）
sudo systemctl status tomcat

# TomcatのメインログでERRORがないか確認
sudo tail -50 /opt/tomcat/latest/logs/catalina.out

# Tomcatが8080番ポートをListenしているか確認
sudo ss -tlnp | grep :8080

# EC2から切断
exit

Tomcatのディレクトリ構成:

UserDataのインストール状況を確認する方法

インスタンスにSSHで接続できた場合、UserDataの実行ログで進捗を確認できます。

# UserDataのログを確認（インストールの進捗・エラーを確認できる）
sudo cat /var/log/cloud-init-output.log

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

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

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

コンソール → EC2 → セキュリティグループ → my-ec2-tomcat-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-tomcat-instance を選択 → 「インスタンスの状態」→「インスタンスを終了」

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

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

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

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

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

3. IAMロールを削除する

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

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

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

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

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

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

CloudFormation版との比較

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

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

• Java + Tomcatのインストール手順が長く、手動では設定ミスが起きやすいことを実感できる
• ポート8080の開放やTomcatユーザーの作成など、セキュリティ設定の重要性が身につく
• UserDataの完了を待つ間に、コンソール版とCloudFormation版の差が体感できる

CloudFormation版でも試してみる: EC2サーバ構築をIaC化：CloudFormationでEC2 Tomcatを自動デプロイする手順

トラブルシューティング

まとめ

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

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

関連記事

-->

The post EC2サーバ構築ハンズオン：AWSコンソールでTomcatを構築する手順【EC2 Tomcat / CloudFormation版との比較付き】 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.

はじめに

「チャットボットの会話ログをAPIで受け取り、AWSに蓄積したい」——そんな要件を実現する構成が API Gateway + Lambda + CloudWatch Logs の組み合わせです。

この記事では、AWSコンソールのみを使って、チャットボットの会話ログを記録・取得するREST APIをゼロから構築するハンズオンを紹介します。

クライアント
  ↓ POST /logs（会話ログを送信）
API Gateway（REST API）
  ↓ Lambda プロキシ統合
Lambda（ChatLogFunction / Python 3.12）
  ↓ boto3 logs.put_log_events()
CloudWatch Log Group（/chatbot/chatbot-logs）
  ↓ Metric Filter（level = "error" のログを検出）
CloudWatch カスタムメトリクス（ChatErrorCount）

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

• API Gateway REST API のリソース・メソッド作成と Lambda プロキシ統合
• CloudWatch Logs カスタムロググループへのログ書き込み（put_log_events）
• Metric Filter によるエラーログの自動メトリクス変換
• CloudWatch Logs Insights でのログクエリ実行

この記事は SAM版ハンズオン の比較記事です。
コンソール操作でAPI Gateway・Lambda・CloudWatch Logsの連携を視覚的に学び、SAM と何が違うのかを比較したい方向けです。

Amazon検索[本 AWS 開発]

キーワード解説

使用するAWSサービス

全体の作業順序

① CloudWatch Log Group を作成する
      ↓
② CloudWatch Metric Filter を作成する（error ログ → メトリクス）
      ↓
③ Lambda 関数を作成する（コード・環境変数・タイムアウト設定）
      ↓
④ Lambda の実行ロールに権限を追加する
  （CloudWatch Logs: 書き込み・読み取り / CloudWatch: PutMetricData）
      ↓
⑤ API Gateway REST API を作成する（POST /logs, GET /logs）
      ↓
⑥ 動作テスト（curl でログ送信 → コンソールで確認）
      ↓
⑦ リソースの削除

Log Group を先に作る理由：
Metric Filter の作成にはロググループが必要なため、最初に作成します。

① CloudWatch Log Group を作成する

AWSコンソール → CloudWatch → ロググループ → 「ロググループの作成」

「作成」をクリック。

控えておく情報:

• ロググループ名: /chatbot/chatbot-logs

② CloudWatch Metric Filter を作成する

エラーログを自動的にカスタムメトリクスに変換するフィルターを設定します。

CloudWatch → ロググループ → /chatbot/chatbot-logs → 「メトリクスフィルター」タブ → 「メトリクスフィルターを作成」

フィルターパターンの設定

「パターンのテスト」でテストデータを入力して確認できます（任意）。「次へ」をクリック。

メトリクスの設定

「次へ」→「メトリクスフィルターを作成」。

Metric Filter の仕組み:
CloudWatch Logs に届いたログが { $.level = "error" } にマッチするたびに、
ChatBot/chatbot-logs 名前空間の ChatErrorCount に 1 が加算されます。
ログに {"level": "error", ...} という JSON が含まれていればマッチします。

③ Lambda 関数を作成する

AWSコンソール → Lambda → 「関数の作成」

「関数の作成」をクリック。

タイムアウトの設定

「設定」タブ → 「一般設定」→「編集」

「保存」をクリック。

環境変数の設定

「設定」タブ → 「環境変数」→「編集」→「環境変数を追加」

「保存」をクリック。

コードの入力

「コード」タブ → lambda_function.py を開いて既存の内容を全て置き換えます。

import json
import os
import time
import uuid

import boto3
from botocore.exceptions import ClientError

logs_client = boto3.client("logs")
cloudwatch = boto3.client("cloudwatch")

LOG_GROUP_NAME = os.environ["LOG_GROUP_NAME"]
METRIC_NAMESPACE = "ChatBot/" + LOG_GROUP_NAME.split("/")[-1]  # "ChatBot/chatbot-logs"


def lambda_handler(event, context):
    http_method = event.get("httpMethod", "")
    resource = event.get("resource", "/")

    if http_method == "POST" and resource == "/logs":
        return post_log(event)
    elif http_method == "GET" and resource == "/logs":
        return get_logs(event)
    else:
        return _response(404, {"error": "Not Found"})


def post_log(event):
    try:
        body = json.loads(event.get("body") or "{}")
    except json.JSONDecodeError:
        return _response(400, {"error": "Invalid JSON"})

    session_id = body.get("session_id") or str(uuid.uuid4())
    user_id = body.get("user_id", "anonymous")
    message = body.get("message", "")
    response_text = body.get("response", "")
    level = body.get("level", "info")

    log_entry = {
        "session_id": session_id,
        "user_id": user_id,
        "message": message,
        "response": response_text,
        "level": level,
    }

    log_stream_name = f"session/{session_id}"
    _ensure_log_stream(log_stream_name)  # ストリームを作成（既存なら無視）
    logs_client.put_log_events(
        logGroupName=LOG_GROUP_NAME,
        logStreamName=log_stream_name,
        logEvents=[
            {
                "timestamp": int(time.time() * 1000),  # ミリ秒単位の Unix 時間
                "message": json.dumps(log_entry, ensure_ascii=False),
            }
        ],
    )

    cloudwatch.put_metric_data(
        Namespace=METRIC_NAMESPACE,
        MetricData=[
            {
                "MetricName": "MessageCount",
                "Dimensions": [{"Name": "Level", "Value": level}],
                "Value": 1,
                "Unit": "Count",
            }
        ],
    )

    return _response(200, {
        "session_id": session_id,
        "log_stream": log_stream_name,
        "message": "ログを記録した",
    })


def get_logs(event):
    params = event.get("queryStringParameters") or {}
    session_id = params.get("session_id")
    limit = min(int(params.get("limit", "20")), 100)

    if not session_id:
        return _response(400, {"error": "session_id クエリパラメーターは必須"})

    log_stream_name = f"session/{session_id}"

    try:
        resp = logs_client.get_log_events(
            logGroupName=LOG_GROUP_NAME,
            logStreamName=log_stream_name,
            limit=limit,
            startFromHead=False,  # 最新のログから取得
        )
        events = []
        for e in resp["events"]:
            try:
                msg = json.loads(e["message"])
            except json.JSONDecodeError:
                msg = e["message"]
            events.append({"timestamp_ms": e["timestamp"], "log": msg})
    except ClientError as e:
        if e.response["Error"]["Code"] == "ResourceNotFoundException":
            events = []  # ログストリームが存在しない場合は空リストを返す
        else:
            raise

    return _response(200, {
        "session_id": session_id,
        "log_count": len(events),
        "logs": events,
    })


def _ensure_log_stream(log_stream_name: str) -> None:
    try:
        logs_client.create_log_stream(
            logGroupName=LOG_GROUP_NAME,
            logStreamName=log_stream_name,
        )
    except ClientError as e:
        if e.response["Error"]["Code"] != "ResourceAlreadyExistsException":
            raise  # 既存ストリームは無視、それ以外のエラーは再送出


def _response(status_code: int, body: dict) -> dict:
    return {
        "statusCode": status_code,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps(body, ensure_ascii=False),
    }

「Deploy」ボタンをクリックしてコードを保存します。

④ Lambda の実行ロールに権限を追加する

デフォルトの実行ロールは CloudWatch Logs への書き込み（Lambdaの実行ログ出力）のみです。
今回はカスタムロググループへの書き込み・読み取りと、カスタムメトリクスへの書き込み権限を追加します。

Lambda → ChatLogFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名のリンクをクリック

（例: ChatLogFunction-role-XXXX）→ IAM コンソールのロール画面が開きます。

CloudWatch Logs と CloudWatch の権限をまとめて追加する

「許可を追加」→「インラインポリシーを作成」→「JSON」タブを選択して以下を入力します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:GetLogEvents",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:ap-northeast-1:YOUR_ACCOUNT_ID:log-group:/chatbot/chatbot-logs",
        "arn:aws:logs:ap-northeast-1:YOUR_ACCOUNT_ID:log-group:/chatbot/chatbot-logs:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "cloudwatch:PutMetricData",
      "Resource": "*"
    }
  ]
}

YOUR_ACCOUNT_ID を自分の AWS アカウント ID（12桁）に置き換えてください。
アカウント ID は aws sts get-caller-identity で確認できます。

「次へ」→ ポリシー名: ChatLogPolicy → 「ポリシーを作成」。

なぜ 2 種類の権限が必要か:

• logs:PutLogEvents — put_log_events() でカスタムロググループにログを書き込む
• logs:GetLogEvents — get_log_events() でログを読み取る
• cloudwatch:PutMetricData — put_metric_data() でカスタムメトリクスを記録する

⑤ API Gateway REST API を作成する

5-1. API の作成

AWSコンソール → API Gateway → 「APIを作成」→ 「REST API」→「構築」

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

5-2. /logs リソースを作成する

「リソース」→「リソースを作成」

「リソースを作成」をクリック。

5-3. POST メソッドを作成する（ログ書き込み）

/logs リソースを選択した状態で「メソッドを作成」。

「メソッドを作成」をクリック。

5-4. GET メソッドを作成する（ログ取得）

同様に GET メソッドを追加します。設定は POST と同じ（Lambda 関数: ChatLogFunction）。

5-5. API をデプロイする

「API をデプロイ」→

「デプロイ」をクリック。

デプロイ後に表示される URL を控えておきます:

https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod

⑥ 動作テスト

事前準備: API URL を変数に設定する

set API_URL=https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod

XXXXXXXXXX を ⑤ でデプロイ後に表示された URL の値に置き換えてください。

テスト 1: ログを記録する（POST /logs）

curl -X POST "%API_URL%/logs" ^
  -H "Content-Type: application/json" ^
  -d "{\"session_id\": \"session-001\", \"user_id\": \"user001\", \"message\": \"今日の天気は？\", \"response\": \"東京は晴れです\", \"level\": \"info\"}"

期待するレスポンス:

{
  "session_id": "session-001",
  "log_stream": "session/session-001",
  "message": "ログを記録した"
}

テスト 2: エラーログを記録する（Metric Filter のテスト）

curl -X POST "%API_URL%/logs" ^
  -H "Content-Type: application/json" ^
  -d "{\"session_id\": \"session-001\", \"user_id\": \"user001\", \"message\": \"注文履歴を見せて\", \"response\": \"エラーが発生しました\", \"level\": \"error\"}"

このリクエスト後、CloudWatch メトリクス ChatBot/chatbot-logs > ChatErrorCount が +1 されます。
反映まで数分かかることがあります。

テスト 3: ログを取得する（GET /logs）

curl "%API_URL%/logs?session_id=session-001"

期待するレスポンス:

{
  "session_id": "session-001",
  "log_count": 2,
  "logs": [
    {
      "timestamp_ms": 1700000000000,
      "log": {
        "session_id": "session-001",
        "user_id": "user001",
        "message": "今日の天気は？",
        "response": "東京は晴れです",
        "level": "info"
      }
    }
  ]
}

CloudWatch でログを確認する

CloudWatch → ロググループ → /chatbot/chatbot-logs → ログストリーム

• session/session-001 ストリームをクリック
• 送信した会話ログが JSON 形式で記録されていることを確認します

CloudWatch Logs Insights でクエリを実行する（任意）

CloudWatch → Logs Insights

ロググループに /chatbot/chatbot-logs を選択し、時間範囲を「直近1時間」など幅のある範囲に設定してから以下のクエリを実行します。

注意: 開始時刻と終了時刻が同じだとエラー Query's end date and time is either before the log groups creation time... が出ます。カレンダーアイコンで時間幅を確保してください。

fields @timestamp, session_id, user_id, level, message
| filter level = "error"
| sort @timestamp desc
| limit 20

エラーログだけを抽出して確認できます。

カスタムメトリクスを確認する（任意）

CloudWatch → メトリクス → すべてのメトリクス → カスタム名前空間 → ChatBot/chatbot-logs

⑦ リソースの削除

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

1. API Gateway を削除する

API Gateway → API → ChatLogAPI → 「削除」→ API 名を入力 → 「削除」

2. Lambda 関数を削除する

Lambda → 関数 → ChatLogFunction → 「アクション」→「削除」

3. CloudWatch Log Group を削除する

CloudWatch → ロググループ → /chatbot/chatbot-logs → 「アクション」→「ロググループを削除」

Metric Filter はロググループを削除すると自動的に削除されます。

4. IAM ロールを削除する（任意）

IAM → ロール → ChatLogFunction-role-XXXX を削除

5. CloudWatch Lambda ロググループを削除する（任意）

CloudWatch → ロগগループ → /aws/lambda/ChatLogFunction → 削除

SAM との対比

コンソール版のつまずきポイント:
IAM のインラインポリシーに YOUR_ACCOUNT_ID を自分のアカウントIDに書き換えるのを忘れると AccessDeniedException が発生します。
SAM版では !GetAtt ChatLogGroup.Arn で自動解決されるため、この手作業が不要です。

トラブルシューティング

まとめ

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

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

• API Gateway のリソース・メソッド・デプロイという3段階の設定が視覚的に理解できる
• IAM ポリシーのリソース ARN を手動で記述することで、権限スコープの意味が身につく
• Metric Filter の仕組みを GUI で設定することで、JSON フィルター構文の動作が理解できる

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

コンソールで API Gateway + Lambda + CloudWatch Logs の連携を理解したら、SAM で同じ構成をコードで定義することで「SAM が何を自動化しているか」が明確になります。IAM ポリシーの ARN 解決や Log Group の保持期間設定など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールでチャットボットログAPIを構築する手順【API Gateway + Lambda + CloudWatch Logs ハンズオン / SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

「S3に画像をアップロードしたら、自動で中身を分析してほしい」——そんな仕組みを、AWSコンソールのみでゼロから構築するハンズオンです。

Amazon Rekognition の DetectLabels API を使うと、画像に写っている物体・シーン・動物などを自動で検出できます。犬の写真をアップロードすれば「Dog（信頼度98%）」「Animal（97%）」といったラベルが返ってきます。

ユーザー
  ↓ JPEG / PNG をアップロード
S3 バケット（UploadBucket）
  ↓ ObjectCreated イベント（自動）
Lambda（DetectFunction）
  ↓ rekognition:DetectLabels（S3Object を指定）
Amazon Rekognition
  ↓ [{"name": "Dog", "confidence": 98.5}, ...] を返す
Lambda
  ↓ print（JSON）
CloudWatch Logs

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

• S3 トリガー — S3 へのアップロードを契機に Lambda を自動起動する仕組み
• Rekognition DetectLabels — 画像内の物体・シーン・動物を検出してラベルと信頼度を返す API
• IAM 権限管理 — Lambda から S3・Rekognition を呼び出すために必要な権限の追加手順
• S3Object 参照 — 画像データを Lambda に転送せず S3 の場所を直接 Rekognition に渡す効率的な方法

この記事は SAM版ハンズオン の比較記事です。
コンソール操作で S3・Lambda・Rekognition の連携を視覚的に学び、SAM と何が違うのかを比較したい方向けです。

Amazon検索[本 AWS 開発]

キーワード解説

使用するAWSサービス

全体の作業順序

① S3 バケットを作成する
      ↓
② Lambda 関数を作成する（コード入力・タイムアウト設定）
      ↓
③ Lambda の実行ロールに権限を追加する
  （S3: GetObject / Rekognition: DetectLabels）
      ↓
④ Lambda に S3 トリガーを追加する
      ↓
⑤ 動作テスト（画像をアップロード → ログを確認）
      ↓
⑥ リソースの削除

① S3 バケットを作成する

AWSコンソール → S3 → 「バケットを作成」

「バケットを作成」をクリック。

控えておく情報:

• バケット名（削除時・IAMポリシー設定時に使用）

バケット名のグローバルユニークについて：
S3 のバケット名は全 AWS アカウントで一意である必要があります。my-rekognition-upload- に自分のアカウントIDや日付を追加すると重複を避けられます。

② Lambda 関数を作成する

AWSコンソール → Lambda → 「関数の作成」

「関数の作成」をクリック。

タイムアウトの設定

「設定」タブ → 「一般設定」→「編集」

「保存」をクリック。

タイムアウトを 30 秒にする理由：
Rekognition API の呼び出しには数秒かかることがあります。デフォルト（3秒）では Rekognition のレスポンスを待ちきれずタイムアウトするため、余裕を持って 30 秒に設定します。

コードの入力

「コード」タブ → lambda_function.py を開いて既存の内容を全て置き換える。

import json
import urllib.parse
import boto3

rekognition = boto3.client("rekognition")


def lambda_handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])

        print(json.dumps({"status": "start", "bucket": bucket, "key": key}))

        response = rekognition.detect_labels(
            Image={
                "S3Object": {
                    "Bucket": bucket,
                    "Name": key,
                }
            },
            MaxLabels=10,
            MinConfidence=70,
        )

        labels = [
            {
                "name": label["Name"],
                "confidence": round(label["Confidence"], 1),
            }
            for label in response["Labels"]
        ]

        result = {
            "bucket": bucket,
            "key": key,
            "label_count": len(labels),
            "labels": labels,
        }
        print(json.dumps(result, ensure_ascii=False))

    return {"processedCount": len(event["Records"])}

「Deploy」ボタンをクリックしてコードを保存する。

コードのポイント:

③ Lambda の実行ロールに権限を追加する

デフォルトの実行ロールは CloudWatch Logs への書き込みのみ。
S3 からの読み取りと Rekognition の呼び出し権限を追加する。

Lambda → DetectFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名のリンクをクリック

（例: DetectFunction-role-XXXX）→ IAM コンソールのロール画面が開く。

3-1. Rekognition 権限を追加する

「許可を追加」→「ポリシーをアタッチ」

検索ボックスに Rekognition と入力 → AmazonRekognitionReadOnlyAccess にチェック → 「許可を追加」。

AmazonRekognitionReadOnlyAccess に含まれる主な権限:

• rekognition:DetectLabels — ラベル検出（今回使用）
• rekognition:DetectFaces — 顔検出
• rekognition:DetectText — テキスト検出

3-2. S3 GetObject 権限を追加する

「許可を追加」→「インラインポリシーを作成」

「JSON」タブを選択して以下を入力する（my-rekognition-upload を ① のバケット名に変更）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-rekognition-upload/*"
    }
  ]
}

「次へ」→ ポリシー名: S3ReadForRekognition → 「ポリシーを作成」。

なぜ S3 の権限が必要か:
Rekognition に S3Object を指定した場合、Rekognition が Lambda の IAM ロールを借りて
S3 からオブジェクトを取得します。Lambda ロールに s3:GetObject がないと 403 エラーになります。

SAM版では S3ReadPolicy（SAM 組み込みポリシー）が特定バケットのみに s3:GetObject を自動付与します。
コンソール版では手動でインラインポリシーを作成する必要があります。

④ Lambda に S3 トリガーを追加する

Lambda → DetectFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「再帰呼び出し」の確認チェックボックスにチェック → 「追加」をクリック。

再帰呼び出しについて：
Lambda の実行結果を同じバケットに書き込む構成にすると、S3 イベントが再発火して無限ループになります。
今回は S3 への書き込みを行わないため問題ありません。

⑤ 動作テスト

テスト用画像の準備

任意の JPEG または PNG 画像を用意する（例: 犬・猫・風景など）。
ファイルサイズは 15MB 以下 であることを確認する。

画像をアップロードする

方法 A: S3 コンソール

S3 → my-rekognition-upload → 「アップロード」→ ファイルをドラッグ＆ドロップ → 「アップロード」

方法 B: AWS CLI

aws s3 cp "C:\Users\yourname\Pictures\dog.jpg" s3://my-rekognition-upload/ --region ap-northeast-1

CloudWatch Logs でラベル検出結果を確認する

Lambda → DetectFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

最新のロットストリームを開いて以下のような出力を確認する。

{"status": "start", "bucket": "my-rekognition-upload", "key": "dog.jpg"}
{
  "bucket": "my-rekognition-upload",
  "key": "dog.jpg",
  "label_count": 8,
  "labels": [
    {"name": "Dog", "confidence": 98.5},
    {"name": "Pet", "confidence": 98.5},
    {"name": "Animal", "confidence": 98.5},
    {"name": "Canine", "confidence": 98.5},
    {"name": "Mammal", "confidence": 97.2},
    {"name": "Golden Retriever", "confidence": 85.3},
    {"name": "Grass", "confidence": 76.1},
    {"name": "Outdoors", "confidence": 71.4}
  ]
}
{"processedCount": 1}

MinConfidence: 70 の効果：
信頼度 70% 未満のラベルは結果に含まれません。
全ラベルを確認したい場合は MinConfidence=0 に変更して「Deploy」する。

複数枚でテストする

aws s3 cp "C:\Users\yourname\Pictures\cat.jpg"  s3://my-rekognition-upload/ --region ap-northeast-1
aws s3 cp "C:\Users\yourname\Pictures\city.jpg" s3://my-rekognition-upload/ --region ap-northeast-1

各ファイルのアップロードごとに Lambda が起動し、それぞれのラベル検出結果がログに記録される。

無料枠の管理：
AWS コンソール → Billing → 無料利用枠 → 「Amazon Rekognition」で当月の使用枚数を確認できます。
月5,000枚まで無料のため、学習目的のハンズオンでは通常課金されません。

⑥ リソースの削除

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

1. S3 バケットのオブジェクトを全て削除する

aws s3 rm s3://my-rekognition-upload --recursive --region ap-northeast-1

2. S3 バケットを削除する

S3 → my-rekognition-upload → 「削除」→ バケット名を入力 → 「削除」

3. Lambda のトリガーを削除する

Lambda → DetectFunction → 「設定」→「トリガー」→ S3 トリガーを選択 → 「削除」

4. Lambda 関数を削除する

Lambda → 関数 → DetectFunction → 「アクション」→「削除」

5. IAM ロールを削除する（任意）

IAM → ロール → DetectFunction-role-XXXX を削除

6. CloudWatch Logs のロググループを削除する（任意）

CloudWatch → ロググループ → /aws/lambda/DetectFunction → 削除

SAM版との大きな違い（SAMのメリット）：
SAM版では sam delete 1コマンドで上記すべてのリソースを一括削除できます。

SAMとの対比

コンソール版のつまずきポイント：
AccessDeniedException が出た場合、S3 の GetObject 権限（インラインポリシー）と Rekognition の DetectLabels 権限（AmazonRekognitionReadOnlyAccess）の両方が揃っているか確認しましょう。どちらか一方が欠けていてもエラーになります。

トラブルシューティング

まとめ

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

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

• S3 → Lambda → Rekognition という3つのサービスのデータの流れが視覚的に理解できる
• 実行ロールに必要な権限を1つずつ追加することで、IAM の仕組みが身につく
• リソースを個別に作成・削除することで、各サービスの独立性と依存関係が明確になる

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

コンソールで S3・Lambda・Rekognition の連携を理解したら、SAM で同じ構成をコードで定義することで「SAM が何を自動化しているか」が明確になります。S3ReadPolicy や RekognitionDetectOnlyPolicy による1行での権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけで画像認識パイプラインを構築する手順【S3 + Lambda + Rekognition / SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

「1回メッセージを送るだけで、複数のシステムに同時に通知したい」——そんな要件を実現する設計パターンが Pub/Sub（パブリッシュ・サブスクライブ） と ファンアウト です。

この記事では、AWSコンソールのみを使って、SNS + SQS + Lambda による通知システムをゼロから構築するハンズオンを紹介します。

Publisher（aws sns publish）
  ↓ メッセージを1回発行するだけ
SNS Topic（NotificationTopic）
  │
  ├─ サブスクリプション（フィルターなし）
  │    → LogQueue → LogFunction → CloudWatch Logs（全メッセージを記録）
  │
  └─ サブスクリプション（level=warning/critical のみ）
       → AlertQueue → AlertFunction → CloudWatch Logs（アラート処理）
                          ↓ 処理失敗（3回）
                        AlertDLQ

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

• Pub/Sub パターン — Publisher と Subscriber が疎結合で通信する仕組み
• ファンアウト — 1回の publish で複数の Lambda が並行して動作する体験
• SNS フィルターポリシー — メッセージ属性で配信先を絞り込む設定
• DLQ（デッドレターキュー） — 処理失敗メッセージの退避先を実際に確認

この記事は SAM版ハンズオン の比較記事です。
コンソール操作で SNS・SQS・Lambda の連携を視覚的に学び、SAM と何が違うのかを比較したい方向けです。

Amazon検索[本 AWS 開発]

キーワード解説

使用するAWSサービス

全体の作業順序

① SNS Topic を作成する
      ↓
② SQS キューを3つ作成する（AlertDLQ / LogQueue / AlertQueue）
      ↓
③ SNS → SQS サブスクリプションを2つ作成する
  （LogQueue: フィルターなし / AlertQueue: フィルターあり）
      ↓
④ Lambda 関数を2つ作成する
      ↓
⑤ SQS トリガーを各 Lambda に追加する
      ↓
⑥ 動作テスト（3パターン）
      ↓
⑦ リソースの削除

AlertDLQ を先に作成する理由：
AlertQueue の作成時に DLQ として AlertDLQ の ARN を指定するため、AlertDLQ を先に作る必要があります。

① SNS Topic を作成する

AWSコンソール → SNS → 「トピック」→「トピックを作成」

その他の設定はデフォルトのまま。「トピックを作成」をクリック。

控えておく情報:

• トピック ARN（例: arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic）

スタンダードとFIFOの違い：
スタンダードは順序保証なし・高スループット。FIFO は順序保証あり・1回限りの配信が必要な場合に使用します。今回のログ/アラート通知にはスタンダードが適しています。

② SQS キューを3つ作成する

AWSコンソール → SQS → 「キューを作成」

2-1. AlertDLQ（デッドレターキュー）を先に作成する

「キューを作成」をクリック。

控えておく情報:

• AlertDLQ の ARN（例: arn:aws:sqs:ap-northeast-1:123456789012:AlertDLQ）

2-2. LogQueue を作成する（フィルターなし・全メッセージ用）

「キューを作成」をクリック。

可視性タイムアウトを 180 秒にする理由：
Lambda のデフォルトタイムアウト（3秒）より長く設定することで、処理中に他のコンシューマーがメッセージを二重取得するのを防ぎます。DLQ テストでは 180秒 × 3回 ≒ 9分待つことになります。

2-3. AlertQueue を作成する（フィルターあり・アラート用）

「デッドレターキュー」セクション:

「キューを作成」をクリック。

控えておく情報:

• LogQueue の ARN
• AlertQueue の ARN

③ SNS → SQS サブスクリプションを2つ作成する

SQS キューポリシーの自動追加について：
コンソールで SNS → SQS サブスクリプションを作成すると、
SNS が SQS キューのアクセスポリシーに sns.amazonaws.com からの sqs:SendMessage 権限を自動追加します。
手動でのポリシー設定は不要です（SAM版では AWS::SQS::QueuePolicy を明示的に定義する必要があります）。

3-1. LogQueue サブスクリプション（フィルターなし）

SNS → NotificationTopic → 「サブスクリプション」タブ → 「サブスクリプションを作成」

「サブスクリプションを作成」をクリック。

3-2. AlertQueue サブスクリプション（フィルターあり）

SNS → NotificationTopic → 「サブスクリプション」タブ → 「サブスクリプションを作成」

「サブスクリプションフィルターポリシー」セクション:

{
  "level": ["warning", "critical"]
}

フィルターポリシーの意味：
level メッセージ属性の値が "warning" または "critical" のメッセージのみ AlertQueue に配信します。
level=info のメッセージは AlertQueue に届かない（LogQueue には届く）。

よくある間違い（フィルターが動作しない場合）：

• スコープが「メッセージ本文」になっている → **「メッセージ属性」**に変更する
• JSON のスペルミス（"warning" のクォートが抜けている等）

「サブスクリプションを作成」をクリック。

④ Lambda 関数を2つ作成する

AWSコンソール → Lambda → 「関数の作成」（共通設定）

コードを貼り付けたあと、必ず 「Deploy」 ボタンを押してコードを保存します。

4-1. LogFunction（全ログ処理）

関数名: LogFunction

コードエディタで lambda_function.py を開き、以下を貼り付けて「Deploy」をクリック。

import json


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:
        sns_envelope = json.loads(record["body"])
        message = sns_envelope["Message"]  # 実際のメッセージ本文
        attributes = sns_envelope.get("MessageAttributes", {})
        level = attributes.get("level", {}).get("Value", "info")

        result = {
            "queue": "log",
            "level": level,
            "message": message,
        }
        print(json.dumps(result, ensure_ascii=False))
        results.append(result)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

json.loads(record["body"]) が必要な理由：
SNS → SQS 配信では、SQS のメッセージボディに SNS エンベロープ（JSON文字列）が格納されます。
そのため record["body"] はそのまま使えず、json.loads でパースする必要があります。

{
  "Type": "Notification",
  "TopicArn": "arn:aws:sns:...:NotificationTopic",
  "Message": "警告メッセージ",
  "MessageAttributes": {
    "level": {"Type": "String", "Value": "warning"}
  }
}

4-2. AlertFunction（アラート処理・DLQ テスト機能付き）

関数名: AlertFunction

import json


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:
        sns_envelope = json.loads(record["body"])
        message = sns_envelope["Message"]
        attributes = sns_envelope.get("MessageAttributes", {})
        level = attributes.get("level", {}).get("Value", "unknown")

        # DLQテスト用: "error" というメッセージを受信したら意図的に例外発生
        if message.strip().lower() == "error":
            raise ValueError(
                f"アラート処理に失敗: level={level}, message={message}"
            )

        result = {
            "queue": "alert",
            "level": level,
            "message": message,
            "alert_triggered": True,
        }
        print(json.dumps(result, ensure_ascii=False))
        results.append(result)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

DLQ テストのしくみ：
message == "error" のとき意図的に ValueError を発生させています。
SQS は処理失敗を検知してメッセージをキューに戻し、可視性タイムアウト（180秒）後に再試行します。
これを3回繰り返すと AlertDLQ に移動します。

⑤ SQS トリガーを各 Lambda に追加する

5-1. LogFunction に LogQueue トリガーを追加する

Lambda → LogFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリック。

権限の追加:

Lambda → LogFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名をクリック（IAM コンソールへ）
→「許可を追加」→「ポリシーをアタッチ」→ AWSLambdaSQSQueueExecutionRole をアタッチ。

AWSLambdaSQSQueueExecutionRole が必要な理由：
Lambda が SQS からメッセージを受信（sqs:ReceiveMessage）・削除（sqs:DeleteMessage）するために必要な権限がまとまったポリシーです。これがないと Lambda がメッセージを取得できません。

5-2. AlertFunction に AlertQueue トリガーを追加する

Lambda → AlertFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリック。権限の追加（AWSLambdaSQSQueueExecutionRole）も同様に実施する。

AlertFunction のバッチサイズを 1 にする理由：
1件ずつ処理することで、1件が失敗しても他のメッセージに影響が出ません。
DLQ へ移動するメッセージを1件に限定できるため、テストが分かりやすくなります。

⑥ 動作テスト

3つのシナリオで SNS フィルター・ファンアウト・DLQ の動作を確認します。

テスト1: level=info（LogFunction のみ受信）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "情報メッセージ" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"info\"}}" ^
  --region ap-northeast-1

123456789012 を自分のアカウントIDに置き換えてください。

期待する動作:

• LogFunction が処理 → CloudWatch Logs にログが記録される
• AlertFunction は動作しない（フィルターで除外）

CloudWatch Logs で確認:

Lambda → LogFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

{"queue": "log", "level": "info", "message": "情報メッセージ"}
{"processedCount": 1}

テスト2: level=warning（両 Lambda が受信 ＝ ファンアウト）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "警告メッセージ" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"warning\"}}" ^
  --region ap-northeast-1

期待する動作:

• LogFunction が処理（level=warning を受信）
• AlertFunction も処理（フィルターを通過）
• 1回の publish で 2つの Lambda が並行して動作する ← ファンアウトのポイント

LogFunction のログ:

{"queue": "log", "level": "warning", "message": "警告メッセージ"}

AlertFunction のログ:

{"queue": "alert", "level": "warning", "message": "警告メッセージ", "alert_triggered": true}

テスト3: level=warning + body=error（AlertFunction 失敗 → DLQ）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "error" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"warning\"}}" ^
  --region ap-northeast-1

期待する動作:

• LogFunction → 正常処理（message=error でも例外なし）
• AlertFunction → ValueError 発生
• AlertQueue の可視性タイムアウト（180秒）後に再試行 × 3回 → AlertDLQ に移動

DLQ に移動するまでの待機時間: 最大 180秒 × 3回 ≒ 9分かかります。
CloudWatch Logs で AlertFunction に [ERROR] ValueError が 3回記録されたことを確認してから DLQ をポーリングするとよいです。

DLQ にメッセージが届いたか確認:

SQS → AlertDLQ → 「メッセージを送受信」→「メッセージをポーリング」

"error" のメッセージ（SNS エンベロープ形式）が表示されれば DLQ 動作確認完了。

⑦ リソースの削除

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

1. Lambda のトリガーを削除する

• Lambda → LogFunction → 「設定」→「トリガー」→ SQS トリガーを削除
• Lambda → AlertFunction → 同様に削除

2. Lambda 関数を削除する

• LogFunction / AlertFunction を削除

3. SNS サブスクリプションを削除する

SNS → NotificationTopic → 「サブスクリプション」タブ → 2つのサブスクリプションを削除

4. SNS Topic を削除する

SNS → トピック → NotificationTopic → 「削除」

5. SQS キューを3つ削除する

SQS → LogQueue / AlertQueue / AlertDLQ を各々削除

6. IAM ロールを削除する（任意）

IAM → ロール → LogFunction-role-XXXX / AlertFunction-role-XXXX を削除

7. CloudWatch Logs のロググループを削除する（任意）

CloudWatch → ロググループ → /aws/lambda/LogFunction / /aws/lambda/AlertFunction を削除

SAM版との大きな違い（SAMのメリット）：
SAM版では sam delete 1コマンドで上記すべてのリソースを一括削除できます。

SAMとの対比

コンソール版の最大のつまずきポイント：
SNS の「サブスクリプション」を作り忘れると、SNS publish しても SQS キューにメッセージが届きません。
「キューにメッセージが来ない」と感じたら、まずサブスクリプションが正しく作成されているか確認しましょう。

トラブルシューティング

まとめ

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

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

• SNS Topic / SQS キュー / Lambda という3つのリソースの組み合わせ方が視覚的に理解できる
• SNS サブスクリプションのフィルターポリシーJSON を直接入力することで、ルールの書き方が身につく
• リソースを1つずつ作成することで、各サービスの役割と依存関係が明確になる

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

コンソールで SNS + SQS + Lambda の連携を理解したら、SAM で同じ構成をコードで定義することで「SAM が何を自動化しているか」が明確になります。AWS::SQS::QueuePolicy の明示的な記述や SQSPollerPolicy によるワンライン権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでSNS + SQS + Lambda 通知システムを構築する手順【Pub/Sub・ファンアウト・DLQ / SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

「複数のLambda関数を順番に呼び出したい」「エラーが起きたとき自動でリトライして、それでも失敗したら別の処理に切り替えたい」という要件を、AWS Step Functions は視覚的なフロー定義で実現します。

この記事では、AWSコンソールのみを使って、受注処理ワークフロー（注文検証 → 在庫確認・支払い並列処理 → 注文確定）をゼロから構築するハンズオンを紹介します。

入力: 注文データ（order_id / item_id / quantity）
  ↓
[ValidateOrder] 注文検証 ... Task + Retry + Catch
  ↓ 成功
[ProcessInParallel] 並列処理 ... Parallel + Catch
  ├─ [CheckInventory] 在庫確認
  └─ [ProcessPayment] 支払い処理
  ↓ 成功
[ConfirmOrder] 注文確定
  ↓
終了（成功）

[HandleError] エラー処理（Catch 先）
  ↓
終了（エラー通知済み）

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

• Step Functions の Task / Parallel / Retry / Catch という基本パターン
• 並列ブランチの結果をリストとして次のステートに渡す仕組み
• Workflow Studio（新UI） の操作方法 — ビジュアルエディタと ASL コードエディタの関係
• ResultPath: "$.error" でエラー情報を元の入力にマージして後続ステートに渡すテクニック

この記事は SAM版ハンズオン の比較記事です。
コンソール操作でStep Functionsの概念を視覚的に学び、SAMと何が違うのかを比較したい方向けです。

Amazon検索[本 AWS 開発]

Step Functions 新UIで戸惑いやすいポイント（先読み）

操作を始める前に、2026年時点の新UIと旧UIの違いを把握しておきましょう。

最大のハマりポイント：
「テンプレートを選択」を押してしまうと36個のテンプレートギャラリーが開きます。今回の目的には 「自分で作成する」 を選ぶ必要があります。これを知らずに迷う人が多いポイントです。

キーワード解説

前提条件

今回はほぼコンソール操作のみで完結します。

使用するAWSサービス

全体の作業順序

① Lambda 関数を5つ作成する
      ↓（各関数の ARN が必要）
② Step Functions ステートマシンを作成する（新UI対応）
      ↓
③ 動作テスト（正常処理 / エラー処理）
      ↓
④ リソースの削除

① Lambda 関数を5つ作成する

共通手順

AWSコンソール → Lambda → 「関数の作成」

各関数でコードを貼り付けたあと、必ず 「Deploy」 ボタンを押してコードを保存します。

1-1. ValidateFunction（注文検証）

関数名: ValidateFunction

コードエディタで lambda_function.py を開き、既存の内容を全て置き換えて以下を貼り付ける。

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    item_id = event.get("item_id")
    quantity = event.get("quantity", 0)

    if not order_id:
        raise ValueError("order_id が指定されていません")
    if not item_id:
        raise ValueError("item_id が指定されていません")
    if not isinstance(quantity, int) or quantity <= 0:
        raise ValueError(f"quantity は正の整数である必要があります: {quantity}")

    result = {
        **event,          # 元の入力フィールドをすべて引き継ぐ（テスト用フラグを後続ステートに渡すため）
        "validated": True,
    }
    print(json.dumps({"step": "validate", **result}, ensure_ascii=False))
    return result

ARN を控えておく: 関数ページ右上の「関数の ARN」をコピー（例: arn:aws:lambda:ap-northeast-1:123456789012:function:ValidateFunction）

1-2. InventoryFunction（在庫確認）

関数名: InventoryFunction

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    item_id = event.get("item_id")
    quantity = event.get("quantity", 1)

    if item_id == "item-999":
        raise ValueError(f"在庫不足: item_id={item_id}")

    result = {
        "order_id": order_id,
        "item_id": item_id,
        "quantity": quantity,
        "stock_available": True,
    }
    print(json.dumps({"step": "inventory", **result}, ensure_ascii=False))
    return result

ARN を控えておく

1-3. PaymentFunction（支払い処理）

関数名: PaymentFunction

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    quantity = event.get("quantity", 1)

    # エラーテスト用: fail_payment=True の場合は例外発生
    if event.get("fail_payment"):
        raise RuntimeError(f"支払い処理に失敗: order_id={order_id}")

    amount = quantity * 1000  # 1個 1,000円

    result = {
        "order_id": order_id,
        "amount": amount,
        "payment_status": "completed",
    }
    print(json.dumps({"step": "payment", **result}, ensure_ascii=False))
    return result

ARN を控えておく

1-4. ConfirmFunction（注文確定）

関数名: ConfirmFunction

import json
import datetime


def lambda_handler(event, context):
    # Parallel ステートの後に呼ばれるため、event はリスト形式
    #   event[0]: CheckInventory（在庫確認）の結果
    #   event[1]: ProcessPayment（支払い処理）の結果
    inventory_result = event[0]
    payment_result = event[1]

    order_id = inventory_result.get("order_id")
    now = datetime.datetime.now(datetime.timezone.utc)

    result = {
        "order_id": order_id,
        "item_id": inventory_result.get("item_id"),
        "quantity": inventory_result.get("quantity"),
        "amount": payment_result.get("amount"),
        "confirmed_at": now.isoformat(),
        "status": "confirmed",
    }
    print(json.dumps({"step": "confirm", **result}, ensure_ascii=False))
    return result

ARN を控えておく

Parallel ステート後の event がリストになる理由：
ProcessInParallel の各ブランチの出力が配列でまとめられて次のステートに渡されます。event[0] が在庫確認の結果、event[1] が支払い処理の結果です。この仕様を知らないと list indices must be integers エラーで詰まります。

1-5. ErrorHandlerFunction（エラー処理）

関数名: ErrorHandlerFunction

import json


def lambda_handler(event, context):
    # ResultPath: "$.error" により、エラー情報が元の入力に付加されて渡される
    error_info = event.get("error", {})
    original_input = {k: v for k, v in event.items() if k != "error"}

    result = {
        "status": "error",
        "error_type": error_info.get("Error", "Unknown"),
        "error_cause": error_info.get("Cause", ""),
        "original_input": original_input,
    }
    print(json.dumps({"step": "error_handler", **result}, ensure_ascii=False))
    return result

ARN を控えておく

② Step Functions ステートマシンを作成する

AWSコンソール → Step Functions → 「ステートマシンを作成」

2-1. 作成方法の選択（新UI：3択モーダル）

「ステートマシンを作成」ボタンを押すと 3択のモーダル が表示されます。

「自分で作成する」 をクリックします。

「テンプレートを選択」を押してしまった場合：
テンプレートギャラリーが開きます。左上の「✕」で閉じて、改めてモーダルから「自分で作成する」を選んでください。

2-2. 名前とタイプの設定（モーダル）

「自分で作成する」をクリックすると Workflow Studio が開き、同時に設定モーダルが表示されます。

「続行」をクリックするとモーダルが閉じ、Workflow Studio の編集画面に切り替わります。

標準（Standard）と Express の違い：
標準タイプは「正確に1回実行」「最大1年の実行時間」「実行履歴をコンソールで確認可能」が特徴です。受注処理のような確実な実行が必要なユースケースに適しています。

2-3. ASL の入力（「{ } コード」タブ）

Workflow Studio の画面上部にある 「{ } コード」 タブをクリックしてコードエディタを表示します。

既存の内容を全て削除し、以下の JSON を貼り付けます。

【重要】 REPLACE_WITH_ARN_ValidateFunction などのプレースホルダーを、① で控えた実際の Lambda ARN に置き換えること。

{
  "Comment": "受注処理ワークフロー（検証 → 並列処理 → 確定）",
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ValidateFunction",
      "Next": "ProcessInParallel",
      "Retry": [
        {
          "ErrorEquals": ["States.ALL"],
          "IntervalSeconds": 2,
          "MaxAttempts": 1,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError",
          "ResultPath": "$.error"
        }
      ]
    },
    "ProcessInParallel": {
      "Type": "Parallel",
      "Branches": [
        {
          "StartAt": "CheckInventory",
          "States": {
            "CheckInventory": {
              "Type": "Task",
              "Resource": "REPLACE_WITH_ARN_InventoryFunction",
              "End": true
            }
          }
        },
        {
          "StartAt": "ProcessPayment",
          "States": {
            "ProcessPayment": {
              "Type": "Task",
              "Resource": "REPLACE_WITH_ARN_PaymentFunction",
              "End": true
            }
          }
        }
      ],
      "Next": "ConfirmOrder",
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError",
          "ResultPath": "$.error"
        }
      ]
    },
    "ConfirmOrder": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ConfirmFunction",
      "End": true
    },
    "HandleError": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ErrorHandlerFunction",
      "End": true
    }
  }
}

貼り付けると 「フロー」タブ に切り替えると、フロー図が自動生成されます。ASL を正しく記述できているかを視覚的に確認できます。

2-4. 実行ロールの確認と作成（「設定」タブ）

画面上部の 「設定」 タブをクリックして実行ロールを確認します。

「新しいロールを作成」を選ぶと、以下のような青いボックスが表示されます。

実行ロールは、完全な許可で作成されます。StepFunctions-OrderWorkflow-role-XXXX という名前の新しい実行ロールが作成されます。ステートマシンで指定されたアクションに必要なすべての許可が自動生成されます。

「自動生成された許可を確認」を展開すると lambda:Invoke が含まれていることを確認できます。

右上の 「作成」 ボタンをクリックします。

IAMロールの自動作成について：
ASL 定義に記述した Lambda ARN に対して lambda:Invoke 権限を持つロールが自動的に作成されます。SAM版では LambdaInvokePolicy ポリシーでこれを明示的に定義しています。

③ 動作テスト

Step Functions → OrderWorkflow → 「実行を開始」

テスト1: 正常処理

入力データ:

{
  "order_id": "ORD-001",
  "item_id": "item-001",
  "quantity": 2
}

「実行を開始」をクリックします。

実行グラフで確認:

• 全ステートが緑色になることを確認する
• ProcessInParallel の2つのブランチが同時に緑になることを確認する（並列処理の視覚化）

出力を確認:

実行完了後、「出力」タブで以下のような JSON が表示されます。

{
  "order_id": "ORD-001",
  "item_id": "item-001",
  "quantity": 2,
  "amount": 2000,
  "confirmed_at": "2026-03-01T10:00:00.000000+00:00",
  "status": "confirmed"
}

テスト2: 在庫切れエラー（Parallel Catch の確認）

入力データ:

{
  "order_id": "ORD-002",
  "item_id": "item-999",
  "quantity": 1
}

期待する動作:

1. ValidateOrder → 成功
2. ProcessInParallel → CheckInventory が ValueError を発生させる
3. ProcessInParallel の Catch が動作 → HandleError へ遷移
4. HandleError → 成功（エラー情報をログに記録して終了）

実行グラフで確認:

• CheckInventory が赤くなる
• ProcessInParallel から HandleError へ遷移するパスが強調される

出力を確認:

{
  "status": "error",
  "error_type": "ValueError",
  "error_cause": "在庫不足: item_id=item-999",
  "original_input": {
    "order_id": "ORD-002",
    "item_id": "item-999",
    "quantity": 1,
    "validated": true
  }
}

テスト3: 支払い失敗エラー（Parallel Catch の確認）

入力データ:

{
  "order_id": "ORD-003",
  "item_id": "item-001",
  "quantity": 2,
  "fail_payment": true
}

期待する動作:

1. ValidateOrder → 成功
2. ProcessInParallel → ProcessPayment が RuntimeError を発生させる
3. ProcessInParallel の Catch が動作 → HandleError へ遷移

テスト4: 検証エラー（ValidateOrder Retry + Catch の確認）

入力データ（order_id を省略）:

{
  "item_id": "item-001",
  "quantity": 2
}

期待する動作:

1. ValidateOrder → ValueError 発生
2. Retry: IntervalSeconds: 2 で2秒後に自動リトライ（合計2回試行）
3. 2回とも失敗 → Catch が動作 → HandleError へ遷移

Retry の確認方法:

実行グラフで ValidateOrder を選択 → 「イベント」タブ で以下の順序を確認します：

TaskStateEntered → TaskScheduled → TaskStarted → TaskFailed
  → TaskScheduled（リトライ1回目）→ TaskStarted → TaskFailed
  → TaskStateExited（Catch 発動）→ HandleError へ

ValidateFunction が合計2回呼ばれていることが分かります。

④ リソースの削除

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

1. ステートマシンを削除する

Step Functions → OrderWorkflow → 「削除」→ 確認テキストを入力 → 「削除」

削除後、ステータスが「削除中」に変わります。以下のようなメッセージが表示されます：

ステートマシンに削除のマークが付けられました。すべての実行が停止されると削除されます。

これは正常な動作です。実行中のワークフローがすべて終了するまで完全削除を待つ仕様のため、実行中のものがなければ数秒〜数十秒でリストから消えます。ページをリロードして確認します。

2. Lambda 関数を5つ削除する

Lambda → 関数一覧 → 各関数を選択 → 「アクション」→「削除」

削除対象:

• ValidateFunction
• InventoryFunction
• PaymentFunction
• ConfirmFunction
• ErrorHandlerFunction

3. IAM ロールを削除する（任意）

Step Functions の実行ロール（StepFunctions-OrderWorkflow-role-XXXX）と、Lambda 関数のロール（ValidateFunction-role-XXXX など5つ）を削除します。

IAM → ロール → 各ロールを検索して削除

4. CloudWatch Logs のロググループを削除する（任意）

CloudWatch → ロググループ → 各 Lambda の /aws/lambda/関数名 を削除

SAMとの対比

トラブルシューティング

まとめ

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

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

コンソールでStep Functionsの概念を理解したら、SAMで同じ構成をコードで定義することで「SAMが何を自動化しているか」が明確になります。DefinitionSubstitutions による ARN の自動差し込みや、LambdaInvokePolicy によるワンライン権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでStep Functions + Lambdaワークフローを構築する手順【SAM版との比較付き / 新UI対応】 first appeared on CayTech Lab.

はじめに

この記事は、SAM版ハンズオン記事の比較版です。

SAM版ではコマンド数本でS3・OAC・CloudFront・バケットポリシーが一括デプロイできましたが、実際にコンソールで操作してみると思わぬハマりポイントがいくつかあります。

特に CloudFront コンソールは 2026年に大きくUIが刷新 され、6ステップのウィザード形式に変わりました。ネット上の古い手順書と画面が全く違って戸惑う人が多いはずです。この記事では 2026年の新UI に対応した手順を詳しく解説します。

この記事を読むとわかること：

• CloudFront 新UI（6ステップウィザード）の各ステップで何を設定するか
• 「Allow private S3 bucket access to CloudFront」チェックボックスで何が自動化されるのか
• 削除時に新登場した「Pricing plan キャンセル」手順（これを知らないと削除できない）
• キャッシュ削除（旧: 「無効化」）の操作と注意点

CloudFront 新UI で戸惑いやすいポイント（先読み）

操作を始める前に、旧UIとの違いを把握しておきましょう。

「Pricing plan キャンセル」が最大のハマりポイント：
新UIで作成したディストリビューションは「Pricing plan（プライシングプラン）」に加入しています。
削除する前にプランをキャンセルする操作が必要で、しかもキャンセルは月末（翌月1日）に有効になるため、すぐに削除できません。
知らないと「subscribed to a pricing plan」エラーで詰まります（後述）。

Amazon検索[本 AWS 開発]

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

構築するもの

SAM版と全く同じ構成・機能の静的サイトホスティング環境を構築します。

ブラウザ
  ↓ HTTPS（HTTPは自動リダイレクト）
CloudFront（CDN・エッジキャッシュ）
  ↓ OAC（署名付きリクエスト）
S3 バケット（非公開・パブリックアクセスブロック）
  └── index.html / error.html

全体の作業順序

① S3 バケット作成（非公開）
      ↓
② CloudFront ディストリビューション作成（6ステップウィザード）
      ↓（自動でOAC設定・バケットポリシー更新）
③ S3 バケットポリシーの確認（自動設定を確認）
      ↓
④ HTML ファイルをアップロード
      ↓
⑤ CloudFront URL でアクセス確認
      ↓
⑥ キャッシュの動作確認（任意）
⑦ リソースの削除（要注意: 月末まで待機が必要）

順序の理由：
② でCloudFrontディストリビューションを作成する際に「どのS3バケットをオリジンにするか」を指定するため、① でバケットを先に作成しておく必要があります。

① S3 バケット作成

AWSコンソール → S3 → 「バケットを作成」

「バケットを作成」をクリックします。

パブリックアクセスをブロックしたまま使う理由：
従来の静的サイトホスティングではS3バケットを公開する方法もありましたが、現在の推奨は S3を非公開にしてCloudFront OAC経由でのみアクセスさせる構成です。直接S3 URLからのアクセスを防ぎ、CloudFrontのHTTPS・キャッシュ・WAFの恩恵を受けられます。

バケット名のルール：

• グローバルで一意（AWS全体で重複不可・削除後しばらく再利用不可）
• my-cloudfront-website-自分のAWSアカウントID のように末尾にアカウントIDを付けると一意にしやすい
• SAMでは !Sub "${AWS::StackName}-website-${AWS::AccountId}" で自動的に一意化しています

控えておく情報：

• バケット名（例: my-cloudfront-website）

② CloudFront ディストリビューション作成（新UI・6ステップウィザード）

AWSコンソール → CloudFront → 「ディストリビューションを作成」

CloudFrontはグローバルサービスのため、コンソール右上のリージョン表示は「グローバル」になります。
S3バケットのリージョンは東京（ap-northeast-1）のままで問題ありません。

ステップ1: Choose a plan（プランを選択）

「Next」をクリックします。

無料プランの内容（1ヶ月あたり）：

• リクエスト数: 100万（1M）
• データ転送: 100GB
• DDoS保護・グローバルCDN・デフォルトキャッシュルールが含まれる

ハンズオン目的では無料枠で十分です。有料プランは本番サービスで大量トラフィックが想定される場合に選択します。

SAMとの差分： SAM（CloudFormation）で作成したディストリビューションにはPricing planの概念がありません。「月額$0」のプランでも加入状態になるため、削除時にキャンセル手続きが必要になります（後述）。

ステップ2: Get started（基本設定）

「Next」をクリックします。

ステップ3: Specify origin（オリジンの指定）

このステップが最も重要です。S3バケットをオリジンとして設定し、OACを自動構成します。

Origin type セクション：

Origin セクション：

Settings セクション：

「Next」をクリックします。

「Allow private S3 bucket access to CloudFront」チェックボックスの重要性：

これが新UIの最大の改善点です。チェックを入れると：

1. CloudFrontが S3 に安全にアクセスするための OAC（Origin Access Control）を自動作成
2. ディストリビューション作成後に S3バケットポリシーを自動で更新

旧UIでの手順（参考）：

1. CloudFront → OAC を手動で作成
2. ディストリビューション作成時にOACを選択・ARNをコピー
3. S3 → バケットポリシーを手動で編集・貼り付け

新UIではこのすべてがチェック1つで完結します。

SAMとの差分： SAMでは Type: AWS::CloudFront::OriginAccessControl リソースと WebsiteBucketPolicy リソースで同じことを明示的に定義しています。

ステップ4: Enable security（セキュリティ設定）

「Security protections from WAF are included in your plan at no additional charge.」と表示されます。無料プランにWAF保護が含まれており、追加料金は発生しません。

「Next」をクリックします。

「Use monitor mode」について：
チェックを入れると「何がブロックされるかを記録するだけ」のモードになります（実際にはブロックしない）。ハンズオンでは不要なのでチェックせずに進みます。

ステップ5: Review and create（確認と作成）

設定内容を確認して「ディストリビューションを作成」をクリックします。

控えておく情報：

• CloudFront ドメイン名（例: xxxxxxxxxxxx.cloudfront.net）
• ディストリビューション ID（例: EXXXXXXXXXXXXXXXXX）

CloudFrontのデプロイには 5〜15分かかります。
ステータスが「有効」になるまで待ってから次のステップに進んでください。

③ S3 バケットポリシーの確認

新UIでは、ステップ3で「Allow private S3 bucket access to CloudFront」にチェックを入れると、ディストリビューション作成時に S3バケットポリシーが自動で更新されます。

自動設定されたポリシーを確認します。

S3 → my-cloudfront-website → 「アクセス許可」タブ → 「バケットポリシー」

以下のようなポリシーが自動で設定されていることを確認します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-cloudfront-website/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXXXXXXXXXXXXXXXXX"
                }
            }
        }
    ]
}

このポリシーのポイント：

• Principal.Service: cloudfront.amazonaws.com — CloudFrontサービスからのアクセスのみ許可
• Condition.AWS:SourceArn — 特定のディストリビューションからのアクセスのみ許可（他のCloudFrontからはアクセスできない）
• Action: s3:GetObject のみ — 読み取り専用。書き込み・削除は不可

SAMとの差分： SAMでは WebsiteBucketPolicy リソースに上記と同じポリシーを明示的に記述しています。コンソールでは自動設定されますが、SAMを読むとその中身が可視化されます。

④ HTML ファイルをアップロード

アップロードするHTMLファイルの内容を確認しておきます。自分で用意したHTMLがあればそちらを使っても構いません。

index.html（トップページ）

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>S3 + CloudFront ハンズオン</title>
  <style>
    body {
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      max-width: 640px;
      margin: 60px auto;
      padding: 20px;
      color: #333;
    }
    h1 { color: #232f3e; }
    .badge {
      background: #ff9900;
      color: white;
      padding: 3px 10px;
      border-radius: 4px;
      font-size: 0.85em;
      font-weight: bold;
    }
    .info {
      background: #f4f6f8;
      border-left: 4px solid #ff9900;
      padding: 12px 16px;
      margin: 20px 0;
      border-radius: 0 4px 4px 0;
    }
  </style>
</head>
<body>
  <h1>デプロイ成功！</h1>
  <p>
    <span class="badge">CloudFront CDN</span> 経由でこのページが配信されています。
  </p>
  <div class="info">
    <strong>このページの配信構成:</strong><br>
    S3 バケット（オリジン） → CloudFront（CDN）→ あなたのブラウザ
  </div>
  <p>S3 + CloudFront による静的サイトホスティングのハンズオンです。</p>
</body>
</html>

error.html（カスタム404ページ）

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>404 - ページが見つかりません</title>
  <style>
    body {
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      max-width: 640px;
      margin: 60px auto;
      padding: 20px;
      color: #333;
      text-align: center;
    }
    h1 { color: #cc0000; }
    a { color: #ff9900; }
  </style>
</head>
<body>
  <h1>404 - ページが見つかりません</h1>
  <p>お探しのページは存在しないか、移動・削除された可能性があります。</p>
  <p><a href="/">トップページへ戻る</a></p>
</body>
</html>

上記2ファイルをS3にアップロードします。

方法A: S3 コンソールからアップロード

S3 → my-cloudfront-website → 「アップロード」

index.html と error.html を選択してアップロードします。

方法B: AWS CLI でアップロード

aws s3 sync C:\my-aws\aws-learning-projects\s3-cloudfront-hosting\website\ ^
  s3://my-cloudfront-website/ ^
  --region ap-northeast-1

⑤ CloudFront URL でアクセス確認

CloudFrontのステータスが「有効」になったらブラウザでアクセスします。

https://xxxxxxxxxxxx.cloudfront.net

期待する表示: index.html の内容が表示される。

HTTP → HTTPS リダイレクトの確認：

http://xxxxxxxxxxxx.cloudfront.net

HTTPでアクセスすると自動的にHTTPSにリダイレクトされることを確認します。

カスタム404ページの確認：

https://xxxxxxxxxxxx.cloudfront.net/notfound

存在しないページにアクセスすると error.html の内容が表示されることを確認します。

⑥ キャッシュの動作確認（任意）

CloudFront CDNの重要な概念「キャッシュ」と「キャッシュ削除（旧: 無効化）」を体験します。

6-1. index.html を更新してアップロード

index.html のテキストを変更して再度アップロードします。

aws s3 cp C:\my-aws\aws-learning-projects\s3-cloudfront-hosting\website\index.html ^
  s3://my-cloudfront-website/index.html ^
  --region ap-northeast-1

ブラウザでCloudFront URLにアクセスしても古いキャッシュが表示される場合があります（TTLが切れるまで）。

6-2. キャッシュを削除する（新UI: 「キャッシュ削除」タブ）

CloudFront → ディストリビューション → 「キャッシュ削除」タブ → 「キャッシュ削除を作成」

「キャッシュ削除を作成」をクリックします。ステータスが「完了」になったら（1〜3分）ブラウザを強制リロード（Ctrl+Shift+R）して確認します。

旧UIとの名称変更：
旧UIでは「無効化（Invalidation）」タブでしたが、新UIでは「キャッシュ削除」に名称変更されました。機能は同じです。

無効化の料金：
毎月最初の1,000パスは無料。それ以降は $0.005/パス。
/* は1パスとしてカウントされるため、ハンズオン程度なら無料枠内です。

⑦ リソースの削除

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

重要: 新UIで作成したディストリビューションの削除手順（旧UIとは異なります）

旧UIでは「無効化 → 削除」の2ステップでしたが、新UIでは以下の手順が必要です：
無効化 → Pricing plan キャンセル → 月末（翌月1日）まで待機 → 削除

月末まで削除できないのは想定外でハマる人が多いポイントです。

1. CloudFront ディストリビューションを無効化する

CloudFront → ディストリビューション → 対象を選択 → 「無効化」ボタン → 確認 → 「無効化」

ステータスが「有効」→「無効」に変わるまで待ちます（5〜15分）。

無効化が完了しないとディストリビューションを削除できません。（削除ボタンがグレーアウトしたまま）

2. Pricing plan（プライシングプラン）をキャンセルする

ステータスが「無効」になったら、プランをキャンセルします。

無効化したディストリビューションをクリック → 「Billing」セクション → 「Manage plan」→「Cancel plan」（プランをキャンセル）→「Cancel plan」ボタン

キャンセルが受け付けられると「無料プランのキャンセルがスケジュールされています。このプランは [月末日] に終了します。」と表示されます。

「この日を過ぎると、すべての使用は従量制料金で課金されます」という警告について：
これは「もし使い続けた場合」の説明です。ディストリビューションは「無効」状態のためリクエストを受け付けず、使用量ゼロ = 課金ゼロです。無効化済みであれば課金されません。

3. 月末を待ってから削除する

プランキャンセルは月末（翌月1日）に有効になります。それまでディストリビューションは削除できません。

月末以降：

ディストリビューションを選択 → 「削除」→ 確認 → 「削除」

キャンセル前に削除しようとすると：
You can't delete this distribution while it's subscribed to a pricing plan.
というエラーが表示されます。その場合は手順2のプランキャンセルを行ってください。

4. S3 バケット内のファイルをすべて削除する

方法A: AWS CLI で一括削除（推奨）

aws s3 rm s3://my-cloudfront-website --recursive --region ap-northeast-1

方法B: S3 コンソールから

S3 → my-cloudfront-website → ファイルをすべて選択 → 「削除」→ 確認テキストを入力 → 「オブジェクトを削除」

5. S3 バケットを削除する

S3 → my-cloudfront-website を選択 → 「削除」→ バケット名を入力 → 「バケットを削除」

6. CloudFront OAC を削除する（任意）

ステップ3で自動作成された OAC は、ディストリビューション削除後も残ります。不要なら手動で削除します。

CloudFront → 左サイドバー「オリジンアクセスコントロール」→ 作成した OAC を選択 → 「削除」

注意： ディストリビューションの「オリジン」タブではなく、左サイドバーの「オリジンアクセスコントロール」から削除します。ディストリビューションが削除済みでないと削除できません。

SAMとの対比まとめ

削除の大きな違い：
コンソール新UIで作成したディストリビューションはPricing planに加入するため、プランキャンセル後に月末まで削除できない制約があります。
SAMで作成したディストリビューションにはPricing planの概念がないため、sam delete で即座に削除手続きが完了します。
これがSAM版の大きなメリットのひとつです。

トラブルシューティング

まとめ

コンソール操作で確認できたこと

今回のコンソール操作で、SAMが自動化していることと、新UI特有のハマりポイントが明確になりました：

どちらを使うべきか

関連記事

• SAM版ハンズオン — コマンド数本でS3 + CloudFront環境を構築

AWSハンズオン - S3 + CloudFrontで静的サイトをCDN配信しよう【SAM版 / Windows対応】

はじめに「ウェブサイトを公開したいけど、サーバーは持ちたくない」「静的なHTMLサイトを世界中から速く見せたい」という要件に、S3 + CloudFront の組み合わせはベストな選択肢のひとつです。この記事では、AWS SAM（Serve...

caymezon.com

2026.02.23

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでS3 + CloudFront静的サイトホスティングを構築する手順【SAM版との比較付き / 新UI対応】 first appeared on CayTech Lab.

はじめに

この記事は、SAM版ハンズオン記事の比較版です。

SAM版ではコマンド数本でS3バケット・Lambda・イベント通知設定が完了しましたが、「SAMが裏で何をやっているのか？」「バケット名のグローバルユニーク問題はどう解決する？」「再帰呼び出しの警告って何？」 といった疑問を実際のコンソール操作を通じて体験できるのがこの記事です。

この記事を読むとわかること：

• S3・Lambda を個別に設定する順序と依存関係
• SAMの !Sub "${AWS::StackName}-upload-${AWS::AccountId}" が解決していること（バケット名のグローバルユニーク問題）
• 「再帰呼び出し」警告の意味と、今回は無視してよい理由
• S3バケット削除時に「先に空にする」が必要な理由

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

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のファイルアップロードトリガー環境を構築します。

ファイルアップロード（コンソール / AWS CLI）
  ↓ S3 ObjectCreated イベント発火
S3 バケット（my-s3-event-upload）
  ↓ Lambda を呼び出し
Lambda（S3EventFunction / Python 3.12）
  ↓ ファイル情報（バケット名・ファイル名・サイズ）をログ出力
CloudWatch Logs

全体の作業順序

① S3 バケット作成
      ↓
② Lambda 関数作成（コード入力）
      ↓
③ S3 トリガーを Lambda に追加（リソースベースポリシーも自動設定）
      ↓
④ ファイルアップロードして動作テスト
⑤ リソースの削除（S3を先に空にする）

順序の理由：
③でS3トリガーを追加する際に「どのバケットを対象にするか」を選択するため、①でバケットを先に作成しておく必要があります。SQSハンズオンのようにARNのコピーが必要な場面はありませんが、バケットが存在しないとトリガー設定画面で選択できません。

① S3 バケット作成

AWSコンソール → S3 → 「バケットを作成」

1-1. バケットの設定

「バケットを作成」をクリックします。

バケット名のルール（SAMとの違いが出るポイント）：

S3のバケット名はAWS全体（全リージョン・全アカウント）でグローバルユニークである必要があります。

• 小文字・数字・ハイフンのみ使用可（大文字・アンダースコアは使えない）
• my-s3-event-upload だと他のユーザーがすでに使っている可能性がある

一意にする推奨の方法：

• my-s3-event-upload-自分のAWSアカウントID（最も確実）
• my-s3-event-upload-20260222（日付を付ける）

SAMでは !Sub "${AWS::StackName}-upload-${AWS::AccountId}" で自動的にアカウントIDを付加しています。コンソールではこのルールを頭の中で考えて手動入力する必要があります。

控えておく情報：

• バケット名（例: my-s3-event-upload）

② Lambda 関数作成

AWSコンソール → Lambda → 「関数の作成」

2-1. 基本設定

「関数の作成」をクリックします。

実行ロールについて：
今回の Lambda はS3イベントのメタデータ（バケット名・ファイル名・サイズ）を受け取るだけで、S3からファイルの中身を読み取る処理は行いません。
そのため、基本実行ロール（CloudWatch Logs への書き込み権限のみ）で動作します。
ファイルの中身を読み取りたい場合は、実行ロールに s3:GetObject 権限を追加する必要があります。

2-2. コードの入力

関数ページ → 「コード」タブ → コードエディタで lambda_function.py を開きます。

既存の内容を全て置き換えて以下を貼り付けます。

import json
import urllib.parse


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:          # 複数ファイル同時アップロードに対応
        bucket = record["s3"]["bucket"]["name"]
        # キー名は URL エンコードされているためデコードが必要（日本語・スペース対応）
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])
        size = record["s3"]["object"]["size"]
        event_name = record["eventName"]     # 例: "ObjectCreated:Put"
        event_time = record["eventTime"]     # 例: "2026-02-22T10:00:00.000Z"

        info = {
            "eventName": event_name,
            "bucket": bucket,
            "key": key,
            "sizeBytes": size,
            "eventTime": event_time,
        }

        print(json.dumps(info, ensure_ascii=False))
        results.append(info)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

「Deploy」ボタンをクリックしてコードを保存します。

③ S3 トリガーを Lambda に追加

Lambdaコンソールからトリガーを追加する方法と、S3コンソールからイベント通知を設定する方法の2つがありますが、ここではLambdaコンソールから行います。

Lambda → S3EventFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリックします。

「再帰呼び出し」の警告とは：

S3バケットへのアップロードをトリガーに同じバケットへ書き込む Lambda を設定すると、無限ループが発生します。例えば「画像をアップロード → Lambdaがリサイズして同じバケットに保存 → それがまたトリガーになる → …」というパターンです。

今回の Lambda はS3への書き込みを行わず、ログを出力するだけなので問題ありません。「このトリガーを確認しました」にチェックして続行してください。

SAMとの差分： SAMの Type: S3 イベントでも同じ構成になっています。SAMは警告なしに設定されますが、同じリスクが存在します。

自動設定されること：
Lambdaのリソースベースポリシーに「S3からの呼び出しを許可するポリシー」が自動追加されます。
S3がLambdaを呼び出すためのIAM設定を手動で行う必要はありません。

④ 動作テスト

4-1. テスト用ファイルの準備

echo テストファイルです > C:\test.txt

4-2. ファイルのアップロード

方法A: S3 コンソールからアップロード

S3 → my-s3-event-upload → 「アップロード」→「ファイルを追加」→ test.txt を選択 → 「アップロード」

方法B: AWS CLI でアップロード

aws s3 cp C:\test.txt s3://my-s3-event-upload/test.txt --region ap-northeast-1

4-3. CloudWatch Logs でログを確認

Lambda → S3EventFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」→ 最新のログストリームを開きます。

期待するログ出力：

{"eventName": "ObjectCreated:Put", "bucket": "my-s3-event-upload", "key": "test.txt", "sizeBytes": 28, "eventTime": "2026-02-22T10:00:00.000Z"}
{"processedCount": 1}

確認ポイント：

• "eventName": "ObjectCreated:Put" — S3の Put（アップロード）が検知されている
• "key": "test.txt" — アップロードしたファイル名が正しく取得されている
• "sizeBytes" — ファイルサイズが記録されている

4-4. 日本語ファイル名のテスト（任意）

echo 日本語テスト > "C:\テスト.txt"
aws s3 cp "C:\テスト.txt" "s3://my-s3-event-upload/テスト.txt" --region ap-northeast-1

ログで "key": "テスト.txt" と正しくデコードされていることを確認します。

⑤ リソースの削除

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

S3バケット削除の重要な注意点：
オブジェクトが残っているバケットは削除できません。
先にバケット内のファイルをすべて削除してからバケットを削除してください。

SAMの sam delete でも同じ理由から「先にバケットを空にする」手順が必要です。この仕様はSAMを使っても変わりません。

1. S3 バケット内のオブジェクトをすべて削除する

方法A: S3 コンソールから

S3 → my-s3-event-upload → ファイルをすべて選択 → 「削除」→ 確認テキストを入力 → 「オブジェクトを削除」

方法B: AWS CLI で一括削除（推奨）

aws s3 rm s3://my-s3-event-upload --recursive --region ap-northeast-1

2. S3 バケットを削除する

S3 → my-s3-event-upload を選択 → 「削除」→ バケット名を入力 → 「バケットを削除」

3. Lambda 関数を削除する

Lambda → 関数 → S3EventFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

4. IAM ロールを削除する（任意）

IAM → ロール → S3EventFunction-role-XXXX を選択 → 「削除」→ ロール名を入力 → 「削除」

Lambda を削除してもIAMロールはそのまま残ります。不要なら手動で削除します。

5. CloudWatch Logs のロググループを削除する（任意）

CloudWatch → ロググループ → /aws/lambda/S3EventFunction → 「アクション」→「ロググループの削除」

SAMとの対比まとめ