皆さん、これが、Amazon Elastic Load Balancer に専用 IP がなく、したがって A レコードのサポートがないという長年の問題に対する実行可能な解決策のように思えるかどうか疑問に思っていました。
マイクロ/スモール インスタンスを作成し、エラスティック IP にフックするとどうなりますか。その後、その IP を Web サイトの A レコード アドレスとして使用できます。そのインスタンスは、そのトラフィックの 100% を ELB ロード バランサー アドレス (Haproxy?) に転送し、その後正常に動作して、そのトラフィックをサーバー プールに転送します。
このアーキテクチャでは、A レコードと ELB を使用できます。
トラフィックを ELB に転送する初期インスタンスのコストを除けば、これには欠点がありますか?
この二重転送によって遅延が発生しすぎますか? それとも、すべて AWS にあるため、無視できるものでしょうか?
フィードバックありがとうございます。
現在 DNS に Route53 を使用している場合は、zone apex の処理がサポートされています。
https://forums.aws.amazon.com/message.jspa?messageID=260459
専用IPが必要な理由について言及していないため、これがあなたの質問に答えるかどうかはわかりません.
トラフィックを ELB に転送する初期インスタンスのコストを除けば、これには欠点がありますか?
ええ、そうです。ELB の利点の約 99.9% を失っています。
この二重転送によって遅延が発生しすぎますか? それとも、すべて AWS にあるため、無視できるものでしょうか?
いいえ、ラグは小さくなければなりません (サブミリ秒)。主な問題は次の 2 つです。
1)トラフィックが増加すると、インスタンスがボトルネックになります。Slashdot や Oprah のようなトラフィックの多い Web サイトからリンクされるなど、突然のラッシュには耐えられません。
ELB の要点は、スケーリング (フロントエンドとバックエンド) を管理できることです。フローに 1 つのボックスを挿入すると、ELB が有用なことを実行できなくなります。
また、マイクロ インスタンスはほとんどトラフィックを受け取ることができません。ネットワーク パケットを調整したくない場合は、少なくとも m1.large に移動する必要があります。
2) インスタンスが単一障害点になります。あなたのボックスが死ぬと、あなたのウェブサイトはダウンします。ELB は、冗長性を備えたフロントエンドとバックエンドの両方の問題を防ぐことができます。
おそらく、A レコードが必要な理由を説明したとしたら?
(独自のフロントエンドを実行することもできます。EIP を使用してボックスを作成し、その上に nginx や HAProxy を配置するだけです。ただし、すべての場合と同様に、トレードオフがあります。)