AWS認定資格 WEB問題集&徹底解説

セキュリティ-専門知識

正解 C問題
分野3:インフラストラクチャのセキュリティ タスクステートメント3.3:ネットワークセキュリティコントロールを設計し、トラブルシューティングする。
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある小売企業は、東京リージョン(ap-northeast-1)のVPC-Aと大阪リージョン(ap-northeast-3)のVPC-Bを、同一AWSアカウント内でVPCピアリング接続により相互接続している。両VPCのルートテーブルには、ピアリング接続を経由する経路がすでに設定済みである。

VPC-Aには、セッションキャッシュ用のAmazon ElastiCache for Redisクラスターがあり、専用のセキュリティグループでアクセスが制御されている。VPC-Bには、CPU使用率に応じてタスク数が増減するAmazon ECS on Fargateのサービスがあり、起動されたタスクにはサービス専用のセキュリティグループが割り当てられている。VPC-BのECSタスクから、VPC-Aのキャッシュクラスターへ支障なくアクセスできるようにする必要がある。

ルートテーブルの設定以外に追加で必要な対応はどれか。
  • VPC-BのECSタスク用セキュリティグループに、送信先をVPC-AのCIDRブロックとするアウトバウンドルールを追加する
  • VPC-Bのルートテーブルに、VPC-A側に配置したNATゲートウェイを経由するルートを追加する
  • VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのCIDRブロックとするインバウンドルールを追加する
  • VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのECSタスク用セキュリティグループのIDとするインバウンドルールを追加する
解説 頻出度★★★★★
この問題は、「異なるリージョン間の VPC ピアリング × セキュリティグループ × 数が増減する ECS タスク」の要件で、ピア VPC のセキュリティグループは別リージョンでは参照できず、CIDR ブロックで許可すると判断できるかがポイント

A. VPC-BのECSタスク用セキュリティグループに、送信先をVPC-AのCIDRブロックとするアウトバウンドルールを追加する

セキュリティグループはステートフルで、既定のアウトバウンドルールは「すべての送信先へすべてのトラフィックを許可」です。ECS タスク側から出ていく通信は最初から許可されており、戻りの通信もインバウンドルールなしで自動的に通ります
通信が届かない原因は送信側ではなく受信側(Redis クラスターの SG)でインバウンドが閉じていることにあるため、アウトバウンドを追加しても状況は変わりません。

B. VPC-Bのルートテーブルに、VPC-A側に配置したNATゲートウェイを経由するルートを追加する

NAT ゲートウェイはプライベートサブネットからインターネットへ出るための仕組みで、VPC ピアリング経由のプライベート通信には関与しません。
そもそも VPC ピアリング接続のトラフィックを NAT ゲートウェイ経由でルーティングすることはできず(ピア VPC の NAT ゲートウェイ・NAT インスタンス・インターネットゲートウェイは利用できない)、問題文でもルートテーブルはすでに設定済みと明示されています。経路の問題ではありません。

正解

C. VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのCIDRブロックとするインバウンドルールを追加する

正解です。異なるリージョン間の VPC ピアリングではピア VPC のセキュリティグループを参照できないため、送信元にはVPC-B の CIDR ブロックを指定します。
Redis クラスター用セキュリティグループに「送信元 = VPC-B の CIDR、ポート 6379」のインバウンドルールを追加すれば、Fargate タスクが増減して IP アドレスが変わっても、VPC-B 内から出た通信はすべて許可されます。
ルートテーブル以外に必要な追加設定は、この受信側のインバウンド許可だけです。

D. VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのECSタスク用セキュリティグループのIDとするインバウンドルールを追加する

「SG を SG で参照する」は同一リージョン内では推奨される書き方ですが、別リージョンにあるピア VPC のセキュリティグループは参照できません(AWS 公式に「代わりにピア VPC の CIDR ブロックを使用する」と明記)。
東京リージョンの SG に大阪リージョンの SG ID を指定しようとしてもルール自体を作成できません。同一リージョンのピアリングであれば最善手になるだけに、最も紛らわしい誤答です。

構成図

VPC-B(大阪 ap-northeast-3)              VPC-A(東京 ap-northeast-1)
  ECS on Fargate タスク  ──ピアリング──▶  ElastiCache for Redis
  (タスク用 SG・台数増減)                 (クラスター用 SG)
                                            ▲ インバウンド許可の送信元は
                                              VPC-B の CIDR ブロック
                                              (別リージョンの SG ID は指定不可)
