Amazon ANS-C01: 自動化、IaCとネットワーク運用 — 学習ガイド

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

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

コアコンセプト

AWSにおけるネットワークのためのInfrastructure as Codeは、ネットワークトポロジー、セキュリティポリシー、ルーティングを宣言的なテンプレートと決定論的なライフサイクル操作に変換します。CloudFormationテンプレート（AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup）が望ましい状態をエンコードし、CloudFormation API（CreateStack, UpdateStack, DeleteStack, DescribeStacks, およびChangeSet操作）が変更をアトミックに適用します。ネストされたスタックとモジュール化されたテンプレートを使用して、ネットワークドメイン（共有サービス、アカウントごとのアプリケーションVPC、イングレス/エグレスゾーン）を分離し、StackSetsを使用してAWS Organizations全体に一貫したネットワークスタックを展開します。ドリフト検出（DetectStackDrift）と変更セットはガードレールを提供し、自動化が手動で行われたネットワーク変更を検出し、人間のレビューを要求できるようにします。

自動化は、CloudFormationがネイティブに表現できない部分や、ライフサイクルフックを必要とする部分もカバーしなければなりません。これには、アカウント間のリソース共有、オンプレミスとの統合、ホスト上のランタイム設定が含まれます。CloudFormationカスタムリソース（Lambdaによってバックエンド処理される）やCloudFormationモジュールは、CreateResourceShare（AWS RAM）などのAPIを呼び出してTransit Gatewayやサブネットを共有したり、Systems Manager（SSM）のSendCommandを呼び出してインスタンスに証明書やルーティングポリシーを注入したりできます。EKS内のKubernetesの場合、AWS Load Balancer ControllerはHelmを介してインストールされ、Serviceアノテーションを通じて管理されます。CloudFormationはAWS::EKS::Clusterやカスタムリソースを介してIAMロール、OIDCプロバイダー、HelmReleaseオブジェクトをプロビジョニングできますが、PodのIPとNLBターゲットグループのランタイムマッピングはコントローラーによって処理されます。

主要なサービスと設定

ネットワーク運用の自動化において繰り返し使用する主要なAWSサービスとAPIがあります。CloudFormation (CreateStack, UpdateStack, DetectStackDrift)、AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare)、AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute)、Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes)、AWS Lambda (CreateFunction, AddPermission, Invoke)、Systems Manager (PutParameter, SendCommand, CreateDocument)、そしてAWS Config (PutEvaluations, StartConfigurationRecorder)です。これらのサービスは、安全で監査可能なネットワーキングのための典型的な自動化スタックを形成します。

テンプレートと自動化を設計する際には、特定のリソース属性とコントローラーのアノテーションに注意を払ってください。ロードバランサーについては、正しいタイプと属性を選択します。TCPリスナーを持つNLBは、送信元IPを保持し、CreateLoadBalancer/ModifyTargetGroupAttributesとターゲットグループでの"proxy_protocol_v2.enabled"設定によりProxy Protocol v2をサポートします。ALB（Application Load Balancer）はTLSを終端し、クライアントIPのためにX-Forwarded-Forヘッダーを挿入し、HTTPSリスナーで設定するとgRPC/HTTP2をサポートします。EKSでは、service.beta.kubernetes.io/aws-load-balancer-type: “nlb"のようなアノテーションや、AWS Load Balancer ControllerのIngress/Serviceアノテーションを使用して、TLSパススルーと終端を制御し、Podへの直接ターゲティングのためにターゲットタイプをipに設定します。アカウント間の共有やマルチアカウントネットワークでは、AWS RAMを使用してTransit Gatewayを共有し、CloudFormation StackSetsを委任管理者ロールと組み合わせて、コンシューマーアカウントにアタッチメントとアクセスを作成します。

設計パターンとトレードオフ

