AWSは Amazon API Gatewayに、カスタムドメイン名用動的ルーティングルールを搭載した新機能を導入した－ユーザーがHTTPヘッダーの値に基づいて、独立して、またはURLパスと組み合わせてAPIリクエストをルーティングできるようにする。
以前、動的ルーティングのためにAPIゲートウェイに依存していた開発者は、トラフィックを分割するために /v1/products や /v2/products のような異なるURLパスをよく使用していた。しかし、このアプローチは機能的ではあるものの、複雑なURL構造やAPIエンドポイントの増加を招く可能性がある。しかし、新しい動的ルーティングルール機能を使用すれば、ユーザーはカスタムドメイン名の設定内で直接ルーティングの決定を行うことができる－すなわち受信したHTTPヘッダー、ベースパス、またはその両方の組み合わせに基づいてルーティング判断できるようになる。
さらにこの機能により、API移行時にパスの変更や新しいパスの作成が不要になるため、APIバージョニングやA/Bテストの実施もスムーズになる。また、ホスト名やテナントID、Cookieの値といった条件に応じた動的バックエンド選択も可能になるため、追加プロキシ層を導入することなく、APIトラフィックに対してきめ細かい制御が実現できる。
（出典：AWS Computeブログ投稿）
本質的に、API Gatewayのルーティングルール)はカスタムドメインに紐づく特定リソースとして機能し、受信したリクエストをどのように転送するかを決定する。各ルールは3つの重要プロパティにより定義される：条件は、最大二つのヘッダー値と一つのベースパス値に基づいてクライテリアを指定する（すべて一致する必要あり、柔軟なマッチングのためにワイルドカードもサポート）。アクションは、条件にマッチした場合に呼び出すAPIステージを定義する。優先度は、評価順序を決定する。たとえば、x-versionのようなヘッダー条件では、*v2*のようなワイルドカードを用いてx-version=alpha-v2-latestやx-version=beta-v2-testに一致させるなど、きめ細かなルーティング戦略を可能にする。
ルーティングルールを作成する前に、ユーザーは少なくとも一つのAPI、ステージ、カスタムドメイン名が必要となる。３つのルーティングモードがある：「APIマッピングのみ」はルーティングルールなしでベースパスマッピングを使う；「ルーティングルール優先後にAPIマッピング」はまずルーティングルールが優先し、マッチしないリクエストはベースパスマッピングにフォールバックする；「ルーティングルールのみ」はもっぱらルーティングルールに依存し、新しいドメインやAPIマッピングから移行した後に推奨されるモードである。既存マッピングが上書きされる可能性があるため、本番環境への適用前に必ず非本番環境で変更内容をテストすること。
APIのバージョン管理やA/Bテストのための動的ルーティング機能は、Azure API ManagementやGoogle Apigeeなどの主要クラウドAPI管理プラットフォームにも存在しているが、これらの実装は一般的にポリシー表現やプロキシレベル設定に依存している。Amazon API Gatewayの新しいアプローチは、特定のルーティングシナリオを簡素化することを目的とし、カスタムドメインレベルで専用の宣言型ルーティングルールリソースを提供する点で際立っている。
さらに、API Gatewayはアクセスログを通じてリクエスト処理の可視性を提供している。各リクエストにはルーティングの決定を明確にするコンテキスト変数が含まれており、例えば$context.customDomain.routingRuleIdMatchedは一致したルールを示す。$context.domainName、$context.apiId、$context.Stageといった他の変数はルーティングの全体的なコンテキストを提供する。これらのログを分析することでユーザーはルーティング動作を確認し、問題のトラブルシューティングを行い、APIバージョンやテストバリエーションごとのトラフィックの傾向なのどインサイトを得ることができる。
Mediumブログ投稿で、ソフトウェアエンジニアのPaul Issack Minoltan氏は結論付けた：
本質的にAPI Gatewayの新ルーティングルールは、高度なルーティングロジックを直接API Gateway設定に組み込むようにし、アーキテクチャの簡素化と、APIトラフィックの振り分け方法に対する制御強化を提供します。
最後に、詳細な情報はサービスのドキュメントで確認でき、この機能のエンドツーエンド事例はGitHubで公開されている。