Amazon EC2の基本から構築・運用まで！WordPressとNginxで学ぶ実践ガイド

Amazon EC2の全体像とWebサービス構築への最短ルート

EC2とは？クラウド仮想サーバーの基礎知識

Amazon EC2（Elastic Compute Cloud）は、クラウド上で仮想サーバーを柔軟に提供するサービスです。物理的なハードウェアの調達やメンテナンスから解放され、OSやアプリケーションの構築・運用に集中できる点が最大のメリットと言えます。これにより、開発者はインフラ基盤の複雑さを意識することなく、自身のWebサービスやアプリケーションのアイデアを迅速に具現化できます。現代のビジネスにおいて、迅速なサービス展開と柔軟なリソース変更は不可欠であり、EC2はその中心的な役割を担っています。実際に、世界のクラウドインフラ市場において、Amazonは約32%の最大シェアを誇っており（総務省 令和7年版 情報通信白書より）、その信頼性と実績は群を抜いています。

EC2を含むAWSのサービス運用では、「責任共有モデル」という重要な原則があります。これは、インフラ基盤自体（サーバー、ストレージ、ネットワーク、データセンター）のセキュリティはAWSが責任を持つ一方で、その上に構築されるOS、アプリケーション、データ、ネットワーク設定（セキュリティグループなど）のセキュリティはユーザー自身が責任を負うという考え方です。このモデルを理解し、ユーザー側で適切なセキュリティ対策を講じることが、安全なクラウド運用には不可欠となります。クラウド活用の能力は、現代のエンジニアにとって必須スキルとなっており、今後もその重要性は増していくでしょう。

なぜEC2でWebサービスを構築すべきなのか？メリットと選定基準

EC2でWebサービスを構築する最大のメリットは、その圧倒的な柔軟性とスケーラビリティにあります。従来のオンプレミス環境では、サーバーのリソース変更や増設には時間とコストがかかりましたが、EC2であれば数分でインスタンスタイプを変更したり、新しいインスタンスを追加したりすることが可能です。これにより、アクセス量の変動に柔軟に対応し、サービスの停止を最小限に抑えながら運用できます。日本国内の企業におけるクラウドサービス利用割合は68.7%に上っており（総務省 令和3年版 情報通信白書より）、多くの企業がその恩恵を受けていることがわかります。

また、EC2は従量課金制が基本であり、使用したリソースに対してのみ料金が発生します。これにより、初期投資を抑えつつ、必要な時に必要なだけリソースを利用できるため、コスト効率に優れた運用が実現できます。さらに、AWSが提供する広範なサービス群（データベース、ストレージ、CDNなど）と容易に連携できるため、堅牢で高機能なWebサービスを効率的に構築することが可能です。これらのメリットを最大限に活かすためには、自身のWebサービスの要件（想定アクセス量、データ量、予算、求める可用性など）を明確にし、適切なインスタンスタイプや構成を選択することが重要です。

EC2を始める前に知っておくべき料金体系とコスト最適化の基本

EC2の料金体系は従量課金制が基本ですが、複数の料金モデルを理解し、適切に組み合わせることで大幅なコスト最適化が可能です。主要な料金モデルとして、「オンデマンドインスタンス」、「Savings Plans」、「スポットインスタンス」があります。

• オンデマンドインスタンス: 長期契約なしで、秒単位（最低60秒）の従量課金です。突発的なアクセス増への対応や、開発・テスト環境など、一時的にリソースが必要な場合に適しています。
• Savings Plans: 1年または3年のコミットメント（一定のコンピューティング使用量をコミット）をすることで、オンデマンド料金から大幅な割引が適用されます。安定した稼働が見込まれる本番環境などに最適です。
• スポットインスタンス: 未使用のEC2容量を利用するモデルで、オンデマンド料金よりもはるかに安価ですが、AWSが容量を必要とする場合に停止される可能性があります。柔軟性が高く、中断されても問題ないワークロード（バッチ処理など）に適しています。

