Amazon SAA-C03: ネットワーキングと接続性 — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

VPC設計とCIDR計画

すべてのVPCはCIDRブロックから始まり、作成時に行われるその選択は、ピアリング、Transit Gatewayアタッチメント、ハイブリッド接続に後続の影響を及ぼします。プライマリCIDRは/16から/28の間で、RFC 1918の空間から選択する必要があり、ピアリング、Transit Gateway経由でのルーティング、またはDirect ConnectやVPN経由で接続する予定のどのネットワークとも重複してはなりません。CIDRの重複は、ハイブリッド設計が破綻する最も一般的な原因です。なぜならAWSはアドレス空間を共有する2つのネットワーク間でルーティングできず、Transit Gatewayはアタッチメントを受け入れますが、伝播が失敗するか、トラフィックをサイレントにブラックホール化するためです。

VPCのアドレス空間が枯渇した場合でも、再構築する必要はありません。最大4つのセカンダリIPv4 CIDRブロックをアタッチできます（さらに、より広いプールからの追加範囲を加えてデフォルトで合計5つまでとなり、クォータの引き上げによって拡張可能です）。セカンダリブロックは、同じRFC 1918の範囲、または100.64.0.0/10の共有アドレス空間から取得できます。これは、10.0.0.0/8が枯渇した場合や、キャリアグレードNATの空間が必要な場合に便利です。セカンダリCIDRを使用すると、既存のワークロードのIPアドレスを再割り当てすることなく、拡張（EKSのポッドネットワーク、新しいティアなど）のために新しいサブネットを切り出すことができます。

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

堅牢な設計では、将来の成長のために/17または/18を予約し、サブネットの境界をアベイラビリティーゾーンに合わせ（AZごと、ティアごとに/20を割り当てるのが一般的なパターンです）、インターフェイスエンドポイント、NATゲートウェイ、ロードバランサーによって消費されるENIのための余裕を残します。

VPCはリージョナルな構成要素であり、それぞれが単一のAZに紐づけられたサブネットに分割されます。「パブリック」と「プライベート」の区別は純粋にルーティングの決定事項です。パブリックサブネットにはInternet Gatewayを指すルート0.0.0.0/0 → igw-xxxxがあり、一方、プライベートサブネットにはデフォルトルートがないか、0.0.0.0/0がNATデバイスを指します。パブリックサブネット内のインスタンスがインバウンドで到達可能であるためには、パブリックIPまたはElastic IPも必要です。IGWはプライベートIPとパブリックIPの間で1:1のNATを実行します。

NATゲートウェイ、NATインスタンス、およびIPv6 Egress

プライベートサブネットからのアウトバウンド専用IPv4インターネットアクセスには、NATゲートウェイが適切なプリミティブです。マネージドなNATゲートウェイは、自動的に45〜100 Gbpsまでスケールし、ユニークな宛先ごとに55,000の同時接続をサポートし、AWSによってパッチが適用され、そのAZ内で高可用性を備えています。NATゲートウェイは、時間単位および処理されたGB単位で課金されます。

NATインスタンス（送信元/送信先チェックが無効化された自己管理型のEC2）はレガシーです。これらは単一インスタンスのスループットに制約され、フェイルオーバーのためにスクリプト化する必要があり、持続的な負荷の下ではボトルネックになります。これらが適しているのはカスタムフィルタリングのような非典型的なニーズの場合のみであり、その場合でさえ、通常はGateway Load Balancerアプライアンスの方が望ましいです。

標準的な高可用性パターンは、AZごとに1つのNATゲートウェイをそのAZのパブリックサブネットに配置し、AZごとに個別のプライベートルートテーブルを用意して、そのデフォルトルートがローカルのNATゲートウェイを指すようにする構成です。

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

AZ間で共有される単一のNATゲートウェイをデプロイするのは、2つの理由から陥りやすい罠です。第一に、それは単一障害点です。あるAZで障害が発生すると、すべてのプライベートサブネットのEgressがダウンします。第二に、他のAZのインスタンスからのすべてのパケットがAZの境界を越えるため、NATゲートウェイの処理費用に加えて、AZ間のデータ転送料金（現在は片道$0.01/GB）が発生します。数百TBのEgressを行うワークロードでは、この料金は追加のNATゲートウェイのコストをはるかに上回ります。2つ目のよくある設定ミスは、NATゲートウェイ自体をプライベートサブネットに配置することです。その場合、IGWへのパスがなく、機能しません。

