ANS-C01 の無料練習問題
高度なネットワーキング 専門知識

この問題では、3つの仕組みを同時に当てはめる必要があります。1つ目は、ELBヘルスチェックを有効にしたAuto Scalingグループでは、アタッチしたロードバランサーのいずれかが異常と報告したインスタンスが置き換え対象になることです。2つ目は、ヘルスチェックの猶予期間中はAuto Scalingグループがヘルス状態をチェックしないことです。3つ目は、各ロードバランサーが自身で正常と判定したインスタンスにだけトラフィックを分散することです。 選択肢Cは、この3点すべてと一致するため正解です。Xは置き換え対象になり、Yは猶予期間の経過を待つことになります。トラフィックについては、インターネット向けApplication Load BalancerだけがXとYを分散先から外します。 選択肢Aは、Yが猶予期間中であることを見落とし、Yも直ちに置き換えるとしている点が誤りです。 選択肢Bは、置き換えの扱いは正しいものの、置き換えまでの間もインターネット向けApplication Load Balancerが異常なインスタンスにトラフィックを送り続けるとしている点が誤りです。 選択肢Dは、正常と報告したターゲットグループの数による多数決で維持されると誤解しています。そのため、猶予期間を過ぎたXが置き換え対象になることを見落としています。

A：「いずれかのロードバランサーが異常と報告すれば置き換え対象になる」という判定基準と、ロードバランサーが正常なインスタンスにだけトラフィックを分散する点は正しいです。しかしインスタンスYは、InService状態に入ってから90秒しか経っていません。猶予期間300秒の間、Auto ScalingグループはYのヘルス状態をまだチェックしません。そのため、Yも直ちに置き換えるという記述は誤りです。

B：XとYに対するAuto Scalingグループの扱いは正しいです。一方、トラフィック分散の記述が誤りです。ロードバランサーは、登録済みインスタンスのうち自身のヘルスチェックで正常と判定したものにだけトラフィックを分散します。したがって、TG-3で異常と報告されているXとYには、インターネット向けApplication Load Balancerからトラフィックが送られません。Auto Scalingグループが置き換えを実行するまで待つ必要はありません。

C：ELBヘルスチェックが有効なため、アタッチしたロードバランサーのいずれかが異常と報告したインスタンスは置き換え対象になります。数時間稼働しているXは、TG-3の異常報告によって置き換え対象となります。Yは、InService状態に入ってから猶予期間の300秒が経過するまで、Auto Scalingグループによるヘルスチェックを受けません。また、各ロードバランサーは自身が正常と判定したインスタンスにだけトラフィックを分散します。そのため、インターネット向けApplication Load BalancerはXとYを分散先から除外します。TG-1・TG-2のロードバランサーは、両インスタンスを正常と判定しているため分散を続けます。置き換え判定・猶予期間・ロードバランサーごとの分散という3点すべてと整合するのはこの選択肢だけです。

D：ロードバランサーごとのトラフィック分散の記述は正しいです。しかし、置き換え判定を多数決と誤解しています。ELBヘルスチェックを有効にしたAuto Scalingグループでは、アタッチしたロードバランサーのいずれか1つが異常と報告すれば、そのインスタンスは置き換え対象になります。正常と報告した数が多いことは維持の理由になりません。そのため、猶予期間を過ぎているXは置き換え対象になり、この記述は誤りです。

学習のポイント：Auto Scalingグループによる置き換え判定(いずれかのロードバランサーが異常と報告すれば対象、ただし猶予期間中はチェックしない)と、各ロードバランサーによるトラフィック分散(自身が正常と判定したインスタンスのみ)は、別々の仕組みとして同時に働く。

公式ドキュメント

• attach-load-balancer-asg.html
• tutorial-ec2-auto-scaling-load-balancer.html

