顧客が独自のカスタム ドメイン名を使用できる SaaS アプリケーションの場合、Let's Encrypt を使用して顧客ドメインの証明書を生成します。
現在、elastic beanstalk (ELB を使用) を使用しています。
beanstalkを引き続き使用することは可能ですか？
証明書の検証は Elastic Load Balancer が処理する必要があり、証明書はインスタンス上にあるため、何らかの方法でトラフィックをインスタンスにルーティングする必要があると思います。
価値のある回避策はありますか? これを実行しても大丈夫ですか?
顧客 -> haproxy を実行する ec2 インスタンス -> ELB -> Beanstalk
SSL は、haproxy を実行している ec2 インスタンスで終了します。
答え1
ここではいくつかのオプションがあります:
- おっしゃったルートを実行し、トラフィックを ELB 経由でインスタンスに転送する前に、HAProxy インスタンスのクラスターで SSL を終了します。
- ELB を TCP フォワーダーに変えます。これにより、ELB は単純なパケット シャッフルになります。この方法では ELB の利点がいくつか失われますが、これは機能します。このシナリオでは、アプリケーションをホストしているインスタンスで SSL を終了するため、負荷分散構成では、すべてのインスタンスに証明書のコピーが必要になります。オーケストレーションするのはかなり難しいかもしれませんが、実行可能です。
- (そして私が推奨するオプション) ALB を使用します。ALB は複数の SSL 証明書をサポートし、クライアントが SNI ヘッダーを示すと正しい証明書を自動的に選択します。必要な証明書部分 (キー、証明書、仲介者) を IAM にアップロードし、ALB 内で選択することができます。すべて API 経由で行えます。
ALB には、SNI 以外にも多くの利点があります。HTTP/2、複数のターゲット グループへのパスベースのルーティング (一部のシナリオでは便利) をサポートし、私の知る限り、従来の ELB よりも安価です。
そして、はい、Elastic BeanstalkはALBをサポートしています。残念ながら、a)環境作成時にのみ選択でき、b)新しいUIからのみ選択できます。私はいくつかの投稿をしました。不満UI と EB 全般については、ここ数週間実際に使用してみていますが、将来的にはこれらの問題が修正されることを期待しています。それまでの間、少なくとも現在の環境の構成を保存し、保存した構成から新しい環境を起動し (作成前にロード バランサーの種類を変更)、起動して実行したら CNAME を切り替えることができるはずです。
また、ALB を使用するには、環境が VPC を使用するように設定されている必要があります。