Amazon ANS-C01: ネットワークパフォーマンスとモニタリング — 学習ガイド

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

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

拡張ネットワーキングと低レイテンシーファブリック

AWSの拡張ネットワーキングは、OSおよびハイパーバイザーレベルの機能群であり、秒間パケット数（PPS）を大幅に向上させ、レイテンシーとCPUオーバーヘッドを削減し、仮想インターフェイスあたりのスループットを高めます。主なテクノロジーは、ほとんどの最新EC2インスタンスファミリーにSR-IOVベースの高性能ネットワーキングを提供するElastic Network Adapter (ENA)と、HPCや密結合されたMPI/libfabricワークロード向けに設計されたOSバイパスのRDMAライクなデバイスであるElastic Fabric Adapter (EFA)です。ENAを有効にするには、インスタンスタイプがENAをサポートしていることと、Linux AMIにENAドライバーが含まれていることを確認します。プログラムからは、EC2 APIコールを使用して有効化やクエリが可能です。例えば、必要に応じてRunInstancesでInterfaceType=efaを指定したり、ModifyInstanceAttributeでenaサポートを設定したりします。EFAは、InterfaceType=efaを指定してネットワークインターフェイスを作成する（aws ec2 create-network-interface --interface-type efa）か、EFAが有効なネットワークインターフェイスを持つインスタンスを起動することでアタッチされます。インスタンスはサポートされているカーネルとlibfabric/efaカーネルモジュールを実行している必要があり、通常、ホスト内のレイテンシーを最小化し、バイセクションバンド幅を最大化するために、クラスタープレイスメントグループに配置されます。

プレイスメントグループは、基盤となるネットワークファブリック内でのインスタンス配置を制御することで、パフォーマンスに影響を与えます。クラスタープレイスメントグループは、インスタンスを単一のラックまたは低レイテンシーのネットワークドメインに偏らせて配置し、最大のeast-west帯域幅と一貫したレイテンシーを可能にします。これは多くのEFAのユースケースで必須です。スプレッドプレイスメントグループは、相関障害を避けるためにホストレベルでの分散を強制しますが、レイテンシーは改善しません。バースト的な高スループットのシナリオでは、インスタンスファミリーとvCPU数がベースラインのネットワーク帯域幅クォータを決定します。例えば、特定のインスタンスサイズは最大25 Gbpsや100 Gbpsを謳っていますが、ENA/EFAなしではパケット処理やTCPスタックがボトルネックになる可能性があります。何千もの同時TCP接続（例：TLS上のgRPC）を想定してアーキテクチャを設計する場合、高い同時接続能力を持つインスタンスタイプを選択し、ENAを有効にし、EKSで実行する際には、ノードポートのボトルネックを避けるために、ポッドへの直接アドレッシング用にNLB / target-type=ip を優先的に使用します。

可観測性と強制のための主要サービスと設定

ネットワークの健全性の監視とボトルネックの診断は、VPC Flow Logs、CloudWatchメトリクス、Traffic Mirroring、およびReachability/Access Analyzerの組み合わせに依存します。VPC Flow Logsは、フローごとのメタデータ（送信元/宛先IP、ポート、パケット、バイト、アクション）を提供します。これらはCloudWatch LogsやS3に送信でき、CloudWatch Logs Insightsでクエリを実行して、大量のトラフィックを占めるプレフィックスや「トップトーカー」を見つけることができます。ライブでのパケットレベルの検査には、Traffic Mirroringを使用すると、ミラーターゲットとフィルターを作成し、セッションを作成して（aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session）、ENIからのトラフィックを、EC2で実行されている検査アプライアンスやAWS Network Packet Brokerパートナーにコピーできます。

