ステップ２：EC2を利用した単純なWebサイトのホスティング

今回のステップの概要とECサイトとの関連について

このステップでは、AWSのEC2（Elastic Compute Cloud）を使って、シンプルなWebサイトをインターネット上に公開する方法を学びます。EC2は、クラウド上の仮想サーバーで、自分のパソコンのように自由に使えるコンピュータリソースです。

ECサイトの構築において、EC2はお店の「建物」に相当します。お客さん（ユーザー）が訪れて商品を見たり購入したりするための場所を提供します。このステップでは、まだ本格的なECサイトではなく、シンプルなWebページを公開することで、EC2の基本的な使い方を理解します。

このステップで学ぶこと

EC2インスタンス（仮想サーバー）の作成方法
セキュリティグループ（ファイアウォール）の設定方法
Systems Manager セッションマネージャーを使ったサーバーへの接続方法
Webサーバーのインストールと設定方法
Next.jsのECサイトのデプロイ方法

リソースの関わりと構成説明

ステップ2で作成するリソースは、ECサイトのWebサーバー環境を構築するものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。

EC2インスタンスとECサイトの関わり

EC2インスタンス「ECサイトWebサーバー」は、ECサイトの「店舗」そのものです。お客さん（ユーザー）がアクセスして商品を閲覧したり購入したりする場所を提供します。このサーバー上でNext.jsアプリケーションが動作し、ECサイトのウェブページを表示します。

セキュリティグループとECサイトの関わり

セキュリティグループ「ECサイトWebSG」は、ECサイトの「セキュリティゲート」のような役割を果たします。どのような通信を許可するかを制御することで、不正アクセスからECサイトを守ります。今回は、ユーザーからのHTTPアクセス（ポート80）のみを許可しています。

IAMロールとECサイトの関わり

IAMロール「EC2SSMRole」は、EC2インスタンスに対して「管理者権限証明書」のような役割を果たします。このロールにより、AWSのSystems Managerサービスを使ってEC2インスタンスに安全に接続できるようになります。SSH ポートを開放せずに管理作業ができるため、セキュリティが向上します。

Next.jsアプリケーションとECサイトの関わり

Next.jsアプリケーションは、ECサイトの「店内ディスプレイ」のようなものです。商品の表示方法や、ユーザーが操作するインターフェイスを提供します。このアプリケーションがあることで、ユーザーは快適にショッピングを楽しむことができます。

PM2との関わり

PM2は「店長」のような役割を果たします。Next.jsアプリケーションが常に正常に動作するように監視し、問題が発生した場合は自動的に再起動します。また、サーバーが再起動した場合でも、アプリケーションが自動的に起動するように設定します。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. EC2インスタンスの作成

Note

AWSでの役割

EC2は、AWSが提供するクラウド上の仮想サーバーサービスです。物理的なサーバーを購入・設置することなく、必要な時に必要な分だけコンピューティングリソースを利用できます。

特徴:

数分でサーバーを起動・停止可能
CPU、メモリ、ストレージを柔軟に選択
従量課金制（使った分だけ支払い）
自動スケーリング機能

さくらクラウドでの対応

さくらクラウドでは「サーバー」がEC2に相当します。

さくらのクラウドサーバー
石狩データセンターなど国内データセンター
時間課金・月額課金を選択可能
CPUとメモリの組み合わせプランを提供

オンプレミスでの対応

オンプレミス環境では「物理サーバー + 仮想化技術」が対応します。

VMware vSphere、Hyper-V、KVMなどの仮想化基盤
物理サーバーの購入・設置・保守が必要
初期投資は高いが、長期利用ではコスト効率が良い場合も
データセンターやサーバールームの確保が必要

1-1. EC2ダッシュボードにアクセス

AWSマネジメントコンソールにログインします。
画面上部の検索バーに「EC2」と入力し、表示される「EC2」をクリックします。
EC2ダッシュボードが表示されます。

1-2. インスタンスの起動

