Step2: クラウド2

RDS インスタンスの作成

RDS で MySQL 8.0 のインスタンスを作成します。sns-camp-api は起動時に CREATE DATABASE IF NOT EXISTS と CREATE TABLE を自動実行するため、データベースやテーブルを手動で作成する必要はありません。

.env ファイルの作成

sns-camp-api のソースには .env.example が同梱されています。これをコピーして .env を作成し、RDS に合わせた値に書き換えます。

アプリケーションのディレクトリに移動します。

cd /home/ec2-user/sns-camp-api

.env.example をコピーして .env を作成します。

cp .env.example .env

エディタで .env を開き（例: vi .env）、以下の項目を RDS に合わせて書き換えます。

vi の操作に慣れていない場合は、以下のように cat と heredoc を使って .env を一括で上書きする方法でも代替できます（<...> の箇所を RDS の値に置き換えてから貼り付けてください）。

cat > .env <<EOF
PORT=8080
DB_HOST=<RDSのエンドポイント>
DB_PORT=3306
DB_USER=<RDSのユーザ名>
DB_PASSWORD=<RDSのパスワード>
DB_NAME=sns_camp
JWT_SECRET=your-secret-key-change-in-production
ALLOWED_ORIGINS=*
EOF

systemd から .env を読み込む

Step 1 で作成した systemd サービスに EnvironmentFile= を追加して、.env の中身を環境変数としてプロセスに渡します。/etc/systemd/system/sns-camp-api.service の [Service] セクションに EnvironmentFile= 行を追記してください。

[Unit]
Description=SNS Camp API
After=network.target

[Service]
Type=simple
User=ec2-user
WorkingDirectory=/home/ec2-user/sns-camp-api
EnvironmentFile=/home/ec2-user/sns-camp-api/.env
ExecStart=/usr/local/bin/uvicorn app.main:app --host 0.0.0.0 --port 8080
Restart=on-failure

[Install]
WantedBy=multi-user.target

設定を反映してサービスを再起動します。

sudo systemctl daemon-reload

sudo systemctl restart sns-camp-api

疎通確認

ユーザ登録のエンドポイントが正常に応答すれば、RDS 接続が成功しています。

curl -X POST http://<公開URL>/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","email":"test@example.com","password":"password123","display_name":"テストユーザ"}'

接続に失敗する場合は、以下を順に確認してください。

• RDS のセキュリティグループで EC2 からのインバウンド（3306）が許可されているか
• EC2 と RDS が同じ VPC のサブネットに配置されているか
• 環境変数の値が RDS の設定と一致しているか

Linux の上で Next.js アプリケーションを動かした経験がない方向けのコマンド例集です。以下の手順を参考に実行することで、sns-camp-front を仮想サーバ上で動作させるところまで到達できます。

sns-camp-front は Next.js 14 で実装されています。仮想サーバ上で動かす場合、Node.js のインストールと、バックエンドの URL を指す環境変数の設定が必要です。まずローカルで、ダウンロードした sns-camp-front.zip を展開して自分の GitHub リポジトリに push します。その後、仮想サーバ上でそのリポジトリを git clone して配置します。GitHub を使った経験がある方は以下の手順で git clone、まだ GitHub を触っていない方は末尾の「（参考）GitHub を使わずに zip を転送する方法」で進めてください。GitHub の使い方は Git／GitHub 章で学べます。

GitHub リポジトリへの push（ローカルで実施）

GitHub にログインして、新しいリポジトリを作成しておいてください。プライベート・公開のどちらでも構いません。初期ファイル（README や .gitignore）は作成しない設定を推奨します。

ダウンロードした zip をローカルで展開します。

Windowsの場合:

Expand-Archive sns-camp-front.zip -DestinationPath sns-camp-front

Macの場合:

unzip sns-camp-front.zip -d sns-camp-front

展開したフォルダに移動します。

cd sns-camp-front

Git リポジトリを初期化します。

git init -b main

ファイルをステージングしてコミットします。

git add .

git commit -m "Initial commit"

GitHub で作成したリポジトリをリモートとして設定します。<自分のGitHubリポジトリURL> は作成したリポジトリの URL（例: https://github.com/<ユーザ名>/sns-camp-front.git）に置き換えてください。

git remote add origin <自分のGitHubリポジトリURL>

リモートに push します。

git push -u origin main

Node.js 20 のインストール

ここからは仮想サーバ側での操作です。Amazon Linux 2023 の場合は、以下のコマンドで Node.js 20 をインストールできます。

sudo dnf install -y nodejs20

サンプルアプリケーションの配置

ホームディレクトリに移動します。

cd ~

自分の GitHub リポジトリから clone します。

git clone <自分のGitHubリポジトリURL> sns-camp-front

clone したディレクトリに移動します。

cd sns-camp-front

依存関係のインストールとビルド

依存関係をインストールします。

npm install

バックエンド API の公開 URL を指定してビルドします。

NEXT_PUBLIC_API_URL=https://<APIの公開URL>/api/v1 npm run build

サーバの起動

NEXT_PUBLIC_API_URL=https://<APIの公開URL>/api/v1 npm start

NEXT_PUBLIC_API_URL は、ブラウザから見える API の URL を指定します（仮想サーバの内部 DNS ではなく、ALB や CloudFront 経由の公開 URL）。常駐化する場合は sns-camp-api と同様に systemd サービスとして登録してください。

（参考）GitHub を使わずに zip を転送する方法

GitHub がすぐに使えない場合は、ローカルの sns-camp-front.zip を SCP で仮想サーバに転送し、仮想サーバ上で unzip して展開する方法でも代替できます。

ローカルで実施

