AWS VPC間リソース共有の新機能について
AWS re:Inventとは
AWS re:Inventは、AWSが年1回ラスベガスで開催する世界最大規模のクラウドコンピューティングカンファレンスです。世界中から数万人の技術者や開発者が集まり、新サービスの発表、技術セッション、ワークショップなどが行われます。2024年は12/1-12/6に開催されており、AWSの最新技術動向や戦略を知ることができる重要なイベントとして位置づけられています。
今回の新機能について
AWS re:Invent 2024で発表された新機能の中で私が所属するチームにおいて注目した機能が、VPC Lattice、PrivateLink、EventBridge、Step Functionsを統合したVPC間リソース共有機能です。
これまで例えばクロスアカウントでのデータベースアクセスには、Network Load Balancer（NLB）やRDS Proxyなど、複数のコンポーネントを組み合わせた複雑な構成が必要でした。新機能では、これらのコンポーネントを必要とせず、よりシンプルな構成でVPCやアカウントを跨いだリソース共有が実現できるようになりました。
我々のチームでは多数のAWSアカウントを保持しており、それら相互の接続が容易になることは保守運用上のメリットが大きいことと、他社含め我々の管轄外のAWS環境との接続要件も多くあることからそこでも使える可能性があるのではないかという期待をしています。
この記事の中ではこの新機能について検証した内容を紹介します。
検証のための構成
今回構築した構成は以下の通りです。
図の左側にあるConsumer AccountのEC2インスタンスから、図の右側にあるOwner AccountのAuroraデータベースへのアクセスを実現しようとしています。
検証の概要
検証環境は、Owner AccountとConsumer Accountの2つのAWSアカウントを使用して構築しました。
Owner Account側では、Private Subnet内にAuroraクラスターを配置し、リソース共有のためのコンポーネントとしてResource GatewayとResource Configを作成しました。
Consumer Account側には、同じくPrivate Subnet内にEC2インスタンスを配置し、Resource Endpointを作成しました。この構成により、インターネットを経由せずにAWSのプライベートネットワークを通じて、Consumer AccountのEC2からOwner AccountのAuroraデータベースへのアクセスが可能となります。
以降、VPCやAurora・EC2の作成手順については割愛し、今回の新機能に直接関係する部分のみにフォーカスをして説明していきます。
Owner Account側の設定について
Owner Account側の設定は、大きく分けて3つのステップで行います。
まず最初に、VPCメニューからResource Gatewayを作成します。ここでは、名前とIPアドレスタイプ（IPv4/IPv6またはデュアルスタック）を指定し、使用するVPCとセキュリティグループを選択します。なお、VPCと共有したいリソースは事前に作成しておく必要があります。
※. VPC/Subnet/Security Group欄を空白にしていますが実際には事前に作成したリソースを選択していきます。
次に、Resource Configを作成します。ここでは名前の他に、コンフィグレーションタイプ（リソースまたはリソースグループ）を選択します。単一のデータベース共有の場合は「リソース」を選択し、通信タイプはTCPを指定します。Resource Gatewayは前段の手順で作成したものを選択します。
Resourece Definitionについて、Auroraの場合にはDNS resourceを指定し、DNSのクラスタエンドポイントやリーダーエンドポイントなど共有したいエンドポイントのDNSを指定します。
ポートについてはデータベースが利用しているポートを指定します。
最後に、Resource Access Manager（RAM）を使用して、これらのリソースをConsumer Accountと共有する設定を行います。共有するリソースのタイプとして"VPC LatticeResource Configrations"を選択すると先ほど作成したResource Configurationが候補として表示されますのでそれを選択し、共有先となるAWSアカウント番号を指定します。
※. 細かいですがアカウント番号を指定した後に"追加"ボタンを押さないと正しく設定されませんのでご注意ください。
これでOwner Account側の設定は完了です。
Consumer Account側の設定について
Consumer Account側で行う作業は大きく2点です。
まずResource Access Managerで共有されたリソースを確認します。その後、エンドポイントの作成を行います。
Resource Access Managerの確認についてはマネジメントコンソールでRAM（Resource Access Manager）を開き、「自分と共有」の中で共有されているリソースの中にOwner Account側で作成したResource Configuraionが含まれていることを確認します。
次にエンドポイントの作成は既存のエンドポイントと同様に、マネジメントコンソールのVPCからエンドポイントを選択します。新しく追加された「リソース」タイプが存在しますのでそちらを選択し、Owner Accountから共有されたResource Configrationを指定します。また、使用するVPCやサブネット、セキュリティグループなどのネットワーク設定を行い、DNS名の解決を有効化することが必要です。
Security Groupsの設定について
通信するにあたりセキュリティ上重要なSecurity Groupsについて、今回の通信においては以下の設定を行う必要があります。
Consumer Account側のSecurity Groups設定
| Security Group | ルール種別 | 送信元/送信先 | ポート | プロトコル | 説明 |
|---|---|---|---|---|---|
| EC2用SG | Outbound | Resource Endpoint SG | DB Port | TCP | DBアクセス用 |
| Resource Endpoint用SG | Inbound | EC2 SG | DB Port | TCP | EC2からの通信許可 |
Owner Account側のSecurity Groups設定
| Security Group | ルール種別 | 送信元/送信先 | ポート | プロトコル | 説明 |
|---|---|---|---|---|---|
| Resource Gateway用SG | Inbound | Resource Endpoint SG | DB Port | TCP | Endpointからの通信許可 ※.ここについてはSGのIDでの設定可否をAWSサポートに問い合わせ予定。今回の検証ではConsumer Accountで使用しているPrivate SubnetのCIDRで許可しました |
| Resource Gateway用SG | Outbound | Aurora SG | DB Port | TCP | DBへの通信許可 |
| Aurora用SG | Inbound | Resource Gateway用SG | DB Port | TCP | Resource Gatewayからの通信許可 |
注：
- DB Portは実際に使用するデータベースのポート番号（例：MySQL=3306, PostgreSQL=5432など）に置き換えてください。
- SGはSecurity Groupの略称として使用しています。
検証結果について
ここまでの設定を行ったうえでEC2からデータベースに対して通信を行うと無事にログイン時のパスワード要求がされます。（代わり映えがしないので画面は載せていません）
なお、EC2からのログイン時に利用するDNS名については、データベースのエンドポイントを直接指定するのではなく、Consumer Account側に作成したResrouce Dndpointの関連付けタブに表示されているDNS名を指定しています。
データーベースのエンドポイント名を指定しても通信はできませんのでご注意ください。
この機能の今後の活用について
この新機能により、クロスアカウントでのリソース共有がより簡単になりました。NLBやRDS Proxyなどの追加コンポーネントが不要となり、構成がシンプルになったことで、運用負荷の軽減も期待できます。
また、この機能はデータベースだけでなく、EventBridgeやStep Functionsなど、様々なAWSリソースでの活用が可能です。マルチアカウント環境でのリソース共有や、マイクロサービスアーキテクチャの実装など、幅広いユースケースでの活用が期待できます。
今回の検証についてはre:Invent期間中に現地（アメリカ ラスベガス）に訪問していた私含めチームメンバ3名で行いました。現地ですぐに機能確認できるぐらいに使いやすいので今後多くの人が気軽に使える機能になるのではないかと感じました。
補足：確認事項と今後の更新について
本検証で確証が持てなかった以下の点についてはAWSサポートへ問い合わせを行う予定です。
- データベースへの接続時に利用するDNS名について
- Resource GatewayのSecurity Group設定について
一点目について今回の検証では、Resource Endpointに表示されるDNS名を使用して接続を行っていますが、この方法が最適な接続方法であるかについて、AWSサポートに確認を行う予定です。
二点目について、RAMによりクロスアカウントでリソースを共有しない限り無関係のAWS環境からアクセスしてくることはできないのでSecurity Groupでの制御はそこまでセキュリティリスクに影響を与えない可能性はありますが、ベストプラクティスがあるのであればそれに従いたいのでその有無を確認予定です。