Amazon Web Services ブログ
Application Load Balancer と Amazon API Gateway プライベート統合を使用したスケーラブルな REST API の構築
本記事は 2025年11月21日 に公開された「Build scalable REST APIs using Amazon API Gateway private integration with Application Load Balancer」を翻訳したものです。
この記事は、プリンシパルソリューションアーキテクトの Vijay Menon とシニアソリューションアーキテクトの Christian Silva によって執筆されました。
本日、Amazon API Gateway REST API が Application Load Balancer (ALB) とのプライベート統合をサポートすることを発表しました。この新機能により、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API 経由で安全に公開できます。
今回のリリース以前は、API Gateway をプライベート ALB に接続する場合、Network Load Balancer (NLB) を中間に配置する必要があり、コストと複雑さが増していました。現在は、NLB を必要とせずに API Gateway をプライベート ALB と直接統合できるため、運用オーバーヘッドが削減され、コストが最適化されます。
従来のアーキテクチャ: API Gateway とプライベート ALB の接続
今回のリリース以前は、API Gateway REST API は ALB の前に配置された NLB を経由してプライベート ALB リソースに接続していました。多くのお客様がこのアーキテクチャを使用して本番ワークロードを構築・運用しており、ビジネスクリティカルなアプリケーションに対する信頼性が実証されています。次の図は、このセットアップを示しています。
図 1. 従来のアーキテクチャ: 中間 NLB 経由での API Gateway からプライベート ALB への接続
アーキテクチャの簡素化とコスト削減を求めるお客様のフィードバックに応えて、VPC Link v2 のサポートを REST API に拡張しました。この機能により、REST API でプライベート ALB との直接統合が可能になり、中間 NLB が不要になりました。
新しいアーキテクチャ: API Gateway とプライベート ALB の接続
プライベート ALB との直接統合により、アーキテクチャはよりシンプルで効率的になります。この統合により中間 NLB が不要になり、クライアントとサービス間のホップ数が削減されます。この合理化されたセットアップにより、アプリケーションのアーキテクチャが簡素化され、ALB のレイヤー 7 ロードバランシング機能、認証、認可機能をより効率的に使用できます。これらの ALB 機能は技術的には以前からアクセス可能でしたが、新しいアーキテクチャでは追加の NLB を管理するオーバーヘッドと複雑さが解消されます。簡素化されたアーキテクチャは次のようになります。
図 2. API Gateway とプライベート ALB 間の直接統合
API Gateway エンドポイントとプライベート ALB の直接統合のメリット
- アーキテクチャの簡素化と運用の優秀性: API Gateway がプライベート ALB に直接接続できるようになったため、API Gateway とプライベート ALB の間のブリッジとして機能する NLB が不要になりました。これにより、中間ロードバランサーのプロビジョニング、設定、管理、監視が不要になります。インフラストラクチャコンポーネントの削減は、運用オーバーヘッドの削減と潜在的な障害ポイントの減少につながります。トラフィックは Amazon Web Services (AWS) ネットワーク内で API Gateway から ALB に直接流れるため、ネットワークホップとレイテンシーが削減されます。
- スケーラビリティの向上: VPC Link v2 は、ロードバランサーとの 1 対多の関係をサポートします。単一の VPC Link v2 により、API Gateway は VPC 内の複数の ALB または NLB と統合できます。このアーキテクチャ上の利点は、それぞれが独自の ALB の背後にある可能性がある複数のマイクロサービスを持つ複雑なアプリケーションを管理する組織や、多数の API を実行している組織にとって特に価値があります。単一の VPC Link を通じて複数のロードバランサー接続を統合する機能は、管理オーバーヘッドを削減するだけでなく、アーキテクチャのスケーリングにおいてより大きな柔軟性を提供します。アプリケーションが成長し、より多くのサービスやロードバランサーを追加する際に、追加の VPC Link をプロビジョニングする必要がないため、運用効率を維持しながらインフラストラクチャを拡張しやすくなります。
- コストの最適化: アーキテクチャから NLB を削除することで、NLB の実行に対する時間料金と、1 時間あたりに使用される Network Load Balancer Capacity Units (NLCU) の両方を削減できます。複数の環境や多数の API を実行している組織では、これらの削減により年間数千ドルの節約が可能になります。さらに、データ転送パターンがより効率的になります。トラフィックは AWS ネットワーク内で API Gateway から ALB に直接流れるため、より多くのデータ転送料金が発生する可能性のある不要なホップを回避できます。この合理化されたパスは、コストを削減するだけでなく、ネットワークレイテンシーを最小限に抑えることでパフォーマンスも向上させます。
はじめる
このチュートリアルでは、AWS マネジメントコンソールと AWS コマンドラインインターフェイス (AWS CLI) の両方を使用したセットアップを実演します。開始する前に、VPC に内部 ALB が設定されていることを確認してください。名前が必要なリソースについては、環境に適した名前を使用してください。
ステップ 1: VPC Link v2 の作成
最初のステップは、API Gateway が内部 ALB にトラフィックをルーティングできるようにする VPC Link v2 を作成することです。設定方法は次のとおりです。
- API Gateway コンソールに移動します。
- 左側のナビゲーションペインで、VPC links を選択します。
- Create VPC link を選択します。
- VPC Link タイプとして VPC link v2 を選択します。
- VPC Link のわかりやすい名前を入力します。
- ALB が存在する VPC とサブネットを選択します。高可用性を実現するには、ALB 設定に一致する複数の AWS アベイラビリティーゾーン (AZ) のサブネットを選択します。
- VPC Link に 1 つ以上のセキュリティグループを割り当てます。これらのセキュリティグループは、API Gateway と VPC 間のトラフィックフローを制御します。
- Create を選択し、VPC Link のステータスが Available になるまで待ちます。このプロセスには数分かかる場合があります。
または、AWS CLI を使用して VPC Link v2 を作成できます。
# VPC Link v2 の作成
aws apigatewayv2 create-vpc-link \
--name "test-vpc-link-v2" \
--subnet-ids "<your-subnet1-id>" "<your-subnet2-id>" \
--security-group-ids "<your-security-group-id>" \
--region <your-AWS-region>
# VPC Link v2 のステータス確認
aws apigatewayv2 get-vpc-link \
--vpc-link-id "<your-vpc-link-v2-id>" \
--region <your-AWS-region>
ステップ 2: REST API の作成と統合の設定
VPC Link v2 が利用可能になったら、次のステップは REST API を作成し、VPC Link を使用するように設定することです。このプロセスには、API の作成、リソースとメソッドの設定、内部 ALB との統合の設定が含まれます。
- API Gateway コンソールで、Create API を選択します。
- REST API を選択します。
- API 名を入力し、Create API を選択します。
- Actions を選択してから Create resource を選択して、新しいリソースを作成します。このリソースは、API のエンドポイントを表します。
- Actions を選択してから Create method を選択して、メソッドを作成します。メソッドは、API が受け入れるリクエストのタイプ (GET、POST など) を定義します。
- 次に、統合を設定します。ここで、VPC Link v2 を介して API を内部 ALB に接続します。
- 統合タイプとして VPC link を選択します。
- バックエンド統合の HTTP メソッドを選択します。
- 新しく作成した VPC Link v2 を選択します。
- 統合ターゲットとして ALB を指定します。
- 統合のエンドポイント URL を入力します。URL で指定されたポートは、バックエンドへのリクエストのルーティングに使用されます。
- Integration timeout を設定します。
AWS CLI を使用する場合:
# REST API の作成
aws apigateway create-rest-api \
--name "test-rest-api" \
--description "REST API integration with internal ALB via VPC link v2" \
--region <your-AWS-region>
# REST API のルートリソース ID を取得
aws apigateway get-resources \
--rest-api-id "<your-rest-api-id>" \
--region <your-AWS-region>
# 新しいリソースの作成
aws apigateway create-resource \
--rest-api-id "<your-rest-api-id>" \
--parent-id "<your-parent-id>" \
--path-part "internal-alb" \
--region <your-AWS-region>
# 新しいメソッドの作成
aws apigateway put-method \
--rest-api-id "<your-rest-api-id>" \
--resource-id "<your-resource-id>" \
--http-method ANY \
--authorization-type NONE \
--region <your-AWS-region>
# 統合の作成
aws apigateway put-integration \
--rest-api-id "<your-rest-api-id>" \
--resource-id "<your-resource-id>" \
--http-method ANY \
--type HTTP_PROXY \
--integration-http-method ANY \
--uri "http://test-internal-alb.com/test" \
--connection-type VPC_LINK \
--connection-id "<your-vpc-link-v2-id>" \
--integration-target "<your-ALB-arn>" \
--region <your-AWS-region>
ステップ 3: デプロイとテスト
API が設定されたら、デプロイして正しく動作していることを確認します。
- Deploy API を選択して、API の新しいデプロイを作成します。
- 新しいステージ (例: “test”) を作成します。ステージを使用すると、API の複数のバージョンを管理できます。
- デプロイ後、API エンドポイント URL が表示されます。テストに必要なため、この URL をコピーします。
お好みの API クライアントまたはシンプルな curl コマンドを使用して API をテストします。
AWS CLI を使用する場合:
# test ステージへの新しいデプロイの作成
aws apigateway create-deployment \
--rest-api-id "<your-rest-api-id>" \
--stage-name "test" \
--region <your-AWS-region>
curl コマンドを使用して API 統合をテストします。
curl https://<rest-api-id>.execute-api.<your-aws-region>.amazonaws.com/internal-alb
{"message": "Hello from internal ALB"}
ステップ 4: VPC Link v2 のスケーリング
単一の VPC Link で、VPC 内の複数の ALB または NLB に接続できるようになり、インフラストラクチャ管理が簡素化されます。この AWS CLI スニペットは、API Gateway が単一の VPC Link v2 を使用して、それぞれが独自の ALB の背後にある複数の内部サービス (例: 注文サービスと支払いサービス) と統合する方法を示しています。両方の統合で同じ VPC Link ID が使用されていることに注目してください。
# 注文サービスの統合 (ALB-1)
aws apigateway put-integration \
--rest-api-id "<your-rest-api-id>" \
--resource-id "<orders-resource-id>" \
--http-method ANY \
--type HTTP_PROXY \
--integration-http-method ANY \
--uri "<your-orders-alb-endpoint>" \
--connection-type VPC_LINK \
--connection-id "<your-vpc-link-v2-id>" \
--integration-target "<your-orders-alb-arn>" \
--region "<your-aws-region>"
# 支払いサービスの統合 (ALB-2)
aws apigateway put-integration \
--rest-api-id "<your-rest-api-id>" \
--resource-id "<payments-resource-id>" \
--http-method ANY \
--type HTTP_PROXY \
--integration-http-method ANY \
--uri "<your-payments-alb-endpoint>" \
--connection-type VPC_LINK \
--connection-id "<your-vpc-link-v2-id>" \
--integration-target "<your-payments-alb-arn>" \
--region "<your-aws-region>"
詳細なステップバイステップガイドについては、API Gateway 開発者ガイドの公式ドキュメントをご覧ください。
ユースケース
API Gateway とのプライベート ALB 統合により、エンタープライズの課題を解決するアーキテクチャパターンが可能になります。この新機能を活用できる 3 つの主要なシナリオを以下に示します。
- Amazon ECS および Amazon EKS 上のマイクロサービス: Amazon ECS または Amazon EKS で実行されているマイクロサービスの公開が、この統合によりシンプルになります。ALB をパブリックインターネットに公開したり、複雑な NLB プロキシパターンを使用したりすることなく、さまざまなサービスへの安全なパスベースのルーティングが可能になります。
- ハイブリッドクラウドアーキテクチャ: AWS Direct Connect または AWS Site-to-Site VPN を介して、クラウドネイティブ API とオンプレミスリソース間のシームレスで安全な接続が実現されます。このセットアップにより、HTTP メソッドとヘッダーに基づいて、さまざまな内部システムへの柔軟なルーティングが可能になります。
- エンタープライズのモダナイゼーション: モノリシックアーキテクチャからマイクロサービスへの段階的な移行を可能にすることで、アプリケーションの段階的なモダナイゼーションが促進されます。組織は、運用の継続性を維持し、リスクを最小限に抑えながら、レガシーコンポーネントと新しいコンポーネント間でトラフィックをルーティングできます。
まとめ
API Gateway REST API と ALB 間の直接プライベート統合により、AWS での API アーキテクチャが強化されます。インフラストラクチャを簡素化し、運用オーバーヘッドを削減することで、この機能は API 駆動型アプリケーションのパフォーマンスと効率を向上させます。
この機能は、VPC Link v2 と ALB が利用可能なすべての AWS リージョンで本日より利用できます。この機能で何を構築し、API アーキテクチャがどのように変革されるかを楽しみにしています。API Gateway コンソールにアクセスして、ALB との直接統合のための最初の VPC Link v2 を作成することで、今すぐ始めることができます。
詳細については、API Gateway 製品ページをご覧いただき、料金の詳細を確認し、包括的な開発者ドキュメントを参照して、AWS で世界クラスの API を構築するために利用できるすべての強力な機能について学んでください。