AWS Advanced Networking Specialty (ANS-C01) 模擬試験 65問

A) VPCピアリング - より安価でシンプル B) Transit Gateway - 中央集中型ルーティング、推移的ルーティングのサポート、N個のVPC接続でO(1)の管理複雑性 C) 両方式は同一でコストのみ異なる D) VPCピアリング - より低いレイテンシ

答え: B

解説: VPCピアリングは推移的(transitive)ルーティングをサポートしません。A-BとB-Cがピアリングされていても、AからCへ直接通信できません。10個のVPCをすべて接続するには最大N*(N-1)/2 = 45個のピアリングが必要です。Transit Gatewayは中央ハブとして機能し、1つのTGWにすべてのVPCを接続すれば推移的ルーティングが可能です。10以上のVPC環境ではTransit Gatewayがはるかに効率的です。

A) VPCピアリングを作成 - 重複するCIDRもサポート B) VPCピアリングは不可能。PrivateLink(エンドポイントサービス)を使用して特定サービスを公開する C) NAT Gatewayでアドレス変換する D) インターネット経由で通信する

答え: B

解説: VPCピアリングとTransit GatewayはCIDRブロックの重複を許可しません。AWS PrivateLinkを使用すると、NLBの後ろのサービスをVPCエンドポイントサービスとして公開し、他のVPCがインターフェースエンドポイント経由でアクセスできます。CIDR衝突があっても動作します。長期的にはVPC CIDRの再設計が推奨されます。

A) TGWリージョン間ピアリングはルート伝播を自動サポート B) TGWリージョン間ピアリングは静的ルーティングのみサポート。ピアリングアタッチメントに手動でルートを追加する必要がある C) BGPを使用した動的ルーティングをサポート D) 同一リージョンのTGWと同じように動作する

答え: B

解説: Transit Gatewayリージョン間ピアリングはBGP動的ルーティングをサポートしません。静的ルーティングのみサポートするため、各TGWルートテーブルに相手リージョンのCIDRブロックを手動で追加する必要があります。リージョン間のトラフィックはAWSグローバルネットワークを通じて暗号化されて送信されます。

A) IPv6 NAT Gatewayを使用する B) Egress-Only Internet Gateway(EIGW)を使用し、ルートテーブルに ::/0 → EIGWのルートを追加する C) 通常のインターネットゲートウェイ(IGW)で十分 D) IPv6はNATが不要なため別途設定は不要

答え: B

解説: Egress-Only Internet GatewayはIPv6専用で、IPv4のNAT Gatewayと同様にアウトバウンドIPv6トラフィックを許可しますが、インターネットからインスタンスへのインバウンド接続をブロックします。プライベートサブネットのIPv6インスタンスがインターネットからパッチを受信したり外部APIを呼び出したりする際に使用します。

A) VPCピアリングの設定 B) NLB(Network Load Balancer)の後ろにサービスを配置し、VPCエンドポイントサービスを作成する C) パブリックIPでサービスを公開する D) Site-to-Site VPNの設定

答え: B

解説: AWS PrivateLinkアーキテクチャでは、サービスプロバイダーはNLB(またはGWLB)の後ろにサービスを配置し、VPCエンドポイントサービスを作成します。コンシューマーはインターフェースVPCエンドポイントを作成し、プライベートIP経由でサービスにアクセスします。トラフィックはAWSネットワーク内のみで移動し、インターネットを経由しません。NLBはIP、インスタンス、Lambdaターゲットをサポートします。

A) Route 53パブリックホストゾーンを作成する B) VPCにRoute 53 Resolverインバウンドエンドポイントを作成し、オンプレミスDNSサーバーにそのVPCドメインへの条件付きフォワーダーを設定する C) Route 53 Resolverアウトバウンドエンドポイントだけで十分 D) VPC Flow LogsでDNSクエリを分析する

答え: B

解説: Route 53 Resolverインバウンドエンドポイントはvpc内にENIを作成し、オンプレミスDNSサーバーがDirect ConnectまたはVPN経由でVPC内ドメイン名を解決できるようにします。オンプレミスDNSサーバーに internal.corp ドメインに対してインバウンドエンドポイントのIPへの条件付きフォワーディングを設定します。

A) すべてのVPCに個別のNAT Gatewayを作成する B) Transit GatewayにすべてのVPCとEgress VPCを接続し、スポークVPCのデフォルトルート(0.0.0.0/0)をTGWへ向け、Egress VPCでNAT Gatewayにルーティングする C) VPCピアリングでEgress VPCに接続する D) 各VPCにインターネットゲートウェイを接続する

答え: B

解説: 中央集中型インターネットアウトバウンド設計: 1) Egress VPCにNAT GatewayとIGWを設定、2) Transit GatewayにすべてのスポークVPCとEgress VPCを接続、3) スポークVPCのルートテーブルに0.0.0.0/0 → TGWのルートを追加、4) TGWのルートテーブルでデフォルトルートをEgress VPCへ向ける、5) Egress VPCでNAT Gatewayにルーティング。このパターンはNAT Gatewayのコストを削減し、中央集中型のセキュリティコントロールが可能です。

A) EC2インスタンス間のマルチキャスト B) VPNアタッチメントを介したマルチキャスト C) ピアリングされたTGW間のマルチキャスト D) マルチキャストドメイン内の複数グループのサポート

答え: C

解説: Transit Gatewayマルチキャストは、ピアリングされたTGW(リージョン間または同一リージョン内TGW間ピアリング)間ではサポートされません。また、Direct Connect GatewayとVPNアタッチメントもマルチキャストをサポートしません。EC2インスタンスはTGWマルチキャストグループのメンバーとして登録できます。

A) 10.0.0.0/24のような小さなCIDRから始める B) RFC 1918アドレス範囲(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16)内で十分に大きなCIDRを割り当て、オンプレミスや他のVPCと重複しないよう計画し、/16〜/20を推奨 C) パブリックIPレンジをVPC CIDRとして使用する D) CIDRはいつでも変更できるので小さく始める

答え: B

解説: VPC CIDR計画のベストプラクティス: 1) RFC 1918プライベートアドレスを使用、2) 十分に大きな範囲を割り当て(/16推奨 - 65,536個のIP)、3) オンプレミスネットワークと重複しないよう組織全体のIP計画を策定、4) VPC間の重複を防ぐ(ピアリング/TGW接続を考慮)、5) サブネット計画のための余裕スペースを確保。VPC CIDRは追加は可能ですが変更はできません。

