Elastic Beanstalkを使用してデプロイされたアプリケーションのElastic IP
Amazazon Web Servicesが提供するElastic IPサービスの使用について少し混乱しています。主なアイデアは、この簡単な手順に従ってダウンタイムなしでWebアプリケーションの新しいバージョンに切り替えることができるということです。
- 新しいEC2インスタンスに新しいバージョンをデプロイします
- 新しいバージョンを適切に構成し、ステージングDBを使用してテストします
- 適切にテストしたら、この新しいバージョンでライブDBを使用する
- Elastic IPをこのインスタンスに関連付けます
- 役に立たないすべてのサービス（ステージングDBと古いEC2インスタンス）を終了する
これは、Webアプリケーションの新しいバージョンをデプロイする一般的な方法ですか？
さて、アプリケーションがより多くのインスタンスでスケーリングされるとどうなるでしょうか？ Elastic Beanstalk設定で自動スケーリングを設定すると、ロードバランサーが作成されました（AWSマネジメントコンソールのEC2セクションで確認できます）。問題は、明らかにElastic IPをロードバランサーに関連付けることができず、既存のインスタンスに関連付ける必要があることです。どのインスタンスに関連付ける必要がありますか？よくわかりません...
いくつかの質問が愚かに聞こえるかもしれませんが、私はプログラマーであり、クラウドシステムをセットアップするのは初めてです。
ありがとうございました！
Elastic Load Balancing（ELB） は Amazon EC2 Elastic IPアドレス では機能しません。実際、2つの概念はまったく一致しません。
Elastic Load Balancingによる弾力性
むしろ、ELBは通常 CNAME records を介して使用されます（ただし、以下を参照）。これにより、エイリアスDNSアドレスが使用中のELBのIPを変更できるようにすることで、弾力性/可用性の第1レベルが提供されます、 必要なら。第2レベルの弾力性/可用性は、登録したEC2インスタンス間でトラフィックを分散するときにロードバランサーによって実行されます。
このように考えてください：CNAMEは変更されない（Elastic IPアドレスと同様）およびEC2インスタンスの置換はロードバランサーを介して処理されます Auto Scaling 、または自分（インスタンスの登録/登録解除）。
これについては、Shlomo Swidlerの優れた分析で詳しく説明されています 「Elastic Load Balancing」の「Elastic」：ELB Elasticity and How to Test it は、最近提供された Best AWSによるElastic Load Balancingの評価の実践 は、彼の分析を確認し、Elastic Load Balancing Serviceのアーキテクチャとそれ自体の仕組みについての優れた全体的な読み物を提供します（ただし、Shlomoが提供するサンプルごとの実例はありません）。
ドメイン名
CNAMEを必要とする以前の制限は、ルートドメイン（またはZone Apex）を許可するために Amazon Route 5 にそれぞれ追加することで対処されていたことに注意してください。同様に、セクションのエイリアスとゾーンApexを参照してください Moving Ahead With Amazon Route 5 の簡単な概要と ドメイン名の使用詳細については、Elastic Load Balancing 。
Elastic Beanstalkによる弾力性
何よりもまず、 AWS Elastic Beanstalk は上記のように順番にElastic Load Balancingを使用します。その上に、アプリケーションライフサイクル管理を追加します。
AWS Elastic Beanstalkは、AWSクラウドでアプリケーションを迅速にデプロイおよび管理するためのさらに簡単な方法です。アプリケーションをアップロードするだけで、Elastic Beanstalkは容量のプロビジョニング、負荷分散、自動スケーリング、およびアプリケーションの状態監視のデプロイの詳細を自動的に処理します。 [...][エンファシスマイン]
これは、Environmentの概念をミックスに追加することで達成されます。これは Architectural Overview で説明されています。
環境はアプリケーションの中心です。 [...]環境を作成すると、AWS Elastic Beanstalkはアプリケーションの実行に必要なリソースをプロビジョニングします。環境用に作成されたAWSリソースには、1つのエラスティックロードバランサー（図のELB）、Auto Scalingグループ、および1つ以上のAmazon EC2インスタンスが含まれます。
すべての環境には、ロードバランサーを指すCNAME（URL）があります、つまりELBを単独で使用するように注意してください。
これらはすべて アプリケーションと環境の管理と設定 にまとめられています。これは、AWSマネジメントコンソールを使用した使用例を含め、AWS Elastic Beanstalkの最も重要な機能のいくつかを詳細に CLI、およびAPI。
ゼロダウンタイム
説明のために最も関連性の高い部分を特定するのは困難ですが、 ゼロダウンタイムでバージョンを展開 はユースケースに正確に対応し、必要なすべての前の手順を意味します（例 新しいアプリケーションバージョンの作成新しい環境の起動 ）ので、セクションを読むと、AWSマネジメントコンソールが、このプラットフォームがどのように機能するかを全体的に最もよく理解できる場合があります。
幸運を！
Steffenの素晴らしい答えで説明されているオプションに加えて、Elastic Beanstalkは、完全に必要ない場合、ごく最近Elastic IPをオプションとして有効にしましたElastic Load Balancerの機能（1つのインスタンスを超える自動スケーリングなど）。
同様の質問に対する私の答え でオプションを説明します。 Elastic Beanstalkでは、2つの 環境タイプ から選択できるようになり、Single-instanceオプションはElastic IPを作成します。
ほとんどの場合、ELBを使用することをお勧めしますが、ステージングサーバーの場合は、より複雑ではない（より安価な）代替手段があると便利です。
数年後に投稿に回答することをおologiesびしますが、実際にELBで静的IPアドレスのセットが必要な場合は、AWSに「安定IP」アドレスと呼ばれるものをELBに追加するようにうまく依頼することができます。その静的IPアドレス機能を指定します。
もちろん、これを行うことは好きではありませんが、正当化できる場合はそうします（主な正当化は、ファイアウォールを介したアウトバウンド接続にIPホワイトリストの制限があり、そのスタンスに完全に手を出そうとしないクライアントがある場合です）。
トラフィックオプションに基づく「自動スケーリング」は簡単ではないことに注意してください-すぐに使用できるソリューションで行うように、AWSはELBにELBエンドポイントを動的に追加できません。時間が経つにつれて顧客と新しいIPアドレスを開くことの苦痛。
ただし、元の質問については、静的IPアドレスが実際には必要ない（クライアントアウトバウンドファイアウォールの問題がない）EC2インスタンスにELBを使用するEBが、受け入れられた回答に従って最善の方法です。