はじめに
こんにちは、Ryuです！
今回はAWS SAAの試験でも出てくるようなWebアーキテクチャ構成をAWS Workshops Studioで見つけたので実際に構築してみたいと思います。
今回構築するアーキテクチャは以下になります。
こちらのAWS Workshops Studioにて参考資料等直接確認できます。
アーキテクチャ概要
今回の構成では、AWS 上に Web アプリケーションの基礎的なネットワーク環境を構築しています。
まず 1 つの VPC を用意し、
パブリックサブネット ×2（AZ A / AZ B）
プライベートサブネット ×2（AZ A / AZ B）
という構成で、2 つの Availability Zone に跨る冗長なネットワークを作成しています。
プライベートサブネットに配置された EC2 Web サーバーは、直接インターネットに出られないため、
NAT Gateway 経由で必要な外部アクセスが行えるように構成しています。
ユーザーからのアクセスは
Internet Gateway → Application Load Balancer (ALB)
というルートを通り、ALB が Web サーバーへリクエストを転送します。
ALB と Web サーバーにはそれぞれ Security Group を設定し、
許可するポートと通信元を明確に制御しています。
Web サーバーで利用する静的コンテンツは Amazon S3 に保存しており、
S3 との通信は VPC Endpoint (Gateway Endpoint) を利用して、
インターネットを経由せず AWS 内部ネットワークで安全にアクセスできる構成になっています。
使用するサービス一覧
- VPC
- SGs
- IAM
- EC2
- SSM
- ALB
- S3
- ASG（オプション）
では実際に構築していきましょう！
VPC作成
まずはAWSのサービスを置くための土台となるVPCを構築していきます。
- VPCと検索しアクセスします。
- VPCを作成をクリック。
VPCなどを選択しその他の設定を行っていきます。 - 名前タグの自動生成ではVPCの名前を決めます。
- IPv4CIDRブロックでは使用する範囲のIPアドレスを決めていくのですが今回はデフォルトにします。
- IPv6はなし。
- テナンシーはデフォルト。
- AZは２つ必要なので２を選択。
下部にスクロールして。 - パブリックサブネットを２つ。
- プライベートサブネットを２つ。
- 今回は各パブリックサブネットにNAT配置したいのでAZごとに１をNATゲートウェイで選択。
- VPCエンドポイントではS3に静的コンテンツ配置するのでS3ゲートウェイを選択します。
- その他DNS設定はデフォルトのままにします。
最後にVPCを作成を押してVPC作成はこれで以上になります、この後他のサービスを作成し配置できるようになります。
セキュリティグループ作成
次はALBとWebサーバーにアタッチするSGを作成します。
検索欄にEC2を検索してアクセスします。
左側の選択画面にてセキュリティグループをクリック、そして右上のセキュリティグループを作成を押します。
セキュリティグループの作成していきたいと思います。
まずはALB用のSGを作成していきます。
- セキュリティグループの名前はハンズオン資料にあるLoad Balancer Security Groupを入力。
- 説明欄もハンズオン資料にあるExternal Accessを入力。
- VPCは先ほどさ作成したものを必ず選択する。
- インバウンドルールでは入ってくる通信の許可をする設定です。今回は80番ポートのHTTPの通信全てを許可するため0.0.0.0/0をソースとして選択します。
- 説明欄ではなぜこのポートを許可するのか簡単な説明を入れます、今回はハンズオンに事前に準備されているものを入力します。
※安全な通信のためには本来 HTTPS を推奨しますが、このワークショップでは構成をシンプルにするため、SSL/TLS 証明書の設定までは行いません。HTTPS を使うには証明書が必要。その証明書を AWS が自動で用意・管理してくれるのがACMになります。
最後に下部スクロールしていくとタグを確認することができます。
タグはAWSのリソースに付けるメモみたいなもので、整理したりコスト管理に役立つものになります。
- 今回はハンズオンに事前に準備されているものをコピペしていきます。
続けてWebサーバー用のSGをALB用で作った方法と同じ方法で作成していきます。
下部へスクロールして。
セキュリティグループを作成で完了です！
以上の設定で２つのセキュリティグループを作成することができました。
IAMロールの設定
Webサーバーがアクセスできる AWS リソースを必要最小限に絞るため、IAM で厳密に権限を設定します。
※IAM ポリシーで権限を作り、それを IAM ロールに付けます。
EC2 はこのロールを引き受けて許可された AWS リソースにアクセスできます。
インスタンスプロファイルは、そのロールを EC2 に付けるための仕組みです。
早速ロール作成をしていきます。まずはIAMを検索しアクセスします。
左側の選択肢を確認するとロールと確認できるのでそちらをクリック、そしてロールを作成を押します。
AWSのサービスを選択します。
※ポリシーやロールは自分で作成することもできますが、AWS にはあらかじめ用意されたテンプレートが多数あります。今回はその既存のロールを利用します。
下部にスクロールして、ユースケースをEC2を選択します。
加えて以下のEC2 Role for AWS Systems Managerを選択してください。
今回選択したロールのテンプレートはEC2にSSH接続しなくても、AWS の管理ツール（SSM）で操作できるようにするための権限セットになります。
以上の設定を終えましたら次へをクリックします。
タイプのところで確認できるようにこのロール自体AWSによって管理されているテンプレートのロールになります
今回の選択したロールにアタッチされているポリシーを確認し次へを押します。
ロール名を記入していくのですがハンズオンに事前に準備してくれている名前をそのままコピペします。
説明の部分もそのままでAWSが準備してくれたものをそのまま使います。
下部にスクロールしていくと、ロールに付与されているポリシーがJSON形式で確認できます。
自作でポリシーを作成する場合JSON形式で作成していくことになります。
さらにスクロールして今回はタグ付けなしでそのままロール作成を押してロールの完成になります！
EC2作成
EC2インスタンス作成してWebサーバーを作っていきたいと思います。
まずはEC2と検索してアクセスします。
右側のインスタンスを起動をクリックします。
ではインスタンスの設定を行っていきます。
- 名前ではわかりやすいサーバー名を入力します。
- Amazonマシンイメージではそのままデフォルトの無料枠を使用するので何も設定は変更行いません。
下部へスクロールします。
- インスタンスタイプも変更を行わないで無料枠のすでに指定されているものを使用します。
- キーペアに関してはキーペアなしを選択します。通常の構成では必ず使用する必要があるのですが今回直接SSH接続するのではなくSSM経由でEC2に入るハンズオンになっております。
下部へさらにスクロールしネットワークの設定を行ってきます。
- VPCでは今回作成したものを選択。
- サブネットは４つ作成したうちのプライベートなものを１つ選択。
- パブリックIPは使用しないので無効化。
-セキュリティグループは今回SG編で作成したWebサーバー用のものを選択。
下部へスクロールし高度な詳細を開いてIAM編で作成したIAMインスタンスプロファイルを選択します。
最後に高度な詳細の一番したへスクロールしてサーバー起動時にPHP関連を自動インストールさせたいので、Userdataでスクリプトを設定します。
スクリプトはハンズオン内の資料に添付してあるものを使用します。
そしてインスタンスを起動するをクリックしてEC2の作成はこれで以上になります！今回のハンズオンほぼ50%が完了しました、ハンズオンが楽しすぎて時間の進みが早く感じます笑
初期化中ではありますが起動できたのを確認できました。
SSMを使用して実際にEC2へアクセス
今回作成したインスタンスを選択して接続をクリックします。
接続方法をセッションマネージャーを選択して接続をクリックします。
簡単にインスタンスに接続できました！
ではハンズオン内に添付してあるコマンドを実行していきます。
echo -n 'Private IPv4 Address: ' && ifconfig enX0 | grep -i mask | awk '{print $2}'| cut -f2 -d: && \
echo -n 'Public IPv4 Address: ' && curl checkip.amazonaws.com
このコマンドはどんなコマンドかというとChatGPTに聞いたところ、「EC2内部のNICが持つプライベートIP」と「外部から見えるパブリックIP」を別々に取って表示する」コマンドになります。
コマンドをそのままコピペして実行したところ、パブリックIPは表示されたがプライベートのIPアドレスはエラーで確認できませんでした。
調べたところエラーの原因はenX0 というインターフェースがそもそも存在しない、だからifconfig enX0 が失敗してエラーがそのまま出ている。
解決策としてifconfigコマンドで実際のインターフェース名を確認し、enX0→ens5にコマンドを変更後に無事に解決できました。
プライベートIPがちゃんと表示されたので、SSH接続をしないで正しいインスタンスに入れていることを確認できました。
表示されているパブリックIPはNAT GatewayのElastic IPで、これのおかげでプライベートサブネット内のWebサーバーがインターネットと通信できています。
ALB作成
ALBを作成していきます！ALBも実はEC2のサービスないから確認することができます。EC2のサービスへアクセスしていただいて左側の選択肢から下部へスクロールするとロードバランサーを確認できるのでそちらをクリックしていきます。
続けてロードバランサーの作成をクリック。
今回はHTTP通信を使用するのでALBを選択します。
ALBの設定を行っていきます。
- ロードバランサー名をわかりやすいものを入力。
- 外部（インターネット）から直接アクセスさせるのでインターネット向けを選択。
- ロードバランサーの IP アドレスタイプはIPv4を選択。
ネットワークマッピング
- 今回作成したVPCを選択。
- IPプールはロードバランサーのパブリックIPv4を“自前のIPプール”から割り当てるものなので基本的んはなし。
- アベイラビリティーゾーンとサブネットでは今回作成した２つのパブリックサブネットを選択。
ALB用に作成したSGを選択します。
リスナーとルーティングでは実際にALBはALB は“どのサーバーにリクエストを送るか”を自分では判断できないのでターゲットグループを作成しそれをアタッチしていきます。
まだターゲットグループは未作成なのでターゲットグループを作成するをクリックして作成していきます。
ではハンズオンの添付資料に添付してある通りに設定を行っていきます。
- インスタンスを登録するのでインスタンスを選択。
- ターゲットグループ名を入力します。
- VPCは必ず今回作成したもの選択。
- その他の設定はデフォルトで特に変更点はありません。
タグ付けして次へをクリックします。
最後にターゲットグループに登録するインスタンスを選択し、保留中として以下を含めるを押して次へを
クリックします。
このままターゲットグループの作成をクリックして作成完了です！
作成完了すると添付のような表示になります。
ターゲットグループができたのでALBの先ほどの設定に戻ります。
ALB設定のリスナーとルーティングにあるターゲットグループを選択します、これでALBはどのインスタンスに振り分けるかわかるようになります。
その他の設定はデフォルトのまませ一番したまでスクロールしロードバランサーの作成をクリックして作成完了です！
Webサーバーアクセスしてみよう！
Webサーバーへアクセスする前にターゲットグループでインスタンスの健康状態を確認します。
正常１が見えますね！これでアクセスできる状態だと確認できました。
ではロードバランサーにあるDNS名を使ってブラウザーでアクセスしていきます！
素晴らしい...アクセスできました！
S3作成
静的コンテンツを置くためのS3を作成します。
S3をまずは検索しアクセスします。
次にバケットを作成をクリックします。
汎用バを選択し、バケット名を入力していきます。
その他の設定はデフォルトのままにして、一番したまでスクロールしたらバケット作成をクリックします。
これでS3バケットの完成です！
コンテンツファイルをアップロードするので対象のバケットを選択しクリックします。
ハンズオン内にある添付資料をダウンロードしてそちらをアップロードしていきます。
アップロードが完了したのでWebサーバーから実際にS3バケットが確認できるか確認していきましょう。
エラーが起きてしまいました...
原因はなんなんでしょうか... そうEC2にS3へアクセスする権限を付けてないのが原因になります。
EC2のIAMロールにS3アクセス権限を追加すれば解決できるので権限を追加していきましょう！
IAMへアクセスし左側のロールをクリックしていきます。
対象のロールを選択クリックします。
ポリシーを追加したいのでポリシーをアタッチをクリックします。
S3をリードしたいだけなのでAmazonS3ReadOnlyAccessを検索して許可を追加します。
これでポリシーがアタッチされ他ので再度WebサーバーからS3アクセス可能かどうか確認していきます。
バケット名とリージョンを入力後にBrowseボタン押した結果無事に確認できることを確認できました。
Auto Scaling Group作成 （チャレンジ）
ハンズオンではASGはチャレンジ枠として自分で作成してみるオプションになっています。
ではAuto Scaling Groupとはなんでしょうか？
今回の“Private Subnetに1台だけEC2を置く構成は、壊れた瞬間にサービスが完全に停止してしまいます。
ASGはそのリスクをゼロにする仕組みであり、可用性・復旧力の基盤として必須であり単一障害点を排除するのに役立ちます。
実際に構築し挙動を確認して可用性と復旧力を確認していきましょう！
まずはEC2を検索しアクセスしていきます。
ASGを作成するためには起動テンプレートをまず作成する必要があるので、対象のインスタンスを選択して、右上のアクションからアクション→イメージとテンプレート→インスタンスからテンプレートを作成をクリックします。
起動テンプレート作成を行っていきます。
- 起動テンプレート名をわかりやすものを命名します。
- テンプレートバージョンの説明を入力。
下部にスクロールしていき、AMIを選択するのですが今回は特に自作したものはないのでデフォルトのものをそのまま選択していきます。
※AMIとは？“ディスクのコピー（スナップショット）” と “OS の設計図” のこと。
下部へスクロールしインスタンスタイプもそのままになります。
キーペアも今回は作成していないのでなしになります。（SSMで接続する仕様になっているため）
ASGが複数AZにまたがってインスタンスを作るため、テンプレートのAZは無視されるためサブネットとAZの選択はデフォルトのままにします。
SGではWebサーバー用で作成したものを必ず選択します。
その他デフォルトのままで進んでいきます。
最後に高度な詳細を開いていただきIAMインスタンスプロフィールを今回作成したものを選択されているか確認します、さらに一番したの欄にあるユーザーデータもしっかり記述されているかチェックして問題なければ起動テンプレートを作成をクリックして完了になります！
これで起動テンプレート作成できましたので、次はASGを作成していきます。
EC2サービスへ戻っていただき左側の選択肢の一番したの欄へスクロールしていくとASGを確認できるのでクリックしていきます。
Auto Scalingグループを作成するをクリック。
ASGnのグループ名を入力し、今回作成した起動テンプレートを選択していきます。
そのまま下部へスクロールし次へをクリックします。
-
インスタンスの要件はデフォルトのままで下部へスクロールします。
-
ネットワークの部分では今回作成したVPCを選択して、AZとサブネット部分では作成したプラベートなサブネット２つを選択します。
-
AZのディストリビューションではではベストエフォートのバランシングを選択。
※バランシング＝ AZ間でインスタンス数を均等に保つこと。
下部へスクロールし次へをクリックして進みます。
-
既存のALBがあるので既存のロードバランサーにアタッチするを選択。
-
ターゲットグループも選択すする必要があるので今回作成したものをを選択。
下部へスクロールしこれらの設定はデフォルトのまま進んでいきます。
-
ヘルスチェックの部分ではElastic Load Balancingのヘルスチェックをオンにします。
-
EC2のヘルスチェックは自動的に有効されているが、ELBのヘルスチェックをONにすることで、ASGは “アプリレベルの異常” に反応するようになります。
-ヘルスチェックの猶予期間は短すぎるとインスタンス起動の無限ループになるので注意。
次へをクリックし進みます。
-
グループサイズを希望するキャパシティ２に設定します。
これは何台常に起動している状態を保ちたいかを設定するものになります。 -
スケーリングではスケールアウトとスケールインする際のインスタンス起動する台数の範囲を指定できます。今回最小２、最大２で指定します。
下部へスクロールしその他の接待はデフォルトのままで進んでいきます。
そのまま最後までスクロールし次へをクリックします。
SNS機能を使ってインスタンスを起動または削除されるたび指定したメールアドレスに通知できる機能もありますが今回は不要なので次へをクリックして進めていきます。
今回タグもなしで次へをクリック。
最後に確認画面に入るので問題なければ一番したまでスクロールしAuto Scaling グループを作成するをクリックして完了になります！
作成できたことを確認できました！
早速インスタンスが起動しているかどうか確認していきたいと思います。
なんと、２台インスタンスが起動していると想定していたのですが３台になっています笑
ASGについて調べると：ASGは自分が作ったEC2だけ台数を合わせる。最初からあった手動で作成したEC2は無視して残る。よって合計３台インスタンスが存在していることになる。
ASGで自動的にインスタンスを起動してくれるかどうか確認したいのでまずは手動で作成したインスタンスを削除します。
- 見分け方はタグを確認しAutoScalingのタグがないインスタンスがASG管理外になりますのでそちらを選んで削除します。
- インスタンスを終了をクリックします。
終了を押して削除完了です。
インスタンス終了できたことを確認できたので、次のステップに移ります。
ASGがインスタンス数を２台に自動的に保ってくれるかどうか、２台あるうちに１台を手動で削除していきたいと思います。
先ほどのインスタンスを削除したようにもう一方を削除することができました、しばらく待っていると....
１台自動で立ち上がっていることを確認できました！Webサイトにも無事にアクセスできることを確認できました、
各インスタンスが別々のAZサブネットに配置しっかりされていることもできました。
今回のハンズオンはこれで終了になります！
終わりに
ハンズオンをやりながら記事を書くのは正直きつかったですが、
“理解した内容を言語化するプロセス” が一番記憶に残ることを痛感しました。
単に手順をなぞるだけでは気づけなかった部分も、記事化することで穴が見つかるし、
自分が曖昧に理解していた箇所もはっきり浮き上がってきました。
資格勉強で学んだ知識も、実際の AWS コンソールで手を動かすと
“この設定はここで効いてくるのか”
“このサービスはこう繋がるのか”
という具体的な理解に変わっていきます。
インプットだけでは腹落ちしなかった内容も、ハンズオンと記事化で一気に固まった感覚があります。
また、今回のハンズオンは日本語版がなく英語のみだったので、
作業しながら技術英語への耐性も自然に鍛えられた点は思わぬ収穫でした。
これからもどんどん色々なアーキテクチャをまずはハンズオンを通して構築挑戦していきたいと思います！