# 例: ウェブサーバーとデータベースサーバーの VPC
<a name="vpc-example-web-database-servers"></a>

この例は、本番環境の 2 層アーキテクチャに使用できる VPC を作成する方法について説明しています。回復性を高めるには、サーバーを 2 つのアベイラビリティーゾーンにデプロイします。

**Topics**
+ [概要:](#overview-vpc-public-private-subnets-multi-az)
+ [1. VPC を作成する](#create-vpc-public-private-subnets-multi-az)
+ [2. アプリケーションをデプロイします](#deploy-web-database-servers)
+ [3. 設定をテストする](#test-web-database-servers)
+ [4. クリーンアップ](#clean-up-web-database-servers)

## 概要:
<a name="overview-vpc-public-private-subnets-multi-az"></a>

次の図は、この例に含まれるリソースの概要を示しています。VPC には、2 つのアベイラビリティーゾーンにパブリックサブネットとプライベートサブネットがあります。ウェブサーバーはパブリックサブネットで動作し、ロードバランサーを介してクライアントからのトラフィックを受信します。ウェブサーバーのセキュリティグループは、ロードバランサーからのトラフィックを許可します。データベースサーバーはプライベートサブネットで動作し、ウェブサーバーからのトラフィックを受信します。データベースサーバーのセキュリティグループは、ウェブサーバーからのトラフィックを許可します。データベースサーバーは、ゲートウェイ VPC エンドポイントを使用して Amazon S3 に接続できます。

![\[2 つのアベイラビリティーゾーンにサブネットを持つ VPC です。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-example-web-database.png)


### ルーティング
<a name="routing-vpc-public-private-subnets-multi-az"></a>

Amazon VPC コンソールを使用してこの VPC を作成すると、ローカルルートとインターネットゲートウェイへのルートを含むパブリックサブネットのルートテーブル、およびローカルルートとゲートウェイ VPC エンドポイントへのルートを含む各プライベートサブネットのルートテーブルが作成されます。

以下は、IPv4 と IPv6 の両方のルートを含むパブリックサブネットのルートテーブルの例です。デュアルスタックサブネットの代わりに IPv4 専用サブネットを作成した場合、ルートテーブルには IPv4 ルートのみが含まれます。


| ルーティング先 | ターゲット | 
| --- | --- | 
| 10.0.0.0/16 | ローカル | 
| 2001:db8:1234:1a00::/56 | ローカル | 
| 0.0.0.0/0 | igw-id | 
| ::/0 | igw-id | 

以下は、IPv4 と IPv6 の両方のルートを含む、プライベートサブネットのルートテーブルの例です。IPv4 専用サブネットを作成した場合、ルートテーブルには IPv4 ルートのみが含まれます。最後のルートは、Amazon S3 を宛先とするトラフィックをゲートウェイ VPC エンドポイントに送信します。


| ルーティング先 | ターゲット | 
| --- | --- | 
| 10.0.0.0/16 | ローカル | 
| 2001:db8:1234:1a00::/56 | ローカル | 
| s3-prefix-list-id | s3-gateway-id | 

### セキュリティ
<a name="security-vpc-public-private-subnets-multi-az"></a>

この設定例では、ロードバランサー用のセキュリティグループ、ウェブサーバー用のセキュリティグループとデータベースサーバー用のセキュリティグループを作成します。

**ロードバランサー**  
Application Load Balancer または Network Load Balancer のセキュリティグループは、ロードバランサーのリスナーポート上のクライアントからのインバウンドトラフィックを許可する必要があります。インターネット上のどこからでもトラフィックを受け入れるには、ソースとして 0.0.0.0/0 を指定します。また、ロードバランサーセキュリティグループでは、ロードバランサーから、インスタンスリスナーポートおよびヘルスチェックポートでのターゲットインスタンスへのアウトバウンドトラフィックを許可する必要もあります。

**ウェブサーバー**  
以下のセキュリティグループルールは、ロードバランサーから HTTP および HTTPS トラフィックを受信することをウェブサーバーに許可します。(オプション) ウェブサーバーがネットワークから SSH または RDP トラフィックを受信するように許可できます。ウェブサーバーから SQL または MySQL トラフィックをデータベースサーバーに送信することができます。


| ソース | プロトコル | ポート範囲 | 説明 | 
| --- | --- | --- | --- | 
| ロードバランサーのセキュリティグループの ID | TCP | 80 | ロードバランサーからのインバウンド HTTP アクセスを許可する | 
| ロードバランサーのセキュリティグループの ID | TCP | 443 | ロードバランサーからのインバウンド HTTPS アクセスを許可する | 
| ネットワークのパブリック IPv4 アドレス範囲 | TCP | 22 | (オプション) ネットワーク内の IPv4 IP アドレスからのインバウンド SSH アクセスを許可する | 
| ネットワークの IPv6 アドレス範囲 | TCP | 22 | (オプション) ネットワーク内の IPv6 IP アドレスからのインバウンド SSH アクセスを許可する | 
| ネットワークのパブリック IPv4 アドレス範囲 | TCP | 3389 | (オプション) ネットワーク内の IPv4 IP アドレスからのインバウンド RDP アクセスを許可する | 
| ネットワークの IPv6 アドレス範囲 | TCP | 3389 | (オプション) ネットワーク内の IPv6 IP アドレスからのインバウンド RDP アクセスを許可する | 


| 目的地 | プロトコル | ポート範囲 | 説明 | 
| --- | --- | --- | --- | 
|  Microsoft SQL Server を実行しているインスタンスのセキュリティグループの ID  |  TCP  |  1433  |  データベースサーバーへのアウトバウンド Microsoft SQL Server アクセスを許可する  | 
|  MySQL を実行しているインスタンスのセキュリティグループの ID  |  TCP  |  3306  |  データベースサーバーへのアウトバウンド MySQL アクセスを許可する  | 

**データベースサーバー**  
次のセキュリティグループルールにより、データベースがウェブサーバーから、読み込みおよび書き込みリクエストを受信できます。


| ソース | プロトコル | ポート範囲 | コメント | 
| --- | --- | --- | --- | 
| ウェブサーバーセキュリティグループの ID | TCP | 1433 | ウェブサーバーからのインバウンド Microsoft SQL Server アクセスを許可する | 
| ウェブサーバーセキュリティグループの ID | TCP | 3306 | ウェブサーバーからのインバウンド MySQL Server アクセスを許可する | 


| 目的地 | プロトコル | ポート範囲 | コメント | 
| --- | --- | --- | --- | 
| 0.0.0.0/0 | TCP | 80 | IPv4 を介してインターネットへのアウトバウンド HTTP アクセスを許可する | 
| 0.0.0.0/0 | TCP | 443 | IPv4 を介してインターネットへのアウトバウンド HTTPS アクセスを許可する | 

Amazon RDS DB インスタンスのセキュリティグループの詳細については、*Amazon RDS ユーザーガイド*の「[セキュリティグループによるアクセスの制御](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)」を参照してください。

## 1. VPC を作成する
<a name="create-vpc-public-private-subnets-multi-az"></a>

次の手順を使用して、2 つのアベイラビリティーゾーンにパブリックサブネットとプライベートサブネットを持つ VPC を作成します。

**VPC を作成するには**

1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。

1. ダッシュボードで、**[VPC を作成]** を選択します。

1. **[Resources to create]** (作成するリソース) で、**[VPC and more]** (VPC など) を選択します。

1. VPC を設定する:

   1. [**名前タグの自動生成**] を選択したままにすると VPC リソース用の名前タグが作成され、オフにすると VPC リソース用の独自の名前タグが提供されます。

   1. **[IPv4 CIDR ブロック]** で、デフォルトの候補を維持するか、アプリケーションまたはネットワークが必要とする CIDR ブロックを入力します。詳細については、「[VPC CIDR ブロック](vpc-cidr-blocks.md)」を参照してください。

   1. (オプション) アプリケーションが IPv6 アドレスを使用して通信する場合は、**[IPv6 CIDR ブロック]**、**[Amazon が提供する IPv6 CIDR ブロック]** を選択します。

   1. **[テナンシー]** を選択します 。このオプションは、VPC で起動する EC2 インスタンスを、他の AWS アカウント と共有しているハードウェアで実行するか、または自分専用のハードウェアで実行するかを定義します。VPC のテナンシーとして `Default` を選択すると、この VPC で起動した EC2 インスタンスは、インスタンスの起動時に指定したテナンシー属性を使用します。詳細については、「Amazon EC2 ユーザーガイド」の「[定義済みのパラメータを使用したインスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)」を参照してください。**VPC のテナンシーで `Dedicated` を選択すると、インスタンスは常に、ユーザー専用のハードウェアで実行される、[専有インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html)として実行されます。

1. サブネットを設定する:

   1. **[アベイラビリティーゾーンの数]** で **[2]** を選択すると、2 つのアベイラビリティーゾーンでインスタンスを起動し、回復性を高めることができます。

   1. **[Number of public subnets]** (パブリックサブネットの数) で **2** を選択します。

   1. **[Number of private subnets]** (プライベートサブネットの数) は、**2** を選択します。

   1. サブネットのデフォルトの CIDR ブロックをそのまま使用したり、**[サブネット CIDR ブロックをカスタマイズ]** を開いて CIDR ブロックを入力したりすることができます。詳細については、「[サブネット CIDR ブロック](subnet-sizing.md)」を参照してください。

1. **[NAT ゲートウェイ]** は、デフォルト値の **[なし]** のままにします。

1. **[VPC エンドポイント]** は、デフォルト値の **[S3 ゲートウェイ]** のままにします。S3 バケットにアクセスしない限り効果はありませんが、この VPC エンドポイントの有効化にコストはかかりません。

1. **[DNS オプション]** で、両方のオプションを選択したままにします。これにより、ウェブサーバーは、パブリック IP アドレスに対応するパブリック DNS ホスト名を受け取ります。

1. **[Create VPC（VPC の作成）]** を選択します。

## 2. アプリケーションをデプロイします
<a name="deploy-web-database-servers"></a>

開発環境またはテスト環境でのウェブサーバーおよびデータベースサーバーをテスト済みで、アプリケーションを本番環境にデプロイするために使用するスクリプトまたはイメージを作成済みであることが理想的です。

ウェブサーバーには EC2 インスタンスを使用できます。EC2 インスタンスをデプロイするには、さまざまな方法があります。例えば、次のようになります。
+ [Amazon EC2 インスタンス起動ウィザード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/ecs/)

可用性を高めるには、[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/) を使用して複数のアベイラビリティーゾーンにサーバーをデプロイし、アプリケーションに必要な最小限のサーバー容量を維持します。

[Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/) を使用すると、トラフィックをサーバー全体に均等に分散できます。Auto Scaling グループにロードバランサーをアタッチできます。

データベースサーバーには EC2 インスタンスを使用するか、目的別データベースタイプのいずれかを使用できます。詳細については、「[AWS のデータベース: 選択方法](https://docs.aws.amazon.com/documentation/latest/databases-on-aws-how-to-choose/)」を参照してください。

## 3. 設定をテストする
<a name="test-web-database-servers"></a>

アプリケーションのデプロイが完了したら、それをテストできます。アプリケーションが想定どおりのトラフィックを送受信できない場合は、Reachability Analyzer を使用してトラブルシューティングを行います。例えば、Reachability Analyzer は、ルートテーブルやセキュリティグループの設定上の問題を特定できます。詳細については、「[Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/)」(到達可能性アナライザーガイド) を参照してください。

## 4. クリーンアップ
<a name="clean-up-web-database-servers"></a>

不要になった設定は、削除できます。VPC を削除する前に、インスタンスを終了し、ロードバランサーを削除する必要があります。詳細については、「[VPC の削除](delete-vpc.md)」を参照してください。