AWS SOA サンプル問題

正解：B

A　詳細モニタリングは既定メトリクスの取得間隔を5分から1分へ短縮するだけで、メモリやディスク空き容量は取得できない

B（正解）　正解。ハイパーバイザーから見えないOS内部の値は、インスタンス上のエージェントが収集してカスタムメトリクスとして発行する必要がある

C　メトリクス数式は既存メトリクスの演算しかできず、そもそもCPU使用率からメモリ使用量は導出できない

D　フローログはネットワークトラフィックのメタデータのみを記録し、OS内部のリソース使用状況とは無関係

正解：B

A　同じトピックにまとめても各アラームは独立して発報するため、片方だけの呼び出しは止まらない

B（正解）　正解。複合アラーム(Composite Alarm)は子アラームの状態をANDやORで組み合わせて評価でき、子側の通知を外せば呼び出しノイズを大きく削減できる

C　発報が遅れるだけで片方だけの通知はなくならず、本当の障害の検知も遅くなる

D　単位の異なるメトリクスの加算に意味はなく、どちらか一方が大きいだけでもしきい値を超えてしまう

正解：C

A　データ不足はデータポイントが存在しないことが原因で、しきい値をいくら変えても状態は変わらない

B　誤検知は消えるが手作業が増え、運用効率を重視する要件に反する。CloudWatchの標準機能で解決できる

C（正解）　正解。欠落データの扱いはmissing/notBreaching/breaching/ignoreから選べ、notBreachingならデータがない期間はOK状態として扱われる

D　取得間隔を短くしても停止中はメトリクス自体が発行されないため、データ不足は解消しない

正解：A

A（正解）　正解。復旧アクションはインスタンスIDやプライベートIP、EBSボリュームを保持したまま別のハードウェアへ移して再起動するため、手動対応なしで復旧できる

B　インスタンスステータスチェックはOSやネットワーク設定などインスタンス側の問題を示すもので、今回のハードウェア障害の検知には対応しない

C　終了させても代替は起動せず、EBSの設定によってはデータも失われる。復旧策になっていない

D　障害と無関係に毎時再起動する構成は正常稼働時のサービス断を招き、ハードウェア障害からの復旧も保証しない

正解：D

A　標準解像度は最小粒度が60秒で、10秒のスパイクは平均に埋もれてしまい検知できない

B　詳細モニタリングでも粒度は1分どまりで、そもそもEC2の既定メトリクスであってAPIのカスタムメトリクスではない

C　メトリクスフィルタが生成するメトリクスも1分粒度が基本で、秒単位のスパイク検知には向かない

D（正解）　正解。StorageResolutionを1にした高解像度メトリクスは10秒や30秒の評価期間でアラームを設定でき、短時間のスパイクを捉えられる

正解：C

A　深夜の誤検知は減るが、昼間に注文が激減しても検知できず見逃しが悪化する

B　周期性には一応対応できるが、しきい値の維持と切り替えの仕組みを自前で運用し続ける必要があり負荷が高い

C（正解）　正解。異常検出は過去データから曜日・時間帯の周期性を学習して予測範囲を作り、その範囲からの逸脱でアラームを発報する

D　統計の種類を変えても周期性そのものは解消せず、固定しきい値の問題は残る

正解：A

A（正解）　正解。メトリクス数式は複数メトリクスの四則演算や集計関数の結果を式として扱え、その式に対して直接アラームを作成できる

B　個々のしきい値は評価できるが、合計値という条件は表現できない。1つが0でも他が多ければ問題ない場合を区別できない

C　実現はできるがエージェントと集計スクリプトの運用が増え、標準機能で足りるところに余計な部品を持ち込んでいる

D　ダッシュボードは可視化のための機能で、しきい値超過時に通知する仕組みではない

正解：B

A　実現は可能だが、コード運用・重複したメトリクス料金・取得遅延を抱え込む。標準のオブザーバビリティアクセス機能があるため不要な作り込み

B（正解）　正解。ソースアカウントをモニタリングアカウントにリンクすると、メトリクス・ログ・トレースを横断して1つのダッシュボードから参照できる

C　1枚にまとめるという要件を満たさず、アカウント切り替えの手間も残る

D　組織証跡が集約するのはAPI呼び出しの記録であり、CloudWatchメトリクスは対象外

正解：C

