[解決済み] 地域/エッジに最適化されたAPIゲートウェイ VS 地域/エッジに最適化されたカスタムドメイン名

質問

これは私には全く意味がありません。新しいAPI Gatewayを作成するときに、地域最適化かエッジ最適化かを指定することができます。しかし、その後、API Gatewayのカスタムドメイン名を作成するときに、2つのうちどちらかを選択することができます。

最悪なのは、混ぜて使うことができることです!!!! エッジ最適化されたAPI Gatewayのために地域カスタムドメイン名を持つことができ、それは私にとって全く無意味なことです!

なぜこの2つは別々に地域/エッジ最適化できるのでしょうか？また、どのような場合にそれぞれを地域/エッジ最適化したいのでしょうか？

どのように解決するのですか？

なぜ、この 2 つは別々に地域/エッジ最適化できるのですか?

RegionalとEdge-Optimizedはデプロイメントオプションです。 どちらのオプションも、リクエストが API Gateway サービスのコアに到達した後に AWS インフラストラクチャによって API が処理される方法、または API Gateway の背後にあるサービスに最終的にアクセスする方法について、基本的には何も変わりません -- 何が変わるかというと、次のとおりです。 どのように リクエストは最初にAWSに到着し、実行のためにAPI Gatewayのコアに配信されます。 これについては、以下で詳しく説明します。

カスタムドメイン名を使用する場合、選択したAPIステージは2回目のエンドポイントにデプロイされるため、デプロイタイプを2回目選択する必要があります。

各エンドポイントは、地域またはエッジに最適化されているかどうか、そのデプロイメント タイプの特性を持っています。 API 自体の元の展開タイプは、カスタムドメイン名で展開され、その後そのカスタムドメイン名を使用してアクセスされた場合の API の動作に影響を与えません - これらは独立しています。

通常、カスタムドメイン名で API をデプロイする場合、メイン API 用に作成されたデプロイメントエンドポイント (たとえば xxxx.execute-api.{region}.amazonaws.com ) を使用し続けることはないでしょうから、最初の選択は重要ではないはずです。

また、それぞれをいつ地域/エッジ最適化すればいいのでしょうか？

カスタムドメイン名を使用している場合、上記のように、API全体に対するオリジナルのデプロイメントの選択は、カスタムドメインを使用する場合、それ以上の影響を与えません。

Edge-optimized エンドポイントはもともと唯一の選択肢でした。選択の根拠となるものがない場合、この選択は通常、合理的なものです。

このオプションは、100以上のグローバルなエッジロケーションを持つCloudFrontネットワークであるAWS "Edge Network,"を介して、受信リクエストをルーティングします。 しかし、リクエストは世界中から最も近いAWSエッジにルーティングされ、そこからAWSが運営するネットワークを通って、あなたがAPIをデプロイしたリージョンに到着します。

API Gatewayステージのクライアントが世界中に散らばっていて、APIを単一のリージョンにしかデプロイしていない場合、おそらくエッジに最適化されたデプロイが必要でしょう。

エッジ最適化構成は、ネットワークのラウンドトリップの影響を減らす傾向があり、リクエストがインターネットからAWSネットワークにジャンプする前に可能な限り最小の距離をカバーするので、トランスポートの品質が公共のインターネットの多くの気まぐれに影響されないので、より良いグローバルな応答性を与える傾向があります。TCP ハンドシェイクと TLS は、接続するブラウザ/クライアントと短い距離 (クライアントからエッジまで) で交渉され、エッジネットワークは再利用できるキープアライブ接続を維持し、そのすべてが通常有利に働きます... しかし、リクエストがエッジネットワークに飛び、その後コア地域ネットワークに戻る必要があるので、クライアントが常に、またはたいてい、同じ地域内の AWS 構造体から API を呼ぶとき、この最適化は相対的障害となります。

API GatewayステージのクライアントがAWS内にあり、APIをデプロイしたのと同じリージョン内にある場合（リージョン内のEC2内の他のシステムからAPIが呼び出される場合など）、ほとんどの場合、リージョナルエンドポイントが必要になるであろう。 リージョナルエンドポイントは、AWSインフラストラクチャのより少ない部分を介してリクエストをルーティングし、同じリージョン内のEC2からリクエストが来るときに最小限のレイテンシとジッタを保証する。

エッジネットワークを介してルーティングする副作用として、エッジに最適化されたエンドポイントは、次のような有用と思われるいくつかの追加のリクエストヘッダを提供します。 CloudFront-Viewer-Country: XX これは、API リクエストを行ったクライアントの地理的な位置の 2 桁の国コードを特定しようとするものです。 地域別エンドポイントにはこれらのヘッダはありません。

一般的なルールとして、そうしない理由が見つからない限り、エッジ最適化されたものを使用します。

そうしない理由とは何でしょうか？ 上記のように、あなたや他の人が同じAWSリージョン内からAPIを呼び出している場合、おそらくリージョナルエンドポイントが必要でしょう。 エッジに最適化されたエンドポイントは、インフラの残りの部分と統合する方法のため、より高度または複雑な構成でいくつかのエッジケースの副作用をもたらす可能性があります。 エッジ最適化されたデプロイメントではできないこと、またはできても最適でないことがあります。

• API Gatewayとは無関係の他のサイトにCloudFrontを使用していて、CloudFrontが以下のようにワイルドカードの代替ドメイン名に設定されている場合。 *.example.com のように、ワイルドカードドメインからサブドメインを使用することはできません。 api.example.com API Gatewayは、CloudFront経由で到着したそのサブドメインに対するすべてのリクエストを要求するために、あなたに代わってエッジネットワークにリクエストを送信し、CloudFrontはこのリクエストを拒否するからです。

• 複数の地域で同じカスタムドメイン名に応答する冗長なAPIを提供し、Route 53 Latency-Based Routingを使用してリクエストを要求者に最も近い地域に配信したい場合、エッジ最適化カスタムドメインでこれを行うことはできません。エッジネットワークは任意のドメイン名（サブドメイン）に対して正確に1つのターゲットを必要とするので、第2 API Gateway地域はそのサブドメインに対してエッジネットワーク上のトラフィックを主張できないからです。 この構成は、リージョナルエンドポイントとRoute 53 LBRを使って実現することもできますし、独自のCloudFront配信、呼び出し元の場所に基づいてターゲットエンドポイントを選択するLambda@Edge、API Gatewayリージョナルデプロイメントを使って、エッジネットワークを活用しながら実現することも可能です。 なお、呼び出し元のIAM認証をサポートする必要がある場合は、呼び出し元がリクエストに署名して送信する前にターゲット地域を知る必要があるため、どのような手段でも実現できるわけではありません。

• 複数のリソースを統合し、CloudFrontの背後に展開され、異なるサービスにルーティングするパスを使用する、より大きなサイトの一部としてAPIを使用したい場合 -- たとえば。 /images/* はS3バケットにルーティングすることができます。 /api/* はAPI Gatewayステージにルーティングするかもしれませんし * (それ以外)はEC2のエラスティックなロードバランサーにルーティングするかもしれない。この場合、エッジネットワークでリクエストが2回ループし(レイテンシーが増加し)、いくつかのヘッダー値が失われることになるので、エッジ最適化APIは使用しない方が良い。 この構成は破綻はしないが、最適とは言えない。 このため、リージョナルエンドポイントが望ましいです。