EC2ダッシュボードで「インスタンスを起動」ボタンをクリックします。

1-3. 名前とタグ

名前：「ec-site-web」と入力します。

1-4. アプリケーションおよびOSイメージ (Amazon マシンイメージ)

Amazon マシンイメージ (AMI)：「Amazon Linux 2023 AMI」を選択します。

1-5. インスタンスタイプ

インスタンスタイプ：「t3.medium」を選択します。

1-6. キーペア (ログイン)

キーペア名：「キーペアなしで続行」を選択します。
- （注：Systems Manager セッションマネージャーを使用するため、SSHキーペアは不要です）

Tip

【解説】Amazon Linux 2023 AMIを選択する理由

Amazon Linux 2023（AL2023）は、AWSが開発・提供するクラウド最適化されたLinuxディストリビューションです。AWSが推奨する理由として、まず長期サポートが挙げられます。AL2023は5年間の長期サポート（最初の2年間は標準サポート、その後3年間はメンテナンスサポート）を提供し、企業の長期プロジェクトに安定性をもたらします。

セキュリティ面では、事前設定済みのセキュリティポリシーやシステム暗号化ポリシーが組み込まれており、SELinuxの強化設定も含まれています。これにより、初学者でも高いセキュリティ基準を保つことができます。また、決定論的アップデート機能により、パッケージのバージョン管理が予測可能で、本番環境での安定性が向上します。

AWSサービスとの統合においても、EC2、EBS、VPCなどのAWSサービスとの最適な連携が実現されており、AWS環境での開発・運用が効率化されます。Fedoraをベースとしているため、モダンなソフトウェアパッケージにアクセスでき、最新の開発ツールや技術を活用できる点も大きなメリットです。

Tip

【解説】t3.mediumを選択する理由

t3.mediumは2つのvCPUと4GiBメモリを提供するバーストパフォーマンス型インスタンスで、料金と性能のバランスが優れています。料金面では時間料金$0.0416（月額約$30.37）と手頃で、t2.mediumより約10%安くAWS無料利用枠を超えても予算に優しい選択肢です。一方で、t2.microの1GiBメモリでは、Node.jsアプリケーションが動作中にメモリ不足でクラッシュするリスクがあります。

Node.jsアプリケーションの要件として、Next.js ECサイトは複数のコンポーネント（フロントエンド、APIルート、TypeScript、shadcn/ui）を同時に実行するため、最低4GiBメモリが推奨されます。特にビルド処理やパッケージインストール時には一時的に多くのメモリを消費します。t3.mediumのバーストパフォーマンス機能により、CPU集約的なタスク実行時に一時的に高いパフォーマンスを発揮でき、通常時は基準パフォーマンスで動作してコストを抑制します。

開発環境やテスト環境としても、ブラウザからのアクセステスト、複数ユーザーでの動作確認、パフォーマンステストに十分な性能を提供します。将来的にトラフィックが増加した場合もは、m7シリーズやr7シリーズへの移行を考えていきましょう。

1-7. ネットワーク設定

「ネットワーク設定の編集」を押します。
VPC：ステップ1で作成した「ec-site-vpc」を選択します。
サブネット：「ec-site-public-us-east-1a」を選択します。
パブリックIPの自動割り当て：「有効化」を選択します。
ファイアウォール(セキュリティグループ)：
- 「セキュリティグループを作成」を選択します。
- セキュリティグループ名：「ec-site-web-sg」と入力します。
- 説明：「for ec-site web instance」と入力します。
  - インバウンドセキュリティグループのルール：
    - 「セキュリティグループルール 1 (TCP, 22, 0.0.0.0/0)」の「削除」ボタンをクリックします。
    - 「セキュリティグループルールを追加」ボタンをクリックし、以下のルールを設定します。
      - タイプ：「HTTP」を選択します。
      - ソースタイプ：「任意の場所」を選択します。（インターネットからのHTTPアクセスを許可）
      - （注：SSH ポートは開放しません。Systems Manager セッションマネージャーを使用するため）