A　インスタンス全体のCPU使用率しか分からず、プロセス単位の内訳も秒単位の粒度も得られない

B　RDSはマネージドサービスでホストOSへのSSH接続は許可されていない。この選択肢自体が実行不可能

C（正解）　正解。拡張モニタリングはDBインスタンス上のエージェントがOSメトリクスをプロセス単位で収集し、最短1秒粒度でCloudWatch Logsに出力する

D　遅いSQLの特定には有用だが、OSレベルのプロセス別CPU消費という今回の観点は分からない

正解：B・E

A　保持期間は古いログを削除する条件にすぎず、新しいログの受信を妨げることはない

B（正解）　正解。エージェントはインスタンスプロファイルの認証情報でPutLogEventsなどを呼び出すため、権限が欠けていると送信が失敗し続ける

C　CloudWatch Agentは必要なログストリームを自動で作成するため、事前作成は不要

D　Insightsは蓄積済みのログを検索するための機能で、ログの取り込みとは無関係

E（正解）　正解。プライベートサブネットではNAT Gatewayかインターフェース型VPCエンドポイントのいずれかがないと、エージェントはサービスのエンドポイントに接続できない

正解：A・D・F

A（正解）　正解。アラーム自体は状態遷移するが、アクションが無効の間はSNSへの発行が行われないため通知だけが届かなくなる

B　CloudWatchのメトリクスは15か月で自動的に期限切れになるが、直近のデータ点の評価と通知には影響しない

C　メトリクスアラーム単独でもアクションは実行できる。複合アラームは複数のアラームの状態を組み合わせて評価するための任意の仕組みで、通知の前提条件ではない

D（正解）　正解。メールのサブスクリプションは受信者が確認リンクを開くまでPendingConfirmationのままで、その間はメッセージが配信されない

E　暗号化の有無は配信の成否とは無関係で、未設定でも通知は送信される

F（正解）　正解。アラームアクションは状態が変化した瞬間にのみ実行される。すでにALARM状態が継続している間は追加の通知が発生しない

正解：C

A　遅れて気づくことはできるが、自動再取得は行われず、通知だけが目的の構成になっている

B　実現はできるが監視用インスタンスの管理が必要で、スクリプトの失敗自体を検知する仕組みも別途必要になる

C（正解）　正解。EBSはスナップショット完了・失敗をイベントとして発行するため、EventBridgeで受けてAutomationランブックを起動すれば、再試行と通知を含む修復手順をコードなしで自動化できる

D　失敗通知は得られるが、自動的な再取得の手順を組み込む要件には応えていない

正解：A

A（正解）　正解。ライフサイクルフックはインスタンスをTerminating:Wait状態で保留し、その間に退避処理を実行してからCompleteLifecycleActionで先へ進められる

B　クールダウンは次のスケーリング動作までの待ち時間であり、終了処理を保留する仕組みではない

C　終了保護はAuto Scalingによるスケールインの終了には効かず、そもそもログ退避の機会を作る手段ではない

D　退避の完了前にインスタンスが終了する可能性があり、処理の完了を待たせる保証がない

正解：C

A　EC2アクションは停止・終了・再起動・復旧のみで、インスタンスを増やす操作は行えない

B　手動でインスタンスを増やす形になり、Auto Scalingグループの管理外になるためヘルスチェックや自動置換の恩恵を受けられない

C（正解）　正解。CloudWatchアラームのアクションにはAuto Scalingポリシーを直接指定でき、キュー長という業務指標に基づくスケーリングが標準機能で実現できる

D　ヘルスチェックは異常インスタンスの置換に関わる設定で、負荷に応じた台数の増減とは無関係

正解：D

A　接続数の変動は間接的な兆候にすぎず、フェイルオーバーの発生そのものを確実に捉えられない

B　手動フェイルオーバーは記録されるが、AWS側の自動フェイルオーバーはユーザーのAPI呼び出しではないため検知できない

C　通知は得られるが手動対応が残り、即座に接続プールをリセットするという自動化の要件を満たさない

D（正解）　正解。RDSはフェイルオーバーをイベントとして発行し、EventBridgeは1つのルールに複数ターゲットを指定できるため通知と修復処理を同時に起動できる

正解：B

A　Multi-AZのスタンバイには接続用のエンドポイントが公開されず、そもそも追記できない

