はじめに こんにちは、クラウドエース株式会社の小勝です。 近年、リモートワークやクラウドサービスの利用が当たり前になる中、業務システムなどのWebリソースへアクセスする際に「アクセス元の身元を毎回検証する」というゼロトラストの仕組みが重要視されています。特に、「アクセス元の端末自体が本当に安全か」を動的に評価することは、現代のセキュリティにおいて欠かせない要素です。 そのゼロトラスト構築の一環として、Chrome Enterprise PremiumとCrowdStrikeを連携させたアクセス制御の実装を行う機会がありました。しかしその中で、「Chrome Enterpriseでゼロ

本記事は 2026 年 7 月 9 日 に公開された「 AWS Transform for migrations now supports localization for 13 languages 」を翻訳したものです。 移行プロジェクトを運営する組織が、単一の共通言語で業務を行うとは限りません。移行チームは地理的に分散しており、多くの場合、依存関係やビジネスコンテキスト、運用上のリスクを理解している担当者がワークロードに最も精通しています。そのため、担当者が最も慣れた言語で作業できることは欠かせません。本日、 AWS Transform のマイグレーションワークフローの多言語サポートを発表します。 提供開始した機能 AWS Transform の表示言語を以下の 13 言語に変更できるようになりました。 English (US) English (UK) Deutsch (German) Español (Spanish) Français (French) 日本語 (Japanese) Bahasa Indonesia (Indonesian) Italiano (Italian) Português (Portuguese) 한국어 (Korean) 中文 简体 (Chinese Simplified) 中文 繁體 (Chinese Traditional) Türkçe (Turkish) このローカライズは、物理サーバーと仮想サーバー (VMware、Hyper-V、KVM など) のディスカバリー、プランニング、ランディングゾーン、ネットワーク移行、リホスト、コンテナ化を含む AWS Transform マイグレーションワークフロー全体に適用されます。 仕組み 表示言語を切り替えるには、AWS Transform コンソール右上の設定アイコンを選択し、言語メニューから希望の言語を選択します。変更はマイグレーションワークフローの Web アプリケーションインターフェース全体に即時反映されます。 チームメンバーは AWS Transform と翻訳ツールを切り替えることなく、会話型インターフェースの操作、ジョブプランの確認、承認の管理、移行タスクの実行を、希望の言語で行えます。 図 1: Web アプリケーションの表示言語を変更するには、右上の設定アイコンを選択し、言語メニューから希望の言語を選択します。 図 2: 言語設定を日本語に変更した例 多言語対応が重要な理由 AWS Transform は会話型サービスです。自然言語で移行の計画と実行を対話形式で進めます。母国語で読み、応答し、意思決定できてこそ、会話型体験の価値が最大限に発揮されます。これまでインターフェースは英語のみでしたが、英語を主な業務言語としない地域（日本、韓国、ラテンアメリカなど）のチームには使いにくい面がありました。 今回のアップデートにより、マイグレーションエンジニアはタスクの説明確認、プロンプトへの応答、ウェーブプランの操作を、業務言語とツール間で頭の中で翻訳することなく実行できます。データ取り込みからネットワーク変換まで、マイグレーションワークフロー全体を日常の業務言語で利用できるようになりました。 使ってみる すでに AWS Transform for migrations をご利用中の方は、コンソールを開いて今すぐ言語設定をお試しください。AWS Transform を初めてお使いの方は、 AWS Transform ドキュメント をご参照ください。自然言語でワークロードの変換を計画・実行する方法をご確認いただけます。 現在、言語ローカライズに対応しているのは AWS Transform for migrations のみです。 著者について Jason Amaya Jason Amaya は、テキサス州ヒューストンを拠点とする AWS の Go-To-Market (GTM) スペシャリストです。エンタープライズ顧客のクラウド変革を加速させることに注力しており、AWS Worldwide Specialist Organization (WWSO) 内で AWS Transform for Migrations 戦略に携わり、セールスチームや顧客と連携してビジネス成果の拡大に取り組んでいます。 Jamie Vinciguerra Jamie は AWS の Worldwide Go-To-Market スペシャリストで、AWS Transform for migrations を担当しています。インフラのマイグレーションとモダナイゼーション GTM に 4 年間の経験を持ち、VMware ワークロードの AWS への移行支援に深い専門知識を持っています。以前は VMware マイグレーション戦略に注力しており、現在は依存関係マッピング、ウェーブプランニング、ネットワーク変換などを自動化するエージェント型 AI マイグレーションツール「AWS Transform」の普及を推進しています。AWS アカウントチームや顧客と緊密に連携し、クラウドマイグレーションを加速させています。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本記事は、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 環境でこれらのパターンを試してみてください。 翻訳はソリューションアーキテクトの長屋が担当しました。