# インターネットから Amazon ECS へのインバウンド接続を受信するためのベストプラクティス
パブリックサービスを運営している場合は、インターネットからのインバウンドトラフィックを受け入れる必要があります。たとえば、公開 Web サイトはブラウザからのインバウンド HTTP リクエストを受け入れる必要があります。このような場合、インターネット上の他のホストもアプリケーションのホストへのインバウンド接続を開始する必要があります。
この問題に対する 1 つの方法は、パブリック IP アドレスを持つパブリックサブネット内のホスト上でコンテナを起動することです。ただし、大規模なアプリケーションにこれを行うことは推奨しません。このような場合は、インターネットとアプリケーションの間にスケーラブルな入力層を設けるのがより適切なアプローチです。このアプローチでは、このセクションに記載されている AWS サービスのいずれかを入力として使用できます。
## Application Load Balancer
Application Load Balancer はアプリケーション層で機能します。これは、開放型システム間相互接続 (OSI) モデルの第 7 層です。これにより、Application Load Balancer はパブリック HTTP サービスに適しています。ウェブサイトまたは HTTP REST API を使用している場合は、Application Load Balancer がこのワークロードに適したロードバランサーです。詳細については、「*Application Load Balancers ユーザーガイド*」の「[Application Load Balancer とは](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」を参照してください。
![\[Application Load Balancer を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/alb-ingress.png)
このアーキテクチャでは、パブリックサブネットに Application Load Balancer を作成します。これにより、パブリック IP アドレスが割り当てられ、インターネットからのインバウンド接続を受信できるようになります。Application Load Balancer は、インバウンド接続、より具体的には HTTP リクエストを受信すると、プライベート IP アドレスを使用してアプリケーションへの接続を開きます。次に、リクエストを内部接続経由で転送します。
Application Load Balancer には以下の利点があります。
+ SSL/TLS ターミネーション — Application Load Balancer は、クライアントとの通信用の安全な HTTPS 通信と証明書を維持できます。必要に応じて SSL 接続をロードバランサーレベルで終了できるため、独自のアプリケーションで証明書を処理する必要がありません。
+ 高度なルーティング — Application Load Balancer は複数の DNS ホスト名を持つことができます。また、ホスト名やリクエストのパスなどのメトリックに基づいて、受信した HTTP リクエストをさまざまな宛先に送信する高度なルーティング機能も備えています。つまり、単一の Application Load Balancer をさまざまな内部サービス、さらには REST API のさまざまなパスにあるマイクロサービスの入力として使用できます。
+ gRPC サポートとウェブソケット — Application Load Balancer は HTTP 以外も処理できます。また、HTTP/2 サポートにより、gRPC およびウェブソケットベースのサービスの負荷分散も可能です。
+ セキュリティ — Application Load Balancer は、悪意のあるトラフィックからアプリケーションを保護するのに役立ちます。HTTP 同期解除対策などの機能が含まれており、AWS Web Application Firewall (AWS WAF) と統合されています。AWS WAF は、SQL インジェクションやクロスサイトスクリプティングなどの攻撃パターンを含む可能性のある悪意のあるトラフィックをさらに効果的に除外できます。
## Network Load Balancer
Network Load Balancer は、開放型システム間相互接続 (OSI) モデルの第 4 層で機能します。HTTP 以外のプロトコルや、エンドツーエンドの暗号化が必要なシナリオに適していますが、Application Load Balancer と同じ HTTP 固有の機能はありません。そのため、Network Load Balancer は HTTP を使用しないアプリケーションに最適です。詳細については、「*Network Load Balancers ユーザーガイド*」の「[Network Load Balancer とは](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)」を参照してください。
![\[Network Load Balancer を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/nlbingress.png)
Network Load Balancer を入力として使用すると、Application Load Balancer と同様に機能します。これは、パブリックサブネットで作成されており、インターネット上でアクセスできるパブリック IP アドレスがあるためです。次に、Network Load Balancer は、コンテナを実行しているホストのプライベート IP アドレスへの接続を開き、パブリック側からプライベート側にパケットを送信します。
**Network Load Balancer の機能**
Network Load Balancer はネットワークスタックの下位レベルで動作するため、機能セットは Application Load Balancer と同じではありません。ただし、以下の重要な機能を備えています。
+ エンドツーエンドの暗号化 — Network Load Balancer は OSI モデルの第 4 層で動作するため、パケットの内容を読み取ることはありません。これにより、エンドツーエンドの暗号化を必要とする負荷分散通信に適しています。
+ TLS 暗号化 — エンドツーエンドの暗号化に加えて、Network Load Balancer は TLS 接続を終了することもできます。これにより、バックエンドアプリケーションが独自の TLS を実装する必要がなくなります。
+ UDP サポート — Network Load Balancer は OSI モデルの第 4 層で動作するため、HTTP 以外のワークロードや TCP 以外のプロトコルに適しています。
**接続を終了する**
Network Load Balancer は OSI モデルの上位層ではアプリケーションプロトコルを監視しないため、それらのプロトコルのクライアントにクロージャメッセージを送信することはできません。Application Load Balancer とは異なり、これらの接続はアプリケーションによって閉じられる必要があります。または、タスクが停止または置換されたときに、第 4 レイヤーの接続を閉じるように Network Load Balancer を設定することもできます。[Network Load Balancer のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)で、Network Load Balancer のターゲットグループの接続終了設定を参照してください。
Network Load Balancer に第 4 層で接続を終了させると、クライアントがそれを処理しない場合、クライアントが望ましくないエラーメッセージを表示する恐れがあります。推奨されるクライアント設定の詳細については、「[こちらの](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter)」 Builders Library を参照してください。
接続を閉じる方法はアプリケーションによって異なりますが、1 つの方法は、Network Load Balancer のターゲット登録解除の遅延時間をクライアントの接続タイムアウトよりも長くすることです。クライアントは最初にタイムアウトし、Network Load Balancer を介して次のタスクに正常に再接続し、同時に古いタスクではすべてのクライアントがゆっくりとドレインされます。Network Load Balancer のターゲット登録解除を遅延させる方法の詳細については、[Network Load Balancer のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)を参照してください。
## Amazon API Gateway HTTP API
Amazon API Gateway は、リクエスト量が突然急増する、またはリクエスト量が少ない HTTP アプリケーションに適しています。詳細については、「*API Gateway デベロッパーガイド*」の「[Amazon API Gateway とは](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)」を参照してください。
![\[API Gateway を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/apigateway-ingress.png)
Application Load Balancer および Network Load Balancer の料金モデルには、ロードバランサーがインバウンド接続を常時受け付けられるようにするための時間単位の料金が含まれています。これとは対照的に、API Gateway ではリクエストごとに個別に請求されます。これには、リクエストを受信しない限り課金されないという効果があります。トラフィック負荷が高い場合、Application Load Balancer または Network Load Balancer は、API Gateway よりも安いリクエストあたりの料金で大量のリクエストを処理できます。ただし、全体的にリクエスト数が少ない場合やトラフィックが少ない期間がある場合は、使用率が低いロードバランサーを維持するために時間単位の料金を支払うよりも、API Gateway を使用する場合の累積料金の方が費用対効果が高くなるでしょう。API Gateway は API レスポンスをキャッシュすることもできるため、バックエンドのリクエスト率が軽減される可能性があります。
API Gateway は、AWS マネージドサービスがプライベート IP アドレスを使用して VPC のプライベートサブネット内のホストに接続できるようにする VPC リンクを使用する機能です。Amazon ECS Service Discovery によって管理されている AWS Cloud Map サービス検出レコードを調べることで、これらのプライベート IP アドレスを検出できます。
API Gateway は、次の機能をサポートしています。
+ API Gateway の動作はロードバランサーに似ていますが、API 管理に固有の追加機能があります。
+ API Gateway は、クライアントの承認、使用レベル、リクエスト/レスポンスの変更に関する追加機能を備えています。詳細については、「[Amazon API Gateway の機能](https://aws.amazon.com//api-gateway/features/)」を参照してください。
+ API Gateway は、エッジ、リージョン、プライベート API ゲートウェイのエンドポイントをサポートできます。エッジエンドポイントは、マネージド CloudFront ディストリビューションを通じて利用できます。リージョナルエンドポイントとプライベートエンドポイントはどちらもリージョンに対してローカルです。
+ SSL/TLS ターミネーション
+ 異なる HTTP パスを別々のバックエンドマイクロサービスにルーティングする
API Gateway は、前述の機能に加えて、API を不正使用から保護するために使用できるカスタム Lambda オーソライザーの使用もサポートしています。詳細については、「[フィールドノート:Amazon ECS と Amazon API Gateway を使用したサーバーレスコンテナベースの API](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/)」を参照してください。