一般的で対照的な2つのパターンは、Transit Gatewayによるハブアンドスポークと、AWS RAMによる共有VPCです。Transit Gatewayによるハブアンドスポークは、ルーティング、インスペクション、VPC間接続を一元化します。アタッチメントとルートテーブルがセグメンテーションを可能にし、RAMを使用してTGWを共有できるため、異なるアカウントが完全な所有権を移転することなくアタッチメントを作成できるため、スケールします。トレードオフは、ルート伝播とルートテーブルの制限です。Transit Gatewayのルートテーブルとアタッチメントの制限は計画を必要とし、ポリシーを強制しなければならない単一のポイント（複数のルートテーブルとAWS Network Firewallを使用してトラフィックを分離する）を生み出す可能性があります。共有VPC（AWS RAMによるVPC共有）は、ホストアカウントにサブネットを配置し、コンシューマーアカウントがそれらのサブネットにリソースを起動できるようにします。これにより、接続性のための中央集権的なセキュリティ制御が簡素化されますが、セキュリティグループの所有権とIAMの境界を慎重に管理する必要があるため、アカウントレベルの自律性が低下し、事業単位ごとのネットワーク分離が複雑になります。

イングレスとTLS終端については、エンドツーエンド暗号化の必要性と、スケールおよびクライアントIP保持の必要性とのバランスを取る必要があります。ロードバランサーでのTLS終端が必要な場合（WAF、証明書の一元管理、HTTPルーティングのため）、ALBが適切なツールです。ALBはX-Forwarded-Forを追加するため、アプリケーションログでクライアントIPをキャプチャでき、パスベースおよびホストベースのルーティングで複数のターゲットグループに振り分けることができます。ロードバランサーがトラフィックを復号してはならない真のエンドツーエンドTLSまたはmTLSが必要な場合は、NLBをTCPモードで使用してTLSをバックエンドのエンドポイント（Podまたはインスタンス）にパススルーし、Kubernetesでtarget typeをipに、externalTrafficPolicyをLocalに設定して送信元IPを保持します。mTLSを使用した数千の同時双方向gRPC接続の場合、生のTLSをPodポートに転送するNLBと、mTLSを終端するPodを組み合わせることで、スケーラビリティと真のエンドツーエンド暗号化が提供されます。その際、AWS Load Balancer Controllerのアノテーションを使用して適切なNLBリスナーとターゲットグループを作成します。

よくある落とし穴と判断基準

よくある落とし穴は、TLS終端の場所とクライアントIPの要件を混同することです。ALBはTLSを終端する際にX-Forwarded-Forを提供しますが、NLBのようにターゲットへのソースIPを維持しません。ALBの機能（ホスト/パスベースのルーティング、WAF）とバックエンドでの元のソースIPの両方が必要な場合、ALBをHTTP終端に使用し、X-Forwarded-ForからソースIPを再構築するリバースプロキシやサイドカーに転送するか、NLBがTLSをmTLSを実行するサービスにパススルーし、HTTPルーティングをクラスター内プロキシにオフロードするアーキテクチャを使用することを検討してください。もう一つの落とし穴は、クロスアカウントの権限設定の誤りです。Transit Gatewayや他のネットワークリソースをRAMで共有する場合、明示的なリソース共有と正しいIAMロールおよびRAMプリンシパルを使用するようにしてください。これを怠ると、不透明な「permission denied」エラーが発生します。

コンプライアンスの自動化に関しては、秘密鍵やCA関連の情報を暗号化せずに平文で保存しないでください。アクセスを必要とするロールとプリンシパルのみを許可する最小限のキーポリシーを持つKMSキーで、SSM Parameter StoreのSecureStringを使用してください。AWS Configのマネージドルール（例：vpc-flow-logs-enabled、restricted-common-ports、security-group-rule-check）を使用し、マネージドルールが要件をカバーしない場合は、PutEvaluationsを呼び出すLambdaベースのConfigルールを実装してください。修復は、Configの修復アクションが呼び出せるSSM AutomationドキュメントやSystems Manager Run Commandを介して自動化されるべきですが、リスクの高い変更に対しては常にアラートと承認のパスを提供してください。