EC2 network

Tip

【解説】なぜSSHではなくセッションマネージャーを使うのか

セッションマネージャーを選択する最大の理由はセキュリティの大幅な向上です。従来のSSH接続では22番ポートを開放する必要があり、これがサイバー攻撃の主要な標的となります。インターネット上では常にSSHポートへのブルートフォース攻撃（総当たり攻撃）が行われており、脆弱なパスワードや設定不備があると不正侵入のリスクが高まります。

セッションマネージャーは「ポートを開放しない安全な接続」を実現します。接続はAWS内部のネットワークを経由し、IAM（Identity and Access Management）による認証・認可でアクセス制御を行います。これにより、SSH鍵の管理や紛失リスク、踏み台サーバーの運用コストが不要になります。さらに、すべてのセッションが自動的にログとして記録され、後から「誰がいつ何を実行したか」を追跡できるため、監査やトラブルシューティングに役立ちます。

運用面でも大きなメリットがあります。ブラウザベースでアクセスできるため、特別なSSHクライアントソフトウェアが不要で、WindowsやmacOSなどのOS環境に依存しません。VPN接続も不要で、どこからでも安全にサーバーにアクセスできます。初学者にとってはSSH鍵の生成・管理という複雑な手順を省略でき、学習の障壁を下げながら高いセキュリティを確保できる理想的なソリューションです。

1-8. ストレージを設定

「8」GiBのままにします。
「gp3」（汎用SSD）を選択します。

Tip

【解説】なぜgp3を使うのか - 他の選択肢との比較と判断軸

gp3（General Purpose SSD v3）を選択する理由は、コストパフォーマンスと柔軟性の最適なバランスにあります。gp3はgp2より20%安い料金（$0.08/GiB-月 vs $0.10/GiB-月）でありながら、性能をストレージ容量から独立して設定できる革新的な仕組みを提供します。ベースライン3,000 IOPS、125 MiB/sのスループットが標準で含まれ、最大16,000 IOPS、1,000 MiB/sまで拡張可能です。

他の選択肢との比較： gp2は容量に比例して性能が決まるため、高性能が必要な場合は大容量（5.33 TiB以上）が必要でコスト効率が悪くなります。io1/io2は最高性能を提供しますが、IOPS課金により非常に高価（$0.065/IOPS-月）で、ミッションクリティカルなデータベース用途向けです。HDD系（st1、sc1）は大容量・低コストですが、低いIOPSでWebアプリケーションには不適切です。

判断軸： ①パフォーマンス要件（Node.jsアプリケーションの起動、ファイル読み書き速度）、②コスト効率（開発・学習用途では予算制約が重要）、③将来の拡張性（トラフィック増加時のスケーラビリティ）、④運用の簡単さ（複雑な性能調整の必要性）を考慮します。gp3は全ての軸でバランスが取れており、特に学習用途や中小規模のWebアプリケーションには最適な選択です。必要に応じて後からIO性能を調整できる柔軟性も大きな利点です。

1-9. 高度な詳細

「高度な詳細」をクリックして、セクションを展開します。
「IAM インスタンスプロフィール」の「新しいIAM プロファイルの作成」をクリックすると、新しいタブでIAMコンソールが開きます。
「ロールを作成」ボタンをクリックします。
- 信頼されたエンティティタイプ：「AWSのサービス」を選択します。
- ユースケース：「EC2」を選択します。
- 「次へ」ボタンをクリックします。
検索ボックスに以下のポリシーを検索、表示されたポリシーにチェックを入れ、「次へ」ボタンをクリックします。
- AmazonS3ReadOnlyAccess
- AmazonSSMManagedInstanceCore
- SecretsManagerReadWrite
ロール名：「ec-site-web-SSMRole」と入力します。
「ステップ1: 信頼されたエンティティを選択する」と「ステップ2: 許可を追加する」の項目が正しいか確認します。

ステップ1: 信頼されたエンティティを選択する：


