AWS Solutions Architect · レッスン

VPC アーキテクチャと CIDR ブロック

適切な CIDR 範囲で VPC を設計し、アベイラビリティーゾーンにまたがってパブリックサブネットとプライベートサブネットに分割します。

「VPC アーキテクチャと CIDR ブロック」はCoddyKit上の無料AWS Solutions Architectレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

VPC とは

Amazon Virtual Private Cloud（VPC）は、AWS Region 内に構築し、管理できる論理的に分離されたプライベートネットワークです。すべての AWS アカウントには、各 Region にデフォルト VPC（CIDR 172.31.0.0/16）が用意されていますが、本番環境のアーキテクチャでは必ずカスタム VPC を使用します。VPC は Region 内のすべての Availability Zone にまたがり、IP アドレス、サブネット、ルートテーブル、インターネットゲートウェイ、セキュリティを完全に制御できます。VPC 内のリソースは、明示的に接続を構成しない限り、他の VPC やインターネットから分離されています。

# Create a custom VPC
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=production-vpc}]'

CIDR ブロック：IP アドレス範囲

CIDR（Classless Inter-Domain Routing）ブロックは、x.x.x.x/prefix 形式を使用して、VPC またはサブネットの IP アドレス範囲を定義します。プレフィックス長によって範囲内の IP アドレス数が決まり、/16 は 65,536 個、/24 は 256 個、/28 は 16 個です（AWS におけるサブネットサイズの最小値）。VPC では、AWS は /16（最大）から /28（最小）までの CIDR ブロックを許可しています。VPC CIDR は、(1) 将来の VPN／Direct Connect 接続に備えてオンプレミスネットワークと重複せず、(2) 計画したサブネットに十分な大きさがあり、(3) プライベート RFC 1918 アドレス空間（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）を使用するように選択してください。

# Common VPC CIDR choices:
# 10.0.0.0/16   -> 65,534 usable IPs (largest common choice)
# 10.0.0.0/20   -> 4,094 usable IPs
# 10.0.0.0/24   -> 254 usable IPs (too small for most VPCs)

# AWS reserves 5 IPs in each subnet:
# x.x.x.0   Network address
# x.x.x.1   VPC router
# x.x.x.2   DNS server
# x.x.x.3   Future use
# x.x.x.255  Broadcast

サブネット：VPC の分割

サブネットは、1 つの Availability Zone 内に存在する VPC の IP アドレス範囲のセグメントです。サブネットは、パブリック（インターネットゲートウェイへのルートがある）またはプライベート（インターネットへの直接ルートがない）に分類されます。一般的な 3 層アーキテクチャのベストプラクティスは、少なくとも 3 つのサブネットティアを作成することです。パブリック（ロードバランサー、踏み台ホスト）、private-app（EC2 インスタンス、ECS タスク）、private-data（RDS、ElastiCache）を用意し、各ティアを少なくとも 2 つの AZ に分散して高可用性を実現します。

# Create a public subnet in AZ-a
aws ec2 create-subnet \
  --vpc-id vpc-12345678 \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-1a}]'

# Create a private subnet in AZ-a
aws ec2 create-subnet \
  --vpc-id vpc-12345678 \
  --cidr-block 10.0.10.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-app-1a}]'

マルチ AZ VPC CIDR レイアウトの設計

2 つの AZ と 3 つのティアにまたがる CIDR 10.0.0.0/16 の VPC では、次のような CIDR 設計が一般的です。Public AZ-a：10.0.1.0/24、Public AZ-b：10.0.2.0/24、Private-App AZ-a：10.0.10.0/24、Private-App AZ-b：10.0.11.0/24、Private-Data AZ-a：10.0.20.0/24、Private-Data AZ-b：10.0.21.0/24。このレイアウトでは、CIDR の設計全体をやり直さなくても、AZ-c のサブネット（10.0.3.0/24、10.0.12.0/24、10.0.22.0/24）を追加できます。常に将来の拡張を考慮して設計してください。

各サブネットの予約済み IP

AWS は、すべてのサブネットで最初の 4 つと最後の IP アドレスを予約します。10.0.1.0/24 サブネットの場合、10.0.1.0（ネットワーク）、10.0.1.1（VPC ルーター）、10.0.1.2（DNS／DHCP）、10.0.1.3（将来の用途）、10.0.1.255（ブロードキャスト）が予約されます。/24 サブネットには合計 256 個の IP があり、5 個が予約されるため、使用可能なのは 251 個です。最小の /28 サブネットでは、16 個の IP から 5 個を除いた 11 個が使用可能です。これは、デプロイする予定のリソース数（EC2 インスタンス、VPC 内の Lambda 関数など）に合わせてサブネットのサイズを決める際に重要です。

VPC のセカンダリ CIDR ブロック

既存の VPC は再作成せずに、最大 4 つのセカンダリ CIDR ブロックを追加できます。これは、プライマリ CIDR を使い切った場合（すべてのサブネットが埋まっている場合）や、Kubernetes の Pod ネットワーキングなど特定の用途のために、別の RFC 1918 範囲からアドレス空間を追加する必要がある場合に便利です。セカンダリ CIDR には、重複する CIDR は追加できない、RFC 1918 に準拠しない一部のパブリック範囲は使用できないなど、いくつかの制約があります。セカンダリ CIDR が必要になる可能性を最小限に抑えるため、VPC の CIDR サイズは事前に慎重に計画してください。