実践的な問題：ユースケースシナリオ

企業：ApexTelemetrics — 課題：真のエンドツーエンドの相互TLS（クライアントとサーバーがmTLSで認証）を必要とし、TCP 443上で数千の同時長寿命接続をサポートし、Podをオートスケールし、証明書の配布とローテーションが自動化され監査可能であることを保証する、グローバルに到達可能なEKSホストのgRPCサービスを提供する。

アプローチ：

CloudFormationでネットワークとロードバランサーをプロビジョニングする：AWS::ElasticLoadBalancingV2::LoadBalancerを介してNLBを作成し、ポート443のTCPリスナーと、targetTypeが「ip」に設定されTCPでのヘルスチェックを行うターゲットグループを設定します。VPC、サブネット、NLBにはCloudFormationのCreateStack/UpdateStackとモジュール化されたネストスタックを使用します。EKS ServiceでAWS Load Balancer Controllerのアノテーション（service.beta.kubernetes.io/aws-load-balancer-type: “nlb”、service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”）を使用し、各ServiceがNLBターゲットグループを直接Podに作成するようにします。
PodでのTLSパススルーとmTLS終端を保証する：EKS ServiceがTCP 443を直接Podのポートに転送するように設定し、各Pod内にサイドカーまたはEnvoyプロキシを実装して、クライアントとのmTLS終端を実行し、相互認証を強制します。必要に応じてソースIPが維持されるように、ServiceでexternalTrafficPolicy: Localを設定し、Podレベルのオートスケーリング（Horizontal Pod Autoscaler）とCluster Autoscalerを使用してノードとPodを一緒にスケールさせます。
証明書のライフサイクルと配布を自動化する：CAとサーバー証明書の秘密鍵を、KMSキーで暗号化されたSSM Parameter StoreのSecureStringに保存します。スタック作成中にSSMパラメータを作成するために、CloudFormationでAWS Lambdaベースのカスタムリソースを作成します（適切なIAMロールを持つCreateFunction、次にPutParameterを呼び出すCloudFormationカスタムリソース）。SSM Run Commandまたは、PodにバインドされたIAMロール（IRSA経由）を介してSSMからシークレットを取得するイミュータブルなDaemonSetを使用して、証明書をサイドカーに注入します。ローテーションには、Lambda関数（CreateFunction + EventBridgeルール）をスケジュールして新しい証明書を生成し、PutParameterを実行し、SSMまたはKubernetes Jobsを使用してローリングリスタートを実行します。
コンプライアンスと監査：AWS Configルール（vpc-flow-logs-enabledなどのマネージドルールや、PutEvaluationsを使用するカスタムLambdaベースのルール）を有効にして、NLBリスナーがTCPであり、このサービスに対してALBがTLSを終端していないことを検証します。設定ミスが検出された場合にSSM Automationドキュメントを呼び出し、検出結果をAWS Security HubとCloudWatch Eventsに送信するようにConfigの修復を設定します。 AWSの論理的根拠：TCPモードのNLBは、エンドツーエンドのmTLSに必要な真のTLSパススルーを提供し、ロードバランサーでの接続あたりのCPUフットプリントが小さく、数千の同時接続にスケールします。targetType=ipを介してPodをターゲットにすることで、余分なホップを排除し、オートスケーリングの応答性を維持します。KMSで保護されたSSM Parameter Storeにキーを保存およびローテーションすることで、IAMコントロールを備えた一元的で監査可能なシークレット管理が提供され、CloudFormationに加えてLambdaカスタムリソースとEventBridgeを使用することで、ライフサイクル全体がコード化され、再現可能で、可観測であることが保証されます。

← ネットワークパフォーマンスとモニタリング · すべてのドメイン · コンテナとサーバーレスネットワーキング →

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