ANS-C01 実践問題集

演習テスト 1

1

■ 問題の要約

• クリジットカード番号を暗語化して保持する要件がある EC サービス
• us-west-2 リージョンの ALB の背後に ECS サービス
  • ALB を CloudFront ディストリビューションのオリジンに指定
• サードパーティの CA を使って証明書を使う
• 伝送仕様
  • HTTPS
  • 処理中も暗号化された状態に保ち、特定のアプリケーションコンポーネントだけが機密データを複合できる
• この伝送仕様を実現するのにフィールドレベルの暗号化が必要
• 2 つのステップ

■ 解答

• ⭕️:
  • 機密データ暗号化用の公開鍵を CloudFront ディストリビューションにアップロードする。フィールドレベルの暗号化プロファイルに機密情報のあるフィールドを指定し、設定を機密性の高い POST リクエストに関連づけられた適切なキャッシュ動作にリンク
  • ALB 用のサードパーティ証明書を us-west-2 リージョンの ACM にインポートする。CloudFront ディストリビューション用の証明書を us-east-1 リージョンの ACM にアップロードする

• ❌

■ 解説

• 証明書は SSL/TLS 証明書のことだとわかる
• CloudFront の証明書は us-east-1 リージョンの ACM に配置する必要がある
  • ACM 自体は各リージョンで利用できるが、CloudFront や API Gateway のようなエッジサービスでそういう制約がある
• フィールドレベル暗号化
  • CloudFront の機能
  • 特定のデータフィールドを暗号化
  • ① 公開鍵暗号化：公開鍵で暗号化する
  • ② クライアント側の暗号化：ユーザーから送信される前に暗号化
  • ③ 選択的暗号化：特定のフィールドだけ暗号化できる
  • ④ エンドツーエンド保護：複合処理をする以外のすべての経路で暗号化

    • デベロッパー側も平文のデータを見れない

2

■ 問題の要約

• 2 つの Direct Connect リンク
  • 1 つは us-east-1
  • もう 1 つは af-south-1
• ルート交換には BGP を使用
• af-south-1 をセカンドリンクとするための BGP 設定

■ 解答

• ⭕️:
  • us-east-1 への Direct connect リンク：コミュニティタグ 7224:7300 を使用するように BGP ピアリング
  • af-south-1 への Direct connect リンク：コミュニティタグ 7224:7100 を使用するように BGP ピアリング
  • us-east-1 への BGP ピアで、ローカルプリファレンス値を 200
  • af-south-1 への BGP ピアで、ローカルプリファレンス値を 50

■ 解説

• Direct Connect 間のルーティング優先順位
• us-east-1 をプライマリリンクにする

• af-south-1 をセカンダリリンクにする

• （LOCAL_PREF 属性）BGP ローカルプリファレンス設定
  • 同じ宛先へのルートが複数あるときにどれを優先するか
  • 数値を設定する
  • 優先度は数値の大きさ
  • スコープは AS 内だけ（隣接する AS には伝播されない）
  • デフォルト値は 100
• BGP コミュニティタグ
  • 書式は AS番号:値
  • 大きい方が優先

3

■ 問題の要約

• リモートユーザー用に、複数のピアリングが設定済みの VPC とオンプレ DC へのアクセスを提供する Client VPN
• VPN エンドポイントのルートテーブルに 0.0.0.0/0 の単一ルートが設定
  • セキュリティグループには 0.0.0.0/0 へのアウトバウンドルールの 1 つだけ
• リモートユーザがウェブ検索結果の地理的位置情報が正しくないと報告
• サービス中断を最小限に抑える
• 解決策を 3 つ

■ 解答

• ⭕️:

  • VPC とオンプレ DC 用のルートを Client VPN ルートテーブルに追加する
  • Client VPN エンドポイントでスプリットトンネルオプションを有効にする
    • AWS に向けられたトラフィックだけが VPN トンネルを通過する
    • インターネット向けのトラフィックとかがユーザの持ってるインターネット接続を通過するので、地理的な位置情報が正しくなる
  • Client VPN エンドポイントのルートテーブルから 0.0.0.0/0 エントリを削除
    • 必要なルートだけ VPN トンネルを通過するようにする