IPv6の場合、すべてのアドレスがグローバルにルーティング可能であるため、NATは不要であり、利用もできません。未承諾のインバウンドをブロックしつつ、アウトバウンド専用のIPv6を許可するには、Egress-Onlyインターネットゲートウェイをアタッチし、プライベートサブネットから::/0をそのゲートウェイにルーティングします。通常のIGWは双方向であり、インスタンスを外部に公開してしまいます。

VPCエンドポイント：ゲートウェイ型 vs インターフェイス型

VPCエンドポイントは、VPCとAWSサービス間のトラフィックをAWSバックボーン上に維持し、インターネット、NATゲートウェイ、インターネットゲートウェイを完全に回避します。根本的に異なる2つの実装があり、この2つを混同することは、最も一般的なアーキテクチャ上の誤りの1つです。

ゲートウェイエンドポイントは、Amazon S3とDynamoDBのためだけに存在します。これはルートテーブルのエントリであり、エンドポイント自体をターゲットとするプレフィックスリスト（例：us-east-1のS3の場合はpl-63a5400a）です。ENIもDNSの変更もなく、時間料金もかからず、セキュリティグループもありません（アクセスはルートテーブルとエンドポイントポリシーによって制御されます）。ルートベースであるため、VPC内のリソースに対してのみ機能します。Direct Connect経由でS3にアクセスするオンプレミスネットワークは、これを使用できません。

インターフェイスエンドポイント（AWS PrivateLink）は、サブネットに配置されるプライベートIPを持つENIであり、AZごとの時間料金とGBあたりの料金が課金されます。SQS、KMS、Secrets Manager、ECR、STS、SSM、SNSなど、他のほぼすべてのサービス、およびエンドポイントサービスとして公開されているサードパーティサービスで機能します。インターフェイスエンドポイントはプライベートDNSをサポートしており、これによりパブリックサービスのホスト名がオーバーライドされ、エンドポイントのプライベートIPに解決されるため、SDKやCLIでコードの変更は不要です。ENIベースであるため、セキュリティグループが適用されます。

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

コストのロジックは重要です。プライベートサブネットからパブリックなAWSサービスへのトラフィックは、デフォルトでNATゲートウェイを経由し、約$0.045/GBの料金がかかります。コンテナ化されたワークロードが1日あたり1TBをS3にプッシュする場合、NATゲートウェイパスとゲートウェイエンドポイントの差は月額数千ドルになります。インターフェイスエンドポイントは、大規模なNAT egressを置き換える場合や、コンプライアンス上インターネットルーティングが禁止されている場合に価値があります。

罠：ゲートウェイエンドポイントにセキュリティグループをアタッチすること（ENIがないため）。ゲートウェイエンドポイントがオンプレミスから到達可能だと想定すること（実際は不可。インターフェイスエンドポイントを使用するか、EC2 → S3ゲートウェイエンドポイント → 別のDXパスというハイブリッドパターンを使用する）。インターフェイスエンドポイントでプライベートDNSを無効にして、未修正のSDKコールが機能すると期待すること（これらはインターネット経由でパブリックエンドポイントにアクセスしてしまい、エンドポイントの意味が全くなくなる）。ゲートウェイエンドポイントを作成したものの、プライベートサブネットのルートテーブルを関連付けるのを忘れること（トラフィックは静かにパブリックパスを使い続ける）。ゲートウェイエンドポイントを持たないサービス（例：KMS）にゲートウェイエンドポイントを使おうとすること（対象はS3とDynamoDBのみ）。

VPC間接続：ピアリング vs. Transit Gateway

VPCピアリングは、2つのVPC間（同一または別アカウント、同一または別リージョン）の1対1の、推移的でないレイヤー3接続です。トラフィックはAWSバックボーンを経由し、帯域幅のボトルネックはなく、時間料金もかかりません。支払うのはクロスAZまたはリージョン間のデータ転送料金のみです。ピアリングには2つの制約があります。(1) 推移的ではないこと。つまりAがBと、BがCとピアリングしていても、AはBを経由してCに到達することはできません。(2) CIDR範囲が重複してはならないこと。N個のVPCをフルメッシュで接続するには、N(N-1)/2個のピアリング接続と、それぞれの双方向でのルートテーブル編集が必要です。30個のVPCでは、435個のピアリングが必要になります。ピアリングが数百のVPCにスケールすると期待するのは罠です。