この設計では、インスタンスの正常性判定に二つの独立したルールが同時に作用します。一つは複数のターゲットグループ間の判定ルールで、TG-HTTPとTG-TCPの両方が正常と報告した場合に限りインスタンスは正常とみなされ、いずれか一方でも異常と報告すれば、他方が正常であってもインスタンスは置換されます(選択肢E・Aが正しく、これに反する選択肢Dは誤りです)。もう一つはヘルスチェックの種類間の判定ルールで、ELBヘルスチェックを有効にした場合、Auto ScalingグループはEC2ステータスチェックまたはELBヘルスチェックのいずれかに失敗したインスタンスを異常とみなします。このためEC2ステータスチェックの結果が無視されることはなく(選択肢Bは誤り)、両方のターゲットグループが正常と報告していてもEC2ステータスチェックに失敗していればインスタンスは異常と判定されます(選択肢Cは正しい)。この二層のAND/OR条件を正しく理解しないと、意図しない置換やコスト増加につながる可能性があります。

A：いずれか一つのターゲットグループが異常と報告した場合、他のターゲットグループが正常と報告していてもAuto Scalingグループはそのインスタンスを置換するというルールに合致するため、この記述は正しいです。

B：ELBヘルスチェックを有効にした場合、Auto ScalingグループはEC2ステータスチェックまたはELBヘルスチェックのいずれかに失敗したインスタンスを異常とみなします。EC2ステータスチェックの結果が無視されるわけではなく、両方の結果が判定に使われるため、この記述は誤りです。

C：ELBヘルスチェックを有効にすると、Auto ScalingグループはEC2ステータスチェックまたはELBヘルスチェックのいずれかに失敗したインスタンスを異常とみなします。したがってターゲットグループの判定結果が両方とも正常であっても、EC2ステータスチェックに失敗していればインスタンスは異常と判定されるため、この記述は正しいです。

D：複数のターゲットグループ(またはClassic Load Balancer)が同じAuto Scalingグループに接続されている場合、インスタンスが正常とみなされるにはすべてのターゲットグループが正常と報告する必要があり、いずれか一つでも異常と報告すれば、他が正常と報告していてもAuto Scalingグループはそのインスタンスを置換します。したがってTG-TCPが正常でもTG-HTTPが異常であればインスタンスは置換対象となるため、この記述は誤りです。

E：複数のターゲットグループが接続されている場合、インスタンスを正常とみなすにはそれらすべてが正常と報告することが条件となります。TG-HTTPとTG-TCPの両方が正常と報告して初めてインスタンスは正常とみなされるため、この記述は正しいです。

学習のポイント：複数のターゲットグループを同一のAuto Scalingグループに接続した場合はAND条件(全て正常でなければ正常とみなされない)で判定され、EC2ステータスチェックとELBヘルスチェックの間はOR条件(いずれかの失敗で異常とみなされる)で判定されるという、二種類の異なる論理を組み合わせて正誤を判断する必要がある。

公式ドキュメント

• getting-started-elastic-load-balancing.html

この構成ではファイアウォール所有者であるアカウントAが、ファイアウォールの作成・設定管理、他アカウントへの共有、プライマリエンドポイントと追加エンドポイントの請求の一括受領、全エンドポイントのメトリクス可視性とフローオペレーションの実行という能力を持つ。一方、共有を受けてVPCエンドポイントアソシエーションを作成したアカウントB・アカウントC(VPCエンドポイントアソシエーション所有者)は、自身のVPC内でエンドポイントアソシエーションを作成し、そこを経由してトラフィックをルーティングするが、ファイアウォールで定義された設定をそのまま使用するのみで、設定変更や請求・可視性・フローオペレーションの権限は持たない。選択肢Aはこの役割分担を正しく反映しており、要件(1)〜(4)のすべてを満たす。選択肢Bは請求がアカウントB・Cに個別発生するとしており、請求一本化の要件(3)に反する。選択肢Cはアカウントb・Cが独自に設定変更できるとしており、設定の一元管理という要件(2)に反する。選択肢Dはメトリクス可視性とフローオペレーションの権限をアカウントB・Cに与え、アカウントAの可視性を限定しており、要件(4)に反する。

A：ファイアウォール所有者(アカウントA)はファイアウォールの作成・設定管理、共有、請求の一本化、全エンドポイントのメトリクス可視性とフローオペレーション実行という能力を持つ一方、VPCエンドポイントアソシエーション所有者(アカウントB・C)は自身のVPC内でエンドポイントアソシエーションを作成してトラフィックをルーティングし、ファイアウォールで定義された設定をそのまま使用するとされている。この記述は4つの要件すべてに整合する。