B（正解）　正解。エンドポイント名は変わらずDNSが指す先だけが切り替わるため、アプリケーションはDNSキャッシュのTTLが切れた後に再接続するだけでよい

C　物理的に別インスタンスへ切り替わるためIPは変わり、既存の接続は切断される。再接続の実装は必要

D　Multi-AZのスタンバイとリードレプリカは別の機能で、フェイルオーバーでレプリカのエンドポイントが使われることはない

正解：C

A　Multi-AZ配置(インスタンス)のスタンバイは可用性のための待機系で接続用エンドポイントも公開されず、読み取りに使うことはできない。よくあるひっかけ(読み取り可能なスタンバイを持つのはMulti-AZ DBクラスター配置)

B　一時的な緩和にはなるがコストが上がり続け、参照負荷と更新負荷を分離するという本質的な解決にならない

C（正解）　正解。リードレプリカは非同期レプリケーションでわずかな遅延を許容する代わりに参照負荷を分離でき、本番の更新性能への影響を避けられる

D　接続管理の効率化とフェイルオーバー時間の短縮には有効だが、クエリ負荷そのものは同じインスタンスにかかり続ける

正解：D

A　実現はできるがサービスごとにコードを書いて維持する必要があり、一元管理という要件から遠い

B　DLMが対象とするのはEBSスナップショットとEBS-backed AMIで、RDSやEFSは扱えない

C　S3オブジェクトの複製機能であり、EBSやRDS、EFSのバックアップ対象にはならない

D（正解）　正解。AWS Backupは対応サービスのバックアップをプランで一元管理し、ルール内でクロスリージョンコピーとライフサイクルをまとめて定義できる

正解：A

A（正解）　正解。コンプライアンスモードのボールトロックは猶予期間の経過後は変更・解除ができなくなり、rootを含む誰も保持期間内のリカバリポイントを削除できない

B　リソースポリシーはアカウントの管理者が編集できるため、権限を持つ利用者による削除を根本的には防げない

C　分離の効果はあるが、コピー先アカウントの管理者は削除できるため要件を完全には満たさない

D　自動削除の時期を先送りするだけで、手動での削除操作は防げない

正解：C

A　実現はできるがコードの保守、エラー処理、対象抽出のロジックをすべて自前で持つ必要がある

B　インスタンスが停止していると取得されず、権限配布と全台のスクリプト保守も負担になる

C（正解）　正解。DLMはタグで対象を選び、取得スケジュールと保持ルールをマネージドに実行するため、コードを書かずに取得と世代管理を自動化できる

D　古いスナップショットの検出はできるが、日次で新規に取得する仕組みが含まれていない

正解：B

A　ボリュームの複製はできるが、起動するにはボリューム作成とアタッチ、インスタンス作成の手順が別途必要で即座には起動できない

B（正解）　正解。AMIはルートボリュームと追加ボリュームのスナップショット、起動に必要なブロックデバイスマッピングを含むため、同一リージョン内の任意のAZで同じ状態のインスタンスを起動できる

C　EC2インスタンスをAZ間で直接移動する操作は存在せず、元のインスタンスも停止してしまう

D　起動時のパラメータは定義できるが、インストール済みのミドルウェアやOS設定そのものは含まれない

正解：C

A　コストは最も低いがバックアップからの復元に時間がかかり、RTO1時間とRPO数分をいずれも満たせない

B　RTO・RPOはほぼゼロにできるが、常時本番同等の環境を稼働させるため平常時のコストを抑えたいという条件に反する

C（正解）　正解。データベースのレプリケーションだけを常時稼働させて数分のRPOを保ち、アプリ層は災害時にAMIや自動化で起動して1時間以内の復旧を狙える

D　AZ障害には有効だがリージョン全体の災害には対応できず、DR要件を満たさない

正解：A

A（正解）　正解。Run CommandはSSM Agent経由でコマンドを配信し、タグによる一括ターゲット指定・同時実行数の制御・実行結果の集約表示までを提供する

B　ユーザーデータは既定では初回起動時のみ実行され、稼働中インスタンスへ即座に適用する用途には使えない

C　望ましい状態を維持する用途には適するが、今すぐ1回だけ実行して結果を確認するという要件にはRun Commandが適する

D　Image Builderは新しいAMIを作る仕組みで、稼働中インスタンスへの即時のコマンド実行はできない