料金の過剰請求を防ぐためには、インスタンスを「停止（Stop）」しただけでは課金が止まらないリソースがあることを理解しておく必要があります。特にEBS（ストレージ）などの永続的なストレージは、インスタンスが停止状態でも料金が発生し続けます。不要になったインスタンスは必ず「終了（Terminate）」することで、計算能力だけでなくストレージなどの関連リソースの課金も停止させることができます。例えば、t3.medium / Linux / 東京リージョンで常時稼働させた場合のEC2利用料金は、約6,200円/月が目安となります（NTT東日本「AWSの料金体系を徹底解説！」2026年2月4日更新より）。常にAWS公式サイトの最新の料金情報を確認し、自社の予算に合わせた最適な料金モデルを選択しましょう。

出典：Amazon Web Services、総務省、NTT東日本

EC2インスタンス作成からWordPress/Nginx環境構築までの実践ステップ

EC2インスタンス起動の基本と初期設定

WordPressとNginxでWebサイトを構築するための第一歩は、EC2インスタンスを起動することです。AWSマネジメントコンソールから「EC2」サービスを選択し、「インスタンスを起動」をクリックします。まず、OSのベースとなる「Amazon マシンイメージ（AMI）」を選択します。ここでは、WordPressとNginxの動作実績が豊富なAmazon Linux 2やUbuntu Serverの最新版がおすすめです。次に、CPUやメモリなどのリソースを決定する「インスタンスタイプ」を選びます。小規模なWebサイトであれば、無料利用枠の対象でもある「t2.micro」や、バランスの取れた性能を持つ「t3.medium」などが選択肢となります。インスタンスタイプは後から変更することも可能です。

インスタンスの設定では、必ず「キーペア」を作成または既存のものを選択してください。これは、SSH接続でインスタンスに安全にアクセスするために必要不可欠な秘密鍵です。作成したキーペアの秘密鍵ファイル（.pem）は大切に保管しましょう。ネットワーク設定では、インスタンスを配置する「VPC（仮想ネットワーク）」と「サブネット」を指定します。そして最も重要なのが「セキュリティグループ」の設定です。これはインスタンスへの仮想ファイアウォールとして機能します。WordPressサイトでは、ウェブアクセス用のHTTP（80番ポート）、HTTPS（443番ポート）、そしてSSH接続用の22番ポートを、それぞれ必要なIPアドレス範囲に限定して許可する必要があります。初期設定では、ご自身のIPアドレスからのみSSH接続を許可し、HTTP/HTTPSは全世界からのアクセスを許可するのが一般的です。これらの設定が完了したら、インスタンスを起動し、公開IPv4アドレスまたはDNS名を確認してSSH接続の準備を進めます。

NginxとPHP-FPMのインストールと設定

EC2インスタンスが起動し、SSHで接続できるようになったら、WordPressを動かすためのWebサーバーとアプリケーションサーバーをインストールします。ここでは、高速なWebサーバーであるNginxと、PHPアプリケーションを実行するためのPHP-FPM（FastCGI Process Manager）を導入します。Amazon Linux 2を使用している場合、まずはシステムを最新の状態にアップデートすることから始めましょう。

sudo yum update -y

次に、NginxとPHP-FPM、そしてWordPressがデータベースと連携するために必要なPHPの拡張モジュールをインストールします。PHP-FPMのバージョンは、WordPressの推奨要件に合わせて選択することが重要です。例えば、PHP 7.4や8.x系をインストールします。

sudo amazon-linux-extras install nginx1
sudo yum install -y php-fpm php-mysqlnd php-gd php-mbstring php-xml php-opcache

インストール後、NginxとPHP-FPMが自動起動するように設定し、サービスを開始します。

sudo systemctl enable nginx
sudo systemctl start nginx
sudo systemctl enable php-fpm
sudo systemctl start php-fpm

