Notes

ELB,SSL/TLS

◆サービスの負荷分散
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/service-load-balancing.html

◆１台のEC2でもELBを使うメリット
https://dev.classmethod.jp/articles/benefit_elb_with_one_ec2/

* HTTPSのSSL終端をELBへ
SSLを利用する場合、EC2でSSLを終端させるとOpenSSLなどの管理が発生します。 一方、ELBをSSLの終端する場合は、管理をAWSにオフロードすることができます。 管理者はOpenSSLの脆弱性が発見されるごとにEC2にパッチを当てるなどの対応が不要になります。
* ACMの無料SSL証明書が利用できる
* AWS Shield Standard が有効になる
* WAFの利用が可能（ALBに限る）

◆SSLオフロード構成でアプリからリダイレクトを返却する場合のTips
https://qiita.com/tmiki/items/4383f66fa521da8aec03

要素技術のポイント（一部抜粋）
- SSL offload/termination
技術的には、ApacheにSSLサーバ証明書をインストールし、HTTPS通信を実現することは可能です。
しかしながら昨今、商用サービスを提供するシステムでこのような構成にすることは稀です。
それは大きく下記2つの理由によります。
* SSL/TLSは処理量が多く、負荷が高い
* サーバがスケールアウトすればするほど、SSLサーバ証明書の管理が煩雑になる
上記の課題を解決するため、下記の構成が用いられます。
この構成は、Load Balancer製品によって呼び名は違いますが、一般的にSSL offloadやSSL terminationと呼ばれます。
* SSL/TLSはクライアント⇔Load Balancer間で完結させる。そのためにSSLサーバ証明書とその秘密鍵をLoad Balancerにインストールする
* Load Balancerとサーバ間は通常のHTTP通信を行う

- Reverse Proxyとは
クライアントとAPサーバ間に配置するProxyサーバです。
クライアントからのHTTP/HTTPS接続を受け付け、一方でバックエンドサーバにHTTP/HTTPSリクエストを行うサーバとなります。
技術的には、これが無くてもWebサービスの提供は可能です。
機能要件を満たすという意味では、[ELB]→[Tomcat]という構成でも十分に可能です。
では何故、Reverse Proxyが必要になるのでしょうか？
幾つかの観点がありますが、概ね以下の利点があります。
1. 柔軟なURL構成が実現できる
1. URLのフィルタリング／リダイレクトが容易
2. 高可用な構成／負荷分散構成の実現が可能
2. HTTPヘッダをきめ細かに制御できる
3. Staticコンテンツをキャッシュし、システムのパフォーマンスを向上させることができる
1つ目のケースとして、あるパスへのアクセスはあるAPサーバ群に振り分ける、別のパスへのアクセスはまた別のAPサーバ群に振り分ける、といった制御が出来ます。ALBで行えることと同じですね。
2つ目のケースとしては、CORSの制御、Cache-Control関連ヘッダの制御などに用いられます。
3つ目の利点は言わずもがな。

上記のようなことは勿論、Reverse Proxyを用いずにTomcat/Javaアプリで実現することは可能だと思います。
しかしながら、それを実現するメリットは全くありません。単にアプリの実装が複雑化し、パフォーマンスが落ちるだけです。
アプリはビジネスロジックの実行に専念し、URLのマッピング・HTTPヘッダの制御という仕事からは分離されるべきです。
そうすることでシステム全体の複雑性が低減し、保守性が向上します。


【メモ】SpringアプリケーションでHTTPSを有効化：AWS利用
https://qiita.com/43z335/items/743be9bd65d50d6cd1c5