Transit Gateway (TGW) は、リージョン単位のクラウドルーターです。各VPC、VPN、またはDirect Connectゲートウェイはアタッチメントとなり、TGWルートテーブルがどのアタッチメントがどのプレフィックスに到達できるかを制御します。これにより、O(n²)のメッシュ構成がO(n)のアタッチメント構成に変わり、セキュリティVPCがすべてのVPC間トラフィックを検査するファイアウォールをホストする、ハブアンドスポーク型トポロジを可能にします。TGWは推移的ルーティングをサポートし、VPNおよびDirect Connectゲートウェイのアソシエーションをネイティブに終端し、Resource Access Managerを介してAWS Organizations全体で共有できるため、中央のネットワークチームがルーティングを制御し、ワークロードアカウントがVPCを所有するという分担が可能です。TGWには、アタッチメントごとの時間料金と、処理されたデータ量に応じた約$0.02/GBの料金が加わります。

リージョン間接続の場合、TGWピアリングは、異なるリージョンのTGWをAWSグローバルバックボーン上で暗号化されたトラフィックで接続します。リージョンごとに1つのTGWを配置し、メッシュまたはハブ設計でピアリングします。これにより、リージョン間VPCピアリングで再び発生する、リージョンをまたいだN二乗問題を回避できます。

ルートテーブルの衛生管理が、ここでのサイレントキラーです。ピアリング接続やTGWアタッチメントを作成しただけでは何も起こらず、両方のVPCのサブネットルートテーブルにpcx-またはtgw-ターゲットを指す明示的なCIDRルートが追加され、セキュリティグループがそのトラフィックを許可するまでは機能しません。接続が静かに失敗する場合、その原因はほぼ常に、ルートの欠落か、間違った送信元CIDRを参照しているセキュリティグループの暗黙の拒否にたどり着きます。

ハイブリッド接続: Site-to-Site VPN と Direct Connect の比較

Site-to-Site VPNとDirect Connectのどちらを選択するかは、導入の速さと組み込みの暗号化を優先するか、一貫した低レイテンシー、専用帯域幅、予測可能なスループットを優先するかのトレードオフになります。

Site-to-Site VPNは、カスタマーゲートウェイ（オンプレミスルーター）とVirtual Private GatewayまたはTransit Gatewayの間に2つのIPsecトンネルを確立します。各トンネルの上限は約1.25 Gbpsです。トラフィックはネットワーク層で暗号化され、TLSと組み合わせることで、ネットワーク層とセッション層での暗号化要件を満たします。公衆インターネットを経由するため、レイテンシーとジッターは変動しますが、数分で利用可能になり、コストは1時間あたり数セントです。接続がすぐに必要な場合、帯域幅がそれほど大きくない場合、またはバックアップパスとして使用します。

**Direct Connect (DX)**は、オンプレミスルーターからAWS Direct Connectロケーションへの専用ファイバー接続（1、10、または100 Gbps）を提供します。公衆インターネットをバイパスするため、一貫したレイテンシーとより高いスループットを実現します。DXの下り（egress）料金はインターネットの下り料金よりも大幅に安価であり、これは1日に数百ギガバイトを移動する場合に重要です。プロビジョニングには、クロスコネクト、LOA、BGP設定など、数週間かかります。

ここには主に2つの落とし穴があります。第一に、Direct Connect単体ではトラフィックを暗号化しません。プライベート回線は暗号技術で保護されたチャネルではありません。DX上で暗号化要件を満たすには、その上にSite-to-Site VPNを重ねるか、サポートされている専用ポートでLayer-2暗号化のためにMACsecを使用します。第二に、素のDX接続だけでは、複数のVPCにルーティングできません。プライベートVIFは、単一のVPCにアタッチされた単一のVirtual Private Gatewayに接続します。多くのVPC（特に複数のアカウントやリージョンにまたがる場合）に接続するには、トランジットVIFを介してTransit Gatewayに関連付けられたDirect Connect Gatewayを使用し、各VPCをTGWにアタッチします。

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

標準的な本番環境のパターンでは、2つのDXロケーションにある2つのDX接続を、別々のカスタマールーターに終端させ、Site-to-Site VPNを自動BGPフェイルオーバーとして使用します。BGPのAS-path prependingまたはMEDが、DXが稼働している間はトラフィックをDXに誘導します。DXが失敗すると、BGPはDXルートを取り下げ、VPNが引き継ぎます。

ロードバランサー: ALB、NLB、GWLB