# Add a secondary CIDR to an existing VPC
aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-12345678 \
  --cidr-block 10.1.0.0/16

VPC Peering：VPC の接続

VPC Peering は、2 つの VPC 間にプライベートネットワーク接続を確立し、それぞれのリソースがプライベート IP アドレスを使用して通信できるようにします。ピアリングされた VPC は、同じアカウント、異なるアカウント、さらには異なるリージョン（リージョン間ピアリング）に配置できます。要件：2 つの VPC の CIDR は重複していなければなりません。制限事項：ピアリングは推移的ではありません。つまり、VPC-A が VPC-B とピアリングし、VPC-B が VPC-C とピアリングしていても、VPC-A は VPC-B を経由して VPC-C と通信できません。多数の VPC 間でフルメッシュ接続を構築する場合は、代わりにAWS Transit Gatewayを使用してください。

AWS Transit Gateway

AWS Transit Gateway (TGW) は、複数の VPC、VPN、Direct Connect 接続をつなぐ中央ネットワークハブ（クラウドルーター）として機能します。N 個の VPC でフルメッシュを構成するために N*(N-1)/2 個の VPC ピアリング接続を作成する代わりに、各 VPC と接続を Transit Gateway にアタッチし、そこで相互のトラフィックをルーティングします。TGW は、どのアタッチメント間で通信できるかを制御するルートテーブルをサポートしており、同じ TGW 上で本番 VPC と開発 VPC を分離するなど、ネットワークのセグメンテーションを実現できます。

VPC での DNS の有効化

VPC の名前解決は、2 つの DNS 設定で制御します。enableDnsSupport：true（デフォルト）の場合、VPC は AWS 提供の DNS リゾルバー 169.254.169.253、または VPC CIDR の 2 番目の IP アドレス（例：10.0.0.0/16 の場合は 10.0.0.2）を使用します。enableDnsHostnames：true の場合（カスタム VPC では有効化が必須で、デフォルト VPC ではデフォルトで有効）、VPC 内の EC2 インスタンスに ip-10-0-1-15.ec2.internal のような DNS ホスト名が付与されます。VPC 内で Route 53 Private Hosted Zones を機能させるには、両方を有効にする必要があります。

# Enable DNS support and DNS hostnames in a VPC
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-12345678 \
  --enable-dns-support '{"Value": true}'
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-12345678 \
  --enable-dns-hostnames '{"Value": true}'

VPC Flow Logs

VPC Flow Logs は、VPC を流れるネットワークトラフィックに関するメタデータ（送信元と宛先の IP、ポート、プロトコル、転送バイト数、トラフィックが許可されたか拒否されたかなど）を記録します。フローログは、CloudWatch Logs（Logs Insights でのクエリ用）またはS3（Athena での分析用）に発行できます。セキュリティフォレンジック（誰が何に接続したか）、トラフィック分析（帯域幅を大量に使用するフローの特定）、トラブルシューティング（接続が拒否された理由の確認）に非常に役立ちます。フローログは、VPC、サブネット、個々の ENI の各レベルで利用できます。

# Enable flow logs for a VPC, deliver to CloudWatch
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole

接続性の計画

VPC を作成する前に、将来必要となるすべての接続性を計画してください。オンプレミス接続（VPN または Direct Connect）：VPC の CIDR がオンプレミスのサブネットと重複しないようにします。VPC 間接続（ピアリングまたは Transit Gateway）：組織内のすべての VPC で重複しない CIDR を計画します。AWS サービスへのアクセス（S3、DynamoDB、SSM 用の VPC エンドポイントを使用し、インターネット経由のトラフィックを回避します）。また、サブネットのサイズについては、EKS Pod、Lambda 関数、Elastic Network Interfaces による IP アドレス消費に備えて、各サブネットに余裕を持たせてください。

クイックチェック

このレッスンで扱った AWS Solutions Architect (SAA-C03) の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、VPC はリージョン内で論理的に分離されたネットワークであり、CIDR ブロックで定義され、AZ 間のパブリックサブネットとプライベートサブネットに分割すること、AWS は各サブネットで 5 つの IP を予約するため、この減少を考慮して常にサブネットのサイズを決める必要があること、そしてVPC Peering と Transit Gateway は VPC をプライベートに接続するが、CIDR 範囲は重複していてはならないことを学びました。次は Internet Gateways と Route Tables について学びます。

よくある質問

「VPC アーキテクチャと CIDR ブロック」レッスンは無料ですか？

はい。「VPC アーキテクチャと CIDR ブロック」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「VPC アーキテクチャと CIDR ブロック」で何を学びますか？

適切な CIDR 範囲で VPC を設計し、アベイラビリティーゾーンにまたがってパブリックサブネットとプライベートサブネットに分割します。ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「VPC アーキテクチャと CIDR ブロック」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AWS Solutions Architectに戻る