{
"Version": "2012-10-17",
"Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Principal": {
                "Service": [
                    "ec2.amazonaws.com"
                ]
            }
        }
    ]
}

ステップ2: 許可を追加する：
- AmazonSSMManagedInstanceCore
- AmazonS3ReadOnlyAccess
- SecretsManagerReadWrite

「ロールを作成」ボタンをクリックします。
「ロール ec-site-web-SSMRole が作成されました。」と表示されることを確認します。
EC2インスタンス起動画面に戻ります。
IAMインスタンスプロファイルのドロップダウンを更新し、作成した「ec-site-web-SSMRole」を選択します。

Tip

【解説】高度な設定でできる設定内容

EC2インスタンスの「高度な詳細」セクションでは、セキュリティ、運用管理、パフォーマンス最適化に関する重要な設定が可能です。今回設定したIAMインスタンスプロファイルは、EC2インスタンスが他のAWSサービス（S3、Systems Manager、Secrets Manager）にアクセスする際の権限を定義します。これにより、アプリケーションがAWSリソースを安全に利用できるようになります。

その他の主要設定項目： ①ユーザーデータ（起動時スクリプト）では、インスタンス起動時に自動実行するコマンドを記述でき、ソフトウェアインストールや設定変更を自動化できます。②メタデータ設定では、インスタンスメタデータサービス（IMDSv2）の有効化によりセキュリティを強化できます。③テナンシー設定では、専用ハードウェアでの実行（Dedicated Instance/Host）を選択でき、規制要件やライセンス要件に対応できます。

モニタリングと詳細設定： CloudWatch詳細モニタリング（1分間隔）の有効化、配置グループの設定（高帯域幅ネットワークや低レイテンシ要件）、Elastic Inference（機械学習推論の高速化）、T2/T3 Unlimited（CPUクレジット制限の解除）なども設定可能です。これらの設定により、用途に応じた最適なインスタンス構成を実現でき、セキュリティ、パフォーマンス、運用効率を向上させることができます。

TODO: TIP - AmazonSSMManagedInstanceCore - AmazonS3ReadOnlyAcces - SecretsManagerReadWriteそれぞれの役割を解説する

1-10. 概要

画面右側の「概要」を確認します。
- インスタンス数：「1」であることを確認します。
画面右側の「インスタンスを起動」ボタンをクリックします。
「インスタンスの起動を正常に開始しました」と表示されることを確認します。
「すべてのインスタンスを表示」ボタンをクリックします。

2. EC2インスタンスへのセッションマネージャー接続

Note

AWSでの役割

Systems Managerは、AWSリソースの運用管理を自動化するサービス群です。その中のSession Managerは、SSHポートを開放せずにEC2インスタンスに安全にアクセスできる機能です。

特徴:

SSHキーやVPN接続が不要
ブラウザベースでのターミナルアクセス
セッションログの自動記録
IAMポリシーによる細かなアクセス制御

さくらクラウドでの対応

さくらクラウドでは標準的なSSH接続を使用します。

コンソール画面からの直接アクセス
SSH鍵認証またはパスワード認証
VPN接続経由でのアクセス（セキュリティ強化時）

オンプレミスでの対応

オンプレミス環境では従来のリモートアクセス手法を使用します。

SSH/RDP: 直接またはVPN経由
IPMI/iLO: 物理サーバーの帯域外管理
運用管理ツール: Ansible、Puppet、Chefなど
踏み台サーバー: セキュリティ強化のための中継サーバー

2-1. インスタンスの状態確認

EC2ダッシュボードの「インスタンス」画面で、作成したインスタンス「ec-site-web」の状態が「実行中」になるまで待ちます。
インスタンスを選択し、「接続」ボタンをクリックします。

2-2. セッションマネージャーでの接続

「接続方法」画面で「セッションマネージャー」タブを選択します。
「接続」ボタンをクリックします。
新しいブラウザタブが開き、EC2インスタンスのターミナルセッションが表示されます。
AWSコンソールから接続したあとはroot権限で作業することが多いので特権管理者になりましょう。