A) すべてのVPCトラフィックが単一の中央Network Firewall VPCを通過する B) 各VPCにNetwork Firewallエンドポイントをデプロイし、VPC内のトラフィックをローカルで検査する C) Transit Gatewayとは独立してデプロイされる D) インバウンドトラフィックのみを検査する

答え: B

解説: Network Firewallデプロイメントモデル: 1) 分散(Distributed) - 各VPCにファイアウォールエンドポイントをデプロイし、VPCレベルでトラフィックを検査、2) 中央集中(Centralized) - 専用セキュリティVPCにファイアウォールをデプロイし、TGWを通じてすべてのトラフィックをルーティングして検査、3) 結合(Combined) - インターネットエッジは中央集中、East-Westは分散。分散モデルはVPCごとの細かいポリシー適用が可能ですが、コストが高くなります。

A) すべての場合にTransit VIFを使用する B) AWSパブリックサービス(S3、DynamoDB)へのアクセス → Public VIF、単一VPCアクセス → Private VIF、Transit Gateway経由の複数VPCアクセス → Transit VIF C) セキュリティ強化のためPrivate VIFのみを使用する D) 用途に関係なく同じVIFを使用する

答え: B

解説: Direct Connect VIFタイプ: 1) Public VIF - AWSパブリックサービス(S3、Glacierなど)およびAWS IPアドレスへのアクセス、BGPでAWSパブリックIPを受信、2) Private VIF - 単一VPCまたは同一リージョンのDirect Connect GatewayでVPCにアクセス、3) Transit VIF - Direct Connect GatewayとTransit Gateway経由で複数のVPCとリージョンにアクセス。Transit VIFとPrivate VIFは同時使用不可。

A) LAGは複数のDirect Connectロケーションにまたがって設定可能 B) LAGは同一Direct Connectロケーションで同一速度の複数接続を論理的にまとめ、帯域幅増加と障害復旧を提供する C) LAGは自動的にActive/Passiveフェイルオーバーを提供する D) LAG内の接続は異なる速度が可能

答え: B

解説: LAG(Link Aggregation Group)は同一Direct Connectロケーションで同一速度の複数の物理接続を1つの論理接続に結合します。LACP(Link Aggregation Control Protocol)を使用して帯域幅を集約します。すべての接続は同一速度で同一Direct Connectロケーションにある必要があります。最小アクティブ接続数を設定してSLAを保証できます。

A) コスト削減のため B) Direct Connectをプライマリルート、Site-to-Site VPNをバックアップルートとして設定し、高可用性を確保する C) 2つの方式は同時使用不可 D) VPNはDirect Connectより速い

答え: B

解説: DX + VPN冗長化パターン: DXは低レイテンシと高帯域幅のプライマリルートとして使用し、VPNはDX障害時の自動フェイルオーバーのバックアップルートとして設定します。BGP MED(Multi-Exit Discriminator)属性やAS Path Prependingを使用してDXルートが優先されるようにします。DX障害時はVPNに自動切り替えされます。

A) VPNパフォーマンスの監視 B) ピアのアクティブ状態を定期的に確認し、非アクティブなピアを検出してトンネルを再初期化またはフェイルオーバーをトリガーする C) VPNトラフィックの暗号化方式を決定する D) 最大転送単位(MTU)の設定

答え: B

解説: Dead Peer Detection(DPD)はIKE(Internet Key Exchange)プロトコルの拡張で、一定間隔でR-U-THEREメッセージを送ってVPNピアの生存を確認します。DPDタイムアウトが発生すると、デッドピアアクションに応じてトンネルを削除(Clear)、再起動(Restart)、または保留(Hold)します。AWS VPNはDPDをサポートしており、アクティブなトンネル維持のためBGP keepaliveまたはDPD設定が重要です。

A) より強力な暗号化を提供する B) AWS Global AcceleratorのAnycast IPとエッジロケーションを活用してインターネット区間を最小化し、AWSバックボーンを通じた最適経路を使用する C) 無料で提供される D) より多くのトンネルをサポートする

答え: B

解説: Accelerated VPNはAWS Global Acceleratorを使用してVPNトラフィックを最も近いAWSエッジロケーションにルーティングし、AWSグローバルネットワーク経由でAWSリージョンに届けます。インターネット経由の区間が最小化されてレイテンシが低下し、接続安定性が向上します。Transit Gatewayに接続されたVPNでのみ使用可能です。

A) VPN暗号化を置き換えるため B) 物理的なDirect Connect接続レイヤーでLayer 2セキュリティを提供(イーサネットフレーム暗号化)し、物理的な盗聴から保護する C) レイテンシを削減するため D) 帯域幅を増加させるため

答え: B

解説: MACsec(IEEE 802.1AE)はイーサネットリンクレベルでデータを暗号化します。Direct ConnectでMACsecを有効にすると、オンプレミス機器とAWS Direct Connectロケーション間の物理リンクでLayer 2暗号化が適用されます。特に共有コロケーション環境での物理的な盗聴を防止します。10Gbpsと100Gbpsの専用接続でサポートされます。

A) 静的ルーティングより遅いがより安全 B) 動的ルーティング更新、自動フェイルオーバー、ECMP(Equal Cost Multi-Path)サポートによる複数VPNトンネルを通じたロードバランシング C) 設定がより簡単 D) BGPを使用すると暗号化が自動適用される

答え: B

解説: BGP VPNの利点: 1) ネットワーク変更時の自動ルーティング更新、2) トンネル障害時の自動フェイルオーバー(DPDと連携)、3) Transit GatewayとECMP使用時に複数VPNトンネルの帯域幅を集約、4) BGPコミュニティ属性でルート優先度を調整。各VPN接続には2つのIPSecトンネルがあり、BGPで両方のトンネルを使用できます。

A) 単一のVPN接続で十分 B) TGWに複数のSite-to-Site VPN接続を作成してECMPを有効化し、オンプレミスルーターから同一のBGPルートをすべてのトンネルにアドバタイズする C) Direct Connectと一緒に使用する場合のみECMPが可能 D) ECMPはVPNではサポートされない

答え: B

解説: Transit GatewayはECMPを通じて複数のVPN接続の帯域幅を集約します。各VPN接続は2つのIPSecトンネルを提供し、複数のVPN接続を使用することで最大帯域幅を増やすことができます(最大50Gbps集約可能)。オンプレミスルーターから同一のBGPルートをすべてのトンネルにアドバタイズする必要があります。TGWではVPNアタッチメントにECMPを有効化する必要があります。

