1. はじめに

インフラ完全未経験の状態から、UdemyでAWS講座をハンズオン形式で学習しました。

VPC、EC2、RDS、ELB、S3…名前は聞いたことがあっても、実際に触るまでは役割がよく分かっていませんでした。

今回は、ハンズオンで学んだこの5サービスについて、「どんなサービスか」「ハンズオンで行ったこと」を整理してまとめます。

2. 各サービスの特徴

2-1. VPC （Virtual Private Cloud）

・VPCとは
AWS上に仮想ネットワーク空間を作成できるサービスです。
パブリックサブネットとプライベートサブネットを使い分けることで、外部に公開する部分と非公開にする部分を分離した構成を作れます。

・ハンズオンで行ったこと

10.0.0.0/16の範囲でVPCを作成し、パブリック・プライベート両方のサブネットを構築しました。

① パブリックサブネットの構築

VPCを作成し、インターネットゲートウェイを作成してアタッチ
AZ(1a・1c)それぞれにパブリックサブネットを作成(10.0.1.0/24、10.0.2.0/24)
ルートテーブルを作成し、「0.0.0.0/0への通信はインターネットゲートウェイへ」というルートを追加して両サブネットに関連付け
パブリックサブネット上にEC2インスタンス(WEB1A)を作成し、Apache・PHPで簡易ブログアプリを表示

② プライベートサブネットの構築とDBサーバーの用意

AZ(1a・1c)それぞれにプライベートサブネットを作成(10.0.101.0/24、10.0.102.0/24)
インターネットゲートウェイへの経路を持たないルートテーブルを関連付け、プライベートサブネットとして扱う
プライベートサブネットにDB用のEC2インスタンスを作成。セキュリティグループの送信元を「特定のIPアドレス」ではなく「Web用セキュリティグループが付いたインスタンス」に指定する設定を体験
Web用インスタンスを踏み台にしてDB用インスタンスにSSH接続

③ NATゲートウェイでの外部通信

プライベートサブネットのDBインスタンスから直接パッケージ更新(DNF)を試みたところ、インターネットに出られず失敗
パブリックサブネットにNATゲートウェイを作成し、プライベートサブネットのルートテーブルに「0.0.0.0/0はNATゲートウェイへ」というルートを追加
再度DNFを実行し、インターネット経由の通信ができるようになったことを確認

④ MySQLのセットアップとアプリ連携

NATゲートウェイ経由でMySQLをインストールしました。

sudo dnf install mysql-community-server -y
sudo systemctl start mysqld
sudo systemctl enable mysqld

Webサーバー側からもMySQLクライアントをインストールし、DBサーバーへの接続を確認しました。

mysql -h <DBサーバーのプライベートIP> -u simple_blog_user -p

PHPのコードを修正し、簡易ブログアプリがDBからデータを取得して表示できることを確認しました。

サブネットが「パブリックかどうか」は名前ではなく、紐づくルートテーブルにインターネットゲートウェイへの経路があるかどうかで決まる、という仕組みを実際に手を動かして理解できました。また、プライベートサブネットのインスタンスも、NATゲートウェイを使えばインターネットへの一方向の通信ができるようになる、という点も体感できたのが大きな収穫でした。

2-2. EC2 （Elastic Compute Cloud）

・EC2とは
クラウド上で仮想サーバーを構築できるサービスです。
OSやスペックを自由に選んで起動でき、必要に応じて台数やスペックを柔軟に変更できます。

・ハンズオンで行ったこと

サンプル用のEC2インスタンスを1台作成し、接続・複製・IP固定までの一連の操作を試しました。

① インスタンス作成とSSH接続のトラブル

セキュリティグループにSSHの許可ルールがない状態でSSH接続を試みると失敗することを確認しました。ルールを追加して再接続したところ、今度はpemファイルの権限エラーが発生したため、権限を絞って解決しました。