sudo su
cd ~

root@ip-xx-xx-xx-xxxのように@の左がrootと表示されていればOKです。
（注意：特権管理者モードではOSにまつわる各種ファイルの変更削除もできるようになっています。業務で利用する場合は知らないコマンドは実行しないようにしましょう。）

3. システムの更新

EC2インスタンスに接続した状態で、以下のコマンドを実行してシステムを最新の状態に更新します：


dnf update -y

「Complete!」と表示されれば完了です。

Tip

【解説】なぜインスタンス起動直後に最新状態にするのか

インスタンス起動直後のシステム更新は、セキュリティとシステムの安定性確保において極めて重要です。AMI（Amazon Machine Image）は作成時点のソフトウェア状態をスナップショットとして保存するため、時間が経過するにつれて新しく発見された脆弱性やバグ修正パッチが含まれていない状態になります。この状態でインターネットに公開すると、既知の脆弱性を狙った攻撃の標的となりやすくなります。

更新しないことによるリスク： ①セキュリティ脆弱性の存在により、システムへの不正侵入やデータ漏洩のリスクが高まります。②古いライブラリやミドルウェアによる互換性問題で、最新のNode.jsパッケージが正常にインストールできない場合があります。③システムバグによる予期しないクラッシュや不安定動作が発生する可能性があります。④コンプライアンス要件を満たせず、規制違反のリスクも生じます。

メリットと推奨手順： dnf update -yコマンドにより、カーネル、SSL/TLS、基本ライブラリなどの重要コンポーネントが最新化されます。これにより、パフォーマンス向上、新機能の利用、安定性向上が実現できます。更新後の再起動によりカーネル更新が反映され、システム全体が最新の安全な状態で稼働します。本番環境では定期的なパッチ適用スケジュールを設定し、開発環境では起動時の自動更新を検討することで、常に安全で安定したシステムを維持できます。

4. Next.jsのECサイトのデプロイ

Tip

【解説】今回動かすサンプルECサイトの内容

今回デプロイするサンプルコードは、本格的なECサイト機能を備えたNext.js 15アプリケーションです。最新のモダンWebフレームワークとコンポーネントライブラリを組み合わせた、実践的な学習教材として設計されています。フロントエンドにはTailwind CSSとshadcn/uiコンポーネント、TypeScriptを採用し、プロフェッショナルな開発環境を体験できます。

主要機能： ①商品カタログページ（製品一覧・詳細表示）、②ショッピングカート機能（商品追加・削除・数量変更）、③チェックアウト機能（注文確定・配送情報入力）、④注文確認ページ（購入完了画面）、⑤レスポンシブ対応（モバイル・デスクトップ両対応）を完備しています。サンプル商品として、プログラミング書籍、ノートパソコン、エルゴノミクスチェア、コーヒー豆、スマートウォッチ、ヘッドホンなど、実際のECサイトで扱われるような多様な商品データを用意しています。

技術構成と学習価値： React Hookを活用した状態管理、Context APIによるカート機能、フォームバリデーション（React Hook Form + Zod）、モダンなUIコンポーネント（Radix UI）、アイコンライブラリ（Lucide React）など、現代的なWebアプリケーション開発のベストプラクティスを学習できます。この一連の手順により、AWSインフラとモダンWebアプリケーションの統合開発を実践的に習得し、実際のビジネスに応用可能なスキルを身につけることができます。

4-1. 必要なソフトウェアのインストール

Node.jsとnpmをインストールします：


dnf install nodejs npm -y

Gitをインストールします：


dnf install git -y

pnpmをインストールし、有効化します：


curl -fsSL https://get.pnpm.io/install.sh | sh -
source /root/.bashrc

PM2（Node.jsアプリケーションのプロセスマネージャー）をインストールします：


pnpm -g install -g pm2

インストールしたソフトウェアが動くか確認しましょう：