B：ファイアウォール所有者はプライマリエンドポイントだけでなく追加のファイアウォールエンドポイントについても一括して請求を受けるとされており、VPCエンドポイントアソシエーション所有者に個別請求が発生するという記述はこの原則と矛盾する。要件(3)の『請求をアカウントAに一本化する』を満たせない。

C：VPCエンドポイントアソシエーション所有者は、自身のVPCエンドポイントアソシエーションに対してファイアウォールで定義された設定をそのまま使用するとされており、独自に設定を変更できるという記述は誤りである。要件(2)の『アカウントB・Cは設定を変更できないようにする』を満たせない。

D：メトリクスへの可視性とフローオペレーションの実行は、プライマリエンドポイントおよび追加のファイアウォールエンドポインの双方についてファイアウォール所有者(アカウントA)の能力とされており、VPCエンドポイントアソシエーション所有者にこれらの権限があるという記述、およびアカウントAの可視性がプライマリエンドポイントに限られるという記述は誤りである。要件(4)を満たせない。

学習のポイント：ファイアウォール所有者(設定管理・請求一括・全エンドポイントの可視性とフローオペレーション)とVPCエンドポイントアソシエーション所有者(自身のVPCでのエンドポイントアソシエーション作成とルーティングのみ、設定は所有者定義のまま使用)という役割分担を、請求・設定変更可否・可視性/フローオペレーションという複数の観点で同時に正しく特定できるかが鍵となる。

公式ドキュメント

• firewall-owners-and-vpc-endpoint-association-owners.html

複数のコンテンツタイプ（静的、動的、ストリーミング、スクリプト）を含むアプリケーションを、単一ドメインでグローバルに低レイテンシで配信する場合、CloudFrontとRoute53の統合が最適な解決策です。 CloudFrontはウェブコンテンツ全体を、グローバルなエッジロケーションネットワークから配信でき、ユーザーの位置に最も近いエッジロケーションにリクエストをルーティングします。これにより、世界中のユーザーが最も低いレイテンシでコンテンツを受け取ることができます。Route53からCloudFrontディストリビューションにエイリアス設定することで、app.example.com という単一ドメインでありながら、全種類のコンテンツを統一的に配信する仕組みが実現されます。 A案は、Route53でAPI Gatewayに直接ルーティングするアプローチです。これはAPI Gatewayへのルーティングが技術的に可能ですが、エッジロケーションネットワークを活用しないため、特にキャッシュ可能なコンテンツについてレイテンシが高くなり、複数コンテンツタイプの統一配信にも向きません。 C案は、オリジンをコンテンツタイプ別に分割し、サブドメインで使い分けるアプローチです。管理上の利点がある可能性もありますが、「単一ドメイン」という要件に矛盾し、複数の独立したルーティングパスが生じるため、エッジロケーションネットワークの統一的な活用ができません。 D案は、複数リージョンのELBへの地理位置情報ベースルーティングです。ELBは負荷分散には適していますが、グローバルなエッジキャッシングやレイテンシ最適化を提供しません。地理的に遠いユーザーはリージョンエンドポイントまでの長い通信距離を経験することになり、最低レイテンシの要件を満たしません。

A：このアプローチではAPI Gatewayが直接リクエストに応答する必要があり、グローバルなエッジロケーションネットワークによるキャッシング機能を活用できません。特に静的コンテンツ、画像、ストリーミング動画といったキャッシュ可能なコンテンツについて、各リージョンのAPI Gateway インスタンスまでの往復通信が発生するため、世界中のユーザーに最も低いレイテンシを提供する要件を満たせません。また、複数コンテンツタイプの統一的な配信も実装しにくくなります。

B：CloudFrontはグローバルなエッジロケーションネットワークを通じて、静的コンテンツ、動的コンテンツ、ストリーミング、インタラクティブコンテンツなど、あらゆるタイプのコンテンツを統一的に配信できます。Route53からCloudFrontディストリビューションにエイリアス設定することで、app.example.com への全リクエストが最も低いレイテンシを提供するエッジロケーションにルーティングされます。複数のコンテンツタイプを単一ドメインで統一的に配信しながら、グローバルな最低レイテンシを実現する最適なアプローチです。