chmod 400 udemy-aws-14days.pem
ssh -i udemy-aws-14days.pem ec2-user@<パブリックIP>

② ミドルウェアのインストールとHTTPアクセスのトラブル

sudo dnf update -y
sudo dnf install httpd -y
sudo systemctl start httpd

ブラウザからパブリックIPにアクセスしてもWebページが表示されず、セキュリティグループに80番ポートの許可ルールがなかったことが原因と判明。ルールを追加して解決しました。

③ AMIによる複製

稼働中のインスタンスを停止し、AMIを作成
作成したAMIから新しいインスタンスを起動し、Apacheがインストール済みの状態で複製されることを確認。ただし自動起動の設定までは引き継がれないため、改めてサービスを起動する必要があった

④ Elastic IPでの固定化

インスタンスを停止・起動するとパブリックIPアドレスが毎回変わることを確認
Elastic IPを割り当ててインスタンスに関連付けたところ、停止・起動を繰り返してもIPアドレスが固定されることを確認
Elastic IPは紐付けていても課金対象になるため、不要な場合は関連付け解除・解放が必要という注意点も学んだ

セキュリティグループの設定漏れによるエラーを実際に体験したことで、「通信の許可はデフォルトで拒否される」というAWSの考え方を実感できました。

2-3. RDS （Relational Database Service）

・RDSとは
MySQLなどのリレーショナルデータベースをマネージドで利用できるサービスです。
バックアップやパッチ適用といった運用作業をAWS側が担ってくれるため、DBの構築・保守にかかる手間を減らせます。

・ハンズオンで行ったこと

これまでEC2上に手動でMySQLを構築していましたが、それをRDS(マネージドサービス)に置き換える形で進めました。

① RDSインスタンスの作成とパラメータ変更

DBサブネットグループ・パラメータグループを作成し、マルチAZ配置(プライマリー・スタンバイの二重構成)でRDS(MySQL)インスタンスを作成
パラメータグループからスロークエリログを有効化する設定変更を実施し、SSH不要でパラメータを変更できることを確認

② アプリとの接続・スナップショットの取得とリストア

Webサーバー(EC2)からRDSのエンドポイントに接続し、データベース・テーブル・アプリ用ユーザーを作成しました。

mysql -h <RDSのエンドポイント> -u root -p

簡易ブログアプリの接続先をEC2上のMySQLからRDSに切り替え
手動でスナップショットを取得した後、データを1件削除して「操作ミス」を再現し、スナップショットからリストアしてデータが復旧することを確認

③ フェイルオーバーの確認

インスタンスを再起動してフェイルオーバーを発生させ、プライマリー・スタンバイが入れ替わること、直前に登録したデータもスタンバイ側にきちんと同期されていることを確認

マネージドサービスに切り替えたことで、MySQLのインストールやOSのパッチ当てといった作業が不要になり、バックアップ・障害対応の機能が最初から備わっていることを実感しました。特にフェイルオーバーが数分程度で完了し、データも失われなかったことから、可用性を高める設計の効果を体感できました。

2-4. ELB （Elastic Load Balancing）

・ELBとは
複数のEC2インスタンスにリクエストを振り分ける負荷分散サービスです。
ヘルスチェック機能により異常なインスタンスを自動的に切り離すため、単一障害点(SPOF)をなくし可用性を高められます。

・ハンズオンで行ったこと

Webサーバー用のEC2を2台構成にし、ALB(Application Load Balancer)とAuto Scalingを使って可用性を高める一連の流れを試しました。

① 2台目のWebサーバーとALBの準備

既存のEC2からAMIを取得し、そのAMIからもう1台Webサーバーを作成(どちらに振り分けられたか分かるよう、それぞれのページタイトルを編集)
ターゲットグループを作成し、ヘルスチェックの間隔・しきい値を短めに設定(検証しやすくするため)
ALB用のセキュリティグループを新規作成し、Webサーバー側のセキュリティグループも「ALB経由のHTTPのみ許可」に変更

