株式会社エブリーは、「前向きなきっかけを、ひとりひとりの日常にとどける。」というミッションのもと、デリッシュキッチン、retail HUB、トモニテ、MOMENTH といった BtoC・BtoB を横断するメディアやサービスを展開しています。同社では、小売事業者向けサービス retail HUB におけるピッキングサービスの新規開発にあたり、データベースとして Amazon Aurora DSQL を採用しました。本ブログでは、お客様の開発チームに伺った Aurora DSQL 採用の背景、導入の取り組み、そして導入後に得られた効果についてご紹介します。 対象システム 今回 Aurora DSQL を採用したのは、 retail HUB 事業のネットスーパーサービスにおけるピッキングサービスです。 retail HUB は、お客様が提供する小売事業者向けの DX ソリューションです。店頭サイネージによるレシピ提案、デジタルチラシ、ネットスーパーアプリの提供、店頭運営の効率化、CRM によるロイヤルカスタマー育成まで、小売事業者の販促プロセス全体をデジタル化し、業務効率化ときめ細やかな顧客アプローチを実現しています。 retail HUB 事業のネットスーパーサービスでは、店舗側が売り場から注文商品をピックアップする作業が発生しますが、従来この運用は紙のリストで行われており、商品を探すのに時間がかかることや習熟度による作業スピードのばらつきなどにより人的ミスの防止が難しく、誤ピックによる取り直しが発生するといった課題がありました。この問題を解決するため、ピッキングアプリ「retail HUB Picker」の開発が求められました。 アーキテクチャ ピッキングサービスのアーキテクチャは、ピッキングアプリ（Android アプリ）から Amazon ECS + ALB で構成された API サーバーに接続し、担当者の認証管理には Amazon Cognito を利用しています。バックエンドのデータベースとして Aurora DSQL を採用し、ピッキング対象の商品情報やピッキング状態、担当者情報の格納・参照に使用しています。 ピッキングサービスのシステムアーキテクチャは以下のとおりです。今回新規に開発したピッキングシステムは既存のネットスーパーシステムとは分離しており、注文データを連携する箇所のみで結合しています。 データベース選定の背景 今回のピッキングサービスは新規開発であり、データベースの選定にあたってはシステムの特性に合わせた検討が行われました。データベースに求められる要件は以下でした。 安定性と可用性 ピッキング作業中にシステムが停止すると店舗のピッキング業務に影響を与え、導入店舗数が増えるほどその影響範囲も大きくなるため、安定性と高い可用性が重要な要件でした。また、小売店舗は土日も稼働しているため、運営側の都合でメンテナンス時間を設定しにくいというビジネス上の課題も考慮する必要がありました。 低コストによるスモールスタート 初期フェーズではリクエスト数が限定的であり、構築・運用にあまりコストをかけたくないという要望がありました。一方で、今後サービスの成長に伴いトラフィックの増加も想定されるため、高いスケーラビリティを備えたデータベースであることが望ましいと考えていました。 運用負荷の軽減 メンテナンスウィンドウに伴う運用負荷が課題となっていました。新規サービスでは、こうした運用負荷を極力下げたいという考えがありました。 Aurora DSQL を選択した理由 お客様では当初、既存システムで利用している Amazon RDS for MySQL や Amazon Aurora MySQL の導入を想定していました。しかし、上記の要件を踏まえて検討を進めた結果、サーバーレスの分散データベースである Aurora DSQL が採用されました。その理由は以下の通りです。 安定性と可用性 — シングルリージョン構成で 99.99%（マルチリージョン構成では 99.999%）の可用性を備えたサーバーレスの分散データベースであり、インフラ管理が不要。ピッキング作業中のシステム停止リスクを低く抑えられる 低コストによるスモールスタート — 従量制の課金モデルで初期コストを抑えつつ、将来のサービス成長に伴うトラフィック増加にも自動スケールで対応できる 運用負荷の軽減 — パッチ適用がダウンタイムなしで自動的に行われるため、関係者との調整や作業工数が不要になる 加えて、Aurora DSQL が PostgreSQL との互換性を備えていたことで、社内の既存知見を活かしながら導入できる点も後押しとなりました。また、お客様の開発チームには分散データベースへの技術的な関心が高く、Aurora DSQL を通じて得られる知見が今後の技術選定の指標になるという期待も大きく、採用の決め手の一つとなりました。 Aurora DSQL とは Aurora DSQL は、AWS が提供するサーバーレスの分散 SQL データベースです。従来のデータベースのようにクエリ処理・ストレージ・トランザクション管理が密結合した構成ではなく、それぞれが独立したコンポーネントに分かれています。各コンポーネントがワークロードに応じて個別にスケールするため、特定の処理がボトルネックになりにくく、低レイテンシーで強固な一貫性を実現しています。また、PostgreSQL との互換性を備えており、既存の PostgreSQL の知見やツールを活かして開発を進めることができます。 お客様が選定の理由に挙げた以下の 3 つについて、Aurora DSQL の特性を簡単に説明します。 安定性と可用性 Aurora DSQL では、すべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたすべてのログデータを 3 つのアベイラビリティーゾーンにあるストレージレプリカに同期レプリケーションします。これにより、Aurora の Multi-AZ 構成と同等の 99.99% の可用性を実現しています。以下の図は、Aurora DSQL の可用性に関する特性を示しています。 低コストによるスモールスタート 課金はリクエスト数やデータ量に応じた従量制で、リクエスト数が少ない段階ではコストを低く抑えられます。アーキテクチャを変更することなく自動的にスケールするため、小規模な構成から始めて、トラフィックの増加に応じてシームレスにスケールすることができます。以下の図は、Aurora DSQL のコストモデルを示しています。 運用負荷の軽減 サーバーのプロビジョニングやパッチ適用、インフラのアップグレードといった管理作業が不要です。パッチ適用やセキュリティアップデートはダウンタイムなしで自動的に処理されるため、メンテナンスウィンドウの調整や計画停止が不要です。以下の図は、Aurora DSQL と従来のデータベースにおけるメンテナンスの違いを示しています。 開発時の課題 開発スケジュール 開発スケジュールは以下のとおりです。 時期 内容 2025年5月 小売事業者に対するヒアリング（事業部門＋開発部門） 2025年6月 運用分析、開発要件定義、分析要件定義、システム設計 2025年7月〜8月 開発（アプリケーション、API サーバー、インフラ、分析基盤） 2025年9月上旬 社内 QA 2025年9月中旬 リリース、小売事業者にて検証・運用開始 Aurora DSQL を用いた開発にあたっては、PostgreSQL との互換性に関していくつかの課題がありました。 スキーマ変更の制約 Aurora DSQL ではカラム追加時にデフォルト値を指定する構文がサポートされていないことが開発中に判明しました。PostgreSQL では一般的に使用される構文であるため、既存の知見をそのまま適用できないケースでした。対処として、カラムのみを追加し、デフォルト値や NOT NULL 制約はソフトウェアレベルで保証する実装としました。なお、サービスリリース前であったため、最終的にはテーブルを再作成することで問題を回避しました。このように、事前のドキュメント確認だけでは把握しきれず、実際の操作を通じて発見される差分もありました。 ローカル開発環境との互換性 当初ローカル開発では PostgreSQL のコンテナを使用していましたが、 CREATE INDEX を CREATE INDEX ASYNC に変更する必要があるなど、Aurora DSQL との互換性がない部分が判明したため、ローカル環境でも Aurora DSQL を使用する方式に切り替えました。 トランザクションサイズの制限 Aurora DSQL にはトランザクションデータ件数に制限があるため、大量のデータを一括で処理する実装には工夫が必要でした。この制限を回避するため、大量のデータ投入処理においては全体を 1 トランザクションにまとめず、処理を分割する設計としました。具体的には、データ量が大きい投入処理ではトランザクションを使わずに実行し、途中でエラーが発生しても何度でもやり直せる設計としました。その上で、整合性の担保が必要な少量のデータ更新処理だけをトランザクション内で実行するようにしました。 こうした課題を一つずつ解消しながら開発を進め、ピッキングサービスは無事にローンチを迎えました。 ローンチと導入後の効果 2025 年 9 月中旬にローンチしてから数ヶ月が経過していますが、大きな問題は発生しておらず、安定した稼働を続けています。 導入後に得られた効果は以下のとおりです。 コスト削減 Aurora PostgreSQL（Provisioned）で想定していたインスタンスサイズと比較すると、コストは 90% 以上低くなっています。従量制のコストモデルにより、初期フェーズにおいて大幅なコスト削減を実現しました。 以下は、今回のワークロードを想定したコスト比較の試算です。Aurora PostgreSQL（Provisioned）を 100 とした場合の相対コストを示しています。 構成 Pattern S コスト比 Pattern M コスト比 Pattern L コスト比 Aurora PostgreSQL (Provisioned) 100% 100% 100% Aurora Serverless v2 41% 41% 66% Aurora DSQL 4% 6% 12% 安定稼働とメンテナンスフリー サービス導入後は安定して稼働しており、パフォーマンス上の問題も発生していません。メンテナンスウィンドウが不要であるため、基盤のメンテナンス作業そのものだけでなく、それに伴う小売事業者やサービス利用者との調整業務も不要となりました。既存システムでは 3 ヶ月ごとのパッチアップデートのたびに、メンテナンス時間帯の調整、影響範囲の洗い出し、小売事業者や関係部署への連携が必要でしたが、Aurora DSQL ではこうした業務コストがゼロになり、運用負荷が大きく削減されました。 スケーラビリティの確保 現時点でのリクエスト数の変動については特に大きな問題は発生していません。今後のサービス成長に伴うトラフィック増加についても、検証の結果スケーリングに問題がないことを確認しており、今後のトラフィック増加にも不安なく運用できる見通しです。 お客様の声 お客様に Aurora DSQL の導入効果について伺ったところ、次のように述べています。 スケーラビリティと安定性の要件が高いシステムにおいて Aurora DSQL を選択する利点は高いと考えています。 – 内原 章 氏　株式会社エブリー 開発本部 開発2部 部長 今後の展望 お客様では、今回のピッキングサービスでの導入実績を踏まえ、スケーラビリティの要件が高いシステムにおいて Aurora DSQL を選択肢として検討していく方針です。新規開発だけでなく、既存システムのリプレースにおいても Aurora DSQL の活用を視野に入れています。 また、Aurora DSQL のさらなる進化への期待として、PostgreSQL との互換性向上を挙げています。特に RLS（Row Level Security）のような機能がサポートされることで、より幅広いユースケースに対応しやすくなると考えています。 Aurora DSQL は、高い可用性とスケーラビリティを必要とするシステムにおいて、運用負荷とコストの低減が期待できるデータベースです。本ブログが、同様の課題を持つお客様にとって参考になれば幸いです。