それぞれ以下のように表示されるはずです。バージョン番号が違っていても問題ありません。何らかのバージョン番号が帰ってくればOKです。


[root@ip-10-0-7-123 ~]# node -v
v18.20.8
[root@ip-10-0-7-123 ~]# git -v
git version 2.47.1
[root@ip-10-0-7-123 ~]# aws --version
aws-cli/2.23.11 Python/3.9.22 Linux/6.1.134-152.225.amzn2023.x86_64 source/x86_64.amzn.2023
[root@ip-10-0-7-123 ~]# pnpm -v
10.11.0
[root@ip-10-0-7-123 ecommerce-app-v0]# pm2 -v
~中略~
[PM2] PM2 Successfully daemonized
6.0.6

TODO: TIP dnfコマンドの説明

4-2. ECサイトのソースコードの取得

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


cd ~

準備されているNext.jsのECサイトのソースコードをコピーし解凍します：


aws s3 cp s3://tenarai-blueprint-sample-code-983911888049-us-east-1/ec-site-tenarai-sample/ecommerce-app-v0.zip ~/ecommerce-app-v0.zip
unzip ecommerce-app-v0.zip

解凍したファイルを確認します：

ll

以下のように所有者（3列目）がroot、ecommerce-app-v0が表示されていればOKです。


[root@ip-xx-xx-xx-xxx ~]# ll
total 4836
drwxr-xr-x. 3 root root      56 Jun  1 06:20 __MACOSX
drwx------. 8 root root   16384 Jun  1 05:45 ecommerce-app-v0
-rw-r--r--. 1 root root 4934796 Jun  1 05:45 ecommerce-app-v0.zip

4-3. 依存パッケージのインストールとビルド

プロジェクトディレクトリに移動します：


cd ecommerce-app-v0

必要なパッケージをインストールしビルドします：


pnpm install
pnpm build

以下のような出力があればOKです。


~~
Done in 11.6s using pnpm v10.14.0
~~
 ✓ Generating static pages (8/8)
 ✓ Collecting build traces
 ✓ Finalizing page optimization
~~

4-4. アプリケーションの起動

PM2を使ってNext.jsアプリケーションを起動します：


pm2 start

PM2のプロセスが動いているか確認します：


pm2 status

以下のようにstatus:onlineになっていればOKです。


[root@ip-10-2-1-174 ecommerce-app-v0]# pm2 status
┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
│ id │ name               │ mode     │ ↺    │ status    │ cpu      │ memory   │
├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
│ 0  │ ecommerce-app-v0   │ fork     │ 0    │ online    │ 0%       │ 72.4mb   │
└────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

pnpmのプロセスが動いているか確認します：


ps -aux | grep pnpm

以下のように表示されていればOKです。


[root@ip-10-2-1-174 ecommerce-app-v0]# ps -aux | grep pnpm
root       28222  0.3  1.7 1080544 68496 ?       Ssl  13:39   0:00 /root/.local/share/pnpm/pnpm start
root       28328  0.0  0.0 222316  2120 pts/1    S+   13:41   0:00 grep --color=auto pnpm

PM2の起動設定を保存します：


pm2 save
pm2 startup

systemctlを使ってシステム再起動時に自動的に起動するようにします：


systemctl enable pm2-root

以下のように表示されていればOKです。


[root@ip-10-2-1-174 ~]# systemctl enable pm2-root
Created symlink /etc/systemd/system/multi-user.target.wants/pm2-root.service → /etc/systemd/system/pm2-root.service.

ログを確認します：


[root@ip-10-2-1-174 ~]# journalctl -u pm2-root
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal systemd[1]: Starting pm2-root.service - PM2 process manager...
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: [PM2] Resurrecting
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: [PM2] Restoring processes located in /root/.pm2/dump.pm2
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: ┌────┬─────────────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬───>
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: │ id │ name                │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ me>
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: ├────┼─────────────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼───>
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: │ 0  │ ecommerce-app-v0    │ default     │ N/A     │ fork    │ 28222    │ 10m    │ 0    │ online    │ 0%       │ 66>
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal pm2[28867]: └────┴─────────────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴───>
Aug 09 13:49:37 ip-10-2-1-174.ec2.internal systemd[1]: Started pm2-root.service - PM2 process manager.

