ステップ2:VPCネットワーク基盤とECSクラスター構築
今回のステップの概要とECサイトとの関連について
このステップでは、前回作成したDockerコンテナをAWS Fargateを使用したサーバーレス環境で実行するための基盤を構築します。具体的には、Amazon VPCによる仮想ネットワーク環境の作成、Amazon ECSクラスター(Fargate専用)の構築、そしてAmazon ECRへのコンテナイメージ保存を行います。
ECサイトにとって、このステップは「サーバー管理不要の自動化された店舗基盤の準備」のような役割を果たします。VPCは安全な商業区画、Fargateクラスターは完全自動化されたショッピングモール、ECRは高速配送可能な商品倉庫に相当し、これらによりインフラ管理の負担なく安全で拡張性のあるECサイト運営が可能になります。
このステップで学ぶこと
- Amazon VPCによる仮想ネットワーク環境の構築
- Amazon ECSクラスターの作成と設定
- Amazon ECRでのコンテナイメージ管理
- パブリックサブネットとマルチAZ構成の理解
リソースの関わりと構成説明
ステップ2で作成するリソースは、ECサイトの安全で拡張性のあるクラウド基盤を構築するものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。
Amazon VPCとネットワーク分離の関わり
Amazon VPC「仮想プライベートクラウド」は、ECサイトの「専用商業区画」のような役割を果たします。他の利用者から完全に分離されたプライベートなネットワーク空間を提供し、セキュリティとプライバシーを確保します。これにより、ECサイトの重要なデータと処理を安全に保護できます。
Amazon ECSクラスター(Fargate)とサーバーレス管理の関わり
Amazon ECSクラスター(Fargate)「サーバーレスコンテナ管理環境」は、ECサイトの「完全自動化されたショッピングモール」のような役割を果たします。サーバーの管理や保守を一切必要とせず、コンテナを効率的に配置・管理し、負荷に応じて自動的にスケールすることで、運用負荷なしで安定したサービス提供を実現します。
Amazon ECRとイメージ管理の関わり
Amazon ECR「コンテナイメージレジストリ」は、ECサイトの「セキュアな商品倉庫」のような役割を果たします。コンテナイメージを安全に保管し、必要な時に迅速にデプロイできる環境を提供します。これにより、アプリケーションの更新やスケーリング時の迅速な対応が可能になります。
実際の手順
実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。
1. VPCとサブネットの作成
この手順では、仮想ネットワークである VPC とインターネットと疎通可能なパブリックサブネットを作成します。
【AWSでの役割】
Amazon VPCは、AWS クラウド内で論理的に分離された仮想ネットワークを提供するサービスです。VPCを使用することで、従来のデータセンターで運用していたネットワークと同様の環境をクラウド上に構築できます。VPCは完全にお客様の制御下にあり、仮想ネットワーク環境を自由に設定することができます。
【オンプレミスでの対応】
オンプレミス環境では「物理ネットワークインフラ」が対応します。スイッチ、ルーター、ファイアウォールなどの物理機器を設置し、ネットワークセグメントを構築する必要があります。また、ネットワーク機器の調達、設置、設定、保守などの運用作業が必要になります。
1-1. VPC ダッシュボードを開く
-
画面右上でリージョンを「米国(バージニア北部)」にします。