正解：C

A　検知が早くなるだけで、非準拠を是正する処理は実行されない

B　適合パックは複数ルールをまとめて配布する仕組みで、それ自体が是正処理を行うわけではない

C（正解）　正解。Configの修復アクションはAutomationドキュメントを呼び出し、自動修復を有効にすると非準拠検出時にコードなしで是正が走る

D　予防的統制としては有効だが、すでに無効になっているバケットを是正する動きはない

正解：B

A　停止処理を実行する側のインスタンスを常時稼働させる必要があり、サーバーレスという要件に反する

B（正解）　正解。スケジュール実行と、AWS-StopEC2Instanceなどの既製ランブックの組み合わせで、コードを書かずに定時の一括操作を実現できる

C　Auto Scalingグループ配下のインスタンスにしか効かず、単独起動のインスタンスは対象外。またスケールインは停止ではなく終了になる

D　AWS Backupはバックアップとリストアのサービスで、インスタンスの起動・停止を行う機能は持たない

正解：B

A　無関係なイベントまで処理してしまい、配信に失敗したイベントの保全にはならない

B（正解）　正解。EventBridgeのターゲットにはSQSのDLQと最大再試行回数・イベント最大有効期間を設定でき、配信に失敗したイベントを保全して後から再処理できる

C　同時実行数を0にすると呼び出しが一切行われなくなり、状況が悪化する

D　呼び出されなかった事実を後から追うのは困難で、失敗したイベント自体を保全して再処理する手段にもならない

正解：B

A　30回の手作業が必要なうえ、新規アカウントへの適用漏れが必ず発生する

B（正解）　正解。Organizations連携のStackSetsは対象OUに新しいアカウントが追加されたときに自動でスタックインスタンスを展開し、削除時には取り除く

C　実行のタイミングと結果が管理者任せになり、統制も進捗の把握もできない

D　SCPは操作を禁止する予防的統制で、リソースを作成して設定を行うことはできない

正解：C

A　差異の有無は分かりづらく、意図しない上書きが本番に適用されるリスクがある

B架空　ドリフトを検出したら自動的にテンプレートの状態へ戻すという機能は存在しない。検出と是正は別の操作

C（正解）　正解。ドリフト検出はスタック内のリソースの実際の設定とテンプレート定義を比較し、差異のあるプロパティを一覧で示す

D　誰が何を変更したかは追えるが、現在の設定がテンプレートとどれだけ乖離しているかは直接分からない

正解：A

A（正解）　正解。変更セットは更新を適用せずに追加・変更・削除の一覧と置換の要否(Replacement)を提示するため、影響を事前に把握できる

B　誤った更新の防止には有効だが、何が起きるかを事前に確認する手段ではない

C　現在の設定とテンプレートの差異を見る機能で、これから行う更新の影響は分からない

D　構文やベストプラクティスの検査はできるが、既存スタックへ適用したときの変更内容は分からない

正解：D

A　本番リソースが失われる可能性があり、最終手段としても影響が大きすぎる

B　この状態のスタックは更新操作を受け付けないため、変更セットの実行もできない

C　差異の把握はできるが、スタックの状態遷移そのものを前へ進める手段ではない

D（正解）　正解。ロールバックを妨げているリソースの問題を手動で解消したうえで継続を指示し、必要ならそのリソースをスキップ指定してUPDATE_ROLLBACK_COMPLETEへ進める

正解：B

A　誤削除の抑止にはなるが、スタック削除がその時点で失敗して中途半端な状態になる。テンプレート側での意思表示にはならない

B（正解）　正解。DeletionPolicyをSnapshotにするとスタック削除時に最終スナップショットが作成され、データを保持したままリソースを削除できる

C　スタックポリシーは更新時の保護であり、スタック削除時の挙動には影響しない

D　分離しても、そのスタックを削除すればやはりデータは失われる。根本的な保護になっていない

正解：C

A　リソースの作成順序は制御できるが、インスタンス内部の処理完了は待たない

B　CreationPolicyなどの仕組みと組み合わせない限り、待機時間の設定単独では完了の合図にならない

C（正解）　正解。インスタンス側から成功のシグナルを送るまでCloudFormationが待機するため、アプリケーションの準備完了をスタックの完了条件にできる

D　カスタムリソースなどの作り込みが必要で、標準機能で解決できるところを複雑にしている