ローカルから仮想サーバに zip を転送します。<鍵ファイル> は仮想サーバ作成時にダウンロードした .pem ファイル、<仮想サーバのパブリックIP> は仮想サーバのパブリック IP アドレスに置き換えてください。

scp -i <鍵ファイル> sns-camp-front.zip ec2-user@<仮想サーバのパブリックIP>:~/

仮想サーバで実施

unzip をインストールします。

sudo dnf install -y unzip

ホームディレクトリに移動し、zip を展開します。

cd ~

unzip sns-camp-front.zip -d sns-camp-front

cd sns-camp-front

sns-camp-front がバックエンド API に接続する URL は、ビルド時引数（NEXT_PUBLIC_API_URL）で指定します。独自ドメインの設定状況に応じて URL を使い分けてください。

NEXT_PUBLIC_* の環境変数は Next.js のビルド時に埋め込まれるため、API の URL を変えた場合は再ビルドが必要です。Amplify を利用する場合は、Amplify Hosting の環境変数で NEXT_PUBLIC_API_URL を設定するとビルド時に注入されます。

Amplify Hosting で sns-camp-front を配信する場合、GitHub リポジトリと連携してビルド・デプロイを自動化します。

Amplify アプリケーションの作成

マネジメントコンソールの AWS Amplify を開き、「新しいアプリ」→「ホスティングを開始」から以下の手順で作成します。

保存すると初回ビルドが始まり、完了するとデフォルトドメイン（https://<ブランチ名>.<ID>.amplifyapp.com）が払い出されます。

独自ドメインの割り当て（任意要件を実施する場合）

Amplify アプリの「ドメイン管理」から独自ドメインを追加し、Route 53 で管理する独自ドメインに割り当てます。Amplify Hosting はデフォルトで ACM 証明書の発行・HTTPS 化を自動で行います。

再デプロイ

GitHub の指定ブランチに push すれば、Amplify Hosting が自動でビルド・デプロイを実行します。NEXT_PUBLIC_API_URL の値を変更した場合は、Amplify の画面から「再デプロイ」を実行してください（環境変数はビルド時に埋め込まれるため、変更後は再ビルドが必要）。

sns-camp-front を Auto Scaling グループで起動する場合、Step 1 の sns-camp-api と同じく、Launch Template の「ユーザデータ」にセットアップスクリプトを設定しておくと、新しいインスタンスの初回起動時に自動実行されます。

以下のスクリプトを Launch Template の「ユーザデータ」に設定してください。<自分のGitHubリポジトリURL> は自分のリポジトリ URL に、<APIの公開URL> は sns-camp-api の公開 URL に書き換えてください。

#!/bin/bash
set -eux

# Git と Node.js のインストール
dnf install -y git nodejs20

# アプリケーションの clone
cd /home/ec2-user
sudo -u ec2-user git clone <自分のGitHubリポジトリURL> sns-camp-front

# 依存関係のインストールとビルド
cd sns-camp-front
sudo -u ec2-user npm install
sudo -u ec2-user NEXT_PUBLIC_API_URL=https://<APIの公開URL>/api/v1 npm run build

# systemd サービスの作成
cat > /etc/systemd/system/sns-camp-front.service <<EOF
[Unit]
Description=SNS Camp Front
After=network.target

[Service]
Type=simple
User=ec2-user
WorkingDirectory=/home/ec2-user/sns-camp-front
Environment=NEXT_PUBLIC_API_URL=https://<APIの公開URL>/api/v1
ExecStart=/usr/bin/npm start
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

# サービスの有効化・起動
systemctl daemon-reload
systemctl enable --now sns-camp-front

ユーザデータは EC2 の初回起動時に root ユーザとして実行されます。実行ログは EC2 インスタンス内の /var/log/cloud-init-output.log で確認できます。

CloudFront + EC2 構成では、CloudFront を迂回して EC2（または ALB）に直接アクセスされてしまうと、CloudFront で設定したキャッシュ・WAF などが素通しになります。本課題の必須要件ではありませんが、本番運用では以下のような対策で CloudFront 経由のアクセスのみに限定する考え方があります。

Step 2 の履修講座では扱っていないトピックです。本番運用に近づける場合は、AWS 応用講座やセキュリティ対策講座で学んだ後に取り組むとよいです。

任意要件の「独自ドメイン・HTTPS化」のうち、バックエンド API（ALB）の HTTPS 化手順の例です。独自ドメインを Route53 で管理している前提で記載しています。

ACM で証明書を発行する

ALB で HTTPS を終端するには、ACM の証明書が ALB と同じリージョン（東京: ap-northeast-1） で発行されている必要があります。CloudFront 用の証明書とは別に、東京リージョンで発行してください。

マネジメントコンソールの ACM（東京リージョン）→ 「証明書をリクエスト」→ 「パブリック証明書をリクエスト」を選び、以下の値で作成します。

発行後、ACM の画面で「Route 53 でレコードを作成」ボタンを押すと、検証用の CNAME レコードが Route53 に自動で追加されます。数分待つと証明書のステータスが「発行済み」になります。

ALB に 443 リスナーを追加する

マネジメントコンソールの EC2 → ロードバランサー → 対象 ALB → 「リスナー」タブ → 「リスナーを追加」から設定します。

あわせて、ALB のセキュリティグループで 443 ポートのインバウンドを許可してください。

Route 53 で ALB にエイリアスを張る

マネジメントコンソールの Route 53 → 対象のホストゾーン → 「レコードを作成」から以下を作成します。

動作確認

以下のコマンドで HTTPS 経由で疎通確認します。

curl -i https://api.<自分のドメイン>/health

HTTP/2 200 と {"status":"ok"} が返れば完了です。