Elastic Load Balancing (ELB)
AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ)
ソリューションアーキテクト 辻 義⼀一
放送：2014.5.07 最終更更新：2014.10.20
ELB Updates
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
2014.7 タイムアウト設定を変更更可能
2014.4 CloudTrail対象に追加
2014.3 接続のストリーミング
2014.3 アクセスログのS3保管
2014.2 SSLサポート強化（Perfect Forward Secrecy(PFS)、Server Order Preference、
ELBSecurityPolicy-‐‑‒2014-‐‑‒01ポリシー追加）
2013.11 クロスゾーン負荷分散
2013.10 CloudWatchのメトリック追加（BackendConnectionError、
SurgeQueueLength、SpilloverCount）
2013.7 Proxy Protocol
2013.5 全てのHTTPメソッド対応
2013.5 Route 53のフェールオーバ連携
2012.6 Internal ELB
Agenda
•  ELBの基本
•  ELBの各種機能
•  ELBと各種サービスの連携
•  ELB負荷試験時のTips
•  まとめ
ELBの基本
Elaastic Load Balancing (ELB) とは？
〜～ AWSクラウド上のロードバランシングサービス 〜～
ELBで実現できるシステム
§  スケーラブル : 複数のEC2インスタンスに負荷分散
§  ⾼高い可⽤用性 : 複数のアベイラビリティゾーンにある複数のEC2インスタンス
の中から正常なEC2インスタンスにのみ振り分け
ELB⾃自⾝身の特徴
§ 
§ 
§ 
§ 
スケーラブル : ELB⾃自体も負荷に応じてキャパシティを⾃自動増減
安価な従量量課⾦金金 : 従量量課⾦金金で利利⽤用可能
運⽤用管理理が楽 : マネージドサービスなので管理理が不不要
豊富な連携機能 : Auto Scaling, Route 53, Cloud Formation… などと連携
ELBの使い⽅方イメージ
開発・管理理者
ユーザー
myLB-xxx.elb.amazonaws.com
マネージメント
コンソール
ELB
EC2
アベイラビリティ ゾーン a
EC2
アベイラビリティ ゾーン b
負荷分散してスケーラブルなシステムを
バックエンドのEC2インスタンスのリクエスト数やコネクション数が
均等になるよう負荷分散
新サーバ追加！
接続が少ない新インスタンスに
新しい接続を振り分ける
過負荷
対応プロトコル
L7： HTTP, HTTPS
L4： TCP, SSL
過負荷
複数アベイラビリティゾーン(AZ)に分散
2段階で負荷分散
1)  DNSラウンドロビンで各AZ内のELBに振り分け
2)  負荷が均等になるようにバックエンドのEC2に振り分け
DNS
ラウンドロビンで
振り分け
AZ -‐‑‒ a
myLB-xxx.elb.amazonaws.com
AZ -‐‑‒ b
ELB
負荷分散
分散した上でヘルスチェックして⾼高い可⽤用性
•  ELBは指定した設定に基づき、バックエンドの
インスタンスのヘルスチェックを⾏行行う
– 
– 
– 
– 
– 
– 
– 
Pingプロトコル 例例：HTTP (200番が返るのを確認）
Pingポート 例例：80番
Pingパス（HTTP/S利利⽤用時）例例：/index.html
タイムアウト時間 例例：20秒
ヘルスチェック間隔 例例：30秒
異異常判定までの回数 例例：4回
正常判定までの回数 例例：2回
•  正常との判定が遅いと追加したインスタンスが
使えるまでに時間がかかる。逆に異異常との判定が厳しすぎても、
過負荷時に処理理できるインスタンスを減らしてしまうことにも。
ELB⾃自⾝身もスケーラブル
ELB⾃自⾝身も負荷の増減に応じて⾃自動でスケール
（キャパシティが⾃自動で増加する）
[注意]
ELBがスケールするときには、IPアドレスが変化します。
ELBへアクセスするときには必ずDNS名で！
独⾃自ドメインに割り当てる際はCNAMEにて。
安価な従量量課⾦金金
2014年年10⽉月20⽇日現在
• 
• 
• 
• 
時間当たりの利利⽤用料料は、複数AZ配置構成でも同じ
SSLを利利⽤用しても同じ料料⾦金金
ELBにリザーブドプランはなし
処理理量量の課⾦金金は合計処理理量量
1GB
2GB
98GB
49GB
1GB
49GB
→ 100GB課⾦金金
ELBの各種機能
ELBの各種機能
§  ELB利利⽤用時のTips
§ 
§ 
§ 
§ 
§ 
§ 
§ 
§ 
独⾃自ドメイン名で利利⽤用
クライアントのIPアドレス取得
AZとバックエンドキャパシティの関係
ELBとバックエンドとのコネクション
SSLサポート
スティッキー セッション
接続のストリーミング
アクセスログのS3保管
§  ELB⾃自⾝身のスケーリング
§  VPCでの利利⽤用
§  ELBとSecurity Group
独⾃自ドメイン名で利利⽤用
CNAMEを利利⽤用して実現
•  独⾃自ドメインの権威DNSサーバに設定すれば完了了
www.example.com CNAME myLB-‐‑‒xxxx.ap-‐‑‒northeast-‐‑‒1.elb.amazonaws.com
•  Zone Apex (www.exapmple.com ではなく
example.com を指定) の場合
à 通常のDNSサーバではCNAME設定不不可
à Route 53のエイリアスレコードを
使うことで実現可能
クライアントのIPアドレス取得
バックエンドサーバへの接続は、
ソースIPアドレスがELBのIPアドレスとなる
–  クライアント⇔ELB, ELB⇔バックエンドの接続はそれぞれ独⽴立立しているため
–  アクセスログにはELBのIPアドレスが記録される
à  HTTP/HTTPSならHTTPヘッダ上のX-‐‑‒Forwarded-‐‑‒Forで参照可
利利⽤用例例： -‐‑‒ アクセスログにクライアントのIPアドレスを記録
-‐‑‒ IPアドレスによるアクセス制限 送信元
経由するルート
X-‐‑‒Forwarded-‐‑‒For: 203.0.113.7, 10.12.33.44, 10.12.23.88
Client IP address
AZとバックエンドキャパシティの関係
•  リージョン内の複数AZに負荷分散可能
–  複数リージョンへの分散にはRoute 53を併⽤用できる
•  各EC2インスタンスのタイプは同じに
•  AZごとのEC2インスタンス数はできれば均等に
–  クロスゾーン負荷分散でAZ間を越えて負荷を均等にできる
良良くない例例：AZ間でキャパシティが不不均等
50%
2台
もう⼀一⽅方より
負荷が⾼高くなる
クロスゾーン負荷分散が有効であれば
50%
3台
AZ-‐‑‒b
2台
AZ-‐‑‒a
AZ-‐‑‒a
50%
New 2013.11
負荷を基に
均等に
50%
3台
AZ-‐‑‒b
ELBとバックエンドとのコネクション
•  クライアント ⇔ ELB のコネクション
–  無通信状態が続くとそのコネクションを切切断する
•  ELB ⇔ バックエンドのEC2インスタンス のコネクション
–  EC2インスタンス上のApache等ではHTTP Keepalive設定を推奨
–  Webサーバのタイムアウト値をELBのアイドルコネクションタイムアウトよ
り⻑⾧長い時間に設定することを推奨
接続を維持できない場合、ELBがそのEC2インスタンスを異異常と判定し、
トラフィックを送らなくなることがあるので注意
New 2014.7
•  タイムアウトは60秒がデフォルト値で、1秒から60分までに変更更可能
クライアント ⇔ ELB
ELB ⇔ バックエンドのEC2インスタンス ELB⾃自⾝身のスケーリング
ELBは負荷に応じて⾃自動でスケールする
•  但し、ELBへの接続・リクエストが瞬間的に急増したために、ELBのス
ケーリングが間に合わない場合、HTTP 503を返す
–  新サービス開始
–  TVやメディアによるサービス紹介
–  負荷テスト 等
•  回避⽅方法は事前にELBをスケールさせておく
–  負荷を段階的にかける
–  Pre-‐‑‒Warming（暖気運転）の申請を⾏行行う ※Business/Enterpriseサポート要
VPCでの利利⽤用
•  ELBを配置するサブネットをAZごとに1つ指定
サブネットは最⼩小 /27 CIDRブロックで、20個以上の空きIPが必要
•  EC2 Classicに設置する場合と⽐比べた制約：IPv6サポートなし (2014年年4⽉月時点)
ELBサブネット
Webサブネット
AZ -‐‑‒ a
myLB-xxx.elb.amazonaws.com
AZ -‐‑‒ b
Internet-‐‑‒Facing ELB / Internal ELB
§  Internet-‐‑‒Facing ELB
インターネットからアクセスできるELB
–  名前解決するとグローバルIP
§  Internal ELB
VPC内やオンプレミス環境からのみ
アクセスできればよいELB
プライベートサブネットにも配置できる。
–  名前解決するとプライベートIP
Internet-Facing ELB
Webサーバ
Internal ELB
APサーバ
ELBとSecurity Group
•  EC2 ClassicのSecurity Groupは”amazon-‐‑‒elb/amazon-‐‑‒elb-‐‑‒sg”、
VPCではELBに任意のSecurity Groupを指定可能
•  ICMP Echo Request/Replyを許可
sg-‐‑‒EC2
すれば、ELBがpingにも応答
80: sg-‐‑‒ELB
•  バックエンドのEC2インスタンスは
22:10.0.0.0/24
ELBからのみリクエストを
受け付ける設定を推奨
80
443
sg-‐‑‒ELB
443: 0.0.0.0/0
80
80
80
22
ELBの各種機能
§  ELB利利⽤用時のTips
§ 
§ 
§ 
§ 
§ 
§ 
§ 
§ 
独⾃自ドメイン名で利利⽤用
クライアントのIPアドレス取得
AZとバックエンドキャパシティの関係
ELBとバックエンドとのコネクション
SSLサポート
スティッキー セッション
接続のストリーミング
アクセスログのS3保管
§  ELB⾃自⾝身のスケーリング
§  VPCでの利利⽤用
§  ELBとSecurity Group
SSLサポート
ELBでSSL Terminationできる
a)  ELBでSSL Terminationし、バックエンドとはSSLなし
バックエンドのEC2インスタンスでSSL処理理せずに済むため
負荷をオフロードできる。
b)  ELBでSSL Terminationし、バックエンドとは別途SSL
c)  SSLをバイパスしてバックエンドにTCPで送信
クライアント証明書認証などを利利⽤用するためにはTCPとして扱う
a)
HTTPS
HTTP
b)
HTTPS　/ SSL
HTTPS / SSL
c)
TCP
TCP
HTTPS/SSL利利⽤用時のサーバ証明書
ELBにサーバ証明書をアップロード
•  HTTPS/SSL利利⽤用にはサーバ証明書のアップロードが必須
•  複数ホスト名には別名・ワイルドカードか複数ELBで対応（SNI未対応）
•  バックエンドとの通信にSSLを⽤用いないなら証明書の管理理が容易易
•  マネージメントコンソール or CLI or IAM APIで設定
サーバ証明書
SSL証明書のライセンスに関し
ては、サーバ単位/ドメイン単位
で発⾏行行などそれぞれ異異なるので
発⾏行行元に問い合わせの事
SSLのセキュリティ強化
•  TLS 1.1, 1.2のサポート
•  Perfect Forward Secrecy (PFS) のサポート New 2014.2
•  Server Order Preference New 2014.2
•  新しい定義済みのセキュリティポリシー New 2014.2
新しく作ったELBではELBSecurity-‐‑‒Policy-‐‑‒2014-‐‑‒01がデフォルト
à 既存のELBには互換性確認の上 ELBSecurity-‐‑‒Policy-‐‑‒2014-‐‑‒01 の適⽤用を
バックエンドインスタンスのサーバ証明書認証
ELBとバックエンドのEC2インスタンス間でHTTPS/SSL使⽤用時に、
特定の証明書を使⽤用しているかどうかバックエンドを認証
ELBの各種機能
§  ELB利利⽤用時のTips
§ 
§ 
§ 
§ 
§ 
§ 
§ 
§ 
独⾃自ドメイン名で利利⽤用
クライアントのIPアドレス取得
AZとバックエンドキャパシティの関係
ELBとバックエンドとのコネクション
SSLサポート
スティッキー セッション
接続のストリーミング
アクセスログのS3保管
§  ELB⾃自⾝身のスケーリング
§  VPCでの利利⽤用
§  ELBとSecurity Group
スティッキー セッション (stickness)
同じユーザから来たリクエストを全て同じEC2インスタンスに送信
•  デフォルトで無効、使うには有効に
•  アプリケーションでのセッション情報、⼀一時ファイルなどを
EC2インスタンスが保持する構成の場合に必要となる。
•  HTTP/HTTPSでのみ利利⽤用可能
•  ELBは独⾃自のセッションCookieを挿⼊入
EC2インスタンスの増減を柔軟にできるように、
セッション情報などは別のDBサーバやキャッ
シュサーバに持たせるのが望ましい。
この場合スティッキー セッションは不不要。
スティッキー セッションの有効期間
有効期間の制御⽅方法は以下２パターン
§  Application Generated Cookie Stickiness（アプリケーション制御）
アプリケーションが作成したCookieにあわせる
–  アプリケーションが作成するCookie名を指定
–  Cookieの有効パスもあわせる
§  Load Balancer Generated Cookie Stickiness（期間ベース）
セッション開始からの有効期間を指定してELBで制御
–  秒単位で指定
–  無期限にする事も可（無期限でもブラウザを閉じれば終了了）
ELBの各種機能
§  ELB利利⽤用時のTips
§ 
§ 
§ 
§ 
§ 
§ 
§ 
§ 
独⾃自ドメイン名で利利⽤用
クライアントのIPアドレス取得
AZとバックエンドキャパシティの関係
ELBとバックエンドとのコネクション
SSLサポート
スティッキー セッション
接続のストリーミング
アクセスログのS3保管
§  ELB⾃自⾝身のスケーリング
§  VPCでの利利⽤用
§  ELBとSecurity Group
接続のストリーミング (Connection Draining)
New 2014.3
バックエンドのEC2インスタンスをELBから登録解除したり、ヘルスチェッ
クが失敗した時に、新規割り振りは中⽌止して、処理理中のリクエストは終わる
まで⼀一定期間待つ。
•  新しく作成したELBではデフォルトで有効、タイムアウト 300秒。
•  タイムアウト最⼤大 3600秒
•  接続のストリーミング動作中
–  Management Consoleではインスタンスの表⽰示が消える （2014.5時点）
–  API/SDK/CLIでは状況がわかる
登録解除時のAWS CLIでの表⽰示
$ aws elb describe-instance-health --load-balancer-name (ELB Name)
{
"InstanceStates": [
{
"InstanceId": "i-XXXXXXXX",
"ReasonCode": "N/A",
"State": "InService",
"Description": “N/A”
}
State
Description
]
正常時
InService
N/A
}
接続のストリーミング InService
動作中
Instance deregistration currently in progress.
全接続終了後 or
タイムアウト後
Instance is not currently registered with the
LoadBalancer.
OutOfService
ELBの各種機能
§  ELB利利⽤用時のTips
§ 
§ 
§ 
§ 
§ 
§ 
§ 
§ 
独⾃自ドメイン名で利利⽤用
クライアントのIPアドレス取得
AZとバックエンドキャパシティの関係
ELBとバックエンドとのコネクション
SSLサポート
スティッキー セッション
接続のストリーミング
アクセスログのS3保管
§  ELB⾃自⾝身のスケーリング
§  VPCでの利利⽤用
§  ELBとSecurity Group
アクセスログのS3保管
New 2014.3
ELBのアクセスログを指定したS3に⾃自動保管
•  簡単にログのS3保管が実現できる
•  ELBだからこそ記録できる項⽬目
–  ELBの応答コード
–  ELBでの処理理時間
–  クライアントのIPアドレス
•  Apache/Nginxでは標準だがELBのログに含まれていない項⽬目 （2014.10時点）
–  リファラ
–  ユーザエージェント
ELBと各種サービスの連携
CloudWatchとの連携
CloudWatchによりELBの以下を1分単位で監視可能
•  正常なバックエンドのホスト数 (HealthyHostCount)
•  異異常なバックエンドのホスト数 (UnHealthyHostCount)
•  リクエスト数 (RequestCount)
監視
•  遅延時間 (Lantency)
•  ELBが返した4xx,5xxのレスポンス数 (HTTPCode_̲ELB_̲4xx)
•  バックエンドが返した2xx,3xx,4xx,5xxレスポンス数 (HTTPCode_̲Backend_̲2xxx)
•  バックエンドへの接続エラー回数 (BackendConnectionError) New 2013.10
•  バックエンドへの送信保留留中の件数 (SurgeQueueLength) New 2013.10
•  キュー溢れのため拒否した件数 (SpilloverCount) New 2013.10
計13項⽬目
Auto Scalingとの連携
•  Auto Scalingによるインスタンス増減時にELBへの追加・削除が可能
•  ELBのヘルスチェックの結果をAuto Scalingに反映可能
•  インスタンス削減時は、接続のストリーミングでの処理理中の接続を待つ New 2014.3
利利⽤用例例
–  ⼀一定間隔でレスポンスをチェックし、遅延が増加したらインスタンスを⾃自動追加
–  ELBのヘルスチェックが成功したEC2インスタンスを常にX台以上
増減
Auto scaling Group
Route 53 DNSフェイルオーバ対応
Route 53のヘルスチェック機能とELBが連携
例例：アプリケーション障害時にSorryページヘ誘導
正常時
3. ELB配下に正常なEC2
インスタンスなし
2. AppサーバのELB
ヘルスチェック失敗
1. DBに問題発⽣生
フェイルオーバ時
5. Sorry
ページ
4. フェイルオーバ
S3 Bucket
OpsWorksのELB対応
OpsWorksでELBをLBレイヤーに利利⽤用可能に
①スタックの作成
②レイヤーの作成
③レシピの作成・設定
（ビルトイン
レシピ利利⽤用可）
④レイヤーにインスタ
ンス追加・起動
⑤レシピによって
パッケージインス トール、設定
スタック
Load Balancerレイヤー
AWS Management Console
LB
レシピ
App Serverレイヤー
レシピ
Databaseレイヤー
レシピ
User
LBとしてELBが選択可能に
Web
/App
Web
/App
D
B
ELB負荷テストに関するTips
ELBを負荷テストする必要性について
ELBのいくつかの特⻑⾧長がテストシナリオに影響を与える可能性がある。
•  ELBのスケーリング
•  ELBの初期キャパシティ
•  アイドル時のコネクションタイムアウト
•  バックエンドインスタンスのヘルスチェック
•  Stickyセッション 等
ご利利⽤用内容に合わせたシナリオでテストが必要
ELBの負荷テスト⽅方法の種類
§  シングルクライアントテスト
負荷⽣生成
クライアント
バックエンド
インスタンス
例例：Apache Bench(ab)
§  マルチクライアントテスト
例例：curl-‐‑‒loader (都度度DNS解決を⾏行行うツールが望ましい)
§  分散テスト
例例：Fabricフレームワーク、
BeesWithMachineGuns
クライアントの負荷が⾜足りない場合はクライアント数を増やす等で対応可
推奨テストアプローチ
•  想定する最⼤大負荷のテスト
•  通常のトラフィック時のテスト
負
荷
–  トラフィックの多い時
時間
–  トラフィックの少ない時
–  トラフィックの傾向に変化がある時（朝や昼の時間帯など）
•  短い時間でトラフィックが⼤大きく変化する場合のテスト
ELB以外にも負荷⽣生成クライアント、バックエンドEC2インスタンスも
監視すべき
–  アプリケーション内部の動作も要確認
–  どこかボトルネックになっているか把握しておく
負荷テストの注意事項
•  ELBの初期スケールに注意
–  スケールするまでに、HTTP 503レスポンスを返す期間があり得る
–  回避策：
•  ELBの暖気運転（ Pre-‐‑‒Warming）申請をする
•  5分間隔で50%以上のトラフィック増加をしないよう負荷テストを設定
•  DNSクエリの仕⽅方に注意
–  テストクライアント側で少なくとも1分に1回DNSの再解決をする
•  スティッキーセッション利利⽤用時の割り振り⽅方
–  同じCookieでリクエストを続けた場合などは振り分けに偏りが
•  バックエンドインスタンスのアイドルタイムアウト
–  60秒以上に設定しないとELBが誤って不不健全なホストと⾒見見なす可能性あり
まとめ
まとめ
〜～ELBはAWSが提供するロードバランシングサービス〜～
§  運⽤用管理理コストを抑えながら
スケーラブルで⾼高可⽤用なインフラを構築可能
§  各種サービスとの連携もスムーズ＆随時拡充
§  負荷試験時はその特性を理理解した上で
§  急激な負荷の増⼤大が想定される場合には、
サポート加⼊入の上で暖気申請（Pre-‐‑‒Warming）を
参考資料料（⽇日本語）
•  Elastic Load Balancing開発者ガイド
http://docs.aws.amazon.com/ja_̲jp/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html
•  Elasitc Load Balancingを評価するための
ベストプラクティス
http://d36cz9buwru1tt.cloudfront.net/jp/documentation/BestPracticesInEvaluatingELB-‐‑‒ja-‐‑‒final.pdf
•  Amazon ELB FAQ
http://aws.amazon.com/jp/ec2/faqs/ （ELBの項⽬目）
参考資料料（英語）
•  Amazon Elastic Load Balancing Developer Guide
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html
•  Best Practices in Evaluating Elastic Load Balancing
http://aws.amazon.com/articles/1636185810492479
•  Amazon ELB FAQ
http://aws.amazon.com/ec2/faqs/（ELBの箇所）
•  AWS CLI – ELB
http://docs.aws.amazon.com/cli/latest/reference/elb/
•  [AWS re:Invent 2012] CPN 205: Zero to Millions of Requests
https://www.youtube.com/watch?v=xKF-‐‑‒Aawz9oc
Appendix
ELBヘルスチェックの詳細
インスタンスが正常とみなされるまで
•  ヘルスチェックの間隔が20秒で、ヘルスチェックの成功判定回数の閾値
が3回の場合、正常と⾒見見なされるまでに60秒かかる
ELBにEC2イン
スタンスを登録
20秒
20秒
成功判定
１回目
20秒
成功判定
２回目
成功判定
３回目→オンライン
ヘルスチェックの成功判定回数の閾値を少なくすることで、オンライン化
を早めることが可能
ELBヘルスチェックの詳細
インスタンスが異異常とみなされるまで
•  ヘルスチェックの間隔が20秒で、ヘルスチェックの失敗判定回数の閾値が4回の
場合、異異常と⾒見見なされるまでに80秒かかる
20秒
20秒
失敗判定
１回目
20秒
失敗判定
２回目
20秒
失敗判定
３回目
失敗判定
4回目→オンライン
EC2インスタンスのステータスがrunning→terminateの場合
•  EC2インスタンスがterminateされたことをELBが検知すると、すぐにEC2イン
スタンスへはトラフィックを送らなくなる
•  ELBがterminateを検知するまでに、遅延が発⽣生する場合があるので、EC2 イン
スタンスをde-‐‑‒registerしてからterminateすることを推奨
Default VPC/Internal ELB制約⼀一覧まとめ
（2014年年10⽉月20⽇日時点）
EC2-Classic
プラットフォーム
Internet-facing
ELB
Internal
ELB
EC2-VPC
Internet-facing
ELB
Internal
ELB
IPv6対応
○
×
×
Dedicated
Instance対応
○
×
×
Security
Group設定
×
○
○
Internet
Gateway定義
ー
必須
不不要
必須
必須
ELBの配置
Subnet定義
ー
作成不不可
（Default VPCでは
任意）
（Default VPCでは
任意）
ELBにおけるサーバ証明書の扱いについて
ELBにサーバ証明書をアップロード可能
パターン１：
ELBに証明書をアップロード
証明書
パターン２：
バックエンドインスタンスに証明書を
アップロード
証明書
証明書
証明書
•  証明書の管理理が容易易
•  IAMを使ってアップロード
•  証明書の管理理が⾯面倒
•  各インスタンスに証明書をアッ
プロード
※証明書のライセンスに関しては、ドメイン単位/サーバ単位で発⾏行行など
それぞれ異異なるので発⾏行行元に問い合わせの事
ELBからS3にRoute 53でフェイルオーバ設定 (1/3)
1)  まずELBを指すレコードを作成する。
ELB, S3などIPアドレス
以外を対象にするには、
AliasをYesに
Alias Targetの候補
として、⾃自動的に
ELB, S3などが表⽰示
されるのでELBを指
定する。
ELBからS3にRoute 53でフェイルオーバ設定 (2/3)
2)  Routing Policyを「Failover」にして、設定します。
Active / Standby形式で、
フェイルーバさせたい事
を指定
通常時のレコードである
ことを「Primary」と設定
して指定
正常かに基いてFailoverさ
せるため「Yes」を指定
ELBの機能と連携できるため、
Route53のヘルスチェックは不不
要なため「No」を指定
ELBからS3にRoute 53でフェイルオーバ設定 (3/3)
3)  2個⽬目のレコードを同じNameでS3を指定するレコードを作成し、Secondaryとして設定します。
Active / Standby形式で、
フェイルーバさせたい事
を指定
切切替先のレコードである
ことを「Secondary」と
設定して指定

記入例 KP44M-J4-A 低圧太陽光発電設備 系統連系・電力

商 品 仕 様 書 - パナソニック

収納ブレーカ一覧 OPK-C キー付プラボックス・

CRM－NEDO 生態リスクの考え方

商 品 仕 様 書 - パナソニック

M-RB・MS-RB

(ELB) とは？ - Amazon Web Services

アマゾン ウェブ サービスユーザー向け専用商品の販売

誤動作及び誤不動作対応方法と漏電状況の具体的調査例（PDF）

ハンズラボ、AWS 活用のためのクラウドソリューションを本格展開 ～企業

Document 7280113