CloudWatchは、さまざまなレイヤーに関連するメトリクスを公開します。NetworkIn/NetworkOutやNetworkPacketsIn/NetworkPacketsOutなどのEC2インスタンスメトリクス、AWS/ApplicationELB名前空間のRequestCount、ActiveConnectionCount、ClientTLSNegotiationErrorCountなどのApplication Load Balancerメトリクス、AWS/NetworkELB名前空間のProcessedBytesやNewFlowCountなどのNetwork Load Balancerメトリクス、そして仮想インターフェイスのBytesIn/BytesOutなどのAWS/DirectConnectメトリクスです。フローログに対してCloudWatch AlarmsとContributor Insightsを使用して、飽和状態のフローを検出します。パスと設定の検証には、Reachability Analyzer（EC2 APIのStartNetworkInsightsAnalysis / CreateNetworkInsightsPath経由）を使用すると、ルートテーブル、NACL、セキュリティグループ、VPN/Direct Connectアタッチメントを通過するエンドツーエンドのパケットパスをモデル化してテストできます。一方、Network Access Analyzerは、VPCやAWS Organizations全体で意図しないネットワークアクセスパスを検出するのに役立ちます。

ロードバランシングとセキュアなアクセスに関する設計パターンとトレードオフ

バックエンドで相互TLS（mTLS）を使用した真のエンドツーエンドTLSを要求し、同時に数千のgRPC接続をサポートする必要がある場合、TCPモードのNetwork Load Balancerが推奨されるパターンです。NLBはデフォルトでクライアントの送信元IPを保持し、EKSサービス向けにはAWS Load Balancer Controllerによって作成できます。その際、

undefined

やtarget-type=ipのようなアノテーションを使用して、PodのIPに直接トラフィックを送信します。ポート443でTCPパススルーを使用すると、バックエンドのPodが相互TLS（クライアントとサーバーの証明書検証）を終端することを意味します。そのため、トラフィックはロードバランサーで復号されることなく、双方向認証が維持されます。このパターンは接続数をうまくスケールさせます。なぜなら、NLBは数百万の同時接続と接続ごとの低いオーバーヘッドに対応するように設計されているからです。

ロードバランサーでのTLS終端と、複数のターゲットグループへのパスベースルーティングを必要とするアーキテクチャでは、Application Load Balancerが適切な選択です。ALBはHTTP/2とgRPC、パスベースルーティング、ホストベースのルールをサポートしているためです。ALBがTLSを終端する場合に正確なクライアントIPをログに記録するには、バックエンドアプリケーションがX-Forwarded-Forヘッダー（ALBが自動的に挿入します）をパースするようにするか、TCPレイヤーで送信元IPの保持が必要な場合はNLBでPROXYプロトコルを使用します。Global Acceleratorを使用して静的なエニーキャストのフロントエンドIPを提供し、クライアントがアクセラレーターをバイパスして直接ALBのURLにアクセスするのを防ぎたい場合は、ALBのセキュリティグループを、アクセラレーターの静的IP（アクセラレーターに割り当てられた2つの静的アドレス）からのみインバウンドを受け入れるように制限し、インターネットからの直接アクセスを拒否します。

事業部門ごとの厳格な制御とスケーラビリティが求められるマルチアカウントの共有サービスには、AWS PrivateLink（内部NLBに支えられたVPCエンドポイントサービス）が、多くの場合、最も安全でスケーラブルなパターンです。共有サービスVPCは、Network Load Balancerのエンドポイント（ターゲットグループを持つ

undefined

）を介してサービスを公開し、VPCエンドポイントサービスとして公開します。コンシューマーアカウントは、プロバイダーのNLBにアタッチするインターフェイスエンドポイントを自身のVPC内に作成します。プロバイダーはエンドポイントポリシーとセキュリティグループを介してアクセスを制御し、トラフィックは中央集権的なルーティングプレーンを通過しません。Transit Gatewayは、完全なルーティングの可視性と推移的な接続性が必要な場合に適していますが、ルーティングを中央集権化し、サービスごとのアクセス制御においてはPrivateLinkよりも粒度が粗くなります。

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

よくある間違いは、インスタンスで公称されている帯域幅が無制限であると想定してしまうことです。インスタンスファミリーとサイズには厳格なネットワーク上限が設定されており、スケーリングの際にはENI間での分散や、一貫したパフォーマンスを得るためのクラスタープレイスメントグループへの配置を考慮すべきです。もう一つの落とし穴は、VPC Flow Logsと関連付けて特定のVPC、サブネット、またはビジネスユニットにトラフィックを帰属させることなく、CloudWatchのNetworkIn/NetworkOutのみに依存することです。Direct Connectの飽和を引き起こしている仮想インターフェイスやアプリケーションを特定するには、Flow LogsとTraffic Mirroringが必要です。また、エンドツーエンドで相互TLSが必要な場合にALBでTLSを終端することは避けてください。ポリシーでバックエンドがクライアント証明書を確認する必要がある場合は、NLBでTLSパススルーを選択するか、適切な証明書検証を伴うTLSブリッジングを実行しますが、信頼が確立される場所を明確にしてください。