-
マネジメントコンソールの検索バーに「VPC」と入力し、VPC ダッシュボードを開きます。
1-2. VPC と 2 つのパブリックサブネットを作成する
-
VPC ダッシュボードを開いたら、「VPC を作成」をクリックします。
-
VPC 作成画面で以下の設定を行います。
| 項目 | 設定値 |
|---|---|
| 作成するリソース | VPC など |
| 名前タグの自動生成 | ON |
| 名前タグ | ecs-handson |
| IPv4 CIDR ブロック | 10.0.0.0/16(デフォルト) |
| IPv6 CIDR ブロック | IPv6 CIDR ブロックなし(デフォルト) |
| テナンシー | デフォルト(デフォルト) |
| アベイラビリティーゾン (AZ) の数 | 2(デフォルト) |
| パブリックサブネットの数 | 2(デフォルト) |
| プライベートサブネットの数 | 0 |
【解説】マルチAZ構成による高可用性設計
このハンズオンでは、簡単のためインターネットから直接アクセスできないプライベートサブネットは作成しません。実際の本番環境では、データベースサーバーやインターネットから直接アクセスする必要のないアプリケーションサーバーなどは、セキュリティの観点からプライベートサブネットに配置することが推奨されます。複数のアベイラビリティーゾーンを使用してサービスを実行することで、単一のデータセンターで障害が発生した場合でも、他のアベイラビリティーゾーンでサービスを継続できるため、サービスの可用性や耐障害性を大幅に向上させることができます。
- その他の項目はそのままで大丈夫です。「VPC を作成」をクリックして、VPC のリソースを作成しましょう。
2. ECSクラスターの作成
Amazon ECS では、クラスターと呼ばれる論理的な単位でリソースを管理します。
【AWSでの役割】
Amazon ECSは、コンテナ化されたアプリケーションを簡単にデプロイ、管理、およびスケーリングするためのフルマネージドなコンテナオーケストレーションサービスです。ECSクラスターは、コンテナが実行される環境の論理的なグループであり、EC2インスタンスやFargateなどの計算リソースを含みます。ECSは、AWSの設定と運用のベストプラクティスが組み込まれており、チームがアプリケーションの構築に集中できるよう環境管理の複雑さを軽減します。
【オンプレミスでの対応】 オンプレミス環境では「Kubernetesクラスター」や「Docker Swarm」が対応します。これらの環境では、マスターノードの構築、ワーカーノードの管理、ネットワーク設定、ストレージ設定など、すべての運用作業を自社で行う必要があります。また、高可用性を確保するためのクラスター設計や障害対応も独自に実装する必要があります。
2-1. ECS ダッシュボードでクラスターを作成する
-
マネジメントコンソールの検索バーに「ECS」と入力し、ECS ダッシュボードを開きます。
-
ECS ダッシュボードのサイドバーの「クラスター」「クラスターの作成」を選択し、ECS クラスターを作成していきます。
-
まず、クラスター名を入力します。
| 項目 | 設定値 |
|---|---|
| クラスター名 | ecs-handson-cluster |
- 続いて、クラスターの実行環境を設定します。ここでは、Fargateのみを使用するサーバーレスクラスターを作成します。
| 項目 | 設定値 |
|---|---|
| AWS Fargate (サーバーレス) | ON(デフォルト) |
| Amazon EC2 インスタンス | OFF |
- Fargateのみを使用するため、ネットワーク設定は不要です。そのまま「作成」をクリックします。
【解説】Fargateクラスターの簡素化
Fargateを使用する場合、EC2インスタンスの管理が不要になるため、Auto Scaling グループ、インスタンスタイプ、AMI、インスタンスロールなどの設定が不要になります。また、Fargateタスクは実行時にVPCとサブネットを指定するため、クラスター作成時のネットワーク設定も不要です。これにより、クラスター作成が大幅に簡素化され、サーバー管理の複雑さから解放されます。
【Fargateの制約事項について】
AWS Fargateはサーバーレスの利便性を提供する一方で、いくつかの制約があります。主な制約事項として、GPUサポートの非対応、特定のLinuxパラメータの制限、Docker ボリューム設定の制限、事前定義されたCPU・メモリ組み合わせの選択制限などがあります。また、コスト面では、低使用率の場合はEC2と比較して割高になる可能性があります。これらの詳細な制約事項や最新の対応状況については、AWS Fargate公式ドキュメント およびFargateタスク定義の制限 をご確認ください。
2-2. ECS クラスターの確認
- 1 分ほど待つと、Fargateクラスターが作成されます。作成したクラスターをクリックし、「クラスターの概要」で「ステータス」が「アクティブ」になっていることを確認できます。
Fargateクラスターでは、EC2インスタンスを管理する必要がないため、「インフラストラクチャ」タブにコンテナインスタンスは表示されません。
3. コンテナイメージの保存
ECS ではクラスター上でコンテナを実行しますが、そのコンテナの元となるコンテナイメージは別の場所から取得してくる必要があります。
【AWSでの役割】
Amazon ECRは、AWSが管理するコンテナイメージレジストリサービスです。セキュアで、スケーラブル、かつ信頼性の高いサービスとして提供されており、プライベートリポジトリでリソースベースの権限をAWS IAMを使用して管理できます。ECRでは、Docker イメージ、Open Container Initiative (OCI) イメージ、および OCI 互換アーティファクトをサポートしており、お好みのCLIを使用してプッシュ、プル、および管理を行うことができます。
【オンプレミスでの対応】
オンプレミス環境では「Harbor」や「Nexus Repository」などのプライベートコンテナレジストリが対応します。これらのソリューションでは、レジストリサーバーの構築、運用、セキュリティ設定、バックアップ戦略などをすべて自社で管理する必要があります。また、高可用性を確保するためのクラスター構成や災害復旧計画も独自に設計・実装する必要があります。
3-1. ECR リポジトリを作成する
-
ECS ダッシュボードのサイドバーで「リポジトリ」をクリックして ECR ダッシュボードを開きます。
-
「リポジトリを作成」をクリックします。
-
ここでは、プライベートなイメージリポジトリを作成していきます。
| 項目 | 設定値 |
|---|---|
| リポジトリ名 | rails-app |
-
残りの設定はそのままに「作成」をクリックします。
-
作成したリポジトリをクリックして詳細画面に移動します。
-
「プッシュコマンドを表示」をクリックすると、コンテナイメージをレポジトリに push するためのコマンドを表示できます。
3-2. ECR にコンテナイメージを push する
ローカル環境から作成したコンテナイメージを ECR に push していきましょう。
前の手順で確認した「プッシュコマンド」を、ローカルの作業ディレクトリで順番に実行していきます。
以下の手順はあくまで一例です。ご自身で表示したプッシュコマンドを順番に実行してください。
# 作業ディレクトリに移動(step1で作成したディレクトリ)
cd docker-rails-workshop
# AWS アカウント ID を取得する
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
# ECR レジストリにログインする
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com
# コンテナイメージをビルドする
docker build -t rails-app .
# コンテナイメージにタグを付与する
docker tag rails-app:latest ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails-app:latest
# タグを付与したコンテナイメージを ECR に push する
docker push ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails-app:latest【解説】コンテナイメージタグのベストプラクティス
latest タグを使い回すことは、特定のコンテナイメージとリリースを関連づけることを困難にします。また、リリースに失敗した際のロールバックも困難になります。実際の本番環境では、コンテナイメージごとに一意のタグを使用することが強く推奨されます。例えば、Git リポジトリのコミット ID、ビルド番号、またはセマンティックバージョニングを使用したタグ付けにより、特定のバージョンのイメージを確実に識別できるようになります。これにより、デプロイメントの追跡性が向上し、問題が発生した際の迅速なロールバックが可能になります。
3-3. 保存したコンテナイメージを確認する
-
ECR ダッシュボードのレポジトリ詳細画面に戻りリフレッシュボタンをクリックすると、pushされたコンテナイメージが確認できます。
-
「イメージの URI」は、取得するコンテナイメージを指定する際に使用するので、どこかに控えておきましょう。
このステップで何をしたのか
このステップでは、コンテナ化されたアプリケーションをクラウド環境で実行するための基盤を構築しました。具体的には、Amazon VPCによる仮想ネットワーク環境を作成し、複数のアベイラビリティーゾーンにパブリックサブネットを配置することで高可用性を確保しました。また、Amazon ECSクラスターを構築してコンテナオーケストレーション環境を整備し、Amazon ECRにコンテナイメージを安全に保存しました。
ECサイトでどのような影響があるのか
この構成により、ECサイトは単一のローカル環境から本格的なクラウド基盤に進化しました。VPCによる論理的に分離されたネットワーク環境により、セキュリティが大幅に向上し、マルチAZ構成により単一障害点を排除しました。ECSクラスターにより、コンテナの自動管理と効率的なリソース利用が可能になり、ECRにより安全で高速なコンテナイメージ配信が実現されました。これは、個人商店から本格的なショッピングモールへの発展に相当します。
技術比較まとめ表
| 技術領域 | AWS | オンプレミス |
|---|---|---|
| 仮想ネットワーク | Amazon VPC フルマネージドな仮想ネットワーク | 物理ネットワーク機器 スイッチ・ルーターの物理構築 |
| コンテナ管理 | Amazon ECS フルマネージドなオーケストレーション | Kubernetes/Docker Swarm 自前でのクラスター運用 |
| イメージレジストリ | Amazon ECR セキュアで高可用性なレジストリ | Harbor/Nexus プライベートレジストリの自前構築 |
| ネットワークセキュリティ | セキュリティグループ ソフトウェア定義のファイアウォール | 物理ファイアウォール ハードウェアベースのセキュリティ |
学習において重要な技術的違い
1. インフラ管理の抽象化
- AWS: VPCやECSなどのマネージドサービスにより、物理的なインフラ管理から解放されます。
- オンプレミス: 物理サーバー、ネットワーク機器、ストレージの調達から設置、保守まですべて自社で対応する必要があります。
2. スケーラビリティの実現方法
- AWS: ECSクラスターにより、需要に応じた自動スケーリングが可能です。
- オンプレミス: 容量計画を事前に立て、物理リソースを先行投資する必要があります。
3. セキュリティの実装
- AWS: IAMやセキュリティグループによる詳細なアクセス制御が標準で提供されます。
- オンプレミス: ファイアウォール、IDS/IPS、アクセス制御システムを個別に導入・設定する必要があります。
4. 可用性の確保
- AWS: マルチAZ配置により、自動的に高可用性が実現されます。
- オンプレミス: 冗長化設計、災害復旧計画、バックアップ戦略をすべて自社で策定・実装する必要があります。
実践チェック:画面キャプチャで証明しよう
下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。
-
VPCとパブリックサブネットの作成確認
-
Fargateクラスターの作成確認(アクティブ状態)
-
ECRリポジトリの作成確認
-
コンテナイメージのECRプッシュ確認
-
ECRでのイメージURI確認
提出方法: 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。 ファイル名やコメントで「どの項目か」が分かるようにしてください。
構成図による理解度チェック
ステップ1のローカルDocker環境の構成図に、このステップで作成したAWSリソースを追記して、現在のクラウドインフラ構成を完成させましょう。
なぜ構成図を更新するのか?
ローカル環境からAWSクラウド環境への移行により、システムアーキテクチャが根本的に変化しました。この変化を視覚的に理解することで、各AWSサービスの役割と相互関係を明確に把握できます。特に、ネットワーク分離とコンテナオーケストレーションの仕組みを図で表現することが重要です。
- VPCネットワーク設計: 論理的に分離された仮想ネットワーク環境の理解
- マルチAZ配置: 高可用性を実現するリソース配置の理解
- コンテナライフサイクル: ECRからECSへのイメージ配信フローの理解
構成図の書き方
ステップ1で作成したローカル構成図をベースに、以下のAWSリソースを追記してみましょう。
- VPC: 全体を囲む仮想ネットワーク境界
- パブリックサブネット: 2つのAZに配置されたサブネット
- Fargateクラスター: サーバーレスコンテナ実行環境の論理グループ
- ECR: コンテナイメージの保存場所
- AWS認証: ローカル環境からのアクセス経路
💡 ヒント: AWSクラウドを大きな雲の形で描き、その中にVPCを配置。Fargateクラスターはサーバーレスを表現するため、物理サーバーの絵は使わず、クラウドマークで表現しましょう。
理解度チェック:なぜ?を考えてみよう
AWSの各リソースや設計には、必ず”理由”や”目的”があります。 下記の「なぜ?」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか?」を意識して考えてみてください。
Q. なぜVPCを作成して仮想ネットワークを分離する必要があるのか?
Q. なぜ複数のアベイラビリティーゾーンにサブネットを配置するのか?
Q. なぜECSクラスターでコンテナを管理するのか?
Q. なぜECRにコンテナイメージを保存するのか?
今回のステップで利用したAWSサービス名一覧
- Amazon VPC:仮想プライベートクラウド
- Amazon ECS:コンテナオーケストレーションサービス
- Amazon ECR:コンテナイメージレジストリ
- パブリックサブネット:インターネットアクセス可能なサブネット