• ❌:

  • ClientVPN エンドポイントを削除して、別の VPC で再作成する
    • 大幅なサービス中断

4

• BFD(Bidirectional Forwarding Detection)が必要そうなのは顧客側のルーター
  • AWS 側には設定済み
• BFD 　　- BGP のセッションを監視するためのプロトコル 　　- BGP セッションがダウンしたときに、迅速に検出して通知する 　　- BGP 自体にハートビート的な障害検知機能はあるが、それよりだいぶ高速

5

■ 問題の要約

• プライベート SaaS アプリケーションを AWS に移行する
• 数百の顧客が VPN トンネルを使用して複数の DC にアクセス
• 顧客の増加による NAT ルールとかセグメンテーションの管理が複雑化している悩み
• AWS 移行後おは AWS 上の顧客に限っては VPC から直接 SaaS アプリケーションにアクセスできるようにしたい
• オンプレの顧客は引き続き IPSec 暗号化トンネル

■ 解答

• ⭕️:
  • AWS 顧客の接続には Private Link
    • SaaS 提供側はルーティングテーブルや NAT ルールの管理が不要
  • オンプレの顧客には Site-to-Site VPN 接続を終端するために、 SaaS アプリケーションの VPC にサードパーティのルーティングアプライアンスを使う
    • 1 つの VPC につき VPN 接続は 10 個まで（VGW がそうなっているため）
    • セグメンテーションやルーティングの管理が簡単になる
• ❌:
  • AWS 顧客の VPC を共有トランジットゲートウェイに接続する
    • ルーティングが複雑な問題を解決しない
  • オンプレ顧客はトランジットゲートウェイへの Site-to-Site VPN 接続
    • ルーティングが複雑な問題を解決しない

6

■ 問題の要約

• us-east-1 リージョンの VPC にあるアプリケーション
• ロンドンオフィスで、レイテンシーの問題を感じている
• ロンドンオフィスからは Site-to-Site VPN（＋ VGW）で VPC に接続している
• 同社はトランジットゲートウェイと他の VPC 間のピアリングを設定している
• レイテンシーの問題を解決するのに必要なアクション

■ 解答

• ⭕️:
  • 新しい Site-to-Site VPN を作成し、トランジットゲートウェイをターゲットゲートウェイにする
    • 既存の VPN の設定は変更できない（たぶん経路の広報とかの問題）
  • 新しい方の Site-to-Site VPN 接続でアクセラレーションを有効にする
    • AWS ネットワークを使って安定・高速にルーティングしてくれる
  • ロンドンオフィスは新しい Site-to-Site VPN 接続を使用する
• ❌:
  • AWS Global Accelerator
    • パブリックインターネット接続向け（CloudFront とか、インターネット公開してる ALB とか）

7

• EC2 ののプレイスメイントグループとかでジャンボフレームを有効にしてて、インターネットアクセスしようとするとパケットが破棄されることがある
  • 破棄されずに済む：Dirrect Connect 経由
  • 破棄されそう：パブリックインターネット経由、Site-to-Site VPN 経由

8

• Route 53 のパブリックホストゾーンへのクエリ数のめとりくす
  • CloudWatch の Route53 の DNS Queries メトリクス

9

■ 問題の要約

• トランジットゲートウェイとオンプレネットワーク間の Site-to-Site VPN 接続
• アクティブ/アクティブモードの 2 つのトンネルで BGP を使用
• ECMP（Equal-Cost Multi-Path）ルーティングを使用
• オンプレから AWS 側へのトラフィックについて、行きと帰りで違うトンネルを通り、カスタマーゲートウェイでドロップされてしまう。
• VPM 全体の帯域幅を減らさずにこれを解決したい

■ 解答

• ⭕️:
  • カスタマーゲートウェイで B 非対称ルーティングを許可するように仮想トンネルインターフェイスを構成する
    • 行きと帰りで違うトンネルを使えるようにする
