Reachability Analyzer が AWS Organizations に対応しアカウントを跨いだ分析が可能となりました

記事タイトルとURLをコピーする

カスタマーサクセス部 佐竹です。
AWS re:Invent 2022 が終了してから少し時間が経過しましたが、re:Invent 2022 期間中に発表された新機能の検証を行いましたのでブログでハマったポイントと共にお伝えしたいと思います。

はじめに

re:Invent 2022 で発表されたネットワークに関するアップデートの中で、周りを見るに最も注目されたのは恐らく「Amazon VPC Lattice」だと感じます。

aws.amazon.com

このサービスは NLB を利用した Private Link とはまた異なる、AWS アカウント及び VPC を跨いだアプリケーション(サービス)ネットワークを構築できる新サービスとなっています。

ただ、実用性で一番盛り上がったのが今回ご紹介する、「Cross-account analyses for Reachability Analyzer」でした。これから本機能をご紹介します。

Reachability Analyzer のアップデートの歴史

2020年12月、re:Invent 2020 で発表されたのが Amazon VPC Reachability Analyzerです。

aws.amazon.com

Reachability Analyzer は実際に Ping などを飛ばすのではなく、分析対象として設定する「接続元」と「接続先」リソース間に存在する AWS のネットワークコンポーネントの各設定を論理的に分析することで、それらの経路到達可能性を表示してくれるネットワーク解析機能です。

これはつまり、ネットワークの疎通確認に EC2 インスタンスなどをわざわざ構築しなくても良い、というメリットがあると共に、経路情報が可視化されるというメリットも享受できる素晴らしい機能となっています。

この時、制限として同 AWS アカウント内のリソースという制限があり、また AWS Transit Gateway のコンポーネントには未対応でした。

2022年3月25日のアップデートについて

2022年の3月に、突然 Transit Gateway (TGW) 及び Transit Gateway Route Table に対応しました。これにより、TGW を経由した到達可能性を分析可能となりました。

しかし、同 AWS アカウント内のリソースという制限は残されたままでした。

このため AWS Organizations 配下において、マルチアカウントで Transit Gateway を共有して利用しているシーンでは、アカウントを跨いだ到達可能性分析に利用できず、その点が残念な制限となってしまっていました。

re:Invent 2022 でクロスアカウント到達可能性の分析に対応

aws.amazon.com

上記のアナウンスページの通り2022年11月28日、ついに Amazon VPC Reachability Analyzer が AWS Organization に対応し AWS アカウントを跨いだ到達可能性分析に対応しました。

これにより、非常に利便性が向上したと言えるでしょう。

利用開始における前提条件

本機能は AWS Organizations において明示的に有効化する必要があり、基本的には管理アカウントで利用可能となる機能です。ただし、委任(Delegation)にも対応していますため、ネットワーク用のアカウントに委任を行うことも可能です。

加えて、この機能を有効化するにあたり CloudFormation StackSets (ReachabilityAnalyzerCrossAccountResourceAccessStackSet) が us-east-1 (ヴァージニア)リージョンで実行され、 IAM Role が各アカウントに 1 つ配備されます。

配備される IAM Role は「IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess」という名称であり、この IAM Role についての詳細は以下のドキュメントに記載されています。

docs.aws.amazon.com

IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess

作成される IAM Role に付与される権限は以下の AWS Managed Policy 2つとなります。

  1. AWSDirectConnectReadOnlyAccess
  2. AmazonEC2ReadOnlyAccess

本 IAM Role は本機能を利用するのに必須の IAM Role であり、このため CloudFormation StackSets が正しく動作しない場合はご利用いただけません。

ハマりポイント

2022年の12月時点で発生した事象ですが、CloudFormation StackSets の Delegated administrators(委任された管理者)を設定している場合、CloudFormation StackSets が正常に完了せず Reachability Analyzer が正しく動作しない状況に陥りました。

このため、本機能の有効化のためには一時的に CloudFormation StackSets の Delegated administrators を解除してから有効化されると良いでしょう。このようにしても、既存の StackSets に悪影響が及ぶことはありませんでした。

実際に有効化してみる

