これが良いアイデアかどうか疑問に思っています。パブリック サブネットとプライベート サブネットを持つ Amazon AWS VPC をセットアップしています。インターネット ゲートウェイと NAT はすでに用意されています。すべての Web サーバー (Apache2 インスタンス) と DB サーバーをプライベート サブネットにセットアップし、ロード バランサー/リバース プロキシを使用してリクエストを取得し、それらをプライベート サブネットのサーバー クラスターに送信するつもりでした。そこで質問ですが、Amazon の ELB はこれらに適した使用法でしょうか。それとも、パブリック リクエストを処理する独自のカスタム インスタンスをセットアップし、nginx または pound を使用して NAT 経由で実行する方がよいのでしょうか。
ログインして確認できるインスタンスがあるという理由だけで、2 番目のオプションが気に入っています。また、キャッシュと fail2ban による DDoS 防止機能を活用し、フェイルセーフを使用してトラフィックをリダイレクトすることもできます。ただし、ELB の使用経験がないため、皆さんの意見を伺いたいと思いました。
また、これについてもご意見があれば、2 番目のオプションを使用すると、パブリック IP アドレスを 1 つだけ使用して、ポート番号を介して SSH 接続をそれぞれのインスタンスにルーティングできるようになりますか?
前もって感謝します！
答え1
ELB と独自のソリューションのどちらが自分にとって良いのかを答えるのは難しいです。
Amazon の多くのサービスと同様に、ELB は単なるマネージド サービスであり、独自の ELB をセットアップして維持する手間が省けます。特に、すべてを自分で行う時間やリソースがない場合には、これは非常に魅力的です。
舞台裏では、Amazon の ELB は、あらゆる量のトラフィックを処理するために自動的にスケールする 1 つ以上の EC2 (ロードバランサーのように動作するように構成) です (ただし、スケールと言っても線形スケールであり、バースト トラフィックにはサポート チケットを通じてロードバランサーを事前にウォームアップする必要があります)。
ELB は数年前から VPC で機能しています。
人気の AWS Elastic Load Balancing 機能が、Virtual Private Cloud (VPC) 内で利用できるようになりました。SSL 終了、ヘルスチェック、スティッキーセッション、CloudWatch モニタリングなどの機能は、AWS マネジメントコンソール、コマンドライン、または Elastic Load Balancing API から設定できます。
ロード バランサーの内部動作にアクセスし、標準のロード バランシングを超えた処理を実行したい場合は、独自のロード バランサーを作成するしかありません。
個人的には、ロード バランサーを管理してもらうというアイデアが気に入っています。セットアップが簡単なので、自分でテストして、ニーズを満たしているかどうかを確認できます。