本記事は、2025 年 6 月 11 日に Networking & Content Delivery で公開された VPC resource gateways: Implementation patterns and use cases を翻訳したものです。 Amazon Virtual Private Cloud (Amazon VPC) 間でアプリケーションを接続する際、従来の AWS PrivateLink のプロバイダー・コンシューマーモデルに適合しないサービスへの接続が必要になると、VPC ピアリングや AWS Transit Gateway だけでは簡単に解決できない複雑なネットワーク課題に直面します。これは特に、IP アドレス空間が重複している場合に顕著です。 従来の PrivateLink の Provider-Consumer Model に適合しないサービスへの接続を、VPC リソースゲートウェイを使用することで実現でき、ネットワークアーキテクチャを簡素化できます。プロバイダーがサービスの前段に Network Load Balancer を配置することを求める VPC エンドポイントサービスとは異なり、リソースゲートウェイはロードバランサーインフラストラクチャの追加オーバーヘッドなしに、より幅広いターゲットを公開できます。 これまで複雑な追加設定が必要だったシナリオでも、追加インフラストラクチャの管理オーバーヘッドなしにサービスにアクセスできるようになりました。リソースゲートウェイは、ARN、DNS、または IP ベースのサービスへの接続を可能にしながら、セキュリティの維持、複雑さの軽減、コストの最適化を実現します。 リソースゲートウェイには複数のアクセス方法があります。 リソースエンドポイント 、 Amazon VPC Lattice サービスネットワークアソシエーション、および VPC Lattice サービスネットワークに接続された サービスネットワークエンドポイント です。本記事では、リソースへのアクセスを提供するために、リソースゲートウェイとリソースエンドポイントを使用したアーキテクチャパターンに焦点を当てます。Amazon VPC Lattice のサービスネットワークエンドポイントのユースケースと使用方法の詳細については、 こちらのブログ を参照してください。 以下のユースケースとトラフィックフローパターンを通じて、リソースゲートウェイの機能を理解していきましょう。 ユースケース 1：RDS リソースへのプライベートかつセキュアなアクセス 異なるビジネスユニットやアプリケーションコンポーネント間で厳密な分離を維持するために、マルチ VPC またはマルチアカウント戦略を採用している場合、アプリケーションサーバーとデータベースが異なる VPC や AWS アカウントに配置されます。また、このアーキテクチャパターンの要件は、合併・買収（M&A）の際にも発生します。 Amazon Relational Database Service (Amazon RDS) は、管理タスクを自動化することで従来型データベースの管理を簡素化します。 Amazon Aurora は、MySQL および PostgreSQL との完全な互換性を持つグローバルスケールのリレーショナルデータベースです。 Web/アプリケーションサーバーと RDS/Aurora データベースが異なる VPC に存在する場合、VPC ピアリングによる直接的な VPC 間通信や、AWS Transit Gateway / AWS Cloud WAN を使用したネットワーク接続のセットアップにより接続を確立できます。しかし、コンシューマーの数が急速に増加すると、これらの VPC ピアリング接続や AWS Transit Gateway / AWS Cloud WAN を経由するネットワークフローの管理オーバーヘッドが増大します。 リソースゲートウェイとリソース VPC エンドポイントを使用して、アプリケーションから Amazon RDS リソースへの接続を可能にできます。図1は、このユースケースのハイレベルアーキテクチャ図を示しています： 図1：RDS リソースへのプライベートかつセキュアなアクセス RDS リソースへのプライベートかつセキュアなアクセスを実現するために、以下の手順でリソースエンドポイントとリソースゲートウェイを構成できます： RDS リソースが存在する VPC にリソースゲートウェイを作成する。 アクセスしたい各 RDS クラスターまたはインスタンスに対して「ARN」タイプの リソース設定 を作成し、リソースゲートウェイに関連付ける。   注意 ：ARN ベースのリソースは現在、パブリックでない Amazon RDS リソースでサポートされています。ARN ベースのリソース設定の 子リソース設定 は、AWS によって自動的に管理されます。 （オプション） コンシューマー VPC と RDS VPC が異なる AWS アカウントにある場合、RDS VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に 「Resource」タイプの VPC エンドポイント を作成し、ARN タイプのリソース設定に関連付ける。VPC エンドポイントの作成時に、オプションで「Private DNS」を有効化する。Private DNS を有効にすると、リソース VPC エンドポイントを通じたプライベート接続を活用しながら、AWS サービスがリソースに対してプロビジョニングした DNS 名を使用してリクエストを続けることができます。   注意 ：Private DNS を使用するには、コンシューマー VPC の DNS ホスト名および DNS 解決が「有効」 （enableDnsHostnames, enableDnsSupport）に設定されていることを確認してください。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 VPC エンドポイントの Private DNS が有効時と無効時での動作を示す：   有効（推奨） ：RDS リソースの DNS 名（ライターエンドポイント、リーダーエンドポイント、またはインスタンスエンドポイント）を使用してリソースにアクセスできます。   無効 ：リソース VPC エンドポイントの DNS 名を使用して RDS リソースにアクセスします。ただし、これはデータベース証明書のコモンネーム（CN）を検証 していない 場合にのみ機能します。これは、リソース VPC エンドポイントの DNS 名が RDS/Aurora DB インスタンスの証明書のサブジェクト代替名（SAN）に含まれていないためです。 ユースケース 2：VPC IP CIDR が重複する環境での接続 CIDR が重複する VPC にコンシューマーとリソースが 存在する場合、それら間の直接通信が困難になります。このシナリオは、合併・買収時、パートナーネットワークへの接続時、または CIDR の計画が調整されていないマルチアカウント環境で一般的に発生します。この問題に対処する従来のソリューションには、NAT（ネットワークアドレス変換）を実行するアプライアンスの設定、NAT ゲートウェイの使用、または Network Load Balancer の作成と VPC エンドポイントサービスを使用したサービスの公開が含まれます。これらの解決策は有効ですが、追加リソースの作成が必要なため、複雑さとコストが増加します。 VPC リソースエンドポイントとリソースゲートウェイは、このような状況でコンシューマーがリソースにアクセスできるようにする、よりシンプルな代替手段を提供します。図2は、このユースケースのハイレベルアーキテクチャ図を示しています。 図2：重複 CIDR ユースケースにおけるリソースエンドポイントとリソースゲートウェイの使用 このケースでコンシューマーがリソースにアクセスできるようにするには、以下を実行します。 アクセス対象のリソースが存在する VPC にリソースゲートウェイを作成する。 リソースまたはリソースグループを表すリソース設定を作成し、リソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に、各リソース設定に対応する「Resource」タイプの VPC エンドポイントを作成する。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 リソース VPC エンドポイントの DNS 名を使用して、リソース VPC 内のリソースにアクセスする。フレンドリーな名前を使用してリソースにアクセスしたい場合は、「コンシューマー VPC」に関連付けられたプライベートホストゾーンを作成し、フレンドリー DNS 名をリソース VPC エンドポイントの DNS 名にポイントする CNAME レコードを追加できます。リソース VPC エンドポイントの DNS 名は、関連するリソース VPC エンドポイントを選択した際の「Associations」の下で確認できます。 図3：リソース VPC エンドポイントの DNS 名 ユースケース 3：パブリックドメインへの接続プロキシ パブリックエンドポイント宛ての通信であっても、一元化されたVPCを経由させるか、あるいはプライベートかつ制御されたネットワーク経路を使用することを義務付けるような厳格なポリシーを採用する場合を想定します。こうしたパブリックエンドポイントは、多くの場合 AWS 外の SaaS サービスか、AWS 上にありながら PrivateLink 経由ではプライベートに公開されていないサービスです。 リソースゲートウェイを使用して、集約 VPC 経由で、または AWS VPN 、 AWS Direct Connect 、VPC ピアリングなどのプライベート接続オプションを介したインクラウド接続ユースケースとして、パブリックエンドポイント（AWS またはサードパーティ）にアクセスできます。図4は、VPC 内のクライアントが集約 VPC とリソースゲートウェイを通じてパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 図4：集約 VPC とリソースゲートウェイによるパブリックエンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC 経由でパブリックエンドポイントへの接続を確立するには、以下のアプローチに従います： パブリックサブネットとプライベートサブネットを持つ VPC（「リソース VPC」）を作成する。VPC ルーティングを設定し、プライベートサブネットからインターネットへのトラフィックがパブリックサブネット内の NAT ゲートウェイを経由してルーティングされることを確認する。 リソース VPC のプライベートサブネットにリソースゲートウェイを作成する。 コンシューマーにアクセスさせたい各ドメイン名に対して、「DNS」タイプのリソース設定を作成する。各 DNS リソース設定は、コンシューマーにアクセスさせたい単一のドメイン名にマッピングされます。複数のドメイン名にアクセスさせたい場合は、複数のリソース設定を単一の「リソースグループ」にグループ化し、単一のリソース VPC エンドポイントで複数ドメインにアクセスできるようにできます。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS Resource Access Manager(RAM) を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 プライベートホストゾーン（コンシューマー VPC に関連付け）を作成し、アクセスするパブリック FQDN をリソースエンドポイントの対応する DNS 名にマッピングする CNAME タイプのレコードを追加する。リソースエンドポイントの DNS 名の確認方法については、図2を参照。 プライベートホストゾーンで作成したレコードを使用して、アプリケーションからパブリックエンドポイントにアクセスする。 同様に、オンプレミスと AWS 間の確立済みプライベート接続を通じて、パブリックエンドポイントへのトラフィックをルーティングすることもできます。これにより、アウトバウンドインターネット接続を信頼できるエンドポイントに制限し、オンプレミスのクライアントがネットワーク分離を維持しコンプライアンス要件を満たしながら、パブリック FQDN とセキュアに通信できるようになります。図5は、オンプレミスのクライアントが AWS Site-to-Site VPN / AWS Direct Connect を介してリソースゲートウェイ経由でパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 ※訳者注：集約 VPC の IGW からのアウトバウンド通信は TGW での接続が分かりやすく一般的ですが、TGW のデータ処理料金は $0.02/GB、リソースエンドポイントのデータ処理料金は $0.01/GB であり、本方式は特にデータ量が圧倒的である場合、コスト削減に大きく寄与します。 図5：集約 VPC とリソースゲートウェイによるオンプレミスからのパブリックエンドポイントへのアクセス ユースケース 4：Transit Gateway や VPC ピアリングを経由せずに AWS サービスのインターフェースエンドポイントを集約する インターネットを経由せずに AWS サービスへのプライベート接続を実現するには、インターフェース VPC エンドポイントを使用できます。しかし、各 VPC でサービスごとに個別のインターフェース VPC エンドポイントを作成すると、大きなコストと管理の複雑さにつながる可能性があります。そのため、より効率的なアプローチは、必要な すべてのインターフェースエンドポイントをホストする集約 VPC を用意し、AWS Transit Gateway または AWS VPC ピアリング接続を使用してコンシューマー VPC とリソース VPC 間の接続を確立し、集約 VPC エンドポイントへの接続を実現することです。 リソースゲートウェイとリソースエンドポイントは、このユースケース（特に大規模ネットワーク）に対処するための、よりシンプルでコスト効率の高いオプションを提供します。Transit Gateway アタッチメントよりも低い全体コスト（時間あたりおよびデータ処理）で、単一のリソースエンドポイントを作成して複数の AWS サービスエンドポイントにアクセスできます（集約 VPC エンドポイントが主なユースケースであることを前提）。図6は、このユースケースのハイレベルアーキテクチャ図を示しています。 図6：リソースゲートウェイを使用した集約 VPC エンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC エンドポイントへのプライベート接続を確立する方法は以下のとおりです。 リソース VPC に、要件に応じた AWS サービスの集約インターフェース VPC エンドポイントを作成する。 リソース VPC にリソースゲートウェイを作成する。 各 AWS サービス VPC エンドポイントに対して、「DNS」のリソース定義を持つリソース設定を作成する。ドメイン名には、インターフェース VPC エンドポイントのリージョナル DNS 名を追加する（例： vpce-xxxx.ec2.<region>.vpce.amazonaws.com ）。   注意 ：リソースゲートウェイでは、リソース設定の DNS 名がパブリックに解決可能である必要があるため、インターフェース VPC エンドポイントのプライベート DNS 名は機能しません。 子 DNS リソース設定を持つリソースグループを作成し、リソースグループをリソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 （オプション）異なるドメイン名を使用してサービスエンドポイントにアクセスしたい場合は、ドメイン名 <region>.amazonaws.com のプライベートホストゾーンを作成し、コンシューマー VPC に関連付ける。アクセスする各サービスに対してプレフィックス付きの CNAME タイプのレコードを追加し（例： <prefix>.ec2.<region>.vpce.amazonaws.com ）、リソースエンドポイントの対応する DNS 名にポイントする。TLS 検証が正常に行われるようにするため、プライベートホストゾーンとレコードは上記の形式である必要がある。 プライベートホストゾーンで作成したレコード（例： <prefix>.<region>.vpce.amazonaws.com ）、またはリソースエンドポイントの DNS 名を使用して、アプリケーションからインターフェースエンドポイントにアクセスする。 まとめ 本記事では、VPC リソースゲートウェイを使用して AWS 環境における複雑なネットワーク課題を簡素化する方法を説明しました。プライベートなデータベース接続の確立、IP アドレスが競合するネットワーク間の通信の実現、セキュアなインターネットアクセスの作成、AWS サービスアクセスの合理化について解説しました。これらのソリューションは、VPC リソースゲートウェイが強固なセキュリティを維持しながら一般的なネットワーク課題に対処する方法を示しており、成長に合わせたクラウドアーキテクチャの構築に有用なツールとなります。 AWS ネットワーク構成を簡素化する準備はできましたか？ VPC リソースゲートウェイ のドキュメントを参照して、今すぐリソースゲートウェイの実装を開始し、ご自身の AWS 環境でこれらのパターンを試してみてください。 翻訳はソリューションアーキテクトの長屋が担当しました。

はじめに 2026年6月に約3週間、CA Tech Jobに参加しました、早稲田大学基幹理工学部情報 ...