A) 両サービスは同一の機能を提供する B) Reachability Analyzerは2つの特定エンドポイント間の接続経路を分析してブロック要素を識別し、Network Access Analyzerは意図しないネットワークアクセス経路を識別する C) Network Access AnalyzerのみVPC Flow Logsを分析する D) Reachability Analyzerはリアルタイムトラフィック分析を行う

答え: B

解説: AWS Reachability Analyzer: 2つのネットワークエンドポイント(EC2、ENI、IGWなど)間の到達可能性を分析し、接続可否と経路を示し、ブロック原因(SG、NACL、ルーティング)を識別します。Network Access Analyzer: ネットワークセキュリティ要件を定義し、これに違反する予期しないアクセス経路(インターネットからEC2へのアクセスなど)を識別します。両サービスとも実際のトラフィックを送信しない静的分析です。

A) VPC間のトラフィックレプリケーションと同期 B) EC2インスタンスのネットワークトラフィックをコピーして侵入検知システム(IDS)またはパケット分析ツールに送信する C) ロードバランサーのトラフィック分散 D) VPNトラフィックの暗号化

答え: B

解説: VPC Traffic MirroringはEC2インスタンスのENI(Elastic Network Interface)からネットワークトラフィックをミラーリングし、セキュリティ分析、脅威検出、トラブルシューティングに活用します。トラフィックを別のEC2インスタンス(IDS/IPSアプライアンス)またはNLBに送信します。ソースとターゲットのENIにフィルターを適用して特定のトラフィックのみミラーリングできます。エージェントなしで動作します。

A) CloudWatchメトリクスを使用する B) AthenaでCREATE EXTERNAL TABLEでFlow Logs S3パスをテーブルとして作成後、SQLクエリを実行する C) GuardDutyダッシュボードで確認する D) VPC Flow Logsコンソールでフィルタリングする

答え: B

解説: VPC Flow Logs + Athena分析手順: 1) Flow Logs S3バケットを指すAthenaの外部テーブルを作成(Flow Logsフィールドに合ったスキーマ定義)、2) SQLクエリを実行: SELECT srcaddr, SUM(bytes) as total_bytes FROM vpc_flow_logs WHERE dstport = 443 AND start BETWEEN timestamp1 AND timestamp2 GROUP BY srcaddr ORDER BY total_bytes DESC LIMIT 10。パーティショニングでクエリパフォーマンスとコストを最適化します。

A) AWSサービスのAPIエラーのモニタリング B) ハイブリッドネットワーク(Direct Connect、VPN)のレイテンシ、パケットロス、ジッターを継続的にモニタリングする C) VPC内EC2インスタンスのCPU使用率のモニタリング D) S3バケットアクセスのモニタリング

答え: B

解説: CloudWatch Network Monitorはハイブリッドネットワークのパフォーマンス指標を継続的にモニタリングします。オンプレミスロケーションとAWSリソース間のレイテンシ、パケットロス率、ジッター指標を測定します。Direct ConnectまたはVPNのパフォーマンス低下を検出し、アラームで運用チームに通知します。ネットワークパフォーマンスSLAのモニタリングに活用されます。

A) TGWのルートテーブルの自動設定 B) グローバルネットワーク(Transit Gateway、Direct Connect、VPN、SD-WAN)を中央ダッシュボードで視覚化し、イベントをモニタリングする C) TGWコストの分析 D) VPC Flow Logsの中央集約

答え: B

解説: Transit Gateway Network Managerはグローバルネットワークトポロジを視覚化する中央管理サービスです。AWSリージョン全体のTGW、VPC接続、Direct Connect、VPN、SD-WANデバイスをマップベースのビューで表示します。イベント(ルーティング変更、接続状態)をモニタリングし、CloudWatchと統合されます。Route Analyzerで経路分析も可能です。

A) セキュリティグループのルール数を削減し、複数のセキュリティグループで共有して一貫性のあるIPリスト管理ができる B) 自動的に脅威IPをブロックする C) NACLルールを置き換える D) コストを削減する

答え: A

解説: 管理プレフィックスリストはCIDRブロックの集合で、セキュリティグループルールやルートテーブルで参照できます。例: 10個のIPアドレスを1つのプレフィックスリストで管理すると、複数のセキュリティグループがこのリストを参照してルール数を削減します。IPアドレス変更時はプレフィックスリストのみ更新すれば、参照するすべてのセキュリティグループに自動反映されます。AWSサービス用の管理プレフィックスリスト(CloudFront、S3など)も提供されています。

A) ALB + ACMパブリック証明書 B) ALBでmTLSを有効化 + ACM Private CAでクライアント/サーバー証明書を発行、またはAPI Gateway + mTLS設定 C) CloudFront + WAFの組み合わせ D) NLB + TCPパススルー

答え: B

解説: mTLS実装オプション: 1) ALB - mTLSサポートを有効化するとクライアント証明書を検証し、証明書情報をヘッダーとしてバックエンドに転送。ACM Private CAからクライアント証明書を発行、2) API Gateway - クライアント証明書設定でmTLSを実装、トラストストアをアップロード、3) App Mesh/Service Mesh - サービス間mTLSを自動処理。

A) サーバーがクライアント応答を送るポートで許可は不要 B) NACLはステートレスなので、サーバーの応答がクライアントのエフェメラルポート(Linux: 32768-60999、Windows: 49152-65535、AWSの推奨: 1024-65535)に出ることをアウトバウンドで許可する必要がある C) エフェメラルポートはセキュリティグループでのみ管理される D) エフェメラルポートの範囲は固定されていないためすべてのポートを許可する必要がある

答え: B

解説: NACLはステートレス(stateless)で応答トラフィックにも別のルールが必要です。クライアントがサーバーの80番ポートにリクエストすると、サーバーの応答はクライアントのエフェメラルポートに戻ります。AWSは1024-65535の範囲の許可を推奨します。一方SGはステートフルなので応答トラフィックを自動的に許可します。実務ではSGだけで十分なケースも多いですが、NACLを追加防御層として使用する場合にエフェメラルポートの設定が必要です。

A) VPN暗号化を提供する B) 元のパケットをカプセル化して仮想アプライアンスに送信し、アプライアンスは検査後GWLBに返却。元のパケットのソース/宛先情報を保存する C) Layer 7ロードバランシングを実行する D) DNSベースのルーティングを提供する