次に、Nginxの設定ファイルを編集し、WordPressへのリバースプロキシとして機能させます。Nginxの設定ファイルは通常/etc/nginx/nginx.confや/etc/nginx/conf.d/default.confにあります。ここで、WordPressの公開ディレクトリを指定し、PHPファイルをPHP-FPMに渡すための設定を記述します。特に、location ~ \.php$ブロック内でPHP-FPMへのプロキシ設定（fastcgi_pass unix:/run/php-fpm/www.sock;など）を適切に行うことが重要です。設定変更後はNginxサービスをリロードして反映させます。

sudo systemctl reload nginx

これにより、NginxがWebリクエストを受け付け、PHPの処理をPHP-FPMに渡す環境が整います。

WordPressの導入とデータベース連携

NginxとPHP-FPMの環境が整ったら、いよいよWordPress本体を導入します。まず、WordPressを配置するWebサーバーの公開ディレクトリ（通常は/usr/share/nginx/htmlや/var/www/htmlなど）に移動し、WordPressの最新版をダウンロードします。

cd /usr/share/nginx/html
sudo wget https://ja.wordpress.org/latest-ja.tar.gz
sudo tar -xzf latest-ja.tar.gz
sudo mv wordpress/* .
sudo rm -rf wordpress latest-ja.tar.gz

次に、ファイルとディレクトリの所有者をNginxが動作するユーザー（通常はnginx）に変更し、適切なパーミッションを設定します。これにより、WordPressがファイルを書き込んだり更新したりできるようになります。パーミッション設定はセキュリティ上非常に重要であり、安易に777のような広すぎる権限を与えないよう注意が必要です。

sudo chown -R nginx:nginx /usr/share/nginx/html
sudo chmod -R 755 /usr/share/nginx/html

WordPressを動かすためにはデータベースが必要です。AWS環境では、専用のマネージド型データベースサービスであるRDS（Relational Database Service）を利用するのが一般的で、高可用性とメンテナンスの手間を削減できます。今回はWordPressの稼働に最低限必要な手順として、既存のデータベースユーザー名、パスワード、ホスト名、データベース名を準備します。RDSインスタンスを作成する際は、セキュリティグループでEC2インスタンスからのアクセスを許可するように設定することを忘れないでください。もしテスト用途などでEC2インスタンス上に直接MySQL/MariaDBをインストールする場合は、その設定も別途必要です。

データベースの準備ができたら、WordPressのwp-config-sample.phpをwp-config.phpにコピーし、データベース接続情報を編集します。DB_NAME、DB_USER、DB_PASSWORD、DB_HOSTに適切な値を記述します。また、セキュリティ強化のために「認証ユニークキーとソルト」も設定しましょう。これらの設定が完了したら、WebブラウザでEC2インスタンスの公開IPアドレスまたはDNS名にアクセスし、WordPressの初期設定ウィザードを進めることで、Webサイトが完成します。ここで設定するサイトタイトル、管理者ユーザー名、パスワードなどは、今後の運用で必要になるため忘れずに控えておきましょう。

出典：Amazon Web Services

WordPress/Nginx構成とログ管理、ロードバランサーの活用例

NginxリバースプロキシとWordPressの最適構成

NginxをリバースプロキシとしてWordPressと連携させる構成は、パフォーマンスとセキュリティの両面で多くのメリットをもたらします。この構成では、Nginxがユーザーからのすべてのリクエストを受け付け、静的なファイル（画像、CSS、JavaScriptなど）はNginx自身が高速に直接配信します。一方、PHPスクリプトを必要とする動的なリクエストは、NginxがバックエンドのPHP-FPMに転送し、その結果をユーザーに返します。この役割分担により、WordPress本体がPHP処理に専念できるようになり、全体的なサイトの応答速度が向上します。

パフォーマンスをさらに最適化するためには、Nginxの設定ファイルでキャッシュ戦略を積極的に活用することが重要です。NginxのFastCGIキャッシュやブラウザキャッシュの設定を適切に行うことで、繰り返しリクエストされるコンテンツの再生成を避け、サーバーの負荷を軽減できます。また、Webサイトのセキュリティ強化と信頼性向上のためには、常時SSL化が必須です。Nginxの設定でSSL証明書（ACMやLet’s Encryptなど）を導入し、すべてのHTTPリクエストをHTTPSにリダイレクトすることで、通信の暗号化を実現します。これにより、ユーザーのブラウザに鍵マークが表示され、安全なサイトであることを示すことができます。これらの最適化により、WordPressサイトはより高速で安全な運用が可能になります。

アクセスログ・エラーログの監視と分析のポイント

Webサイトの安定運用には、アクセスログとエラーログの適切な管理と監視が不可欠です。これらのログは、サイトへのトラフィック状況、ユーザー行動、そして発生している問題やセキュリティインシデントに関する貴重な情報源となります。Nginxのアクセスログは通常/var/log/nginx/access.logに、エラーログは/var/log/nginx/error.logに保存されます。WordPressのエラーはPHPのエラーログとして、PHP-FPMの設定によりますが、/var/log/php-fpm/www-error.logなどに記録されることが多いです。これらのログファイルを定期的に確認し、異常がないかをチェックすることが、トラブルシューティングやサイト改善の第一歩となります。

しかし、ログファイルを手動で監視するには限界があります。より効率的なログ管理のためには、AWSが提供するCloudWatch Logsなどのサービスと連携することが推奨されます。EC2インスタンスにCloudWatch Agentを導入することで、NginxやPHP-FPMのログを自動的にCloudWatch Logsに集約し、一元的に管理・監視できるようになります。CloudWatch Logsでは、特定のキーワード（例: “error”, “404”）を検知した場合にアラートを発生させたり、ログデータを分析してグラフ化したりする機能も利用できます。これにより、問題の早期発見、セキュリティ監査、そしてユーザーエクスペリエンスの改善に向けた貴重な洞察を得ることが可能になります。ログの保持期間やコストも考慮し、要件に合わせた設定を行いましょう。

ロードバランサー（ALB）を活用した高可用性Webサイトの構築

Webサイトのアクセスが増加し、単一のEC2インスタンスでは処理しきれなくなった場合や、高い可用性が求められる場合には、ロードバランサー（ALB: Application Load Balancer）の導入が有効な戦略となります。ALBは、複数のEC2インスタンスにトラフィックを効率的に分散させることで、サーバーへの負荷を均等にし、パフォーマンスを向上させます。これにより、たとえ一部のインスタンスに障害が発生しても、他の正常なインスタンスがリクエストを処理し続けるため、サービス停止のリスクを大幅に軽減できます。

ALBは、バックエンドのEC2インスタンスのヘルスチェックを常時行い、異常を検知したインスタンスにはトラフィックを送らないように自動で切り替えます。さらに、ALBはAuto Scaling Groupと連携することで、Webサイトのアクセス量に応じてEC2インスタンスを自動的に増減させることが可能になります。例えば、CPU使用率が一定のしきい値を超えた場合にインスタンスを自動的に追加し、負荷が下がれば自動的に削除するといった設定が可能です。これにより、急激なアクセス増にも柔軟に対応できるだけでなく、リソースの無駄をなくし、コスト最適化にも貢献します。ALBを導入する際は、インスタンスを異なるアベイラビリティーゾーンに配置し、真に冗長性のある構成を目指しましょう。

出典：Amazon Web Services

EC2運用で避けるべきセキュリティとコストの落とし穴

セキュリティグループとIAMロールで守る最小権限の原則

EC2運用におけるセキュリティの第一歩は、セキュリティグループを適切に設定し、「最小権限の原則」を徹底することです。セキュリティグループは仮想的なファイアウォールであり、EC2インスタンスへのインバウンド（受信）およびアウトバウンド（送信）トラフィックを制御します。WordPressサイトを運用する場合、SSH（22番ポート）、HTTP（80番ポート）、HTTPS（443番ポート）以外のポートは、原則として閉じておくべきです。特にSSHポートは、特定の信頼できるIPアドレス範囲からのみアクセスを許可するように設定することで、不正なアクセス試行のリスクを大幅に低減できます。

また、AWSの各種サービスにEC2インスタンスからアクセスさせる必要がある場合（例: S3バケットへのファイルアップロード、CloudWatch Logsへのログ送信など）には、アクセスキーとシークレットキーをインスタンス内に直接保存するのではなく、IAMロールを利用することが強く推奨されます。IAMロールを使用することで、インスタンスに一時的な認証情報を安全に付与でき、アクセスキーの漏洩リスクをなくすことができます。責任共有モデルに基づき、OS、アプリケーション、データのセキュリティはユーザー側の責任です。不必要なポートを開放しない、サービスアカウントには最小限の権限のみを付与するなど、常にセキュリティ意識を持って設定を行いましょう。

パッチ管理と定期的な脆弱性対策の実践

EC2インスタンスを運用する上で、パッチ管理と定期的な脆弱性対策は避けて通れない重要な作業です。AWSがインフラ基盤のセキュリティを管理する一方で、EC2インスタンス内部のOS、WordPress本体、Nginx、PHPなどのミドルウェアやアプリケーションのセキュリティパッチ適用は、すべてユーザー側の責任となります。これらのソフトウェアには日々新たな脆弱性が発見されており、パッチを適用せずに放置すると、不正アクセスや情報漏洩のリスクに直面する可能性があります。

定期的にOSのパッケージをアップデートするコマンド（例: sudo yum update -yやsudo apt update && sudo apt upgrade -y）を実行し、最新の状態を保つようにしましょう。WordPressや各種プラグイン、テーマについても、管理画面から提供されるアップデート情報を常にチェックし、速やかに適用することが重要です。自動アップデート機能を活用することも一案ですが、互換性の問題でサイトが停止するリスクも考慮し、本番環境への適用前には必ずステージング環境でのテストを行うなどの慎重な運用が求められます。信頼できる情報源（AWS公式ブログ、セキュリティニュースサイトなど）から脆弱性情報を収集し、常に最新のセキュリティ対策を講じる習慣をつけましょう。

予期せぬ課金を防ぐコスト管理と監視のテクニック

EC2の従量課金制は柔軟な反面、誤った運用をしてしまうと予期せぬ高額な請求につながるリスクがあります。特に注意すべきは、インスタンスの「停止（Stop）」と「終了（Terminate）」の違いを正しく理解し、使い分けることです。「停止」はインスタンスの電源を落とすような状態であり、計算能力に対する料金は止まりますが、アタッチされているEBS（ストレージ）や関連するIPアドレスなど、一部のリソースに対する料金は発生し続けます。一方、「終了」はインスタンス自体を完全に削除するため、ほとんどのリソースに対する課金が停止します。不要になったインスタンスは必ず「終了」させる習慣をつけましょう。

また、アタッチされたEBSボリュームやスナップショット、ロードバランサー、Elastic IPアドレスなども、インスタンスが停止または終了した後も課金が継続する可能性があります。定期的にAWSマネジメントコンソールでこれらのリソースを確認し、不要なものは削除することがコスト削減につながります。さらに、AWSの「AWS Budgets」機能を利用して、予算を設定し、月間の利用料金が設定したしきい値を超過しそうになった際にアラートを受け取るようにすることも有効です。「CloudWatch」でEC2インスタンスのCPU使用率やネットワークI/Oなどを監視し、異常な高負荷が継続している場合は、無駄なリソース消費がないか、インスタンスタイプが適切かなどを確認するようにしましょう。これらの対策を講じることで、EC2運用におけるコストの落とし穴を効果的に回避できます。

出典：Amazon Web Services

【ケース】Webサイトのアクセス急増とインフラ改善戦略

アクセス急増時に発生しうる問題とその兆候

架空のケースとして、あるスタートアップ企業が運営するWordPressベースのECサイトが、SNSでのキャンペーン成功により突然アクセスが急増したとします。この時、Webサイトのレスポンスが極端に遅くなり、最終的には「Service Unavailable」や「502 Bad Gateway」といったエラーが表示され、サイトが閲覧できなくなる事態が発生しました。これはアクセス急増時に単一のEC2インスタンス構成で発生しがちな典型的な問題です。

このような状況の兆候としては、まずEC2インスタンスのCPU使用率がほぼ100%に張り付くことや、メモリ使用率の急激な上昇が挙げられます。Nginxのエラーログには「upstream timed out」のようなPHP-FPMとの通信エラーが頻繁に記録され、PHP-FPMのプロセスが飽和していることが示唆されます。また、MySQLなどのデータベースに接続できないエラーや、スロークエリの増加も見られます。Webサーバーへの同時接続数が増えることで、Nginxのワーカープロセスが足りなくなり、新たなリクエストを受け付けられなくなることもあります。これらの兆候を見逃さず、早期に検知し対応することがサイトの安定稼働には不可欠です。

スケールアップ・スケールアウトによるインフラ拡張戦略

上記のアクセス急増によるサイト停止を受け、このスタートアップ企業はインフラ改善戦略として、まずスケールアップを検討しました。これは、既存のEC2インスタンスのタイプをより高性能なもの（例: t3.mediumからm5.largeなど）に変更し、CPUやメモリなどのリソースを増強する手法です。一時的にアクセスが急増した場合や、特定の処理能力が不足している場合に効果的です。インスタンスタイプ変更は比較的短時間で実施でき、ダウンタイムを最小限に抑えつつパフォーマンスを向上させることが可能です。

しかし、スケールアップには性能の限界があり、コストも比例して増加します。根本的な解決策として、この企業はスケールアウト戦略に移行しました。これは、複数のEC2インスタンスを並列に稼働させ、ロードバランサー（ALB）でトラフィックを分散させる手法です。さらに、Auto Scaling Groupを導入することで、CPU使用率などのメトリクスに基づいてEC2インスタンスを自動的に増減させるように設定しました。これにより、アクセス量の変動に自動で追従できるようになり、急激なアクセス増にも柔軟に対応できる冗長性の高いシステムを構築できました。データベースに関しても、単一のEC2上からマネージドサービスのRDS（Multi-AZ構成）に移行し、データベース層の可用性とスケーラビリティも向上させました。

安定稼働を実現するためのWordPress/Nginx最適化と監視

インフラのスケールアウト後も、安定稼働を維持するためにはWordPressとNginxの継続的な最適化と監視が重要です。この企業は、まずNginxのキャッシュ設定を強化しました。FastCGIキャッシュを導入し、動的に生成されるWordPressのページの一部をNginx側でキャッシュすることで、PHP-FPMとデータベースへのリクエスト数を大幅に削減しました。さらに、CDN（Content Delivery Network）を導入し、静的ファイル（画像、CSS、JS）をユーザーに地理的に近いエッジロケーションから配信することで、サイト全体の読み込み速度を向上させました。

WordPress本体の最適化としては、不要なプラグインの削除、データベースの定期的なクリーンアップ、画像圧縮プラグインの導入などを行いました。また、データベースのクエリを監視し、スロークエリがあればインデックスの最適化やクエリのリファクタリングを実施しました。これらの対策と並行して、CloudWatchを利用した継続的な監視体制を確立しました。EC2インスタンスのCPU使用率、メモリ使用率、ネットワークI/O、Nginxのエラーログなどをリアルタイムで監視し、異常を検知した場合は自動でSlackに通知するアラートを設定しました。これにより、問題発生時に迅速に対応できる体制が整い、急激なアクセス増にも耐えうる、より堅牢で安定したWebサイト運用を実現しました。