こちらの URL」から「Network Manager > Reachability Analyzer > Settings」に移動が可能となっております。

今回の機能有効化においては、AWS Organizations の管理アカウントで AWS Network Manager のコンソールにて、Reachability Analyzer の「Setting」画面を開いて設定を行う必要があります。

Trusted access

Trusted access から、機能を「Turn on」することで本機能が利用できるようになります。

Delegated administrators は任意で設定が可能です。

IAM role deployments status

IAM role deployments status

有効化において重要となるのが、最下部にある「IAM role deployments status」です。ここで、「Console role status」が「StackSet managed」となっていることを確認してください。

もし以下のように StackSet managed がテーブルの一覧に表示されていない場合は、ヴァージニアリージョンで実行されている CloudFormation StackSets が正常に完了していないと思われます。

問題がある場合

この場合、CloudFormation StackSets の Delegated administrators が影響している可能性が高いため、一時的に CloudFormation StackSets の Delegated administrators を管理アカウントに戻してください。

ただ、戻すだけでは正常に動作しないため、Trusted access をオフにし、さらにヴァージニアリージョンに残された CloudFormation StackSets を削除する必要があります。

Error

StackSets についての状況が不明であっても、上画像のように Reachability Analyzer で「Error fetching resources」が発生する場合は IAM Role の Deploy が正常に完了していない可能性が疑われます。

できれば CloudFormation StackSets の Delegated administrators(委任された管理者)を設定している状況でも問題なく設定が完了して欲しいと感じますが、現時点ではこの点でかなりハマってしまいましたので注意点として本ブログに残させて頂きます。

※StackSets の委任をしたままでも問題なく Deploy できる場合もあるようですが、弊社の特定のアカウントでは本事象が発生していました

動作確認

ヴァージニアリージョンで実行されている StackSets が正しく完了していれば、IAM Role が正常に作成されていますため、Reachability Analyzer をクロスアカウントで利用が可能となる前提条件が完了しています。

実際に委任されたアカウントで、クロスアカウントした Reachability Analyzer を東京リージョンのマネジメントコンソールから動作させてみます。

アカウント設定

アカウントを跨いでリソースを設定するため、接続元も接続先もそれぞれでまずは AWS アカウントを選ぶことになります。この時点でかなりよいアップデートになったように感じました。

戻りは実行できず

実際に試してみたところ問題なく動作しており、かつコンポーネントの閲覧性も素晴らしいものでした。一点、reverse path のボタンは押下できず、手動で「戻りの経路」を分析する必要があるでしょう。

構成例とメリット

先の画像にあるように、通過したコンポーネントが順序通りに明示的に表示される点が Reachability Analyzer の優れているポイントです。

今回必要があり、マルチアカウント環境において NAT Gateway の集約を行いました。

この時、EC2 インスタンスを利用した動作確認を行いましたが、インターネットへの疎通が確認できたとして実際に「アカウント内部の NAT Gateway が誤って利用されている状況」であるのか「集約された NAT Gateway を通過している狙い通りの状況なのか」の判別が難しくなります。

NAT Gateway 集約構成図の例

しかし、Reachability Analyzer であればどのアカウントの保持するコンポーネントを通過するのか一目瞭然であり、経路の分析や理解に強力に作用すると感じます。

別アカウント(集約先)の IGW をクロスアカウントで指定可能

このアップデートは素晴らしいもので、AWS Organizations を利用したマルチアカウントを数多く管理する弊社では特に活躍していきそうに感じます。

まとめ

本ブログでは、VPC Reachability Analyzer が AWS Organizations に対応したことでアカウントを跨いだ到達可能性の分析が可能となったアップデートについて記載しました。

本機能の有効化のためには AWS Organizations における事前作業が必要であり、その裏側では IAM Role の配備のためヴァージニアリージョンで CloudFormation StackSets が動作している点についても言及させて頂きました。

本機能は AWS Organizations におけるマルチアカウントのネットワーク到達性の分析にかなり有効活用できるでしょう。

是非とも積極的にご利用いただきたい機能となっています。

関連ブログ

過去のブログで関連する記事をご紹介しています。

blog.serverworks.co.jp

以上となります。

それでは、またお会いしましょう。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。