答え: B

解説: GWLBはGENEVE(Generic Network Virtualization Encapsulation)プロトコルを使用して元のパケットをカプセル化し、仮想アプライアンス(IDS/IPS、ファイアウォール)に届けます。アプライアンスはパケットを検査後にGWLBに返却し、GWLBは元の宛先にトラフィックを転送します。GENEVEは元のIP/ポート情報を保存するため、アプライアンスが実際のトラフィック情報を見ることができます。

A) 単一のルートCAですべての証明書を発行する B) ルートCA(オフライン維持) → 中間CA(発行CA) → リーフ証明書の階層構造、各環境/チーム別に別の発行CAを設定する C) すべてのCAをアクティブ状態に維持する D) リーフ証明書のみ使用し、CAは外部に委託する

答え: B

解説: PKI階層設計のベストプラクティス: 1) ルートCA - 最上位の信頼アンカー、オフライン状態維持を推奨(実際の署名には使用しない)、2) 中間/発行CA - 実際のリーフ証明書を発行するCA、各環境(prod/dev)やチーム別に別途設定、3) リーフ証明書 - TLS/mTLSに使用される実際の証明書。ルートCAが侵害された場合の影響を最小化するためにこの階層構造が重要です。

A) インターネット接続速度の向上 B) MPI(Message Passing Interface)ベースのHPCおよび機械学習分散訓練のためのOSバイパス通信で、超低レイテンシと高帯域幅を達成する C) VPNパフォーマンスの向上 D) S3転送速度の向上

答え: B

解説: EFA(Elastic Fabric Adapter)はAWSのカスタム高性能ネットワークインターフェースです。OSバイパス機能でカーネルを経由せずに直接NICと通信し、マイクロ秒単位の超低レイテンシを達成します。HPCクラスターのMPIアプリケーション(気象予測、流体力学、分子動力学)とディープラーニング分散訓練(PyTorch Distributed、Horovod)に使用されます。クラスター配置グループで使用すると最大の効果を発揮します。

A) Active/Passive/Standbyの3つのタイプ B) クラスター(超低レイテンシHPC)、分散(高可用性、単一障害点の防止)、パーティション(Kafka、HDFSなどの大規模分散処理) C) すべての配置グループは同一の機能を提供する D) オンデマンド/スポット/リザーブドインスタンスタイプによって区分される

答え: B

解説: EC2配置グループタイプ: 1) クラスター(Cluster) - 同一AZの単一ラックまたは隣接ラックにインスタンスを配置、10Gbpのネットワーク、低レイテンシ、HPC用、2) 分散(Spread) - 各インスタンスを別々のハードウェアに配置、AZ別最大7インスタンス、重要なワークロードの高可用性、3) パーティション(Partition) - 各パーティションを別のラックに配置、AZあたり最大7パーティション、Kafka、Cassandra、HDFSのような大規模分散システム用。

A) Global Acceleratorはコンテンツキャッシングを提供する B) Global AcceleratorはAnycast IPを使用してTCP/UDPトラフィックを最適なAWSエッジで受信後AWSバックボーンでルーティング、非HTTPプロトコルと静的IP要件をサポートする C) CloudFrontより遅い D) HTTPトラフィックのみをサポートする

答え: B

解説: Global Accelerator vs CloudFront: GAはAnycast IP 2つを提供し、世界中のエッジロケーションでトラフィックを受信後AWSグローバルネットワークでルーティングします。TCP、UDPプロトコルをサポートしてゲーム、IoT、VoIPに適しており、静的IPが必要な場合に使用します。トラフィックダイヤルで加重ルーティング、ヘルスチェックによる自動フェイルオーバーをサポートします。CloudFrontはHTTP/HTTPSコンテンツキャッシングと動的加速に特化しています。

A) ユーザーの場所に基づいたDNS応答 B) AWSリソースまたはユーザー定義の場所のバイアス値を調整してトラフィック分散比率を細かく制御する C) レイテンシベースのルーティング D) IPアドレスベースのルーティング

答え: B

解説: Route 53 Geoproximityルーティングはユーザーとリソース間の地理的距離に基づいてトラフィックをルーティングします。バイアス値を正に設定するとそのリソースへのトラフィックが増え、負に設定すると減ります。AWSリソースはリージョンを基準に、非AWSリソースは緯度/経度座標で指定します。トラフィックフローポリシーで視覚的に設定できます。

A) 2つの機能は同一で名前だけが異なる B) Lambda@Edgeはビューワー/オリジンリクエスト/レスポンスの4つのイベントを処理可能、Node.js/Pythonをサポート、実行時間最大30秒; CloudFront Functionsはビューワーリクエスト/レスポンスのみサポート、JavaScriptのみ、実行時間ミリ秒、より安価 C) Lambda@EdgeのみHTTPヘッダーを変更可能 D) CloudFront Functionsはオリジンリクエストを変更可能

答え: B

解説: Lambda@Edge: ビューワーリクエスト、ビューワーレスポンス、オリジンリクエスト、オリジンレスポンスの4つのイベントで実行。Node.js/Pythonをサポート。最大5秒(ビューワー)/30秒(オリジン)。1MBパッケージサイズ。CloudFront Functions: ビューワーリクエスト、ビューワーレスポンスのみサポート。JavaScript(ECMAScript 5.1)。実行時間ミリ秒以内。2KBコードサイズ制限。100倍安価。シンプルなヘッダー操作、URL書き換え、A/BテストにはCloudFront Functionsが適しています。

A) 2つの別々のドメインを使用する B) Route 53加重ベース(Weighted)ルーティングポリシーで、オンプレミスIPとAWSリソースに重みを設定して段階的にトラフィックを切り替える C) CloudFrontでトラフィックを分散する D) ALBでトラフィックを分散する

答え: B

解説: Route 53加重ベースルーティングによる段階的移行: 例えば、初期はオンプレミス90、AWS 10に設定し、テスト後にAWSの重みを徐々に増やします。ヘルスチェックと組み合わせると障害時に正常なリソースへ自動的にトラフィックが移動します。最終的にはオンプレミス0、AWS 100で切り替え完了します。

A) シンプルルーティングポリシー B) レイテンシベース(Latency)ルーティング + ヘルスチェックを組み合わせ、各リージョンのALBにレイテンシレコードを作成してヘルスチェックを関連付ける C) 地理的位置(Geolocation)ルーティングのみ使用する D) 加重ベースルーティングのみ使用する

