本記事は 2026/2/24に投稿された Well-Architected design for resiliency with Oracle Database@AWS を翻訳した記事です。 Oracle Database@AWS は、Amazon Web Services（AWS）データセンター内で Oracle Cloud Infrastructure（OCI）によって管理される Oracle Exadata インフラストラクチャを使用する データベースサービス を通じて、エンタープライズグレードのデータベース機能を提供します。Oracle Database@AWS を使用して、オンプレミスの Oracle Exadata と同じパフォーマンスと機能を維持しながら、Oracle Exadata ワークロードを AWS に移行できます。Oracle Exadata と AWS 上で実行されているアプリケーション間で低遅延接続を確立することで、アプリケーション遅延の削減という恩恵を受けることができます。さらに、観測可能性、分析、人工知能と機械学習（AI/ML）、生成 AI アプリケーションの構築など、様々な機能のために Oracle Database@AWS を他のAWS サービスと統合できます。複数のアベイラビリティーゾーンにわたって自動管理、最適化されたパフォーマンス、および組み込みセキュリティ機能を提供することで、Oracle Database@AWS は最高レベルのデータベース信頼性とパフォーマンスを維持しながら運用オーバーヘッドの削減に役立ちます。 高可用性（HA）と災害復旧（DR）オプションは、Oracle Database@AWS で重要なデータベースを移行または展開する際に考慮すべき重要な側面であり、アーキテクチャがアプリケーションのサービスレベルアグリーメント（SLA）を満たせるようにするためにも役立ちます。ハードウェア障害、リージョン障害、またはその他の中断によってデータベースにダウンタイムが発生すると、重大な収益損失、顧客関係の悪化、および潜在的なコンプライアンス違反に直面する可能性があり、堅牢な可用性ソリューションがビジネスにとって必要不可欠です。これらの課題に対処するために、Oracle Database@AWS の多層的なアプローチを使用して、包括的な保護戦略を実装できます。高可用性のためのクロス AZ 構成と災害復旧のためのクロスリージョン設定の両方で Oracle Data Guard を使用することにより、ローカルハードウェア障害から AWS リージョン全体の障害まで及ぶ多層防御保護を構築できます。 この投稿は、Oracle の Maximum Availability Architecture（MAA） のベストプラクティスと AWS の Well-Architected フレームワーク に従った Data Guard 構成の実装と維持に役立ちます。適切なネットワークアーキテクチャの選択方法と、クロス AZ とクロスリージョンの両方に Data Guard アソシエーションを構成する方法を示します。これにより、ロール移行中にアプリケーションがシームレスな接続を維持できるようにします。 Data Guard を使用した Oracle Database@AWS での HA とDR Oracle Database@AWS で提供される Exadata Database Service on Dedicated Infrastructure（ExaDB-D）と Autonomous Database Dedicated（ADB-D）サービスは、Data Guard 構成を作成および維持するためのマネージド体験を提供します。プライマリとスタンバイの仮想マシン（VM）クラスター間で必要な接続が確立された後、OCI コンソールまたはコマンドラインインターフェース（CLI）を使用してプライマリサイトとスタンバイサイト間の Data Guard 構成を構築できます。次の図は、同一リージョン内の2つの AZ 間およびリージョン間で Data Guard アソシエーションを使用した ExaDB-D の HA/DR 構成のリファレンスアーキテクチャを示しています。 次の表は、ExaDB-D と ADB-D サービスで利用可能な Data Guard アソシエーション機能の比較を示しています。 機能 ExaDB-D ADB-D Data Guardの作成と管理のマネージド体験 はい はい クロス AZ 構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい クロスリージョン構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい サポートされるスタンバイデータベース数（ローカルとリモートを含む） 6 2 推奨構成 クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) Data Guard アソシエーションのネットワーク接続を確立するには、2つのオプションから選択できます： AWS Transit Gateway を使用して、2つの AZ または2つのリージョンにある2つのODBネットワークを接続する。 クロス AZ 構成ではローカルピアリングゲートウェイを使用し、クロスリージョンでの Data Guard 構成の場合はリモート VCN ピアリングと 動的ルーティングゲートウェイ （DRG）を使用して、OCI Virtual Cloud Network（VCN） レベルでピアリングを確立する。 次のセクションでは、Oracle Database@AWS の Data Guard アソシエーションにおける様々な接続オプションのネットワーク詳細、利点、およびコストへの影響について詳しく説明します。 同一リージョン内のクロス AZ デプロイメント AWS 上のレジリエンシーのあるデータベースアーキテクチャの基盤は、プライマリ AZ の障害から重要なデータベースを保護することから始まります。ExaDB-D と ADB-D の両方のサービスで利用可能なクロス AZ Data Guard 構成のネットワークオプションを見ていきましょう。 Data Guard 接続に2つの ODB ネットワークを接続するための Transit Gateway を使用する Transit Gateway を使用して、リージョン内の2つの AZ にある2つの ODB ネットワーク 間のトラフィックを AWS ネットワーク内でルーティングできます。次の図は、2つの AZ （ az1 と az2 ）でホストされている2つの Exadata VM クラスターと ODB ネットワーク間の構成の詳細を示しており、各 ODB ネットワークとピアリングされたトランジット仮想プライベートクラウド（VPC）を経由してルーティングされる接続を持つ Transit Gateway を使用しています。 この例では、b.b.b.b/b は az1 の ODB ネットワークのクライアントサブネット CIDR 範囲、a.a.a.a/a は az1 の ODB ネットワークとピアリングされた Transit VPCの CIDR 範囲、y.y.y.y/y は az2 の ODB ネットワークのクライアントサブネット CIDR 範囲、x.x.x.x/x は az2 の ODB ネットワークと ODB ピアリングされた Transit VPC の CIDR 範囲です。 ネットワーク CIDR プライマリ Transit VPC a.a.a.a/a プライマリ ODB ネットワーククライアントサブネット b.b.b.b/b スタンバイ Transit VPC x.x.x.x/x スタンバイ ODB ネットワーククライアントサブネット y.y.y.y/y Oracle Database@AWS のネットワークアーキテクチャと ODB ピアリングの概念について学ぶには、 ODB ピアリング を参照してください。 次の図は、リージョン内の2つの AZ 間で Transit Gateway を使用して Data Guard トラフィックの接続を設定する方法を示しています。 このアーキテクチャを実装するには、次の手順に従う必要があります： ODB ピアリング方法 を使用して、Transit VPC1（CIDR a.a.a.a/a）を ODBNetwork-az1 （クライアント CIDR b.b.b.b/b）とピアリングし、Transit VPC2（CIDR x.x.x.x/x）を ODBNetwork-az2 （クライアント CIDR y.y.y.y/y）とピアリングします。 Transit Gateway をプロビジョニングするか既存の Transit Gateway を使用し、ODB ネットワークがデプロイされている AZ にマッピングされたサブネットに対して、Transit VPC1 と Transit VPC2の両方にアタッチします。Transit VPCへの Transit Gateway アタッチメントは、ODB ネットワークがプロビジョニングされている AZ にマッピングされたサブネットのみをカバーする必要があります。 Transit VPC1 のルートテーブル（Transit Gateway アタッチメント用のサブネットで使用される）を変更して、Transit VPC2 CIDR（x.x.x.x/x）と ODBNetwork-az2 CIDR（y.y.y.y/y）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 Transit VPC2 のルートテーブル（Transit Gatewayアタッチメント用のサブネットで使用される）を変更して、Transit VPC1 CIDR（a.a.a.a/a）と ODBNetwork-az1 CIDR（b.b.b.b/b）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 これらのサブネットにアタッチされたルートテーブルからのルートは、Transit Gateway のルートテーブルに自動的に入力されます。 Transit Gateway に直接接続されていない両方の AZ の ODB ネットワーククライアント CIDR に対して、Transit Gateway 上に2つの静的ルートを追加します。CIDR b.b.b.b/b とy.y.y.y/y の静的ルートは、Transit VPC の対応する Transit Gateway アタッチメントを指す必要があります。 ODB ピアリング接続を変更して、他の ODB ネットワークとその Transit VPC のピアリング CIDR 範囲を追加します： ODBNetwork-az1 の ODB ピアリング接続を変更して、x.x.x.x/x と y.y.y.y/y をそのピアリング CIDR リストに追加します。 ODBNetwork-az2 の ODB ピアリング接続を変更して、a.a.a.a/a と b.b.b.b/b をそのピアリング CIDR リストに追加します。 ODB ピアリング接続のピアリング CIDR リストを変更することで、対応する OCI VCN のネットワークセキュリティグループが自動的に更新されて必要なトラフィックが許可されます。データベースリスナーポート、SSH（22）、および ICMP での接続を確認するために、ネットワークセキュリティグループルールを確認できます。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために AWS Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じものを使用できます。 Data Guard 接続に OCI VCN でローカルピアリングゲートウェイを使用する VM クラスター間の接続を確立する2番目のオプションは、ローカルピアリングゲートウェイを使用して ODB ネットワークに関連付けられた2つの OCI VCN 間でトラフィックをルーティングすることです。 次の図では、 ODBNetwork-az1 はクライアント CIDR b.b.b.b/b を持つ AZ1 の ODB ネットワークの名前であり、 ODBNetwork-az2 はクライアント CIDR y.y.y.y/y を持つ AZ2 の ODB ネットワークの名前です。 OCI VCN をピアリングして接続を実装するには、次の手順に従う必要があります： OCI コンソールから ODB ネットワークに関連付けられた OCI VCN を特定し、クライアントネットワークの CIDR 範囲を記録します。 各 VCN に1つのローカルピアリングゲートウェイを追加します。 2つのローカルピアリングゲートウェイをピアリングします。 ODBNetwork-az1 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az2 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 ODBNetwork-az2 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az1 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 各 OCI VCN のネットワークセキュリティグループ（名前が調整可能なもの）を変更して、他の ODB ネットワーククライアント CIDR からのトラフィックを許可します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 この構成の詳細については、 Oracle Database@AWS でのクロスゾーン Data Guard を使用したディザスタ・リカバリの実装について を参照してください。 クロス AZ Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用して AZ 間で Data Guard トラフィックをルーティングする2つのオプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー 1桁台前半のミリ秒 1桁台前半のミリ秒 コスト Transit Gateway と クロス AZ 料金 データ転送料金なし データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D は Data Guard アソシエーションを追加する際、自動フェイルオーバー用の Data Guard Observer を自動的に構成しません。ただし、Observer 構成を手動で構築することができます。アプリケーションとデータベース間の接続が影響を受けた際にフェイルオーバーをトリガーするために、アプリケーションスタックが主に配置されている AWS ネットワーク上に Data Guard Observer インスタンスをホストすることが推奨されます。次の図は、Fast-Start Failover（FSFO）用に3番目の AZ に展開された Observer 構成を持つ、2つの AZ にわたる Data Guard アソシエーションのリファレンスアーキテクチャを示しています。ADB-D の場合、Observer プロセスを手動で構成することなく、クロス AZ 構成の自動フェイルオーバーを有効にできます。 Data Guardアソシエーションを使用したクロスリージョンディザスタリカバリー AZ 間で HA 構成を確立した後、次のステップは DR 保護を実装することです。DR 要件がクロス AZ 構成で提供できる範囲を超える場合は、リージョン間で Data Guard を実装します。クロスリージョン Data Guard 構成で利用可能な接続オプションを検討し、その効果を比較してみましょう。 リージョン間での2つの ODB ネットワークを接続するために Transit Gateway を使用する 次の図に示すように、Transit Gateway 構成を使用して、AWS ネットワーク内の2つのリージョンにある2つの ODB ネットワーク間でトラフィックをルーティングできます。 この構成の高レベルの手順には以下が含まれます： 各リージョンに1つずつ、2つの Transit Gatway をプロビジョニングします。既存の Transit Gateway を使用することもできます。 各リージョンの ODB ピアリングVPCに、ODB ネットワークが存在する AZ にマッピングされたサブネットへ Trasnit Gateway をアタッチします。 AWS Transit Gateway の Transit Gateway ピアリングアタッチメント で説明されているように、ピアリングアタッチメントを作成し、ピアリングリクエストを受け入れて、Transit Gateway 間の接続を確立します。 クロス AZ トラフィック用の Transit Gatway 構成について前述した手順に従って、ルーティングルールを更新します。 ODB ネットワーク構成を変更して、リモート ODB ネットワークからのトラフィックを許可するように ODB ネットワークのピアリング CIDR リストを更新します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じ手順を使用できます。 OCI VCN とのリモート VCN ピアリングを使用する クロスリージョンの Data Guard 構成のための接続を確立するためにバックエンドの OCI VCN をピアリングする2番目のオプションでは、各側に追加の HUB VCN を構成する必要があります。これは、OCI VCN は1つの DRG にのみアタッチできるためであり、ODB ネットワークにマッピングされた VCN はすでに AWS-OCI ネットワーク統合のために DRG にアタッチされているためです。そのため、HUB VCN を導入し、ODB ネットワークの OCI VCN と HUB VCN 間でローカルピアリングゲートウェイ接続を確立します。その後、次の図に示すようにクロスリージョン接続のために DRG にアタッチできます。 詳細な構成手順については、 Oracle Database@AWS 上のリージョン間 Active Data Guard によるディザスタ・リカバリの実装 を参照してください。 クロスリージョン Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用してリージョン間でData Guardトラフィックを行う接続オプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー ミリ秒 ミリ秒 コスト Transit Gateway 料金 と クロスリージョンデータ転送料金 クロスリージョンデータ転送料金 データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D と ADB-D の Data Guard アソシエーションの構成 ExaDB-D と ADB-D は両方とも、バックアップ、リストア、および Data Guard 構成の手順を手動で実行することなく、コンソールまたは API と CLI を使用して Data Guard アソシエーションを設定するためのマネージド体験を提供します。ExaDB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Oracle Exadata Database Service on Dedicated Infrastructure を選択します。 プライマリデータベース用の VMC を選択します。 プライマリデータベースを選択します。 Data Guard associations を選択します。 スタンバイインスタンスに適切なターゲット AD、インフラストラクチャ、および VMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 ADB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Autonomous Database on Dedicated Infrastructure を選択します。 Autonomous Container Database（ACD）を選択します。 Data guard associations を選択します。 スタンバイに適切なターゲット AD、インフラストラクチャ、および AVMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 クロス AZ Data Guard フェイルオーバーとスイッチオーバーのアプリケーション接続 データベースへのアプリケーション接続は、ADB-D と ExaDB-D の両方で Data Guard のスイッチオーバーとフェイルオーバーのシナリオを計画する際に慎重な検討が必要です。このセクションでは、適切な TNS 構成を使用することで、アプリケーションが再構成なしにロール移行シナリオ全体でデータベースへの接続を透過的に確立できるようにする、アプリケーションスタックからデータベースへの接続のための Well-Architected で推奨されるモデルについて説明します。 ほとんどの場合、顧客は高可用性のために異なる AZ にマッピングされたサブネットにまたがる VPC 内にアプリケーションスタックをデプロイします。VPC はプライマリ AZ とスタンバイ AZ の ODB ネットワークと同時にピアリングできるため、その VPC で実行されているアプリケーションは、次の図に示すように Data Guard のスイッチオーバーとフェイルオーバーのシナリオ全体でデータベースへの透過的な接続を促進できます。 Transit Gateway を介して ODB ネットワーク内のデータベースにアプリケーションが接続されている場合、プライマリおよびスタンバイ AZ の ODB ネットワークとピアリングされた Transit VPC を Transit Gatway にアタッチすることで、スイッチオーバーとフェイルオーバーのシナリオ全体で透過的な接続を確立できます。次の図に示すように、アプリケーションは Transit Gateway を介して ODB ネットワークに接続し、ODB ピアリング VPC は単にトランジットパスとして機能します。 このアーキテクチャでは、Transit VPC はアプリケーションコンポーネントをホストせず、アプリケーションは Transit Gateway を使用してデータベース層に接続します。 まとめ この投稿では、Oracle Database@AWS で実行されている重要なデータベースの HA と DR 要件を満たすために Data Guard を使用する方法を示しました。また、Data Guard トラフィックをルーティングするための接続オプションについて説明し、データベースへのアプリケーション接続のベストプラクティスを共有しました。Oracle RAC (Real Application Clusters) が提供するサーバーラックレベルのレジリエンシー、Data Guard マルチ AZ レプリケーション、クロスリージョンディザスタリカバリなど、複数の保護層を慎重に実装することで、Oracle Database@AWS にデプロイされたデータベースに対して望ましい保護レベルと可用性を実現できます。現在の可用性要件を評価し、適切な Data Guard 構成を選択し、ビジネスニーズに最適なネットワークアーキテクチャを実装することで、包括的なデータベースレジリエンシーへの取り組みを今日から始めましょう。この投稿の詳細な構成手順とアーキテクチャパターンは、アプリケーションのビジネス継続性を提供する堅牢な Oracle Database@AWS 環境の構築と維持に役立ちます。 Oracle Database@AWS の機能と構成について詳しく学ぶには、 Oracle Database@AWS ユーザーガイド を参照してください。 著者について Jobin Joseph Jobin は、トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンに焦点を当て、顧客のデータベースワークロードの AWS への移行とモダナイズを支援しています。25年以上の Oracle Database 経験を持つ Oracle 認定マスターです。 Julien Silverston Julien は、25年の経験を持つ Oracle Cloud Infrastructure マルチクラウドチームのプリンシパルソリューションアーキテクトです。Julien は、マルチクラウド、ハイブリッドクラウド、およびクラウドベースのソリューションに精通しています。Oracle Cloud Infrastructure 認定ソリューションアーキテクトです。 Jeremy Shearer Jeremy は、ヒューストンを拠点とし、Oracle Alliance に専念する AWS のプリンシパルパートナーソリューションアーキテクトです。約30年の Oracle 経験を持ち、特に JD Edwards などの Oracle エンタープライズ ERP システムのインストール、構成、管理、および移行を専門としています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