C：このアプローチはオリジンの分離により管理しやすくなる利点がある一方で、要件で指定された「単一ドメインでの統一アクセス」を実現できません。複数のサブドメインを使用することになり、ユーザー体験が分断されます。また、サブドメイン別のルーティングは各オリジンへの独立したアクセスをもたらし、エッジロケーションネットワークからの統一的なコンテンツ配信と低レイテンシの最適化を十分に活かせません。

D：ELBは複数インスタンス間の負荷分散には対応していますが、グローバルなエッジロケーションネットワークやコンテンツキャッシング機能を提供しません。Route53で各リージョンのELBに地理位置情報ベースでルーティングしても、各リージョンのロードバランサーまでの距離が遠いユーザーは高レイテンシを経験します。また、複数のコンテンツタイプを各リージョンのサーバーで直接処理する必要があり、エッジからのキャッシング配信による効率化が得られません。結果として、世界中のユーザーに最も低いレイテンシを提供する要件を満たしません。

学習のポイント：複数のコンテンツタイプをグローバルに低レイテンシで単一ドメインで配信する場合、CloudFrontのグローバルエッジロケーションネットワークとRoute53の統合が必須です。CloudFrontはあらゆるコンテンツタイプに対応でき、エッジロケーションから最も低いレイテンシでユーザーにルーティングします。

公式ドキュメント

• integration-with-other-services.html

Bが正解です。サービスネットワーク型VPCエンドポイントを使うとインターネットゲートウェイなしでサービスネットワーク内のサービスへプライベートに接続でき、接続の開始方向もエンドポイントを持つVPCからサービスネットワーク側へ限られます。エンドポイントはAZごとに1つのサブネットを指定でき、指定した各サブネットにElastic Network Interfaceが作成されるため、両AZにアクセス経路を配置できます。さらにレイヤー7のサービス向けにはAZごとに連続した16個の空きIPv4アドレスが必要で、それを満たすサブネットをap-northeast-1cに用意する必要があります。Dは接続方式は正しいものの、ap-northeast-1aのサブネットしか指定しないためap-northeast-1cにElastic Network Interfaceが作成されず、可用性の要件を満たしません。Aは両AZを指定しますが、ap-northeast-1cの既存サブネットには連続した空きIPv4アドレスが8個しかなく、必要な連続ブロックを確保できません。Cはエンドポイントを作成しないためサービスネットワーク内のAPIへのプライベートアクセス手段にならず、接続開始方向の制限も満たしません。

A：両AZを指定する方針は正しいものの、サービスネットワークに関連付けられたレイヤー7のサービス向けには、AZごとに連続した16個の空きIPv4アドレス(/28)が割り当てられます。ap-northeast-1cのサブネットは空きが断片的な8個しかなく、この連続ブロックを確保できないため、この構成はそのままでは成立しません。

B：サービスネットワーク型VPCエンドポイントはインターネットゲートウェイなしでサービスネットワーク内のサービスへプライベートに接続でき、接続を開始できるのはエンドポイント側のVPCからに限られます。AZごとに1つのサブネットを指定して各サブネットにElastic Network Interfaceが作成されるため、両AZにアクセス経路を確保できます。レイヤー7のサービスにはAZごとに連続した16個の空きIPv4アドレスが必要なので、ap-northeast-1c側は条件を満たす新しいサブネットを用意することで成立します。

C：ピアリングと経路追加ではタスクのVPCにサービスネットワーク型VPCエンドポイントが作成されず、サービスネットワークに関連付けられたAPIへのプライベートアクセス手段になりません。また双方向に到達できる経路となるため、API側から接続を開始させないという要件も満たしません。

D：接続方式としては適切ですが、エンドポイントのElastic Network Interfaceが作成されるのは指定したサブネットだけです。ap-northeast-1aのみを指定するとap-northeast-1c側にアクセス経路が存在せず、1aが利用できなくなったときにAPIへ到達できなくなるため、可用性の要件を満たしません。

学習のポイント：サービスネットワーク型VPCエンドポイントはAZごとに1つのサブネットを指定でき、指定した各サブネットにElastic Network Interfaceが作られるが、レイヤー7のサービス向けにはAZごとに連続した16個の空きIPv4アドレスが必要なため、両AZに経路を置くにはアドレス空間の条件を満たすサブネットを用意する必要がある。

公式ドキュメント

• privatelink-access-service-networks.html