答え: B

解説: Active-Activeマルチリージョン設計: 1) 各リージョンのALB/NLBに対してRoute 53レイテンシベースレコードを作成、2) 各レコードにヘルスチェックを関連付け、3) 正常時は最低レイテンシのリージョンにルーティング、4) ヘルスチェック失敗時はそのリージョンのレコードを自動的に除外し次の最低レイテンシリージョンにルーティング。Global Acceleratorも同じパターンをTCP/UDPレイヤーで実装できます。

A) 単一のDirect Connect接続で十分 B) 異なるDirect Connectロケーションから2つのDirect Connect接続を作成し、それぞれ別の顧客ルーターとAWSデバイスを使用する C) Direct Connect + NAT Gatewayの冗長化 D) 2つのVPN接続でDXを置き換える

答え: B

解説: Direct Connect高可用性アーキテクチャ: 最高レベル - 2つの異なるDXロケーション、それぞれ異なるAWSデバイス、顧客側は異なるルーター。これにより、機器障害、ロケーション障害、ケーブル切断などすべての単一障害点を排除します。最低推奨 - 同一DXロケーションで2つの接続(異なるAWSデバイス)。VPNはDX障害時のバックアップとして使用するのであり、単独の冗長化手段としては不十分です。

A) enableDnsSupportのみ有効化する B) enableDnsSupport(DNSサーバーの提供)とenableDnsHostnames(EC2にDNS名を割り当て)の両方を有効化する C) Route 53 Resolverエンドポイントのみ必要 D) DHCPオプションセットを変更する必要がある

答え: B

解説: VPC DNS属性: 1) enableDnsSupport - AWSが提供するDNSサーバー(169.254.169.253またはVPC CIDR+2番アドレス)をVPC内インスタンスで使用可能にします。デフォルト: 有効、2) enableDnsHostnames - パブリックIPを持つEC2インスタンスにパブリックDNS名を割り当てます。デフォルトVPC: 有効、新規VPC: 無効。プライベートホストゾーンをVPCに関連付けるには両方の属性が有効化されている必要があります。

A) オンプレミスDNSサーバーにハードコードされたIPを登録する B) Direct Connect/VPN設定 + Route 53 Resolverインバウンドエンドポイント作成 + オンプレミスDNSサーバーに条件付きフォワーダーを設定(AWS内部ドメイン → インバウンドエンドポイントIP) C) パブリックRoute 53ホストゾーンを使用する D) CloudFrontでDNS処理する

答え: B

解説: ハイブリッドDNS統合アーキテクチャ: 1) Direct ConnectまたはVPNでオンプレミス - AWS間のネットワーク接続、2) VPCにRoute 53 Resolverインバウンドエンドポイントを作成(ENI 2個、各AZに1個)、3) オンプレミスDNSサーバーに条件付きフォワーダーを設定: *.ap-northeast-1.compute.internal またはカスタムドメイン → インバウンドエンドポイントのIPアドレス、4) オンプレミスアプリケーションが内部DNS名でAWSリソースにアクセス。

A) VPCエンドポイントのパフォーマンスを最適化するため B) VPCエンドポイントを通じてアクセスできるAWSサービスのリソースと操作を制限する C) VPC間の接続を許可/拒否するため D) ネットワークACLを置き換えるため

答え: B

解説: VPCエンドポイントポリシーはエンドポイントを通じたサービスアクセスを制限するリソースベースのポリシーです。例: S3ゲートウェイエンドポイントポリシーで特定のS3バケットのみを許可: "Resource": "arn:aws:s3:::my-company-bucket/*"。DynamoDB、S3などのゲートウェイエンドポイントとインターフェースエンドポイントの両方に適用可能です。これによりVPCからS3にアクセスする際に特定のバケットのみに制限してデータ漏洩を防ぐことができます。

A) S3バケットをプライベートに設定する B) S3ゲートウェイエンドポイントを作成 + ルートテーブルを更新 + S3バケットポリシーにaws:SourceVpce条件でエンドポイント外のアクセスを拒否する C) S3 Transfer Accelerationを無効化する D) CloudFront + OAC(Origin Access Control)を使用する

答え: B

解説: 実装ステップ: 1) VPCにS3ゲートウェイエンドポイントを作成、2) サブネットのルートテーブルにS3エンドポイントのルートを追加、3) S3バケットポリシーに条件を追加: "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-xxxxx"}} → 指定されたVPCエンドポイント以外のアクセスを拒否、4) EC2インスタンスのIAMロールにS3アクセス権限を付与。これによりすべてのS3トラフィックがAWS内部ネットワークのみを経由します。

A) IPアドレスベースのブロックのみサポートする B) HTTP SNIおよびHTTPS SNI検査で特定ドメインを許可/ブロックし、ワイルドカードをサポート(.example.com) C) DNSクエリのみをブロックする D) 正規表現のみ使用可能

答え: B

解説: Network Firewallドメインリストルールグループは、HTTP HostヘッダーおよびアウトバウンドのHTTPS SNI(Server Name Indication)を検査して、特定ドメインへのトラフィックを許可またはブロックします。.example.comのようにワイルドカードを使用するとサブドメインを含むすべての下位ドメインを処理します。HTTPおよびHTTPSトラフィックのホワイトリスト/ブラックリストポリシーを実装できます。

A) パフォーマンス向上のため B) トラフィックの分離とネットワークセグメンテーションの実装(例: 開発/本番VPCの分離、スポーク間トラフィックのブロック、検査VPCを通じた強制ルーティング) C) コスト削減のため D) AWSサービスの制限のため

答え: B

解説: TGW複数ルートテーブルのユースケース: 1) 環境分離 - ProductionとDevのVPCが直接通信できないよう別のルートテーブルに接続、2) セキュリティ検査 - すべてのEast-Westトラフィックをセキュリティ VPC(Network Firewall、IDS)を通過するよう強制ルーティング、3) 共有サービス - DNS、Active Directoryなどの共有サービスVPCはすべてのスポークと通信可能だが、スポーク間の直接通信はブロック。ブラックホールルーティングで特定CIDRトラフィックを完全にブロックすることも可能です。

A) 複数のオリジンに負荷分散するため B) プライマリオリジン障害時に自動的にセカンダリオリジンにフェイルオーバーするため C) 複数のオリジンのコンテンツをマージするため D) オリジンサーバーのパフォーマンスを向上させるため