本ブログは 2026 年 3 月 10 日に公開された AWS Blog、” AWS Security Hub is expanding to unify security operations across multicloud environments ” を翻訳したものです。 多くのお客様と話をして、1 つ明確なことがあります。それは、セキュリティの課題は容易になっていないということです。今日の企業は、オンプレミスインフラストラクチャ、プライベートデータセンター、複数のクラウドなど、複雑に混在する環境で運用しており、多くの場合、連携を前提に設計されていないツールを使用しています。その結果、企業のセキュリティチームは、リスク管理よりもツール管理に多くの時間を費やすことになり、ますます複雑化する環境全体で脅威に先回りすることが困難になっています。 Amazon Web Service (AWS) では、セキュリティはシンプルで、統合され、企業が実際に運用する方法に合わせて構築されるべきだと考えています。この信念が、 AWS Security Hub を再構築し、単一のエクスペリエンスを通じてフルスタックセキュリティを提供する原動力となり、このビジョンが私たちの次の展開を推し進めています。 統合セキュリティの基盤の上に 私たちは Security Hub を、 統合セキュリティオペレーションソリューション に変革しました。これは、 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub Cloud Security Posture Management (Security Hub CSPM) 、 Amazon Macie を含む AWS セキュリティサービスを統合し、脅威、脆弱性、設定ミス、機密データに関するセキュリティシグナルを自動的かつ継続的に分析する単一のエクスペリエンスを実現しています。Security Hub は共通の基盤を提供し、AWS 環境全体からの検出結果を統合することで、セキュリティチームがシグナルの解釈に費やす時間を減らし、対応により多くの時間を割けるようにします。この基盤の上に構築された統合オペレーションレイヤーは、セキュリティチームにニアリアルタイムのリスク分析、自動化された分析、優先順位付けされたインサイトを提供し、大規模に最も重要なことに集中できるよう支援します。 また、企業がエンドポイント、ID、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション全体にわたるフルスタックセキュリティソリューションを調達、デプロイ、統合する方法を簡素化する新機能 ( the Extended plan ) を導入しました。現在、お客様は Security Hub を使用して、厳選された AWS パートナーソリューション (ローンチ時: 7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (Cisco 傘下)、Upwind、Zscaler) を通じて、すべて 1 つの統一されたエクスペリエンスでセキュリティポートフォリオを拡張できます。AWS が販売元となるため、従量制料金の料金体系、単一の請求書、長期契約なしというメリットを享受できます。私たちのゴールはシンプルです。企業が運営するあらゆる場所で、統一されたセキュリティを提供することです。 ワークロードがどこにあっても、自由にイノベーションを AWS では、相互運用性とは、お客様のニーズに最適なソリューションを自由に選択でき、ワークロードが実行される場所でそれらを使用できることを意味します。しかし、マルチクラウド環境全体で自由にイノベーションを起こすということは、運用の複雑さを増すことなく、一貫してそれらを保護することが重要であることも意味します。 Security Hub の今後の展開 今後数か月間で、AWS を超えた統合セキュリティオペレーションを拡張する新しいマルチクラウド機能を Security Hub に追加します。この拡張の基盤となるのは、ワークロードがどこで実行されていても、セキュリティシグナルを統合する共通データレイヤーです。その上に、統合されたポリシーとオペレーションレイヤーが、一貫したポスチャ管理、エクスポージャー分析、リスクの優先順位付けを提供するため、セキュリティチームは断片化されたコンソールの集合ではなく、単一のリスクビューから運用できます。 Security Hub は、マルチクラウド環境全体にわたる重要なリスクを明らかにする統合リスク分析を提供します。一貫したセキュリティポスチャの可視性を提供する Security Hub CSPM チェックを使用してクラウドセキュリティポスチャを管理でき、仮想マシンスキャン、コンテナイメージスキャン、サーバーレススキャンを含む拡張された Amazon Inspector 機能により、脆弱性管理を拡張できます。また、Security Hub は、外部ネットワークスキャンにより、AWS 以外で実行されているリソースを含むマルチクラウド環境全体のインターネット公開状態に関するコンテキストでセキュリティ検出結果をエンリッチします。 その結果、企業全体でより包括的なリスクカバレッジが実現されます。これは、セキュリティチームに対して、どこで運用していても、リスクを検出して対応するための単一の統一されたエクスペリエンスを提供することを目的としています。 ビジネスを加速するセキュリティ 私が話をするセキュリティリーダーたちは、単により良いツールを求めているわけではありません。求めているのは、リスクを管理するだけでなく、リスクに先回りする方法です。ビジネスのペースについていくセキュリティを求めており、ビジネスを遅らせるセキュリティではありません。 これが AWS Security Hub のビジョンです。共通のデータ基盤上に構築され、インテリジェントな分析によって強化され、一貫した運用レイヤーを通じて提供される、単一の統合されたセキュリティ運用体験による統一されたセキュリティです。これにより、セキュリティリスクの軽減、チームの生産性向上、AWS 全体およびそれ以外でのセキュリティ運用の強化を支援します。 マルチクラウドへの拡大は進行中であり、まだ始まったばかりです。 詳細については、 aws.amazon.com/security-hub をご覧いただくか、3 月 23 日から 26 日にサンフランシスコで開催される RSA Conference の AWS ブース (S-0466) にお越しください。 Gee Rittenhouse Gee は AWS のセキュリティサービス担当バイスプレジデントで、Security Hub、GuardDuty、Inspector などの主要サービスを統括しています。MIT で博士号を取得し、エンタープライズセキュリティとクラウド分野で豊富なリーダーシップ経験を持っています。以前は Skyhigh Security の CEO および Cisco セキュリティビジネスグループの SVP 兼 GM を務めていました。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

1. はじめに Amazon Web Services（AWS）でハイブリッドネットワークを設計する際、 Direct Connect + Transit Gateway + Site-to-Site VPN という構成が採用されることがあります。 金融・公共系のシステムでセキュリティ要件が厳格で、専用線でかつ暗号化が必須といった場合などです。 このとき、多くの方が 「Transit Gatewayを使うならTransit VIFを使う」 と自然に考えるのではないでしょうか。 しかしSite-to-Site VPNを構築する場合には、実はPublic VIFを使ってTransit