Direct Connectのような共有物理リンクで断続的な飽和を診断する場合、レイヤーをまたいでメトリクスを関連付けます。仮想インターフェイスに対するAWS/DirectConnectメトリクス、サブネット/ENIごとのバイト数を把握するためのVPC Flow Logs、インスタンスレベルの挙動を把握するためのEC2 Network*メトリクスです。非対称ルーティングや誤ったルート伝播がリターンパスの問題を引き起こしているかどうかを検証するためにReachability Analyzerを使用し、詳細なプロトコル検査のためにパケットダンプをキャプチャするためにTraffic Mirroringを使用します。

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

AcmeIoT社は、世界中の自動販売機がgRPCと相互TLSを使用してEKSでホストされたバックエンドに接続する必要があるという課題に直面しています。接続数は数千にのぼり、サービスはエンドツーエンドで暗号化され、バックエンドのPodはCluster AutoscalerとHPAによって動的にスケールする必要があります。

Kubernetes Service用に、AWS Load Balancer Controllerとアノテーションを使用して、Network Load BalancerタイプのAWS LoadBalancerを作成します。NLBとtarget-type=ipを指定します（service.beta.kubernetes.io/aws-load-balancer-type: "nlb"およびservice.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"）。ポート443でTCPリスナーを設定し、NLBが純粋なTCPパススルーを実行するようにします。NLBにTLS証明書は設定しません。
アプリケーションPodで相互TLSの終端と検証を実装します。各Podはサーバー証明書を提示し、クライアント証明書を検証します。これには、AWS Secrets ManagerまたはSSM Parameter Storeと統合された、短命な証明書のローテーションプロセスを使用します。target-type ipを使用してPodのIPに到達可能であることを確認し、ヘルスチェックがターゲットグループで設定されたTCPまたはgRPCヘルスチェックであることを確認します。
ENAをサポートし、十分なネットワーク帯域幅を持つインスタンスを選択することで、高い接続スケールを確保します。ENAを有効にし（AMIのENAドライバーで確認し、必要に応じてaws ec2 modify-instance-attributeを使用してena-supportを有効化）、Podのリクエストに基づいてノードをスケーリングするCluster Autoscalerを使用して、複数のノードにPodをデプロイします。一貫したレイテンシーが必要な密結合クラスターにはプレイスメントグループを使用し、AZをまたいで十分な数のノードをデプロイします。
CloudWatchとVPC Flow Logsを使用して監視と検証を行います。NLBのActiveFlowCount/NewFlowCountおよびEKSワーカーのEC2 NetworkIn/Outに対するCloudWatchメトリクスとアラームを作成します。VPC Flow Logsを使用してトップトーカーを特定し、Reachability Analyzer（StartNetworkInsightsAnalysis/CreateNetworkInsightsPath）を使用してオートスケーリングイベント中のルーティングパスを検証します。パケットレベルのデバッグが必要な場合は、Traffic Mirroringセッションを検査インスタンスに作成します。

AWSの論理的根拠：TCPモードのNetwork Load Balancerは、ソースIPを保持し、大規模な同時接続をサポートし、TLSを終端しないためエンドツーエンドのTLSを可能にします。AWS Load Balancer Controllerでtarget-type ipを使用すると、EKSのオートスケーリングセマンティクスと統合され、新しいPodのIPがターゲットとして動的に登録されます。ENAと適切なインスタンスサイジングは、ホストのCPUを枯渇させることなく数千の同時TLS接続を処理するための生のネットワークキャパシティを提供します。そして、CloudWatch、VPC Flow Logs、Reachability Analyzer、Traffic Mirroringの組み合わせは、飽和やルーティングの問題を検出および修正するために必要な可観測性を提供します。

← コンテンツ配信とエッジネットワーキング · すべてのドメイン · 自動化、IaCとネットワーク運用 →

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