こんにちは、虎塚です。 今日は、ELBに紐づけたEC2を停止・開始した時に、EC2をELBに再登録する必要があることについて書きます。 これはELBを使い始めるとすぐに遭遇する問題のため、お客様からのお問い合わせが多い話題です。今月（2014年9月）すでに2件の問い合わせがあったので、書いておくことにしました。 現象 ELBと紐づけたEC2が、ELBから正しく認識されていて、リクエストを分配できる状態の時、ELBのステータスは「In Service」となります。ELBにEC2を紐づけてすぐの状態だと「Out of Service」ですが、数分たつと「In Service」になりますね。 ところが、ELBと紐づけたEC2を停止して、一定時間後に開始した後、「Out of Service」のままになることがあります。 公式ドキュメントによる解説 公式ドキュメントでは、この件について次のように書
Elastic Load Balancing とは? - エラスティックロードバランシング
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Elastic Load Balancing とは? Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。登録されているターゲットの状態をモニタリングし、正常なターゲットにのみトラフィックをルーティングします。Elastic Load Balancing は、着信トラフィックの変化に応じて、自動的にロードバランサーの容量を拡張します。 ロードバランサーの利点 ロードバランサーは、ワークロードを仮想サーバーなど複数のコンピューティングリソース間に分散させます。ロードバランサーを使用すると、アプリケーションの可用性と耐障害
はじめに ELB上でSSL証明書の設定をしている状態で、http(80)で来たアクセスをhttps(443)に転送したい話しです。 困った事 httpsでサービスを展開したいので、httpアクセスはhttpsにリダイレクトしようと思って、こちらを参考にNginxのconfに return 301 https://$host$request_uri;を書いてみました。 しかし、ELBで443を80に転送される設定がある状態でこれを書くと、当たり前の話しですがリダイレクトループが発生します。 状況として ①80で待ってるNginxにアクセスが来る ②returnの設定に従ってhttps(443)に転送 (つまりELBに戻る) ③また①に戻る これが繰り返されます やった事 ELBでリダイレクトされるとX-Forwarded-Protoというヘッダーを持ってNginxに到達します。 例
CVE-2016-0800 アドバイザリ
2016 年 3 月 1 日午前 10 時 30 分 (太平洋標準時) 「DROWN」と呼ばれる CVE-2016-0800 で説明されている問題を確認した結果、AWS サービは影響を受けないと判断しました。SSLv2 を明示的に受け入れるためにデフォルトの ELB 設定を変更した Amazon Elastic Load Balancing をご使用のお客様は、すぐに以下の手順通りにご使用の環境から SSLv2 を無効にしてください。 次の手順を使用して、AWS コンソール経由で AWS 推奨の事前定義済みセキュリティポリシーを有効にできます。 1.ロードバランサーを選択します (EC2 > ロードバランサー)。 2.リスナータブで、暗号列の [変更] をクリックします。 3.[事前定義されたセキュリティポリシー] のラジオボタンが選択されていることを確認します 4.ドロップダウンで、[E
今回は、先日書籍（Amazon Web Servicesクラウドデザインパターン設計ガイド）が発売されたCloud Design Pattern（CDP）の記事になります。 対象は「Multi Load Balancerパターン」です。 ELBのSSL Termination機能で、SSLの処理をEC2(Webサーバ)ではなくELBに行わせることが可能ですが、それに伴い、このパターンの「注意点」に下記の記載があります。 ELBのSSL Termination機能を用いるとEC2側はHTTPでリクエストを受けることになるのでアプリケーションでのHTTPS接続の判定が難しくなる。 直接EC2のWebサーバでSSLの設定をして、HTTPSでのアクセスを行う場合はPHPの場合、下記の環境変数でHTTPSの接続かどうかチェックしている場合が多いとお思います。 ($_SERVER[“HTTPS”]の有
ELB について勘違いしていたこと。 それは、ELB から切り離されたインスタンスは自動で復帰しない、ということです。 僕の確認した中では、以下の状況では復帰しないようでした: ELB に繋がっているインスタンスに異常が発生して、ELB から切り離された(Out of Service になった)場合 インスタンスを Stop して、ELB から切り離された(Out of Service になった)場合 上のような状況では、インスタンスが正常な状態に戻った場合、ヘルスチェックが行われて、In Service に戻るものかと思っていました。 実際には、ヘルスチェックは行われず、切り離されたままです。 インスタンスを復帰させるためには、インスタンスを ELB から削除して、再度登録する必要があります。 ヘルスチェックの設定項目にある「Healthy Threshold」の意味を勘違いしており、正
ELB配下のEC2インスタンスは接続元がELBのアドレスになる ELB配下のEC2インスタンスが、接続元のIPアドレスなど情報を得ようとする場合、初期設定ではおそらくELBのIPアドレスが返されてしまいます。これは、ELBを経由しているので当たり前といえば当たり前ですが、これではどこからアクセスされているのか把握できません。そこで、ELBの機能を利用して接続元のIPアドレス等を取得したいと思います。 X-Forwarded-ForとX-Forwarded-Proto ELBには市販されているロードバランサー製品と同じように、接続元のIPアドレスをヘッダー情報に付けてくれます。そこで、EC2インスタンス側でその情報を取得してログとして書き出してみます。また、ELBはSSLターミネーション機能がありますので、接続元がどのプロトコル（HTTPかHTTPSか）でEC2インスタンスにアクセスしたのか
インターネット向けロードバランサーと内部向けロードバランサー - Elastic Load Balancing
ロードバランサーを VPC 内に作成するとき、内部向け（プライベート）かインターネット向け（パブリック）かを設定できます。ロードバランサーを内部向けとして設定する場合は、ロードバランサーのプライベート IP アドレスが含まれる DNS 名が作成されます。内部向けロードバランサーはインターネットには公開されません。ロードバランサーをインターネット向けとして設定する場合は、パブリック IP アドレスが含まれる DNS 名が作成されます。DNS レコードはどちらの場合でもパブリックで解決されます。 内部向けロードバランサーとインターネット向けロードバランサーを併用することで、アプリケーションの複数の層の間でリクエストを分散することができます。例えば、フロントエンドに、インターネットからリクエストを受信してバックエンドアプリケーションインスタンスに渡すウェブサーバーがあるとします。VPC に内部向
EC2 だと ELB の内側では、nginx のアクセスログに ELB の IP アドレスが記載されてしまうので、HttpRealIpModule を使って Apache の mod_rpaf、lighttpd の mod_extforward と同じような挙動を設定します。 configure オプションに --with-http_realip_moduleが必要ですので、nginx -V で configure オプションを確認して、入っていなかったらコンパイルし直しましょう。 実際の設定は以下です。set_real_ip_from に ELB など Proxy やロードバランサーの IP を指定します。real_ip_header には、X-Real-IP や X-FORWARDED-FOR など Proxy が追加するヘッダーを指定してください。 http { set_real_i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