正解：A

A（正解）　正解。スタックポリシーは特定の論理IDに対するUpdate:Replaceなどを拒否でき、他のリソースの更新は許可したまま重要リソースだけを保護できる

B　スタックの更新自体ができなくなり、開発者が更新できるようにするという条件に反する

C　スタック削除時にリソースを残す設定で、更新時の置換は防げない

D　スタック更新時にDBが削除対象と見なされ、かえって危険な結果になる

正解：D

A　削除の抑止にはなるが、ログファイル自体が改ざんされていないことを検証する手段が含まれていない

B　暗号化は機密性を守るが完全性の証明にはならず、キーポリシーもオブジェクト削除の抑止手段ではない

C　保管コストは下がるが、権限を持つ利用者による削除は防げず、改ざん検証の仕組みもない

D（正解）　正解。整合性検証はダイジェストファイルの署名で改ざんの有無を検証でき、Object Lockのコンプライアンスモードは保持期間中の削除・上書きをrootを含め誰にも許さない

正解：D

A　保管期間の短縮はリスク低減にはなるが、暗号化の要件そのものを満たしていない

B　エンコードは暗号化ではなく、誰でも復号できるため保護にならない

C　エクスポート先は保護されるが、CloudWatch Logsに残っている元データが要件を満たさないままになる

D（正解）　正解。ロググループにカスタマー管理キーを関連付けると保存データがそのキーで暗号化され、キーポリシーによる制御・ローテーション・CloudTrailでの使用監査が可能になる

正解：D

A　EBSボリュームを走査してマルウェアの有無を調べる機能で、インスタンスを隔離用のセキュリティグループへ切り替える動作は行わない

B　通知にとどまり自動的な隔離は行われない。またGuardDutyの検出結果はCloudTrailのイベントとして流れるものではない

C　Configはリソース設定の準拠性を評価する仕組みで、GuardDutyの検出結果を評価の入力にはできない

D（正解）　正解。GuardDutyの検出結果はEventBridgeイベントとして発行されるため、重大度でフィルタして修復処理を起動する構成が定石

正解：C

A　IAMのポリシー評価に付与順という概念はなく、時系列で優先度が決まることはない

B　許可が拒否に優先することはない。AdministratorAccessであっても明示的な拒否は上書きできない

C（正解）　正解。IAMの評価論理では明示的Denyが最優先で、他のどのポリシーによる許可よりも強い。原因となる拒否を特定して外すしかない

D　グループのポリシーは所属ユーザーに適用される。継承されないという前提が誤り

正解：A

A（正解）　正解。SCPで許可されていない操作はIAM側で許可されていても実行できないため、原因の見えないAccessDeniedではまずアタッチされているSCPを確認する

B　パスワードの複雑さや有効期限に関する設定で、API操作の可否とは無関係

C　クォータ超過の場合はAccessDeniedではなく上限超過のエラーになる

D　証跡は記録の設定であり、操作の許可・拒否には影響しない

正解：B

A　ロールの作成自体ができなくなり、委譲するという要件を満たさない

B（正解）　正解。IAMポリシーの条件で、指定した境界ポリシーを付けたロールしか作れないようにでき、そのロールの実効権限は境界との重なりに制限される

C　作成時点で過剰な権限のロールが生まれてしまい、事後レビューでは防止にならない

D　検出と是正は可能だが、その間は過剰な権限が有効なままで予防的な統制にならない

正解：D

A　長期認証情報を外部に渡すことになり、失効や監査が難しい

B　S3以外のリソースを読めず、また代理問題への対策も含まれていない

C　外部組織を自社の組織に取り込むのは統制上不適切で、必要な権限委譲の手段としても過剰

D（正解）　正解。ExternalIdを条件にすると、ベンダーが自社専用の値を提示したときだけAssumeRoleが成立し、他の顧客の依頼で誤って自社リソースへアクセスされることを防げる

正解：C

A　通信が遮断されている場合はタイムアウトや接続エラーになり、AccessDeniedにはならない

B　オブジェクトの世代管理に関する設定で、アクセス可否の判定には関与しない

C（正解）　正解。IAM側は全リソースを許可しているため切り分けの手がかりにならず、バケットごとに結果が変わるならバケット側の設定が原因になる。まず対象バケットの設定を確認する

