リージョナル/エッジ最適化APIゲートウェイVSリージョナル/エッジ最適化カスタムドメイン名

Question

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

最悪なのは、それらを混ぜて合わせることができることです!!! Edgeに最適化されたAPIゲートウェイに地域のカスタムドメイン名を付けることができますが、それは私にはまったく意味がありません！

これら2つを個別にリージョナル/エッジ最適化できるのはなぜですか？そして、それらのそれぞれを地域/エッジに最適化するのはいつですか？

Michael - sqlbot · Accepted Answer

なぜこれら2つを地域ごとに/個別に最適化できるのか？

リージョナルおよびエッジ最適化は展開オプションです。どちらのオプションも、リクエストがAPI Gatewayサービスのコアに到着するAWSインフラストラクチャによるAPIの処理方法や、API Gatewayの背後にあるサービスへの最終的なアクセス方法に関する基本的な変更はありません-変更点は何ですかhowリクエストは最初にAWSに到着し、実行のためにAPI Gatewayコアに配信されます。詳細については、以下をご覧ください。

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

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

通常、カスタムドメイン名でAPIをデプロイする場合、メインAPI用に作成されたデプロイメントエンドポイント（xxxx.execute-api.{region}.amazonaws.comなど）の使用は継続されないため、最初の選択は重要ではありません。

そして、それらのそれぞれをリージョナル/エッジ最適化するのはいつですか？

カスタムドメイン名を使用している場合、上記のように、API全体の元の展開選択は、カスタムドメインを使用してもそれ以上の影響はありません。

エッジに最適化されたエンドポイントは、もともと利用可能な唯一のオプションでした。選択の基礎となるものがない場合、この選択は通常合理的な選択です。

このオプションは、100以上のグローバルエッジロケーションを持つCloudFrontネットワークであるAWS「エッジネットワーク」を介して着信リクエストをルーティングします。 API Gatewayコアが最終的にリクエストを処理する場所は変わりません-リクエストは最終的に同じリージョン内で処理されますが、リクエストは世界中から最も近いAWSエッジにルーティングされ、そこから運用されているネットワーク上を移動しますAWSによってAPIをデプロイしたリージョンに到着します。

API Gatewayステージのクライアントがグローバルに分散しており、APIを単一のリージョンにのみデプロイしている場合、おそらくエッジに最適化されたデプロイメントが必要です。

Edgeに最適化された構成は、ネットワークラウンドトリップの影響を軽減する傾向があるため、グローバルな応答性が向上する傾向があり、トランスポートの品質は、要求が最小限しかカバーしないため、パブリックインターネットの多くの気まぐれの影響を受けませんインターネットからAWSネットワークにジャンプする前に可能な距離。 TCPハンドシェイクとTLSは、クライアントからエッジまでの短距離で接続ブラウザ/クライアントとネゴシエートされ、エッジネットワークは再利用可能なキープアライブ接続を維持します。これは通常あなたの都合で機能します...しかし、クライアントが常に（または通常）同じリージョン内でAWSインフラストラクチャ内からAPIを呼び出している場合、この最適化は比較的障害になります。リクエストはEdgeネットワークにホップする必要があるためですそしてコア地域ネットワークに戻ります。

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

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

一般的なルールとして、そうしない理由が見つからない限り、Edge-optimizedを使用してください。

しない理由は何ですか？前述のように、あなたまたは他の人が同じAWSリージョン内からAPIを呼び出している場合、おそらく地域のエンドポイントが必要です。エッジに最適化されたエンドポイントは、インフラストラクチャの残りの部分に統合する方法のため、より高度な構成や複雑な構成でエッジケースの副作用を引き起こす可能性があります。 Edgeに最適化された展開では実行できないこと、または実行すると最適でないことがいくつかあります。

aPI Gatewayとは関係なく他のサイトにCloudFrontを使用しており、CloudFrontが*.example.comなどのワイルドカード代替ドメイン名に設定されている場合、そのワイルドカードドメインのサブドメイン（api.example.comなど）をEdge-optimizedでは使用できませんカスタムドメイン名を持つエンドポイント。APIGatewayは、ユーザーに代わってEdgeネットワークにリクエストを送信し、CloudFront経由で到着したサブドメインへのすべてのリクエストを要求します。APIGatewayで使用するとサポートされない構成を表すため、CloudFrontはこのリクエストを拒否します。 CloudFrontは他の状況でもサポートしていますが。
複数のリージョンで同じカスタムドメイン名に応答する冗長APIを提供し、Route 53レイテンシベースのルーティングを使用してリクエスターに最も近いリージョンにリクエストを配信する場合、エッジ最適化されたカスタムではこれを行えませんこれは、エッジネットワークが特定のドメイン名（サブドメイン）に対して正確に1つのターゲットを必要とするため、2番目のAPIゲートウェイリージョンがエッジネットワーク上のそのサブドメインのトラフィックを要求できないためです。この構成は、リージョナルエンドポイントとRoute 53 LBRを使用して実現できます。または、独自のCloudFrontディストリビューション、Lambda @ Edgeを使用してエッジネットワークを活用しながら、発信者の場所に基づいてターゲットエンドポイントを選択し、API Gatewayのリージョナル展開を実現できます。呼び出し元のIAM認証をサポートする必要がある場合、これは決して達成できないことに注意してください。これは、呼び出し元がリクエストに署名して送信する前にターゲット領域を知る必要があるためです。
複数のリソースを統合し、CloudFrontの背後にデプロイされ、異なるサービスにルーティングするためにパスを使用する大規模サイトの一部としてAPIを使用する場合、たとえば、/images/*はS3バケットにルーティングし、/api/*はAPI Gatewayステージ、および*（他のすべて）がEC2のエラスティックロードバランサーにルーティングされる場合があります。これにより、エッジ最適化APIを使用したくない場合があります。）および一部のヘッダー値が失われます。この構成は壊れませんが、最適ではありません。このため、地域のエンドポイントが望ましいです。