• ❌:
  • カスタマーゲートウェイの設定で、AS PATH プリペんどとローカルプリファレンスを使用して、一方のトンネルの優先度を上げるようにする
    • トンネルごとの帯域幅の偏りが出るので不適切

10

• EC2 で HPC クラスター
  • とりあえず単一 VPC でクラスタープレイスメントグループを設定するところから考える
  • 高スループットを出すのに EFA ドライバーがインストールされてる必要がある(c5n、c6gn、p4d 等)
  • 総スループットが 100Gbps くらいから、複数のサブネットだと実現が厳しくなってくる

11

• Route53 離ゾルバーには、DHCP オプションセットがある
  • AWS リソースへの名前解決を自分でやるか、AWS にやらせるかを選べる
  • 自分でやるケースがわからんが…

12

■ 問題の要約

• NLB-EC2 の多層アプリケーションをイネターネットで公開している
• UDP と TCP の両方のトラフィックを処理する必要がある
• グローバルに提供するにあたって、レイテンシやジッターを最小限に抑えたい

■ 解答

• ⭕️:
  • NLB を Global Acceraletor のエンドポイントに設定する
    • Global Accelerator は、AWS のグローバルネットワークを利用して、レイテンシやジッターを最小限に抑える
    • NLB は TCP と UDP の両方をサポートしているため、要件を満たす
• ❌:
  • CloudFront を使用して、NLB の背後に配置する
    • CloudFront は HTTP/HTTPS トラフィック用で、UDP をサポートしていない

13

14

■ 問題の要約

• IDS 機能を追加したい
• VPC がいくつかあって、ピアリングで接続
• VPC を増やす予定はない
• 暗号化されていないトラフィックにも対応する必要がある
• 環境の再設計は NG

■ 解答

• ⭕️:
  • 各 VPC で AWS Network Firewall の分散型デプロイモデルを使用する
    • 既存の VPC ピアリングされてるアーキテクチャに適用できる
    • ”集中型デプロイモデル”の場合、トランジットゲートウェイが前提

15

• Site-to-Site VPN 接続のアクセラレーションオプションは、トランジットゲートウェイをターゲットにした時だけしか使えない
  • VGW をターゲットにした時ダメ

16

• VPC フローログはカスタムフォーマットフィールドを設定できる
  • vpc-id, subnet-id, tcp-flags とかをキャプチャしたい時とか
• 保存先も指定できる
  • CloudWatch Logs は超保存するストレージとしては高コスト
  • S3 は安上がり

17

• Route53 でリージョン単位のフェイルオーバーを実装する具体的な手順
  • 各 ALB に対して XXX ポリシーを持つ A レコードを作成
  • ホストしているドメインを ALB へのエイリアスに設定する
  • レコードの「ターゲットヘルスチェックの評価」を True

18

■ 問題の要約

• 新しい Web アプリケーションを ALB の背後にある EC2 インスタンスにデプロイ
• 世界中の企業顧客がアプリケーションを使用
• 企業顧客は承認済み IP アドレスへのアウトバウンドトラフィックのみを許可するファイアウォールを構成
• 最小限のレイテンシーでアクセスできる必要がある

■ 解答

• ⭕️:
  • AWS Global Accelerator に新しいアクセラレーターを作成し、ALB をエンドポイントとして追加
    • 2 つの固定エニーキャスト IP アドレスを提供 → 企業のファイアウォールで許可リストに追加が簡単
    • 世界中の AWS エッジロケーションからアクセス可能
    • AWS のプライベートネットワークを経由してトラフィックを転送 → レイテンシー低減
• ❌:
  • CloudFront ディストリビューション
    • 動的に多数の IP アドレス範囲を使用 → ファイアウォール設定が複雑
    • 動的 Web アプリケーションでのキャッシュ効果は限定的
  • Route 53 のホストゾーンとレコード作成
    • DNS サービス → レイテンシー低減効果なし
    • ALB の動的 IP アドレスをファイアウォールで管理が困難
  • NLB を ALB の前に配置
    • 単一リージョン内での動作 → グローバルルーティング最適化なし
    • 複数リージョンで異なる IP アドレス → 多数の許可設定が必要

19

■ 問題の要約