ALBはレイヤー7であり、HTTPセマンティクス（ホストおよびパスベースのルーティング、WebSocket、リダイレクト、Cookieベースのスティッキーセッション）を理解します。HTTPでないもの（MQTT、生のTCP、UDP経由のsyslog、SMTPなど）には不適切なツールです。ALBは、時間とともに変化するIPを持つDNSベースのアドレッシングを使用するため、Elastic IPを割り当てることはできません。クライアントが宛先IPをホワイトリストに登録する場合、ALB単体では不適切です。EIPを持つNLBを使用するか、ALBの前にGlobal Acceleratorの2つの静的エニーキャストIPを配置します。「ALBのDNSを一度解決して、そのIPをファイアウォールルールに固定する」というのは罠です。AWSは予告なくIPを変更します。

NLBはレイヤー4であり、毎秒数百万のフローにスケールします。デフォルトで真のクライアント送信元IPを保持し（ターゲットには実際のクライアントが見えます）、AZごとに静的なElastic IPの割り当てをサポートし、高スループットのTCP/UDPワークロードを処理します。歴史的に、NLBはロードバランサー自体にセキュリティグループをサポートしていませんでした。クライアントのCIDRをターゲットのSGで直接許可する必要がありました。AWSは2023年にオプションのNLBセキュリティグループを追加しましたが、多くの設計ではまだ従来の動作を前提としています。

標準的な公開向けパターンは次のとおりです。

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

バックエンドでソースとしてCIDRではなくALBのセキュリティグループを参照することは、最小権限のパターンであり、ALBのENIから発信されるヘルスチェックトラフィックを自動的にカバーします。ALB自体は、少なくとも2つのAZのパブリックサブネット（IGWへのルートを持つ）に配置され、ターゲットはプライベートサブネットに配置されます。インターネット向けのALBをプライベートサブネットに配置するのは、典型的な設定ミスです。ターゲットの登録は成功しますが、クライアントは到達できません。

Gateway Load Balancer (GWLB)は、サードパーティの仮想アプライアンス（ファイアウォール、IDS/IPS、DPI）を透過的に挿入するために専用設計されています。レイヤー3で動作し、UDP 6081上のGENEVEカプセル化を使用してすべてのIPプロトコルを転送します。トラフィックはGWLBエンドポイント（GWLBe）（サブネット内に配置され、ルートテーブルにターゲットとして表示されるインターフェイスエンドポイント）を介してGWLBに到達します。

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

エンドポイントはPrivateLink経由でパケットをGWLBに転送し、GWLBはフローの維持（stickiness）を使用してアプライアンスフリート全体に負荷分散します。これにより、フローの双方向の通信が同じアプライアンスに到達します。ハブアンドスポーク型のインスペクション設計では、スポークVPCはTGWにアタッチされ、そのルートテーブルは東西（east-west）トラフィックをインスペクションVPC（GWLBとアプライアンスを含む）経由で強制的に通過させてから、宛先VPCに到達させます。イングレスインスペクションでは、IGWからウェブ層へのトラフィックをまずGWLBe経由にリダイレクトするエッジルートテーブルを使用します。

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

これは、集中型、クロスアカウントのインスペクションに対する正しい答えです。EC2、カスタムルートテーブルのハック、フェイルオーバースクリプトで自作することは、GWLBがネイティブに提供する機能を再発明するようなものです。

コンシューマーからプロバイダーへのサービスのためのPrivateLink

PrivateLinkは、AWSサービスのインターフェイスエンドポイントを支えるだけでなく、サードパーティや他のAWSアカウントによって公開されたサービスへのプライベート接続を可能にします。プロバイダーはサービスをNLBの背後に配置し、VPCエンドポイントサービスを作成します。コンシューマーは、それをターゲットとするインターフェイスエンドポイントを自身のVPC内に作成します。

接続の方向性に関する重要なルール：**接続は常にコンシューマーからプロバイダーに向かって開始されます。**プロバイダーはコンシューマーのVPCへの接続を開始することはできません。トラフィックはインターネットを経由せず、特定のターゲットサービスのみが到達可能であり（ピアリングのようにプロバイダーVPC全体ではない）、両側でエンドポイントのIPのみが公開されるため、CIDRの重複問題は発生しません。これは、コンシューマーVPCにIGW、VPN、Direct ConnectがないSaaSやベンダーデータベースへのアクセスパターンに対する標準的な解決策です。VPCピアリングはCIDR範囲全体を公開し、重複しないIPを必要とします。TGWアタッチメントは広範にルーティングします。インターネット経由のパブリックAPIはプライベートではありません。

Global AcceleratorとRoute 53