② ALBの作成と負荷分散の確認

2つのパブリックサブネットにまたがる形でALBを作成し、先ほどのターゲットグループに紐付け
ALBのDNS名でアクセスし、リロードのたびに2種類のページが交互に表示されることを確認

③ ヘルスチェックによる自動切り離しの確認

片方のインスタンスでApacheを停止しました。

sudo systemctl stop httpd

リロードを繰り返すと、最初の10〜20秒は正常な方と502エラーが交互に出ますが、ヘルスチェックが異常を検知した後は正常なインスタンスのみが表示されるようになることを確認しました。Apacheを再起動すると、しばらくして再びそのインスタンスにもルーティングされるようになることを確認しました。

④ Auto Scalingの設定とスケールアウト/インの確認

起動テンプレート(AMI・インスタンスタイプ・セキュリティグループなどを定義)を作成
Auto Scalingグループを作成し、希望容量2台・最小2台・最大4台、CPU使用率を基準にしたターゲット追跡スケーリングポリシーを設定してALBのターゲットグループに接続

yes > /dev/null &

上記コマンドで意図的にCPU負荷をかけ、アラームが発動して2台から4台にスケールアウトすることを確認しました。負荷を止めると、CPU使用率が下がったことを検知して4台から2台にスケールインすることも確認しました。

ヘルスチェックによる自動切り離し・復旧や、負荷に応じた自動スケーリングを実際に手を動かして確認できたことで、「可用性を高める」という言葉の意味を体感できました。あわせて、複数台構成にする場合はアプリケーションをステートレスに保つ必要がある、という設計上の注意点も学びました。

2-5. S3 （Simple Storage Service）

・S3とは
安価で耐久性の高いオブジェクトストレージサービスです。
画像などの静的ファイルの保存・配信や、静的ウェブサイトのホスティングなど幅広い用途で利用されます。

・ハンズオンで行ったこと

S3を使って、画像配信用と静的サイトホスティング用の2種類のバケットを作成しました。

① 画像配信用バケットの作成

バケットを作成し、パブリックアクセスブロックを解除
バケットポリシーを編集し、外部からのGetObject(読み取り)を許可
フォルダを作成して画像ファイルをアップロードし、オブジェクトURLで外部からアクセスできることを確認

② アプリからS3画像を参照する形に変更

Web用EC2からRDSに接続し、投稿データの画像パスをローカルパスからS3のURLに書き換え
ブログアプリをリロードし、S3上の画像が表示されるようになったことを確認

③ 静的ウェブサイトホスティングでSorryページを作成

別のバケットを作成し、同じくパブリックアクセスブロックの解除とバケットポリシーの設定を実施
「プロパティ」タブから静的ウェブサイトホスティングを有効化し、インデックスドキュメントにindex.htmlを指定
メンテナンス案内用のindex.htmlをアップロードし、バケットのウェブサイトエンドポイントにアクセスしてSorryページが表示されることを確認

EC2のようなサーバーを立てなくても、S3だけで画像配信や簡易的なページ公開ができることを実際に確認できました。また、EC2・RDSはVPCの中で動くサービスだったのに対し、S3はVPCを指定せずに作成できる(VPCに紐づかない)という違いも体感できました。

3. まとめ

今回は、VPC・EC2・RDS・ELB・S3という5つのサービスについて、役割とハンズオンの内容を整理しました。

VPCでネットワークを作り、EC2でサーバーを立て、RDSでデータベースを用意する。ELBで負荷分散をかけ、S3で静的コンテンツを配信する。並べてみると、Webシステム全体の構成が少しずつ見えてきました。

特にELBのヘルスチェックとAuto Scalingは、実際に手を動かすことで「可用性を高める」という言葉の意味を体感できたのが大きな収穫でした。

今回学習したのは、AWSのごく一部です。今後はRoute 53やCloudFront、CLIやSDKにも学習範囲を広げていきたいと考えています。