AWS VPC とアプリケーション用サブネットの作成

はじめに

荷物配送アプリケーションでは、公開サービスと内部ワーカーに別々のアドレス範囲が必要です。VPC を作成し、重複しない 2 つのサブネットを異なるアベイラビリティーゾーンに配置して、AWS View でアドレス計画を確認します。

AWS CLI のコマンド実行とリソース ID の読み取りに慣れていることが前提です。CLI はこの新しい環境向けに設定済みです。最後に、自分で作成したリソースだけを削除します。

認定試験との関連

この実験では、次の試験トピックを実践します。

Cloud Practitioner (CLF-C02) · タスク 3.2 と 3.5：VPC とサブネットの構成要素、およびリージョンとアベイラビリティーゾーンの関係。
Solutions Architect – Associate (SAA-C03) · タスク 3.4：サブネット階層の基本的な配置と重複しない IP アドレス計画。
CloudOps Engineer – Associate (SOA-C03) · タスク 5.1：VPC とサブネットの基本設定。

配送用 VPC の作成

このステップでは、アプリケーション全体のアドレス範囲を選び、その VPC を作成します。

Virtual Private Cloud（VPC）は、1 つの AWS リージョン内のリソース向けの隔離されたネットワークです。CIDR ブロックはサブネットが使用できるアドレスを定義します。IPv4 CIDR 表記は開始アドレスとプレフィックス長の組み合わせです。10.20.0.0/16 は 10.20.0.0 から 10.20.255.255 を含みます。プレフィックスの数値が小さいほどアドレス用のビットが多いため、/16 は /24 より広い範囲です。

準備済みの Terminal でコマンドを実行し、その隣の AWS View タブをクリックします。この画面は CLI と同じリソース状態を読み取り、作成したネットワークリソースを表示します。作業中は両方を使える状態にしてください。

作業ディレクトリに移動します：

cd /home/labex/project

変更前に既存の VPC 一覧を確認します。--query は ID と CIDR フィールドを選択し、--output table は比較しやすい表にします：

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

参照用ネットワークは 10.99.0.0/16 を使用しています。他の既存 VPC が表示される場合もあります。これらを変更せず、自分の 10.20.0.0/16 ネットワークを作成して最後に削除します。

EC2 コマンドグループには VPC のネットワーク操作が含まれます。--cidr-block は範囲を指定し、--tag-specifications は作成時に Name と Project タグを付けます。引用符により、角括弧とカンマを含む値を 1 つの引数として渡します。

シェルの $(...) はコマンドを実行して出力を取り込みます。VPC_ID に代入すると、後続のコマンドで使う VPC ID を保存できます。--query 'Vpc.VpcId' --output text はその ID だけを返します：

VPC_ID=$(aws ec2 create-vpc \
  --cidr-block 10.20.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=delivery-network},{Key=Project,Value=parcel}]' \
  --query 'Vpc.VpcId' \
  --output text)

出力を取り込むコマンドは結果を表示しません。保存した ID でリソースを読み直します。"$VPC_ID" はその値を 1 つの引数として展開します：

aws ec2 describe-vpcs \
  --vpc-ids "$VPC_ID" \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock,State:State}' \
  --output table

CIDR は 10.20.0.0/16、状態は available です。AWS View に同じ CIDR の delivery-network が表示され、アプリケーション用サブネットはまだありません。保存した ID を保持するため、この Terminal を開いたままにしてください。

公開サービス用サブネットの追加

このステップでは、VPC 内に小さなアドレス範囲を割り当て、アベイラビリティーゾーンに配置します。

サブネットは VPC のアドレス範囲の一部です。各サブネットは、そのリージョンの 1 つのアベイラビリティーゾーン（AZ）にのみ属します。VPC 自体はリージョンにまたがります。us-east-1a のような AZ 名はサブネット内のリソースの配置先を示します。

将来の公開サービス用に 10.20.1.0/24 を確保します。これは 10.20.1.0 から 10.20.1.255 を含み、10.20.0.0/16 の内側にあります。通常の IPv4 サブネットでは AWS が先頭 4 個と末尾 1 個のアドレスを予約するため、この /24 には割り当て可能なアドレスが 251 個あります。予約済みアドレスをワークロードに割り当てないでください。