D　配置されるAZはS3の権限評価に影響しない

正解：A

A（正解）　正解。セキュリティグループはステートフルなので戻りは許可され、往路のみREJECTが記録される。ネットワークACLはステートレスなため復路のREJECTも記録され、この違いで切り分けられる

B　ファイアウォールエンドポイントを通過したトラフィックの判定が残る仕組みで、セキュリティグループやネットワークACLによる拒否は記録されない

C　設定変更の履歴は分かるが、現在の通信がどちらで落ちているかというランタイムの事実は分からない

D　OS起動時の情報が中心で、VPCのフィルタリングによる遮断は記録されない

正解：B

A　自動割り当てのパブリックIPでも通信は可能で、固定IPが必須というわけではない

B（正解）　正解。パブリックサブネットの条件はIGWへのデフォルトルートが関連付けられていることで、これがなければパブリックIPがあっても到達できない

C　AZの選択はインターネットからの到達性に影響しない

D　インスタンスタイプは帯域や性能に関わるもので、疎通の可否を決めるものではない

正解：C

A　サブネットのルートがIGWを向いていなければ通信できず、仮に向ければインターネットからの受信も可能になってしまう

B　そのサブネットがパブリックサブネットになり、インターネットからの接続を許してしまう

C（正解）　正解。NAT Gatewayは内部から開始した通信のみを外部へ中継し、外部から内部への接続開始は許可しない

D　S3とDynamoDBへのプライベート経路を提供するだけで、一般的なインターネット上のリポジトリへは到達できない

正解：A

A（正解）　正解。SGは許可した通信の戻りを自動的に許可するが、NACLは方向ごとに独立して評価するためエフェメラルポートの戻りルールが必要になる

B　適用範囲の違いはあるが(NACLはサブネット単位)、戻り通信の扱いの差を説明する理由にはならない

C　実際は逆で、SGは許可のみ、NACLは許可と拒否の両方を定義できる

D　評価順の話であって、戻り通信を自動的に許可するかどうかの違いとは無関係

正解：D

A　NACLに拒否優先の原則はなく、ルール番号の小さい順に評価して最初に一致したものが適用される

B　一致した時点で評価が終わるため、後続のルールは参照されない

C　評価順は番号の昇順で、大きい番号が優先されるという理解は逆

D（正解）　正解。NACLはルール番号の小さい順に評価し、最初に一致したルールを適用して以降は評価しない

正解：C

A　フィルタでALL、ACCEPT、REJECTを選べるため、設定次第で拒否も記録される

B　集約間隔は1分または10分から選択でき、1時間固定という理解は誤り

C（正解）　正解。169.254.169.254へのメタデータアクセスやAmazon提供DNSへの問い合わせ、DHCPトラフィックなどは仕様上フローログに記録されない

D　VPC、サブネット、ENIのいずれの単位でも有効化でき、ENI単位の記録も可能

正解：B

A　S3とDynamoDBのみに対応するため、SSMのAPIエンドポイントへの到達手段にはならない

B（正解）　正解。ssm、ssmmessages、ec2messagesのインターフェイスエンドポイントを作れば、PrivateLink経由でインターネットを介さずSSMを利用できる

C　VPC間の通信は可能になるが、AWSのサービスエンドポイントへの到達手段にはならない

D　インターネット経路を持たせない方針に真っ向から反する

正解：A

A（正解）　正解。VPCエンドポイントポリシーはそのエンドポイントを通過できるリクエストを制限でき、特定バケットのみを許可する記述ができる

B　ゲートウェイエンドポイントはルートテーブル経由で機能するためセキュリティグループを持たず、S3のIPも変動する

C　S3のIPアドレス範囲は変動するうえ、バケット単位の識別はIPレイヤーではできない

D　エンドポイント経由の通信がすべて止まるだけで、特定バケットのみ許可する制御にはならない

正解：D

A　ルートを書いてもピアリングは推移的な転送を行わないため、パケットは転送されない

B架空　VPCピアリングに推移的ルーティングを有効化する設定は存在しない。設計上の制約であり設定で回避できない

C　セキュリティグループは自身に紐づく通信の制御であり、他VPC間のパケットを中継する機能はない

D（正解）　正解。ピアリングは1対1の関係で推移的な通信を行わないため、直接ピアリングするかTransit Gatewayでハブ型に集約する