• Direct Coonect リンクと SD-WAN オーバーレイを使用したハイブリッドインフラ
• Site-to-Site VPN で VPC を SD-WAN アプライアンストランジット VPC に接続している
• VPC を増やしたい。ルートテーブルとかコストとかの課題がある。
• 運用オーバーヘッドの少ないソリューション

■ 解答

• ⭕️:
  • トランジットゲートウェイを使う
  • SD-WAN アプライアンストランジット VPC ようにトランジットゲートウェイ Connect アタッチメント
    • IPsec VPN を設定せずに SD-WAN インフラストラクチャを AWS と接続するならこれ
    • BGP とか、GRE をサポートしてるので、設計とか運用のコストを抑える
  • トランジットゲートウェイ Connect の SD-WAN 仮想ハブとのネイティブ統合

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

■ 問題の要約

• 複数の VPC 環境をトランジットゲートウェイで接続
• セキュリティグループ、ネットワーク ACL、VPC 内のルートテーブル変更後にアプリケーション間の接続が失われた経験
• 単一 VPC 内の異なるリソース間の接続性を自動的に検証したい

■ 解答

• ⭕️:
  • VPC Reachability Analyzer で確認する異なるリソース間のパスのリストを作成
  • AWS CloudTrail に記録された変更をモニタリングする EventBridge ルールを作成
  • Lambda 関数を呼び出し、VPC Reachability Analyzer で異なるパスをテスト
• ❌:
  • CloudWatch での変更監視
    • セキュリティグループやネットワーク ACL の変更は API 呼び出し →CloudTrail に記録される
    • CloudWatch はメトリクスやログを監視するサービス
  • Transit Gateway Network Manager Route Analyzer
    • 複数 VPC 間の接続性を分析するもの
    • 単一 VPC 内のリソース間の検証には不適切

■ 解説

• VPC Reachability Analyzer
  • 単一 VPC 内のリソース間のネットワーク接続性を分析
  • セキュリティグループ、ネットワーク ACL、ルートテーブルの影響を評価
  • 接続の成功・失敗の理由を詳細に説明
• CloudTrail vs CloudWatch
  • CloudTrail：AWS の API 呼び出しを記録（設定変更はここに記録）
  • CloudWatch：リソースのメトリクスやログを監視
• 自動化フロー
  1. CloudTrail が API 呼び出し（設定変更）を記録
  2. EventBridge が特定の変更を検出し Lambda を呼び出し
  3. Lambda が VPC Reachability Analyzer で接続性をテスト

■ 感想

VPC の接続性の CI/CD 的な単体テストに、VPC Reachability Analyzer を使う。パイプラインの発火には Cloud Trail + EventBridge + Lambda を使う感じか。

35

36

37

38

■ 問題の要約

• 既存の AWS 環境に AWS Network Firewall をデプロイする必要
• 環境構成：
  • トランジットゲートウェイで接続された数百のアプリケーション VPC
  • 集中型イグレス（出口）インターネット VPC（NAT ゲートウェイ + インターネットゲートウェイ）
  • 集中型イングレス（入口）インターネット VPC（パブリック ALB）
  • Direct Connect Gateway 接続
• East-West（VPC 間）と North-South（インターネット-オンプレミス）トラフィックを検査
• Suricata 互換ルール使用
• 本番環境への構造的変更を最小限に抑える

■ 解答（3 つ選択）

• ⭕️:

  • 集中型の検査 VPC のすべてのアベイラビリティーゾーンに Network Firewall をデプロイ
    • 単一の場所ですべてのトラフィックを検査 → 管理オーバーヘッドが少ない
    • 既存の VPC への変更が最小限（主にルーティング更新のみ）
  • トラフィックを強制的に検査 VPC 通過させるための 2 つのトランジットゲートウェイルートテーブルを設定
    • アプリケーション VPC 用：すべてのトラフィックを検査 VPC に転送
    • 検査 VPC 用：検査済みトラフィックを適切な宛先に転送
  • HOME_NET ルールグループ変数を VPC とオンプレミスの CIDR 範囲に更新
    • 保護対象の「内部」ネットワークを定義
    • Suricata ルールで East-West/North-South トラフィック検査に必須