答え: B

解説: CloudFrontオリジングループは高可用性のための自動オリジンフェイルオーバーを提供します。プライマリとセカンダリのオリジンをグループとして設定し、プライマリオリジンが指定されたHTTPレスポンスコード(4xx、5xx)を返したり接続に失敗したりすると自動的にセカンダリに切り替わります。例: S3バケットをプライマリ、別リージョンのS3をセカンダリとして設定してリージョン障害に備えます。

A) VPCピアリングは自動的にルーティングを設定する B) ルートテーブルの未更新、セキュリティグループの未許可、NACLのブロック、DNS解決設定の欠如 C) ピアリング状態がActiveでない場合 D) 2つのVPCが異なるリージョンにある場合

答え: B

解説: VPCピアリング後の通信失敗チェックリスト: 1) 両方のVPCのルートテーブルに相手VPCのCIDR → ピアリング接続のルートが追加されているか確認、2) セキュリティグループで相手VPCのCIDRまたはSGをソースとして許可しているか確認、3) NACLで該当トラフィックを許可しているか確認(エフェメラルポートを含む)、4) ピアリング接続のステータスがActiveか確認、5) ピアリングされたVPCのDNS解決オプションが有効化されているか確認。

A) 両タイプは同じ方式で動作する B) インターフェースエンドポイントはENIベースでVPC内にプライベートIPが割り当てられ、コストが発生し、セキュリティグループの適用が可能で様々なサービスをサポート。ゲートウェイエンドポイントはルートテーブルエントリーベースで無料でS3/DynamoDBのみをサポートする C) ゲートウェイエンドポイントがすべてのサービスをサポートする D) インターフェースエンドポイントはパブリックトラフィックを含む

答え: B

解説: エンドポイントタイプの比較: インターフェースエンドポイント - VPCにENIを作成、プライベートIPアドレスを割り当て、セキュリティグループを関連付け可能、エンドポイントごとの時間別コスト + データ処理コスト、ほとんどのAWSサービスをサポート、DNS名でアクセス。ゲートウェイエンドポイント - ルートテーブルにルートを追加、追加コストなし、S3およびDynamoDBのみサポート、ポリシーでアクセスを制御。

A) 外見上の違いはない B) ENAはSR-IOVを通じてハイパーバイザーをバイパスしてハードウェアと直接通信し、最大100Gbpsの帯域幅、より低いレイテンシ、より高いPPS(Packet Per Second)を実現する C) ENAはIPv6のみをサポートする D) ENAは特定のAZでのみ使用可能

答え: B

解説: Enhanced Networking(ENA): SR-IOV(Single Root I/O Virtualization)を使用してハイパーバイザーのオーバーヘッドなしに直接NICと通信します。最大100Gbpsネットワーク帯域幅、高いPPS(パケット処理数)、低いジッター(jitter)。最新世代のEC2インスタンス(C5、M5、R5など)でデフォルトで有効化されています。Intel 82599 VF(10Gbps)もENAの旧バージョンとしてサポートされています。

A) バケットポリシーにCloudFront IPリストを追加する B) Origin Access Control(OAC)を使用 - CloudFrontがAWS SigV4でS3に署名付きリクエストを送り、S3バケットポリシーでCloudFrontサービスプリンシパルのみを許可する C) S3パブリック読み取りを許可してCloudFrontでWAFにより保護する D) Origin Access Identity(OAI)を使用 - 設定がより簡単

答え: B

解説: OAC(Origin Access Control)はOAI(Origin Access Identity)の後継機能でより強力なセキュリティを提供します。OACはSigV4でS3リクエストに署名して認証します。S3バケットポリシーは "Principal": {"Service": "cloudfront.amazonaws.com"} と "Condition": {"StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT:distribution/DIST_ID"}} 条件で特定のCloudFrontディストリビューションのみを許可します。

A) Direct Connect接続の帯域幅を増加させるため B) 単一のPrivate VIFまたはTransit VIFを複数のAWSリージョンのVPCまたはTransit Gatewayに接続する(クロスリージョン接続) C) Direct Connect接続コストを削減するため D) VPN接続をサポートするため

答え: B

解説: Direct Connect Gatewayはオンプレミスから単一のDX接続を使用して複数のAWSリージョンのVPCにアクセスできるようにします。Private VIFをDXGWに接続すると複数リージョンのVPCに単一VIFでアクセス可能になります。Transit VIFをDXGWに接続するとTransit Gateway経由で複数のVPCにアクセスします。ただし、DXGWは同一アカウントと同一リージョンのVPC間のルーティングは提供しません。

A) すべてのヘッダー、クエリ文字列、クッキーをキャッシュキーに含める B) キャッシュポリシー(Cache Policy)で実際にキャッシュ結果に影響するヘッダー、クエリ文字列、クッキーのみをキャッシュキーに含め、残りはオリジンリクエストポリシー(Origin Request Policy)でオリジンにのみ転送する C) すべてのキャッシングを無効化する D) CloudFrontディストリビューション設定を変更する

答え: B

解説: CloudFrontキャッシュヒット率の最適化: キャッシュキーに含まれる項目が多いほどキャッシュエントリー数が多くなりヒット率が低下します。例: User-Agentヘッダーをキャッシュキーに含めると、ブラウザごとに別のキャッシュエントリーが作成されます。キャッシュポリシーには実際にレスポンスに影響するパラメーターのみを含め、オリジンへの転送が必要でもキャッシュキーに不要な情報(認証ヘッダーなど)はオリジンリクエストポリシーに分離します。

A) RDSインスタンスにパブリックIPを割り当てる B) Direct ConnectまたはSite-to-Site VPNでオンプレミス - VPC間を接続し、RDSサブネットのセキュリティグループでオンプレミスCIDRを許可し、Route 53 Resolver経由でRDS DNS名を解決する C) RDSプロキシをインターネットに公開する D) Lambdaを中間層として使用する

答え: B

解説: オンプレミス - RDSプライベートアクセスアーキテクチャ: 1) DXまたはVPNでネットワーク接続、2) RDSインスタンスが存在するサブネットのセキュリティグループでオンプレミスIP範囲からのDBポート(3306、5432など)のインバウンドを許可、3) Route 53 ResolverインバウンドエンドポイントでオンプレミスからRDS DNS名(FQDN)を解決、4) RDSのパブリックアクセスを無効化。Secrets ManagerでDB認証情報管理を推奨。