pm2コマンドでもログを確認します：


[root@ip-10-2-1-174 ~]# pm2 log
[TAILING] Tailing last 15 lines for [all] processes (change the value with --lines option)
/root/.pm2/pm2.log last 15 lines:
PM2        | 2025-08-09T13:35:39: PM2 log: Node.js version      : 18.20.8
PM2        | 2025-08-09T13:35:39: PM2 log: Current arch         : x64
PM2        | 2025-08-09T13:35:39: PM2 log: PM2 home             : /root/.pm2
PM2        | 2025-08-09T13:35:39: PM2 log: PM2 PID file         : /root/.pm2/pm2.pid
PM2        | 2025-08-09T13:35:39: PM2 log: RPC socket file      : /root/.pm2/rpc.sock
PM2        | 2025-08-09T13:35:39: PM2 log: BUS socket file      : /root/.pm2/pub.sock
PM2        | 2025-08-09T13:35:39: PM2 log: Application log path : /root/.pm2/logs
PM2        | 2025-08-09T13:35:39: PM2 log: Worker Interval      : 30000
PM2        | 2025-08-09T13:35:39: PM2 log: Process dump file    : /root/.pm2/dump.pm2
PM2        | 2025-08-09T13:35:39: PM2 log: Concurrent actions   : 2
PM2        | 2025-08-09T13:35:39: PM2 log: SIGTERM timeout      : 1600
PM2        | 2025-08-09T13:35:39: PM2 log: Runtime Binary       : /usr/bin/node-18
PM2        | 2025-08-09T13:35:39: PM2 log: ===============================================================================
PM2        | 2025-08-09T13:39:30: PM2 log: App [ecommerce-app-v0:0] starting in -fork mode-
PM2        | 2025-08-09T13:39:30: PM2 log: App [ecommerce-app-v0:0] online
 
/root/.pm2/logs/ecommerce-app-v0-error.log last 15 lines:
/root/.pm2/logs/ecommerce-app-v0-out.log last 15 lines:
0|ecommerc |
0|ecommerc | > my-v0-project@0.1.0 start /root/ecommerce-app-v0
0|ecommerc | > next start -H 0.0.0.0 -p 80
0|ecommerc |
0|ecommerc |    ▲ Next.js 15.2.4
0|ecommerc |    - Local:        http://localhost:80
0|ecommerc |    - Network:      http://0.0.0.0:80
0|ecommerc |
0|ecommerc |  ✓ Starting...
0|ecommerc |  ✓ Ready in 464ms
 
<!-- ctrl+cでログを終了します。 -->

5. Webサイトへのアクセス確認

EC2インスタンスの詳細画面で「パブリックIPv4アドレス」をメモします。
ブラウザを開き、メモしたIPアドレスにアクセスします。（例：http://xx.xx.xx.xx）

Important

注意： http です。httpsではありません。

Note

注釈：Next.jsがデフォルトで動くPortは3000ですが、今回はport:80(HTTP)で動くように設定を変えています。（気になる方は、package.jsonの中身を見てみてください。）

以下のようなECサイトが表示されれば成功です！

ecommerce-app-v0-sample-image

6. おまけ

EC2を再起動してもWebサービスが起動するか確認してみよう。
このコンテンツは単語をクリックすると詳細な解説ページを見たり、右上から検索することができます。利用したコマンドやサービス名をクリックして調べてみましょう！

このステップで何をしたのか

このステップでは、EC2インスタンスを作成し、その上にNext.jsアプリケーションをインストールしました。セキュリティグループを設定して、必要な通信（HTTP）のみを許可し、インターネットからアクセス可能なECサイトの基本形を構築しました。また、Systems Manager セッションマネージャーを使用して安全にサーバーに接続できるようにIAMロールを設定し、PM2を使ってアプリケーションの安定稼働を確保しました。