これだけ覚える(記憶フック)
SG 参照は「同一リージョンのピアリング」限定。リージョンをまたいだら CIDR で開ける。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
VPC-A(東京)と VPC-B(大阪)という異なるリージョン間のピアリング インターリージョンのピアリングではピア VPC の SG を参照できない。送信元には CIDR ブロックを使う
→選択肢(D)を消す
両 VPC のルートテーブルは設定済みと明示されている 経路はすでに完成しており、NAT ゲートウェイの追加は不要(ピアリング経由のトラフィックは NAT を通せない)
→選択肢(B)を消す
Redis クラスターは専用のセキュリティグループでアクセス制御されている 受信側の SG は既定でインバウンドをすべて拒否。到達させるにはインバウンドルールの追加が必須
→選択肢(C)が正解
ECS タスク側のセキュリティグループから出ていく通信 SG はステートフルで既定のアウトバウンドは全許可。戻り通信も自動で通るため送信側の追加は不要
→選択肢(A)を消す
CPU 使用率に応じて Fargate タスク数が増減する(IP が固定でない) 個々のタスク IP ではなくVPC-B の CIDR ブロックで許可すれば、スケールしても設定変更が要らない
→選択肢(C)が正解
ひっかけポイント
  • 選択肢 D の「送信元にピア SG の ID を指定」は同一リージョンのピアリングなら正解の書き方。問題文がリージョン名(ap-northeast-1 と ap-northeast-3)を明示している時点で、SG 参照は使えないと判断する
  • 「アウトバウンドを開ける」は一見必要そうに見えるが、SG はステートフルかつ既定で全アウトバウンド許可。SG で追加設定が要るのは原則受信側のインバウンドだけ
  • NAT ゲートウェイはインターネットへの出口であってピアリングの経路装置ではない。「ルートテーブルは設定済み」と書かれた時点でルーティング系の選択肢は候補から外れる
  • タスク数が増減する構成では個別 IP のホワイトリスト運用は破綻する。CIDR 単位で許可するのが定石という点も本問の隠れた論点
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「VPC-A と VPC-B が同一リージョンにある」 ピア SG の ID を送信元に指定する方式(選択肢 D 相当)が正解に。CIDR より粒度が細かく推奨される。
「ピアリングではなく Transit Gateway で複数 VPC を接続している」 同じくSG 参照は不可で CIDR 許可+TGW ルートテーブルの設計が論点に(同一リージョンなら SG 参照をサポートする構成もある)。
「ルートテーブルにピアリング経由の経路が入っていない SG ではなくルートテーブルへのピアリング接続経路の追加が正解軸に。
「Redis への通信をアカウントをまたいで許可したい(同一リージョン)」 SG 参照はクロスアカウントでも可能(ピアリング済みかつ同一リージョンなら peer-owner-id 付きで参照)。
「サブネット単位で特定の CIDR からの通信だけを拒否したい」 SG では拒否ルールを書けないため、ネットワーク ACL が正解軸に。
関連サービスの解説 Amazon Elastic Container Service (Amazon ECS)
Amazon ElastiCache
Amazon VPC
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
インターリージョン VPC ピアリングでのセキュリティグループ参照の制限 ピアセキュリティグループを参照するようにセキュリティグループを更新する
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 0%
No.11 解説
ある小売企業は、東京リージョン(ap-northeast-1)のVPC-Aと大阪リージョン(ap-northeast-3)のVPC-Bを、同一AWSアカウント内でVPCピアリング接続により相互接続している。両VPCのルートテーブルには、ピアリング接続を経由する経路がすでに設定済みである。

VPC-Aには、セッションキャッシュ用のAmazon ElastiCache for Redisクラスターがあり、専用のセキュリティグループでアクセスが制御されている。VPC-Bには、CPU使用率に応じてタスク数が増減するAmazon ECS on Fargateのサービスがあり、起動されたタスクにはサービス専用のセキュリティグループが割り当てられている。VPC-BのECSタスクから、VPC-Aのキャッシュクラスターへ支障なくアクセスできるようにする必要がある。

ルートテーブルの設定以外に追加で必要な対応はどれか。
  • VPC-BのECSタスク用セキュリティグループに、送信先をVPC-AのCIDRブロックとするアウトバウンドルールを追加する
  • VPC-Bのルートテーブルに、VPC-A側に配置したNATゲートウェイを経由するルートを追加する
  • VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのCIDRブロックとするインバウンドルールを追加する
  • VPC-AのRedisクラスター用セキュリティグループに、送信元をVPC-BのECSタスク用セキュリティグループのIDとするインバウンドルールを追加する

(会員限定)当問題の評価をお願いします。改善に活用します。