A) 各スポークVPCにNetwork Firewallをデプロイする B) 検査VPC(Inspection VPC)にNetwork Firewallを中央デプロイし、TGWでスポークVPCのトラフィックを検査VPCへ強制ルーティングする(Appliance Modeを有効化) C) セキュリティグループでスポーク間の直接通信を制御する D) WAFでEast-Westトラフィックを検査する

答え: B

解説: 中央集中型East-Westトラフィック検査: 1) 検査VPCにNetwork Firewallエンドポイントをデプロイ、2) TGWに検査VPCを接続、3) TGWのルートテーブルでスポークVPC間のトラフィックを検査VPCへルーティング、4) 検査VPCのTGWアタッチメントにAppliance Modeを有効化(非対称ルーティングを防止)、5) 検査VPC内でトラフィックがNetwork Firewallを通過後、宛先のスポークVPCに転送。

A) 両ポリシーは同一の結果を提供する B) レイテンシベースはAWSが測定したネットワークレイテンシを基準に最適なリージョンにルーティング(より速い応答)。地理的位置はユーザーのIPの場所を基準に特定地域の規制準拠/コンテンツ提供に使用 C) 地理的位置が常により低いレイテンシを提供する D) レイテンシベースはIPアドレスベース

答え: B

解説: Latencyルーティング: AWSが測定したリージョン間の実際のネットワークレイテンシを基準に最も速いレスポンスを提供するリージョンにルーティング。パフォーマンス最適化に適しています。Geolocationルーティング: ユーザーのIPアドレスから国/大陸/州を判断して、その場所に合ったリソースにルーティング。GDPR(EUデータ主権)、地域別コンテンツ(言語、価格)、コンプライアンスに適しています。ユーザーの実際の物理的な場所が必ずしもレイテンシが低い場所と一致するとは限りません。

A) セカンダリCIDRは追加不可 B) VPCと重複しないCIDRを追加可能。既存の接続(ピアリング/TGW)のCIDRと重複してはならない。合計5個までCIDRブロックが可能(デフォルト値) C) セカンダリCIDRは必ずプライマリCIDRのサブセットでなければならない D) セカンダリCIDRを追加する際には既存のサブネットを再作成する必要がある

答え: B

解説: VPCセカンダリCIDRブロックの制限: 1) プライマリVPC CIDRと重複してはならない、2) 接続されているVPCピアリングやTGWの他のVPC CIDRと重複してはならない、3) RFC 1918アドレス範囲の使用を推奨、4) デフォルト最大5個のCIDRブロック(AWS Supportに制限増加を依頼可能)、5) 特定のCIDR範囲は予約されていて使用不可(例: 198.19.0.0/16はAWS内部使用)。

A) 複雑なディープパケットインスペクション(DPI)を実行する B) パケットごとの個別処理(セッション追跡なし)、シンプルな5-tuple(プロトコル、ソース/宛先IP、ソース/宛先ポート)ベースの許可/拒否/フォワードの決定 C) DNSクエリの検査 D) TLSの検査

答え: B

解説: Statelessルールグループは各パケットを独立して処理します(SGと異なりセッション状態の追跡なし)。5-tupleベースでパケットを許可、拒否、またはStatefulルールグループにフォワードします。高性能な基本フィルタリングに使用します。Statefulルールグループはセッションを追跡してより精緻な検査(HTTP検査、Suricata IDSルール、TLS SNI検査)を実行します。

A) SD-WANはAWSでサポートされていない B) EC2にSD-WAN仮想アプライアンス(VMware SD-WAN、Cisco Viptelaなど)をデプロイするか、Transit Gateway Network Managerと連携する C) 直接API統合のみ可能 D) AWS Marketplaceからのみデプロイ可能

答え: B

解説: AWSでのSD-WAN統合方法: 1) EC2にSD-WANアプライアンスの仮想インスタンスをデプロイし、Site-to-Site VPNまたはDirect ConnectでオンプレミスのSD-WANファブリックと接続、2) Transit Gateway Network ManagerのSD-WANデバイス登録機能でグローバルネットワークを可視化、3) AWS MarketplaceのサードパーティSD-WANソリューションAMIを活用。SD-WANは拠点ネットワークを一元管理し、複数のWANリンクを最適化します。

A) 各アカウントに別々のRoute 53ホストゾーンを作成する B) 共有サービスVPCにRoute 53 Resolverエンドポイントとプライベートホストゾーンを中央配置し、RAM(Resource Access Manager)でResolverルールを他のアカウントと共有する C) パブリックDNSのみを使用する D) 各アカウントに独立したDNSサーバーを設定する

答え: B

解説: 中央集中型DNSアーキテクチャ: 1) 共有サービスアカウントの中央VPCにRoute 53インバウンド/アウトバウンドエンドポイントをデプロイ、2) すべての内部ドメインのプライベートホストゾーンを中央VPCに関連付け、3) RAMでResolverフォワーディングルールを他のアカウントと共有、4) スポークアカウントのVPCで共有されたResolverルールを関連付けて中央DNSにフォワーディング。これにより一貫したネームスペースとDNSポリシー管理が可能になります。

A) 該当IPをすべてのインスタンスのSGで手動にブロックする B) WAF IPセットまたはNACLにブロックルールを追加するか、Network Firewallのステートレスルールで該当IPをブロックする C) EC2インスタンスを終了する D) インターネットゲートウェイを削除する

答え: B

解説: ポートスキャン攻撃への対応: 1) Network Firewall(最も速いブロック - ネットワークレイヤーでブロック)、2) WAF IPセット(HTTP/HTTPSトラフィックのブロック、ALB/CloudFrontの前段)、3) NACL(サブネットレイヤーでブロック、ただし手動でルール数の制限あり)。GuardDutyが有効化されていれば Recon:EC2/PortProbeUnprotectedPort検出結果を受け取れます。自動化された対応はEventBridge + LambdaでNACLまたはWAF IPセットを自動更新します。

A) 両タイプは技術的に同一 B) Dedicated Connectionは単一顧客専用の物理接続(1Gbps、10Gbps、100Gbps)。Hosted Connectionはパートナー経由でより小さな帯域幅(50Mbps〜10Gbps)を共有インフラで提供する C) Hosted Connectionの方が高価 D) Dedicated Connectionはより多くの仮想インターフェースをサポートする

答え: B