AWS Global Acceleratorは、世界中のAWSエッジロケーションからアドバタイズされる2つの静的なエニーキャストIPv4アドレスを割り当てます。クライアントのトラフィックは最寄りのエッジに入り、AWSバックボーンを経由して、最も近い正常なリージョンエンドポイント（ALB、NLB、EIP、またはEC2）に到達します。これにより、2つの問題が一度に解決されます。ALBの前に静的IPを配置すること（ホワイトリスト登録の問題を解決）、そしてパブリックインターネットをショートカットすることで世界中に分散したユーザーのジッター/レイテンシーを削減することです。これは、（コンテンツをキャッシュする）CloudFrontが適用できないオリジンへの、キャッシュ不可能なTCP/UDPトラフィックを高速化します。

Route 53は異なる問題、つまりDNSレベルのトラフィックステアリングを解決します。Global Acceleratorはデータプレーン自体に影響を与えますが、Route 53はDNS解決にのみ影響を与え、その後TCP接続は解決されたIPがどこにあってもそちらに向かいます。この2つは頻繁に組み合わせて使用されます。Route 53のエイリアスレコードが、リージョンALBの前段に配置されたGlobal Acceleratorを指す、といった構成です。

Route 53のルーティングポリシー：

レイテンシーと位置情報はよく混同されます。レイテンシーはユーザーが体感するRTTを最小化し、位置情報はレイテンシーに関係なくデータ所在地を強制します。マルチリージョンのフェイルオーバーには、プライマリに対するヘルスチェックが必要です。エイリアスレコードはAWS固有のもので、クエリ料金なしでALB、NLB、CloudFront、S3ウェブサイト、API Gatewayのエンドポイントに直接解決され、CNAMEとは異なり、ゾーンエイペックスで機能します。

Route 53 Resolverは、VPC内のDNSクエリに対して.2アドレス（VPC CIDRのベース + 2）を介して応答します。ハイブリッドDNSの場合、インバウンドエンドポイントはオンプレミスのリゾルバーがAWSのプライベートホストゾーンにクエリできるようにし、アウトバウンドエンドポイントは転送ルールを用いてVPCリソースがオンプレミスの名前を解決できるようにします。これらがないと、EC2インスタンスはcorp.internalを解決できず、オンプレミスのサーバーはdb.prod.internalを解決できません。これは、アプリケーションが環境をまたいだ名前解決を開始したときに初めて表面化する、見過ごしやすい問題です。インターフェイスエンドポイントでは、SDKコールがエンドポイントのENIに到達するためにプライベートDNSの有効化が必要です。これがないと、コールは依然としてインターネット経由でパブリックエンドポイントに到達してしまい、目的を達成できません。

セキュリティグループ、NACL、最小権限

セキュリティグループはステートフルであり、戻りのトラフィックは自動的に許可され、ENIレベルで機能します。NACLはステートレスであり、サブネットの境界で機能します。NACLのTCPルールには、明示的なインバウンドおよびアウトバウンドルールが必要です。クライアントはエフェメラルポート範囲からソースポートを選択するため、戻り方向のルールではポート1024–65535を許可する必要があります（Linuxはデフォルトで32768–60999を使用しますが、より広い範囲はWindowsや他のスタックをカバーします）。このエフェメラルポートの戻りルールを忘れることは、SYNは完了するもののレスポンスでハングする接続の典型的な原因です。

ティア間の最小権限のためには、セキュリティグループのルールはCIDRではなく、他のセキュリティグループIDを参照すべきです。これにより、Auto Scalingに合わせてスケールし、脆弱なIPホワイトリストを回避できます。

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACLは、大まかな影響範囲の制御手段であり、セキュリティグループの代替にはなりません。「多層防御のため」にセキュリティグループの変更を伴わずにNACLを厳格化すると、ステートレスな戻りトラフィックがサイレントにドロップされるため、NATゲートウェイ経由のyum/aptアップデートのようなアウトバウンドで開始されるフローが一般的に壊れます。最終的に到達可能性を決定するのはルートテーブルです。許可的なセキュリティグループであっても、ルートテーブルに宛先のエントリがなければトラフィックを配信できません。逆に、ゲートウェイエンドポイントは、S3プレフィックスリストのルートがワークロードをホストするサブネットのルートテーブルに実際にインストールされている場合にのみ有効です。

意思決定リファレンス

← データ転送と移行 · すべてのドメイン · コンテンツ配信、エッジ、パフォーマンス最適化 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →