[レポート] VPC の多層セキュリティとインスペクション #NET311 #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

AWS ネットワークを保護するための重要なステップは、適切なトラフィック検査アーキテクチャを作成することです。 このセッションでは、AWS 環境へのアクセスと AWS 環境からのアクセスをロックダウンする方法について学びます。 このセッションは、VPC セキュリティグループやネットワーク・アクセス・コントロール・リスト (NACL) などの VPC セキュリティのコンポーネントと、それらが VPC のセキュリティを保護する方法について説明します。 次に、AWS ネットワーク ファイアウォール、Amazon Route 53 リゾルバー DNS ファイアウォール、サードパーティのセキュリティ アプライアンスなどのサービスが、ネットワーク内外で実行されるトラフィックの検査にどのように役立つかを見てみましょう。

セッション動画

セッション資料

Layered VPC security and inspection

セッション情報

NET311

イントロダクション

私は Pratik Mankad です。私はネットワーク専門のソリューションアーキテクトで、お客様と連携し、AWSおよびハイブリッド環境でのネットワークアーキテクチャの構築を支援しています。

Rashpal Kler です。 ミルウォーキーを拠点とし、戦略的なアカウントでAWSの大規模顧客をカバーしています。 本セッションは300レベルで、IPルーティング、CIDR表記、DNS解決、およびIPサブネット化についての知識が前提です。このセッションでは、基本的な構成要素を説明し、セキュリティ要素の配置を検討するために、ネットワークアーキテクチャを深掘りし、オブザーバビリティとオーケストレーションについてまとめます。

セッション概要

このセッションでは、1個のリージョン内の VPC 内リソースを保護する方法、 リージョン内の複数の VPC 内のリソースを保護する方法、 2 番目のリージョンを追加した場合に何が起こるか、どのようにするかについても説明します。 リージョン間のリソースを確保します。

ハイブリッドアプローチが好まれる理由や、 オンプレミス、ブランチロケーション、データセンター間でのリソース保護方法についても触れます。 最後に、入力セキュリティと出力セキュリティという2つの一般的なアーキテクチャについて解説します。

AWS 多層セキュリティ

まず、VPC内で利用可能なリソースやサービスを確認し、セキュリティグループやネットワークACLを検討します。 次に、VPCの境界を検証し、Gateway Load Balancerやファイアウォール、AWS Network Firewallを検討します。 また、アプリケーションのセキュリティには、AWS Webアプリケーションファイアウォール（WAF）を利用します。 オブザーバビリティの面では、フローログやトラフィック監視を用いて環境内の状況を把握します。 オーケストレーションでは、すべてを統合する方法を調査し、セキュリティグループから始めます。 VPC内のリソースにはセキュリティグループが付与されており、デフォルトでステートフルな設定になっています。 さらに、セキュリティグループを相互参照でき、VPC間で参照可能です。 ただし、VPCピアリングやトランジットゲートウェイには対応していません。 また、プレフィックスリストを用いて、セキュリティグループに複数のアドレスを割り当てることができます。 この機能は、標準的なアドレスグループを複数のVPCで再利用する際に便利です。 3層アーキテクチャでは、セキュリティグループを層ごとに分割し、それぞれの層で必要なアクセスのみを許可します。 広範囲なセキュリティグループへのアクセスは避けるべきです。

ネットワーク・アクセス・コントロール・リスト (NACL)

ネットワーク・アクセス・コントロール・リスト（NACL）について説明します。 NACLはステートレスの設計で、トラフィックの受信と送信を許可する必要があります。 例えば、ポート22の受信を許可する場合、一時ポートの送信も許可しなければならず、維持するのは面倒です。

デフォルトでは、すべてのトラフィックの送受信が許可されます。 NACLは、サブネットに送受信されるすべてのトラフィックを監視します。 サブネットにルーティングする際、その時点では ACL は評価されません。

ルールの評価では、最小値から最大値の順序で処理されます。 ACLを設定する場合は、 数値が、 10、20、30、40 だとか、 100、200、300 だとか、 後で追加や削除する余裕があることが重要です。

セキュリティグループに関する制限を見ると、 デフォルトの最大ルール数は 60 で、 最大 1000 ルールまで拡張可能です。

NACLは、デフォルトの最大ルール数は 20 で、 最大 40 ルールまで拡張可能です。

セキュリティグループは、レイヤー3とレイヤー4、つまりIPとポートを対象に監視します。 標準のセキュリティグループでは、 すべてのVPCに対して監査を行うことはできませんが、 AWS Firewall Manager サービスを利用すると、 セキュリティグループをすべてのVPCにデプロイできます。

アーキテクチャ構造 - VPC ルーティング

VPCルーティングに関して基本的な構成を説明していきます。 すべてのサブネットにはルートテーブルが関連付けられている必要があり、 特定の機能に対して特定のルートテーブルを作成できます。 例えば、トラフィックをインターネットゲートウェイや トランジットゲートウェイに送信するように設定することが可能です。 ルートテーブルは1つのサブネットには1つだけですが、 1つのルートテーブルを複数のサブネットに関連付けることができます。 イングレスルーティングでは、 インターネットゲートウェイと関連付けられたイングレスルートテーブルがあり、具体的なルーティング設定ができます。 この設定により、例えばインターネットからのトラフィックをサブネット2に送信する前に、サブネット1のアプライアンスやENIなどで検査できます。 また、トラフィックが元の方向に戻る必要があることに注意する必要があります。 ローカルルートはVPCのルートで、VPC内の通信を制御します。 例えば、監視デバイスやトラフィックミラーリングデバイスがある場合、 トラフィックが検査される前に特定のサブネットを通過させたくありません。 これに対応するために、サブネットルートテーブルにはローカルルートよりも具体的なルートを設定できます。 ただし、この設定を行う場合は、使用しているENIが何に使われているかを考慮する必要があります。 ファイアウォールデバイスの場合は、セキュリティグループやNACLなどの他のリソースを使用して第3層や第4層の検査やフィルタリングを行うことができます。 以上がVPCルーティングの基本的な構成になります。

アーキテクチャ構造 - AWS トランジットゲートウェイ

これまで単一VPCについて話しましたが、実際には複数のVPCやアカウントが存在します。トランジットゲートウェイは、クラウドルーターとして複数のネットワーク接続を一元管理できます。 AWS Cloud WANは、複数リージョンでのルーティングを一元管理できる画面を提供します。ルーティングによってセキュリティもセグメント化されており、適切なアクセス制御が可能となります。 また、ACM（AWS Certificate Manager）を使用することで、証明書を生成し、ロードバランサーやCloudFront、API Gatewayにアタッチできます。ACMは証明書の更新を自動化できるため、手間を削減できます。 さらに、アプリケーションロードバランサーは、インスタンス、IPアドレス、Lambda関数をターゲットにできますが、既存のALBをターゲットにすることはできません。 最後に、Gateway Load Balancerは、トラフィックの検査やフィルタリングを行い、セキュリティを向上させることができます。 このように、AWSのトランジットゲートウェイやCloud WANなどの機能を用いることで、複数VPCやアカウントを効率的に管理し、セキュリティを維持することが可能です。

アーキテクチャ構造 - Gateway Load Balancer (GWLB)

GWLBは、サードパーティのファイアウォールやロードバランサーなどを利用しているユーザーにとって重要な要素です。 GWLBは特別なタイプのロードバランサーで、必要に応じてスケールアップやスケールアウトが可能です。背後にあるフリートの可用性も管理できます。 スライドの例では、フロントエンドとバックの2つの部分があります。 ソースから送信されたデータがVPC内のGateway Load Balancerエンドポイントを経由してルーティングされ、 GWLBによってトラフィックが転送されます。 この際、データはGeneveパケットにカプセル化されます。 このカプセル化されたパケットは、ファイアウォールに送信されます。 ファイアウォールでは、Geneveを理解しているため、パケットのカプセル化を解除し、決定を行い、パケットを送信元に送り返します。 その後、ファイアウォールはGWLBに戻り、エンドポイントと宛先にデータが送信されます。 これが、Gateway Load Balancerの基本的な動作です。

アーキテクチャ構造 - AWS Network Firewall

AWS Network Firewallは、サードパーティのファイアウォールを使いたくない場合に利用できるAWSマネージドサービスです。 内部でGateway Load Balancerを使用し、SuricataオープンソースサークルエンジンでIPS、IDS、およびフィルタリングを実行します。Network Firewallはフルマネージドであり、スケールアップとスケールダウンはAWSによって管理されます。 Suricataが提供するIPS/IDSのルールに基づくポリシー作成、IPルール作成、および必要に応じたWebフィルタリング実行のルール作成ができます。ネットワークアーキテクチャを保護するためのセキュリティ検査アーキテクチャの設計を開始する際、セキュリティコンポーネント、すなわちセキュリティエンドポイントをどこに実装するかを理解することが重要です。 セキュリティコンポーネントを集中検査VPCに集めることにより、トラフィックが複数のVPCに展開される前に、その集中検査VPCに流入するか、各VPCが独自のセキュリティスタックを持ってトラフィックを処理するという選択肢があります。ネットワークアーキテクチャを始める前に、展開モデルについて検討することが重要です。

分散導入モデル

分散デプロイメントモデルの目的は、各VPCに独自のセキュリティ検査やセキュリティコンポーネントを持たせることです。 このモデルでは、爆発半径が減少し、データ処理コストも低くなります。 なぜなら、VPC内のリソースに直接到達しているため、トランジットゲートウェイのような複数のコンポーネントを横断することがありません。 ただし、各VPCに独自のセキュリティコンポーネントがあるため、時間あたりのコストが高くなる可能性があります。 最終的には、アーキテクチャに依存しますので、設計時に注意が必要です。

集中導入モデル

集中導入モデルについて説明します。 このモデルでは、セキュリティソリューションを検査VPCでホストします。 そのため、セキュリティコンポーネントが一元化され、すべてのトラフィックが検査VPCやファイアウォールのルール、ポリシーによってルーティングされます。 このアーキテクチャでは、トラフィックが複数のコンポーネントを経由しますが、セキュリティコンポーネントが一つのVPCに集中しているため、時間あたりのコストが低くなります。 ただし、実際にはアーキテクチャのタイプによって異なるため、設計時に注意が必要です。

統合導入モデル

私たちが扱っている統合導入モデルでは、集中型展開モデルと分散型展開モデルの両方でセキュリティコンポーネントやセキュリティソリューションを展開する必要がある状況が考えられます。デプロイメントモデルを選択する際、VPC間やVPCとオンプレミス・インフラストラクチャ間のトラフィックを検査する際には、集中型デプロイメントモデルを推奨します。 しかし、インターネットのイングレスやイーグレスについては、一概には言えません。適切なアーキテクチャや管理しやすいアーキテクチャは、ユーザーである私たちがどのようなニーズを持っており、どの種類のソリューションを利用するかによって決まります。選択肢は私たちの要件や利用するソリューションに依存しています。

Gateway Load Balancer と Network Firewall の比較

そのことを念頭に置いて、 Rashpal は Gateway Load Balancer の構成と Network Firewall の構成 について説明しました。 そこで、集中展開モデルと分散展開モデルに関して、それらがどのように異なるのかについて説明します。

分散展開モデルでは、サードパーティのファイアウォールが検査VPCに配置され、Gateway Load Balancerの背後にターゲットとして追加されます。 一方、AWS Network Firewallの場合、検査VPCはAWSが管理し、顧客は設定に責任を持ちます。 このモデルでは、サードパーティのファイアウォールは顧客管理であり、サービスパートナーが提供する場合もあります。また、分散モデルでは1対多マッピングが可能で、複数のVPCが同じファイアウォールを参照できます。AWS Network Firewallでは、1対1マッピングを使用し、各VPCが独自のファイアウォールを持ちます。しかし、これらはAWS Firewall Manager で管理されるため、ファイアウォール管理が難しくなることはありません。 集中型デプロイメントモデルでは、エンドポイントとファイアウォールが同じVPC内に存在します。このモデルでは、トラフィックはファイアウォール経由でルーティングされます。Network Firewallでも同様の概念が適用されており、アーキテクチャはファイアウォールに関係なく同じままです。

ネットワークアーキテクチャ

それでは、ネットワークアーキテクチャから始めましょう。 ここでは、AWS環境間のトラフィックの検査方法について取り上げています。 具体的には、同じVPC内のトラフィックを検査できるアーキテクチャに焦点を当てています。 このアーキテクチャを利用することで、同じリージョン内のVPC間、異なるリージョン間のVPC間、VPCとオンプレミスインフラストラクチャ間、インターネット上り下りのトラフィックを検査できます。 例として、アプリサブネット1とアプリサブネット2にある2つのインスタンス間のトラフィックを検査したいケースを挙げています。 このシナリオでは、基本的な構成でカバーされたより具体的なルーティングに依存することになります。

サブネットからサブネットへ

2つのサブネットがルートテーブルで関連付けられ、Gateway Load Balancerエンドポイントにトラフィックがルーティングされます。 インスタンス1がインスタンス2と通信する際の手順も示されています。 複数のAZにまたがるサブネットがある場合、エンドポイントがゾーンであるため、興味深いシナリオが提供されます。 非対称ルーティングを維持するために、2つのAZ間のエンドポイントを選択する必要があります。 例えば、AZ1とAZ2の間のトラフィックを検査したい場合、AZ1のエンドポイントを選択すると説明されています。 また、AZ2とAZ3の間でトラフィックを検査するために、AZ2のエンドポイントを選択し、AZ2とAZ3の間でトラフィックを検査するために、AZ3のエンドポイントを選択します。 パケットフローとその仕組みについても見ていきます。 2つのAZ間のトラフィックが検査される場合、ルートテーブルの検索、エントリの照合、そしてGateway Load Balancerエンドポイントへの送信が行われます。 その後、ファイアウォールやAWSプライベートリンクによって検査され、Gateway Load Balancerのエンドポイントサブネットに戻ってルートテーブルの検索が行われ、最終的にインスタンス2に送り返されます。 最後に、同じリージョン内のVPC間のトラフィックを検査するアーキテクチャを見ていきます。 トラフィックを検査するために、セキュリティコンポーネントを集中検査VPCにデプロイする必要があります。 これは、同じリージョン内、異なるリージョン内の2つのVPC間のトラフィック、またはVPCとオンプレミスのインフラストラクチャ間のトラフィックの場合に適用されます。

一元化モデル: VPC から VPC

Rashpalが提案したトランジットゲートウェイは、VPC間のトラフィック検査に必要です。 スポークVPCルートテーブルと検査VPCルートテーブルを連携することで、トラフィックルーティングが可能になります。 トランジットゲートウェイは、検査アーキテクチャにおける重要な要素で、各ルートテーブルのデフォルトルートも指定しています。 各リージョンに独自の検査スタックを持ち、異なるリージョン間のVPCトラフィックやオンプレミス・インフラストラクチャ間のトラフィックも検査できます。 アプライアンスモードを有効にすることで、トランジットゲートウェイがフローの存続期間中に次のトップを選択するようになります。

インターネットのイングレスを一元化する必要がありますか?

一元化の利点は、イングレス管理を中央チームに任せることで、セキュリティやネットワークチームが制御を簡単にすることができる点です。 また、すべてのVPCでのIGWの急増を防ぐことができます。 しかし、一元化には欠点もあります。爆発範囲が広がり、危険性が増すことが一つの問題です。 また、複雑さとコストが増加することも懸念点です。 例えば、すべてのリソースを1つのVPCに配置した場合、アクセスが必要なリソースは別のアカウントの別のVPCに存在することになり、ルーティングが複雑になります。 その結果、システムのトラブルが発生しやすくなり、問題解決も難しくなることが考えられます。 以上のことから、インターネットのイングレスを一元化する必要性は、利点と欠点を総合的に判断する必要があります。

AWS Webアプリケーションファイアウォール (WAF)

AWS Webアプリケーションファイアウォール（WAF）は、レイヤー7ファイアウォールで、IPセットやレピュテーションリストを含めることができ、 ALB、CloudFront、API Gatewayに簡単に接続できます。 分散モデルでは、インターネットからのトラフィックを受信するインターネットゲートウェイがあり、アプリケーションロードバランサーにWAFを接続しています。 処理が完了して許可されると、EC2インスタンスに送信されます。 Firewall Manager を通じて管理が一元化されており、手軽に採用し複数のVPCに適用できます。 CloudFrontを使用する場合、AWS WAFをCloudFrontにアタッチし、セキュリティポリシーを設定します。 集中型モデルでは、トランジットゲートウェイを導入し、検査VPCでトラフィックが処理されます。 プライベートリンクを使用する方法もあり、エンドポイントとネットワークロードバランサーを使用します。 分散モデルでは、イングレスルートテーブルを使用して、より具体的なルーティングを実現できます。 例えば、インターネットゲートウェイに到着したトラフィックは、Gateway Load Balancerのエンドポイントに送信され、ファイアウォールで検査された後、許可されると返送されます。 管理に関しては、例えば、パロアルトのパノラマといったソリューションを通じて、ルールの管理が可能です。 また、パブリック向けALBやNLBを通じて、許可したいトラフィック（HTTP、HTTPSなど）のみを許可することができます。 以上のように、AWS Webアプリケーションファイアウォールを使用することで、よりセキュアなWebアプリケーションの実現が可能です。 各種モデルや方法に応じて、適切なアーキテクチャを選択し、効果的なトラフィックの管理を行うことが重要です。

イングレスルーティングとより具体的なルーティング

イングレスルーティングと具体的なルーティングについて、どちらを選ぶべきかという問題について説明します。 イングレスルーティングでは、ファイアウォールがすべてのトラフィックを確認しますが、スケールアップやスケールダウンの責任も伴います。 また、クライアントIPアドレスの確認に役立ちますが、ACM証明書は使用できません。 一方、具体的なルーティングでは、ロードバランサーがパブリックアクセスを前面に置き、送信元IPアドレスを認識できます。 クライアントのIPアドレスを確認するには、ALBにX424オプションを追加します。 イングレスルーティングの集中モデルでは、すべての検査が受信され、ファイアウォールがロードバランサーに到達する前に決定を行います。 具体的なルーティングの集中モデルでは、ALBやNLBをフロントエンドとし、受信トラフィックがファイアウォールに到達する前にフロントエンドになります。 どちらのモデルもプライベートリンクが絡んでいます。 また、ELBサンドイッチという例もあります。 これは、ロードバランサーとファイアウォールの間に内部向きのロードバランサーがあるモデルです。 このモデルでは、所有している証明書に応じて、パブリック証明書を使用できます。 ただし、サードパーティのファイアウォールが関係している場合、管理はプロバイダーが提供できるものに依存します。 これらの選択肢を考慮して、イングレスルーティングと具体的なルーティングのどちらが適切か判断することが重要です。 データの流れやセキュリティ要件に応じて、最適な選択を行いましょう。

ELB サンドイッチと GWLB の展開

ELBサンドイッチでは、ユーザーから送信されたパケットはALBのパブリックIPアドレスを経由してファイアウォールに届きます。 ファイアウォールはIPアドレスを変更し、内部ELBを宛先としてインスタンスに送信します。 一方で、Gateway Load Balancerを利用する場合、ユーザーからのパケットはそのままの形でインスタンスに届けられます。 クラウドWANシナリオでは、IPパケットはALBに入り、ゲートウェイロードバランサがルートを決定してCNEに送ります。 その後、コアネットワークに向けてルーティングが行われ、許可された場合はアプリケーションVPCに送信されます。 インターネットにアクセスする必要がある際、Squidプロキシなどのオープンソースソリューションが用いられることがあります。 これにより、トラフィックは自動的にフィルタリングされ、インターネットに送信されます。 分散モデルでは、例えば http://example.com を送信する必要がある場合、デフォルトルートがNATゲートウェイに向かいます。 NATゲートウェイは、パケットのソースアドレスを変換してパブリックアドレスにします。 その後、インターネットに送信され、パケットが受信されます。 集中型モデルでは、リージョン内に1つのVPCが存在し、デフォルトルートがトランジットゲートウェイに向かいます。 トランジットゲートウェイは、検査VPCに送信するために必要なルートテーブルが含まれます。 その後、トラフィックはファイアウォールエンドポイントにルーティングされ、検査が行われた後、NATゲートウェイに送信され、インターネットに出力されます。 DNSファイアウォールを利用することで、DNSセキュリティを確立し、トラフィックが許可される前にルーティングを行うことができます。 許可された場合、トラフィックはファイアウォールエンドポイントにルーティングされ、その後、NATゲートウェイにルーティングされ、インターネットに送信されます。 AWS Firewall Manager を使用すると、AWSアカウントとアプリケーション全体でファイアウォールルールとポリシーを一元的に設定および管理できます。 AWS Organizations とAWSリソースアクセスマネージャーを使用して、ファイアウォールとDNSファイアウォールを管理できます。 これにより、セキュリティポリシーに従って、許可されたドメインのみにアクセスできるように制御ができます。

アプリケーションおよびネットワーク サービスの一元管理

Firewall Manager は、Webアプリケーションファイアウォール、Shield Advanced、DDoS保護サービス、VPCセキュリティグループ、AWS Network Firewall、およびRoute 53リゾルバーDNSファイアウォールをサポートしています。 これらを使用して、セキュリティハブというクラウドセキュリティ体制管理に通知を送ることができます。 セキュリティベストプラクティスを保証し、アラートをチェックして集約することができるサービスです。 これにより、作業の実行が容易になります。

AWS Firewall Manager - AWS ネットワーク ファイアウォールの導入

AWS Firewall Manager を使うと、複数のVPCを持つ異なるアカウントで一元化してファイアウォールをデプロイできます。 方法としては、ポリシーの種類とリージョンを選択し、ポリシーを記述します。 次にエンドポイントタイプを選択し、ルート管理を構成します。 その後、ポリシースコープを定義し、ポリシータグを設定して確認後、適用します。 これにより、すべてのエンドポイントとファイアウォールが作成されます。 最後に、VPCルートテーブルを手動で編集し、ルートテーブルの変更が必要です。 このように、AWS Firewall Manager を利用することで、簡単にファイアウォールの管理ができます。

ネットワークのオブザーバビリティ - フローログ

フローログについて説明します。 VPCフローログは、ネットワークインターフェイス間を流れるIPトラフィック情報を取得できる機能で、エラスティックネットワークインターフェイスやサブネットなどのフローログが作成可能です。 VPC内のすべてのネットワークインターフェイスが監視され、フローログをAmazon CloudWatchやAmazon S3に送信できます。 フローログやVPCフローログを使うことで、制限のあるセキュリティルールグループを分析し、インスタンスやネットワークインターフェイスの送受信トラフィックを監視できます。 複数のVPCがトランジットゲートウェイに接続された際には、VPCフローログを活用する必要があります。 トランジットゲートウェイの所有者がVPCフローログにアクセスできない場合、対処が困難です。 このため、トランジットゲートウェイフローログという機能がリリースされました。 これにより、トランジットゲートウェイを経由するIPトラフィックを可視化し、アーキテクチャ全体の視点でネットワーク全体を把握できます。 最後に、VPCフローログとトランジットゲートウェイのフローログフィールドには、デフォルト形式とカスタム形式が存在します。 これらを利用して、効果的なネットワーク監視・管理が可能です。

ネットワークのオブザーバビリティ - Amazon VPC トラフィック ミラーリング

VPCトラフィックミラーリングは、ネットワークタブやポートミラーリングに似ており、パケット全体をキャプチャする機能です。 これにより、インスタンスやエラスティックネットワークインターフェイス（ENI）に関連付けられたトラフィックをターゲットに送信することができます。 また、EC2インスタンス、ネットワークロードバランサー、Gateway Load Balancerエンドポイントに関連付けられたエラスティックネットワークインターフェイスも対象となります。

VPC Reachability Analyzer

VPC Reachability Analyzer は、ソースと宛先間の接続の確認ができる構成分析ツールです。 送信元と宛先が接続できるかどうかをチェックし、接続できる場合は、パス間の各ホップの詳細を表示します。 宛先に到達できない場合、何が問題かを特定し、構成ミスによるブロックがあるかどうかを通知します。 このツールは、セキュリティグループ、ルートテーブル、ネットワークACL、ロードバランサーなどの問題解決に役立ちます。 加えて、接続問題のトラブルシューティングやネットワーク構成の検証、接続意図の自動検証ができます。 ソースや宛先として利用可能なリソースタイプがいくつかあり、VPC Network Access Analyzer もその一つです。

Amazon VPC Network Access Analyzer

Amazon VPC Network Access Analyzer は、リソースへのネットワークアクセスを把握するためのツールです。 ネットワークを保護する際に、適切なアーキテクチャの理解が重要ですが、自身で設計したアーキテクチャが目的やビジネス目標を達成しているかの確認も大切です。 このツールを利用することで、それらの確認を効率的に行うことができます。

Network Access Analyzer のユースケース

ここでは、アクセス分析を活用した一部のユースケースについて紹介します。 VPC内のリソースへのインターネットアクセスが可能になり、信頼できるネットワークポートが実現できることを確認できます。 また、Network FirewallやNATゲートウェイがネットワーク間に存在するかを確認することも可能です。 リソースとインターネットゲートウェイ、ネットワークセグメントを使用することで、信頼できるネットワークアクセスが実現し、プライベートネットワーク接続も可能になります。

今回のセッションにご参加いただきありがとうございました。 新しい知識が得られて楽しんでいただければ幸いです。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。