ECサイトでどのような影響があるのか

このステップにより、ECサイトの「店舗」が完成し、インターネット上でユーザーがアクセスできるようになりました。ユーザーは商品を閲覧できるようになりましたが、まだ注文情報を保存する機能はありません。これは、お店の建物と商品棚は完成したが、レジや在庫管理システムがまだない状態に相当します。また、Systems Managerを使用することで、SSH ポートを開放せずに安全に管理できるようになり、セキュリティが向上しました。

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

EC2インスタンス「ECサイトWebサーバー」が正常に起動している
セキュリティグループ「ECサイトWebSG」が正しく設定されている（HTTPのみ許可）
IAMロール「EC2SSMRole」が正しく設定され、EC2インスタンスにアタッチされている
Systems Manager セッションマネージャーを使ってEC2インスタンスに接続できる
Next.jsのECサイトがデプロイされ、PM2のプロセスが動いている
ブラウザでパブリックIPアドレスにアクセスすると、ECサイトのトップページが表示される

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

ステップ1の構成図に、このステップで作成したリソースを追記して、現在のインフラ構成を完成させましょう。

なぜ構成図を更新するのか？

インフラを段階的に構築する際、構成図も都度更新していくことは非常に重要です。

変更点の明確化: 前のステップから何が追加・変更されたのかが一目でわかります。
関係性の理解: 新しいリソース（EC2）が既存のネットワーク（VPC, サブネット）とどのように連携するのかを視覚的に理解できます。
実践的なスキル: 実際の開発現場でも、設計変更のたびにドキュメントや図を更新するスキルは不可欠です。

構成図の書き方

ステップ1で作成した構成図をベースに、以下のリソースを追記してみましょう。

EC2インスタンス: パブリックサブネット（ec-site-public-us-east-1a）の中にEC2インスタンスを描きます。
セキュリティグループ: 作成したEC2インスタンスを囲むようにセキュリティグループ（ec-site-web-sg）を描き、HTTP (ポート80) の通信を許可していることを示します。
通信経路: インターネットから来た通信が、インターネットゲートウェイを経由してEC2インスタンスに到達する流れを矢印で示します。
IAMロール: EC2インスタンスにIAMロール（ec-site-web-SSMRole）がアタッチされていることを、注釈などで書き加えます。

💡 ヒント: EC2インスタンスがどのサブネットに配置されているか、セキュリティグループがどのように通信を制御しているかが、このステップの構成図の重要なポイントです。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず“理由”や“目的”があります。下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。仕組みや設計意図を自分で説明できることが、真の理解につながります。ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. 今回はなぜパブリックサブネットにEC2を配置したのでしょうか？パブリックサブネットに配置することでどのような危険性がありますか？

Q. なぜSSH通信ではなくSession Managerを用いているのでしょうか？セキュリティ的なポイントで解説してください。

Q. なぜEC2インスタンスを再起動した際に、アプリケーションが自動的に起動するようになっているのでしょうか？自動的に起動しない場合どのような問題が発生するでしょうか？

今回のステップで利用したAWSサービス名一覧

EC2 (Elastic Compute Cloud)：仮想サーバーを提供するサービス
セキュリティグループ：トラフィックの許可ルールを定義し、EC2やAuroraやALBなどのAWSリソースへの通信を制御する仮想ファイアウォール
Systems Manager：AWSリソースを安全に管理するためのサービス
Session Manager：SSH ポートを開放せずにEC2インスタンスに接続するためのツール
IAM (Identity and Access Management)：AWSリソースへのアクセス権限を管理するサービス
EBS (Elastic Block Store)：EC2インスタンス用のストレージボリュームを提供するサービス（インスタンス作成時に自動的に設定）
VPC (Virtual Private Cloud)：AWS上に構築する仮想ネットワーク
サブネット：VPCという大きな仮想ネットワークを目的に応じて分割した小さなネットワーク