利用可能な AZ 名を調べます。リージョンは環境の起動時に設定されています：

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].{Zone:ZoneName,State:State}' \
  --output table

このサブネットには us-east-1a、次には us-east-1b を使用します。--vpc-id は親ネットワーク、--availability-zone は配置先を選びます。削除用に新しいサブネット ID を保存します：

PUBLIC_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-public},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

親ネットワーク、範囲、AZ を読み直します：

aws ec2 describe-subnets \
  --subnet-ids "$PUBLIC_SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

VPC ID は保存した ID と一致し、範囲は 10.20.1.0/24、AZ は us-east-1a です。AWS View はこのサブネットを delivery-network 内に表示します。

delivery-public という名前は予定する用途を表しています。名前だけではパブリックサブネットになりません。次の実験で設定するインターネットゲートウェイへのルートも必要です。

ワーカー用の独立したサブネットの追加

このステップでは、内部ワーカーに重複しない専用サブネットを与え、完成した計画を比較します。

同じ VPC の 2 つのサブネットは重複できません。ワーカーに 10.20.2.0/24 を与えると、10.20.1.0/24 と別の範囲になります。どちらも VPC の /16 内です。

このサブネットを us-east-1b に配置し、1 つの VPC が異なる AZ のサブネットを含むことを確認します。これは配置の説明であり、AZ 間で冗長化したアプリケーションをまだデプロイしていません。

PRIVATE_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.2.0/24 \
  --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-private},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

サーバー側フィルターで、自分の VPC のサブネットだけを選びます。Name=vpc-id,Values=... の Name はフィルター、Values は一致させる VPC ID を指定します：

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[].{ID:SubnetId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

2 行の結果は次の計画を示します。生成 ID と行の順序は変わることがあります：

用途	CIDR	アベイラビリティーゾーン
公開サービス	`10.20.1.0/24`	`us-east-1a`
内部ワーカー	`10.20.2.0/24`	`us-east-1b`

重複の境界を確認するため、10.20.1.128/25 の追加を試します。この小さな範囲はすでに delivery-public 内にあるため、同じ VPC の別サブネットにはできません：

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.128/25 \
  --availability-zone us-east-1a

想定するエラーには InvalidSubnet.Conflict が含まれます。3 つ目のサブネットは作成されません。作成済みの有効な 2 つの /24 範囲を保持してください。

AWS View で同じ範囲と AZ を比較します。どちらのサブネットにもまだインターネットルートはありません。別々の範囲により、後続の実験でルーティングとアクセスルールを個別に適用できます。

配送用 VPC に異なる AZ の重複しない 2 つのサブネットが表示される

結果の例：どちらのサブネット CIDR も VPC の範囲内にあり、それぞれの AZ が表示されます。環境によってリソース ID は異なります。

練習用ネットワークの削除

このステップでは、既存の参照用ネットワークを保持したまま、自分の 2 つのサブネットと VPC を削除します。

リソースには依存関係があります。自分のサブネットが残る VPC は削除できません。保存したサブネット ID だけを削除します。成功した削除コマンドには出力がありません：

aws ec2 delete-subnet --subnet-id "$PUBLIC_SUBNET_ID"

aws ec2 delete-subnet --subnet-id "$PRIVATE_SUBNET_ID"

空になった VPC を削除します：

aws ec2 delete-vpc --vpc-id "$VPC_ID"

変更できるタグで削除を判断せず、完全な VPC 一覧を再度読み取ります：

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

10.20.0.0/16 の VPC はありません。参照用の 10.99.0.0/16 と他の既存ネットワークは残ります。一覧取得の失敗は削除成功の証拠になりません。AWS View にはアプリケーション用 VPC がないことが表示されます。

このステップの完了チェックを実行してください。

次の実験は、独自の準備済みアプリケーションを持つ新しい環境で始まります。インターネットゲートウェイ、ルート、公開アドレスによって外部リクエストがアプリケーションに届く仕組みを学びます。

まとめ

VPC のアドレス範囲を作成し、重複しない 2 つのアプリケーション用サブネットに分割して、それぞれを AZ に配置しました。CLI と AWS View で親子関係を確認し、自分の練習用ネットワークだけを削除しました。

次は「パブリックサブネットをインターネットに接続する」で、アドレス計画を動作するアプリケーション経路に変えます。

アプリケーション用サブネットを持つ VPC の作成