• ❌:

  • 各アプリケーション VPC にファイアウォールをデプロイ
    • 数百の VPC それぞれに設置 → 管理オーバーヘッド大幅増加
    • 構造的変更が多すぎる
  • 単一のトランジットゲートウェイルートテーブル
    • VPC 間で直接ルーティング → 検査をバイパスする可能性
  • EXTERNAL_NET を VPC・オンプレミス CIDR に設定
    • EXTERNAL_NET は「外部・信頼できない」ネットワーク用
    • 内部ネットワークを外部扱いすると誤検知の原因

■ 解説

• 集中型 vs 分散型デプロイ
  • 集中型：検査 VPC に 1 か所でファイアウォール → 管理簡単・コスト効率良い
  • 分散型：各 VPC にファイアウォール → 管理複雑・高コスト
• ルートテーブル分離の重要性
  • アプリケーション VPC と検査 VPC で異なるルートテーブル
  • トラフィックを強制的に検査 VPC 経由にする仕組み
• Suricata ルールグループ変数
  • HOME_NET：保護対象内部ネットワーク
  • EXTERNAL_NET：外部ネットワーク（通常は “!$HOME_NET”）

39

40

41

42

43

44

45

46

47

48

■ メモ

• ALB の背後を HTTPS 通信にするには？

49

■ 問題の要約

• 複数の AWS リージョンにまたがる VPC 内のリソースを管理
• 内部ドメイン名を使用してリソースに接続
• すべてのリソースに aws.example.com の DNS サフィックスを適用する必要

■ 解答

• ⭕️:
  • aws.example.com の Amazon Route 53 プライベートホストゾーンを 1 つ作成
  • プライベートホストゾーンをリソースを持つすべての VPC に関連付け
  • プライベートホストゾーンに、すべてのリソースの DNS レコードを作成
• ❌:
  • 各リージョンに個別のプライベートホストゾーンを作成
    • 管理負担増加・一貫性維持が困難
    • 他リージョンリソースの解決ができない可能性
  • マルチバリューアンサールーティングポリシー使用
    • 単一レコードの複数 IP 対応 → 異なる名前の複数リソースには不適切
    • DNS サフィックスの実装には複数の個別レコードが必要
  • ゾーン転送の設定
    • Route 53 プライベートホストゾーンはゾーン転送非対応
    • VPC との関連付けで DNS 可視性を制御

■ 解説

• Route 53 プライベートホストゾーンの特徴
  • VPC との関連付け：1 つ以上の VPC に関連付け可能
  • 限定的な可視性：関連付けられた VPC 内からのみ解決
  • クロスリージョン対応：異なるリージョンの VPC と関連付け可能
  • ゾーン転送非対応：従来の DNS ゾーン転送は未サポート
• DNS サフィックスの実装
  • 短縮名（server1）→ FQDN（server1.aws.example.com）に変換
  • 単一ネームスペースで一貫した DNS 解決
  • 組織構造を反映した階層的ドメイン名
• 単一ホストゾーンの利点
  • 管理の単純化
  • リージョン間での一貫した DNS 解決
  • どの VPC からでも同じ DNS 名でアクセス可能

50

51

52

• Organizations を使っていて、複数アカウントにアクセス許可 IPv4 セットを共有したいとき
  • カスタマー管理プレフィックスリストに IPv4 のリストを登録
  • RAM のリソース共有で先ほど作ったプレフィックスリストを組織と共有する
• firewall Manager はリストの共有には使えない（共通の Firewall ルールを共有するのには使える）

53

54

• 2 つの VPC があって、リモートユーザーに VPN 接続させたい
  • 2 つの VPC 間でピアリング接続を作成
  • Client VPN エンドポイントを作成
  • 一方の VPC と Client VPN エンドポイントを関連付けて、Client VPN エンドポイントには他方の VPC にトラフィックを誘導するルートを追加しておく
    • 他方の VPC の CIDR ブロック向けのルートを追加する感じ？

55

56

57

58

59

60

61

62

63

64

65