解説: DX接続タイプ: Dedicated Connection - AWSと顧客間の専用物理イーサネット接続。1/10/100Gbps。最大50個のVIFを作成可能。Hosted Connection - AWS Direct Connectパートナーが提供。50Mbps〜10Gbps。VIF 1個のみ作成可能(ホステッドVIF)。小規模な帯域幅が必要な場合や、迅速なプロビジョニングが必要な場合はHosted Connectionが適しています。

A) リアルタイム分析が必要な場合 B) コスト削減(S3の保存コストはCW Logsより低い)、Athenaによる大容量長期分析、S3 Lifecycleポリシーによるデータ保管管理、サードパーティSIEM統合 C) より速い収集のため D) CloudWatch LogsはFlow Logsをサポートしていない

答え: B

解説: Flow Logs保存先の選択: CloudWatch Logs - リアルタイムモニタリング、メトリクスフィルター、アラーム、サブスクリプションフィルター(Lambda、Kinesisへのストリーミング)、コストが高い。S3 - 大容量データの費用対効果の高い保存、Athenaによる直接クエリ、サードパーティツール統合、Glacierアーカイブ。両方の宛先を同時に使用することもできます。大規模な環境ではS3 + Athenaがデフォルトで、リアルタイムのセキュリティアラームはCloudWatchサブスクリプションフィルターでLambdaをトリガーします。

A) サービスが中断される B) Global Acceleratorが自動的に正常な他のエンドポイント(別のリージョンまたはAZ)にトラフィックをルーティングする C) ユーザーが手動でフェイルオーバーを実行する必要がある D) DNSキャッシュが期限切れになるまで待つ必要がある

答え: B

解説: Global Acceleratorのヘルスチェックは TCP、HTTP、HTTPSをサポートし、各エンドポイント(ALB、NLB、EIP、EC2)の状態を継続的に確認します。エンドポイント障害を検出すると1分以内にトラフィックを正常なエンドポイントに自動リダイレクトします。これはRoute 53ヘルスチェック(DNS TTLに依存)よりもはるかに速いフェイルオーバーを提供します。また、トラフィックダイヤル(Traffic Dial)で特定のエンドポイントグループのトラフィック比率を0に設定して手動フェイルオーバーも可能です。

A) TLSトラフィックの暗号化キーを確認できる B) TLS復号化(SSLインスペクション)を実行してHTTPSペイロードを検査する。Network FirewallがMITM(中間者)の役割を果たし、ACM Private CAで発行した証明書を使用する C) TLS 1.0以下のみ検査可能 D) TLS検査はパフォーマンスに影響がない

答え: B

解説: Network Firewall TLS検査: アウトバウンドまたは双方向のTLSトラフィックを復号化してSuricataルールで検査できます。Network FirewallがMITM(Man-In-The-Middle)の役割を実行するため、ACM Private CAで発行したCA証明書が必要で、クライアントがこのCAを信頼する必要があります。検査後、元の宛先と新しいTLSセッションを確立します。パフォーマンスへの影響があるため、適切なキャパシティプランニングが必要です。

A) VPCアタッチメント B) VPNアタッチメント C) Direct Connect Gatewayアタッチメント D) S3バケットアタッチメント

答え: D

解説: Transit Gatewayがサポートするアタッチメントタイプ: 1) VPC - TGWとVPCを接続、2) VPN - Customer GatewayとIPSec VPN接続、3) Direct Connect Gateway - DXGWを通じたDX接続、4) Transit Gatewayピアリング - 別のTGWとのピアリング(リージョン間または同一リージョン内)、5) Connect - SD-WANデバイスとGRE/BGPで接続。S3バケットはTGWアタッチメントタイプではありません。

A) HTTPクッキーベースのセッション固定が必要な場合 B) 超低レイテンシ、極めて高いスループット(数百万RPS)、TCP/UDP/TLSパススルー、固定IPアドレス、PrivateLinkバックエンドサービスの公開が必要な場合 C) パスベースのルーティングが必要な場合 D) WAF統合が必要な場合

答え: B

解説: NLBのユースケース: 1) 極めて高いスループットと超低レイテンシ(マイクロ秒レイテンシ)、2) TCP/UDP/TLSトラフィックのパススルー(Layer 4)、3) 固定IPアドレスの提供(EIPの接続が可能)、4) PrivateLinkサービスのエンドポイントとして使用、5) ソースIPの保存(クライアントIPをバックエンドに直接転送)。ALBはHTTP/HTTPS(Layer 7)、パス/ヘッダーベースのルーティング、WAF統合に適しています。

A) 競合を防ぐために1度に1つのトンネルのみアクティブにする B) 両方のトンネルをアクティブにし、BGPまたは静的ルーティングで両方のトンネルを使用する(Active/ActiveまたはActive/Standby) C) トンネル数はパフォーマンスに影響しない D) 2番目のトンネルはAWSが自動管理する

答え: B

解説: AWS Site-to-Site VPNは常に2つのIPSecトンネルを提供します(高可用性)。両方のトンネルをアクティブにすることがベストプラクティスです。BGP使用時: 両方のトンネルでBGPセッションを維持し、MED値またはAS Pathでプライマリ/セカンダリトンネルを設定します。Transit GatewayとECMPを使用すると両方のトンネルをActive/Activeで設定して帯域幅を集約できます。1つのトンネルのみアクティブにするとAWSのメンテナンス作業中に接続が切断される可能性があります。

A) CloudFrontキャッシュのTTLを0に設定する B) オリジングループでセカンダリオリジンへのフェイルオーバーを設定し、オリジン応答タイムアウト値を増加し、AWS Shield AdvancedでDDoS防御し、WAFレート制限でオリジンの過負荷を防ぐ C) CloudFrontディストリビューションを削除してオリジンに直接アクセスする D) Route 53ヘルスチェックでオリジンの状態を確認する

答え: B

解説: CloudFrontオリジンエラー削減戦略: 1) オリジングループで自動フェイルオーバー(プライマリオリジン失敗時にセカンダリに切り替え)、2) オリジン応答タイムアウトを増加(デフォルト30秒、最大60秒に増加可能)、3) オリジン接続試行回数を増加(デフォルト3回)、4) WAFレート制限でオリジンの過負荷を防ぐ、5) AWS Shield AdvancedでDDoS攻撃によるオリジンの過負荷を防ぐ、6) スケーリングの自動化でオリジン容量を拡張。