AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) Amazon Elastic Load Balancing (ELB)

1. Elastic Load Balancing (ELB)
AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ)
ソリューションアーキテクト 辻 義⼀一
放送：2014.5.07 最終更更新：2014.10.20

2. 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

3. Agenda
• ELBの基本
• ELBの各種機能
• ELBと各種サービスの連携
• ELB負荷試験時のTips
• まとめ

4. ELBの基本

5. Elaastic Load Balancing (ELB) とは？
〜～ AWSクラウド上のロードバランシングサービス 〜～
ELBで実現できるシステム
§ スケーラブル : 複数のEC2インスタンスに負荷分散
§ ⾼高い可⽤用性 : 複数のアベイラビリティゾーンにある複数のEC2インスタンス
の中から正常なEC2インスタンスにのみ振り分け
ELB⾃自⾝身の特徴
§ スケーラブル : ELB⾃自体も負荷に応じてキャパシティを⾃自動増減
§ 安価な従量量課⾦金金 : 従量量課⾦金金で利利⽤用可能
§ 運⽤用管理理が楽 : マネージドサービスなので管理理が不不要
§ 豊富な連携機能 : Auto Scaling, Route 53, Cloud Formation… などと連携

6. ELBの使い⽅方イメージ
アベイラビリティ ゾーン a
ELB
ユーザー
マネージメント
コンソール
開発・管理理者
EC2
EC2
アベイラビリティ ゾーン b
myLB-xxx.elb.amazonaws.com

7. 負荷分散してスケーラブルなシステムを
バックエンドのEC2インスタンスのリクエスト数やコネクション数が
均等になるよう負荷分散
接続が少ない新インスタンスに
新しい接続を振り分ける
新サーバ追加！
過負荷
過負荷
対応プロトコル
L7： HTTP, HTTPS
L4： TCP, SSL

8. 複数アベイラビリティゾーン(AZ)に分散
2段階で負荷分散
1) DNSラウンドロビンで各AZ内のELBに振り分け
2) 負荷が均等になるようにバックエンドのEC2に振り分け
myLB-xxx.elb.amazonaws.com
AZ -‐‑‒ aELB
AZ -‐‑‒ b
DNS
ラウンドロビンで
振り分け
負荷分散

9. 分散した上でヘルスチェックして⾼高い可⽤用性
• ELBは指定した設定に基づき、バックエンドの
インスタンスのヘルスチェックを⾏行行う
– Pingプロトコル 例例：HTTP (200番が返るのを確認）
– Pingポート 例例：80番
– Pingパス（HTTP/S利利⽤用時）例例：/index.html
– タイムアウト時間 例例：20秒
– ヘルスチェック間隔 例例：30秒
– 異異常判定までの回数 例例：4回
– 正常判定までの回数 例例：2回
• 正常との判定が遅いと追加したインスタンスが
使えるまでに時間がかかる。逆に異異常との判定が厳しすぎても、
過負荷時に処理理できるインスタンスを減らしてしまうことにも。

10. ELB⾃自⾝身もスケーラブル
ELB⾃自⾝身も負荷の増減に応じて⾃自動でスケール
（キャパシティが⾃自動で増加する）
[注意]
ELBがスケールするときには、IPアドレスが変化します。
ELBへアクセスするときには必ずDNS名で！
独⾃自ドメインに割り当てる際はCNAMEにて。

11. 安価な従量量課⾦金金
2GB
→ 100GB課⾦金金
1GB
49GB
49GB
98GB
2014年年10⽉月20⽇日現在
• 時間当たりの利利⽤用料料は、複数AZ配置構成でも同じ
• SSLを利利⽤用しても同じ料料⾦金金
• ELBにリザーブドプランはなし
• 処理理量量の課⾦金金は合計処理理量量
1GB

12. ELBの各種機能

13. ELBの各種機能
§ ELB利利⽤用時のTips
§ 独⾃自ドメイン名で利利⽤用
§ クライアントのIPアドレス取得
§ AZとバックエンドキャパシティの関係
§ ELBとバックエンドとのコネクション
§ SSLサポート
§ スティッキー セッション
§ 接続のストリーミング
§ アクセスログのS3保管
§ ELB⾃自⾝身のスケーリング
§ VPCでの利利⽤用
§ ELBとSecurity Group

14. 独⾃自ドメイン名で利利⽤用
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のエイリアスレコードを
使うことで実現可能

15. クライアントの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

16. AZとバックエンドキャパシティの関係
良良くない例例：AZ間でキャパシティが不不均等
2
AZ-‐‑‒b3
New 2013.11
AZ-‐‑‒a
50%
50%
もう⼀一⽅方より
負荷が⾼高くなる
クロスゾーン負荷分散が有効であれば
50%
50%
台
台
2台
AZ-‐‑‒a
負荷を基に
均等に
3
台
AZ-‐‑‒b• リージョン内の複数AZに負荷分散可能
– 複数リージョンへの分散にはRoute 53を併⽤用できる
• 各EC2インスタンスのタイプは同じに
• AZごとのEC2インスタンス数はできれば均等に
– クロスゾーン負荷分散でAZ間を越えて負荷を均等にできる

17. ELBとバックエンドとのコネクション
• クライアント ⇔ ELB のコネクション
– 無通信状態が続くとそのコネクションを切切断する
• ELB ⇔ バックエンドのEC2インスタンス のコネクション
– EC2インスタンス上のApache等ではHTTP Keepalive設定を推奨
– Webサーバのタイムアウト値をELBのアイドルコネクションタイムアウトよ
り⻑⾧長い時間に設定することを推奨
接続を維持できない場合、ELBがそのEC2インスタンスを異異常と判定し、
トラフィックを送らなくなることがあるので注意
• タイムアウトは60秒がデフォルト値で、1秒から60分までに変更更可能
クライアント ⇔ ELBELB ⇔ バックエンドのEC2インスタンス
New 2014.7

18. ELB⾃自⾝身のスケーリング
ELBは負荷に応じて⾃自動でスケールする
• 但し、ELBへの接続・リクエストが瞬間的に急増したために、ELBのス
ケーリングが間に合わない場合、HTTP 503を返す
– 新サービス開始
– TVやメディアによるサービス紹介
– 負荷テスト 等
• 回避⽅方法は事前にELBをスケールさせておく
– 負荷を段階的にかける
– Pre-‐‑‒Warming（暖気運転）の申請を⾏行行う ※Business/Enterpriseサポート要

19. VPCでの利利⽤用
• ELBを配置するサブネットをAZごとに1つ指定
サブネットは最⼩小 /27 CIDRブロックで、20個以上の空きIPが必要
• EC2 Classicに設置する場合と⽐比べた制約：IPv6サポートなし (2014年年4⽉月時点)
myLB-xxx.elb.amazonaws.com
AZ -‐‑‒ a
AZ -‐‑‒ b
ELBサブネット Webサブネット

20. Internet-‐‑‒Facing ELB / Internal ELB
§ Internet-‐‑‒Facing ELB
インターネットからアクセスできるELB
– 名前解決するとグローバルIP
§ Internal ELB
VPC内やオンプレミス環境からのみ
アクセスできればよいELB
プライベートサブネットにも配置できる。
– 名前解決するとプライベートIP
Internet-Facing ELB
Webサーバ
Internal ELB
APサーバ

21. ELBとSecurity Group
• EC2 ClassicのSecurity Groupは”amazon-‐‑‒elb/amazon-‐‑‒elb-‐‑‒sg”、
VPCではELBに任意のSecurity Groupを指定可能
• ICMP Echo Request/Replyを許可
すれば、ELBがpingにも応答
• バックエンドのEC2インスタンスは
ELBからのみリクエストを
受け付ける設定を推奨
443
sg-‐‑‒EC2
80: sg-‐‑‒ELB
22:10.0.0.0/24
80
80
80
sg-‐‑‒ELB80
443: 0.0.0.0/0
22

22. ELBの各種機能
§ ELB利利⽤用時のTips
§ 独⾃自ドメイン名で利利⽤用
§ クライアントのIPアドレス取得
§ AZとバックエンドキャパシティの関係
§ ELBとバックエンドとのコネクション
§ SSLサポート
§ スティッキー セッション
§ 接続のストリーミング
§ アクセスログのS3保管
§ ELB⾃自⾝身のスケーリング
§ VPCでの利利⽤用
§ ELBとSecurity Group

23. 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

24. HTTPS/SSL利利⽤用時のサーバ証明書
ELBにサーバ証明書をアップロード
• HTTPS/SSL利利⽤用にはサーバ証明書のアップロードが必須
• 複数ホスト名には別名・ワイルドカードか複数ELBで対応（SNI未対応）
• バックエンドとの通信にSSLを⽤用いないなら証明書の管理理が容易易
• マネージメントコンソール or CLI or IAM APIで設定
SSL証明書のライセンスに関し
ては、サーバ単位/ドメイン単位
で発⾏行行などそれぞれ異異なるので
発⾏行行元に問い合わせの事
サーバ証明書

25. 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 の適⽤用を

26. バックエンドインスタンスのサーバ証明書認証
ELBとバックエンドのEC2インスタンス間でHTTPS/SSL使⽤用時に、
特定の証明書を使⽤用しているかどうかバックエンドを認証

27. ELBの各種機能
§ ELB利利⽤用時のTips
§ 独⾃自ドメイン名で利利⽤用
§ クライアントのIPアドレス取得
§ AZとバックエンドキャパシティの関係
§ ELBとバックエンドとのコネクション
§ SSLサポート
§ スティッキー セッション
§ 接続のストリーミング
§ アクセスログのS3保管
§ ELB⾃自⾝身のスケーリング
§ VPCでの利利⽤用
§ ELBとSecurity Group

28. スティッキー セッション (stickness)
同じユーザから来たリクエストを全て同じEC2インスタンスに送信
• デフォルトで無効、使うには有効に
• アプリケーションでのセッション情報、⼀一時ファイルなどを
EC2インスタンスが保持する構成の場合に必要となる。
• HTTP/HTTPSでのみ利利⽤用可能
• ELBは独⾃自のセッションCookieを挿⼊入
EC2インスタンスの増減を柔軟にできるように、
セッション情報などは別のDBサーバやキャッ
シュサーバに持たせるのが望ましい。
この場合スティッキー セッションは不不要。

29. スティッキー セッションの有効期間
有効期間の制御⽅方法は以下２パターン
§ Application Generated Cookie Stickiness（アプリケーション制御）
アプリケーションが作成したCookieにあわせる
– アプリケーションが作成するCookie名を指定
– Cookieの有効パスもあわせる
§ Load Balancer Generated Cookie Stickiness（期間ベース）
セッション開始からの有効期間を指定してELBで制御
– 秒単位で指定
– 無期限にする事も可（無期限でもブラウザを閉じれば終了了）

30. ELBの各種機能
§ ELB利利⽤用時のTips
§ 独⾃自ドメイン名で利利⽤用
§ クライアントのIPアドレス取得
§ AZとバックエンドキャパシティの関係
§ ELBとバックエンドとのコネクション
§ SSLサポート
§ スティッキー セッション
§ 接続のストリーミング
§ アクセスログのS3保管
§ ELB⾃自⾝身のスケーリング
§ VPCでの利利⽤用
§ ELBとSecurity Group

31. 接続のストリーミング (Connection Draining)New 2014.3
バックエンドのEC2インスタンスをELBから登録解除したり、ヘルスチェッ
クが失敗した時に、新規割り振りは中⽌止して、処理理中のリクエストは終わる
まで⼀一定期間待つ。
• 新しく作成したELBではデフォルトで有効、タイムアウト 300秒。
• タイムアウト最⼤大 3600秒
• 接続のストリーミング動作中
– Management Consoleではインスタンスの表⽰示が消える
– API/SDK/CLIでは状況がわかる
（2014.5時点）

32. 登録解除時の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
タイムアウト後
OutOfService Instance is not currently registered with the
LoadBalancer.

33. ELBの各種機能
§ ELB利利⽤用時のTips
§ 独⾃自ドメイン名で利利⽤用
§ クライアントのIPアドレス取得
§ AZとバックエンドキャパシティの関係
§ ELBとバックエンドとのコネクション
§ SSLサポート
§ スティッキー セッション
§ 接続のストリーミング
§ アクセスログのS3保管
§ ELB⾃自⾝身のスケーリング
§ VPCでの利利⽤用
§ ELBとSecurity Group

34. アクセスログのS3保管New 2014.3
ELBのアクセスログを指定したS3に⾃自動保管
• 簡単にログのS3保管が実現できる
• ELBだからこそ記録できる項⽬目
– ELBの応答コード
– ELBでの処理理時間
– クライアントのIPアドレス
• Apache/Nginxでは標準だがELBのログに含まれていない項⽬目
– リファラ
– ユーザエージェント
（2014.10時点）

35. ELBと各種サービスの連携

36. 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項⽬目

37. Auto Scalingとの連携
• Auto Scalingによるインスタンス増減時にELBへの追加・削除が可能
• ELBのヘルスチェックの結果をAuto Scalingに反映可能
• インスタンス削減時は、接続のストリーミングでの処理理中の接続を待つ
利利⽤用例例
– ⼀一定間隔でレスポンスをチェックし、遅延が増加したらインスタンスを⾃自動追加
– ELBのヘルスチェックが成功したEC2インスタンスを常にX台以上
増減
Auto scaling Group
New 2014.3

38. Route 53 DNSフェイルオーバ対応
Route 53のヘルスチェック機能とELBが連携
例例：アプリケーション障害時にSorryページヘ誘導
正常時フェイルオーバ時
S3 Bucket
3. ELB配下に正常なEC2
インスタンスなし
2. AppサーバのELB
ヘルスチェック失敗
1. DBに問題発⽣生
4. フェイルオーバ
5. Sorry
ページ

39. OpsWorksのELB対応
OpsWorksでELBをLBレイヤーに利利⽤用可能に
UserAWS Management
Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
レシピ
レシピ
レシピ
D
B
Web
/App
Web
/App
LB
①スタックの作成
②レイヤーの作成
③レシピの作成・設定
（ビルトイン
レシピ利利⽤用可）
④レイヤーにインスタ
ンス追加・起動
⑤レシピによって
パッケージインス
トール、設定
スタックLBとしてELBが選択可能に

40. ELB負荷テストに関するTips

41. ELBを負荷テストする必要性について
ELBのいくつかの特⻑⾧長がテストシナリオに影響を与える可能性がある。
• ELBのスケーリング
• ELBの初期キャパシティ
• アイドル時のコネクションタイムアウト
• バックエンドインスタンスのヘルスチェック
• Stickyセッション 等
ご利利⽤用内容に合わせたシナリオでテストが必要

42. ELBの負荷テスト⽅方法の種類
§ シングルクライアントテスト
例例：Apache Bench(ab)
§ マルチクライアントテスト
例例：curl-‐‑‒loader
(都度度DNS解決を⾏行行うツールが望ましい)
§ 分散テスト
例例：Fabricフレームワーク、
BeesWithMachineGuns
負荷⽣生成
クライアント
バックエンド
インスタンス
クライアントの負荷が⾜足りない場合はクライアント数を増やす等で対応可

43. 推奨テストアプローチ
• 想定する最⼤大負荷のテスト
• 通常のトラフィック時のテスト
– トラフィックの多い時
– トラフィックの少ない時
– トラフィックの傾向に変化がある時（朝や昼の時間帯など）
• 短い時間でトラフィックが⼤大きく変化する場合のテスト
ELB以外にも負荷⽣生成クライアント、バックエンドEC2インスタンスも
監視すべき
– アプリケーション内部の動作も要確認
– どこかボトルネックになっているか把握しておく
時間
負荷

44. 負荷テストの注意事項
• ELBの初期スケールに注意
– スケールするまでに、HTTP 503レスポンスを返す期間があり得る
– 回避策：
• ELBの暖気運転（ Pre-‐‑‒Warming）申請をする
• 5分間隔で50%以上のトラフィック増加をしないよう負荷テストを設定
• DNSクエリの仕⽅方に注意
– テストクライアント側で少なくとも1分に1回DNSの再解決をする
• スティッキーセッション利利⽤用時の割り振り⽅方
– 同じCookieでリクエストを続けた場合などは振り分けに偏りが
• バックエンドインスタンスのアイドルタイムアウト
– 60秒以上に設定しないとELBが誤って不不健全なホストと⾒見見なす可能性あり

45. まとめ

46. まとめ
〜～ELBはAWSが提供するロードバランシングサービス〜～
§ 運⽤用管理理コストを抑えながら
スケーラブルで⾼高可⽤用なインフラを構築可能
§ 各種サービスとの連携もスムーズ＆随時拡充
§ 負荷試験時はその特性を理理解した上で
§ 急激な負荷の増⼤大が想定される場合には、
サポート加⼊入の上で暖気申請（Pre-‐‑‒Warming）を

47. 参考資料料（⽇日本語）
• 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の項⽬目）

48. 参考資料料（英語）
• 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

49. Appendix

50. ELBヘルスチェックの詳細
インスタンスが正常とみなされるまで
• ヘルスチェックの間隔が20秒で、ヘルスチェックの成功判定回数の閾値
が3回の場合、正常と⾒見見なされるまでに60秒かかる
ヘルスチェックの成功判定回数の閾値を少なくすることで、オンライン化
を早めることが可能
20秒 20秒 20秒
成功判定
１回目
成功判定
２回目
成功判定
３回目→オンライン
ELBにEC2イン
スタンスを登録

51. ELBヘルスチェックの詳細
インスタンスが異異常とみなされるまで
• ヘルスチェックの間隔が20秒で、ヘルスチェックの失敗判定回数の閾値が4回の
場合、異異常と⾒見見なされるまでに80秒かかる
20秒 20秒 20秒
失敗判定
１回目
失敗判定
２回目
失敗判定
３回目
失敗判定
4回目→オンライン
20秒
EC2インスタンスのステータスがrunning→terminateの場合
• EC2インスタンスがterminateされたことをELBが検知すると、すぐにEC2イン
スタンスへはトラフィックを送らなくなる
• ELBがterminateを検知するまでに、遅延が発⽣生する場合があるので、EC2 イン
スタンスをde-‐‑‒registerしてからterminateすることを推奨

52. Default VPC/Internal ELB制約⼀一覧まとめ
プラットフォーム
（2014年年10⽉月20⽇日時点）
EC2-Classic EC2-VPC
Internet-facing
ELB
Internal
ELB
Internet-facing
ELB
Internal
ELB
IPv6対応○
作成不不可
××
Dedicated
Instance対応○××
Security
Group設定×○○
Internet
Gateway定義ー必須不不要
ELBの配置
必須
Subnet定義ー
（Default VPCでは
任意）
必須
（Default VPCでは
任意）

53. ELBにおけるサーバ証明書の扱いについて
ELBにサーバ証明書をアップロード可能
パターン１：
ELBに証明書をアップロード
• 証明書の管理理が容易易
• IAMを使ってアップロード
パターン２：
バックエンドインスタンスに証明書を
アップロード
証明書
証明書
証明書
• 証明書の管理理が⾯面倒
• 各インスタンスに証明書をアッ
プロード
証明書
※証明書のライセンスに関しては、ドメイン単位/サーバ単位で発⾏行行など
それぞれ異異なるので発⾏行行元に問い合わせの事

54. ELBからS3にRoute 53でフェイルオーバ設定 (1/3)
1) まずELBを指すレコードを作成する。
ELB, S3などIPアドレス
以外を対象にするには、
AliasをYesに
Alias Targetの候補
として、⾃自動的に
ELB, S3などが表⽰示
されるのでELBを指
定する。

55. ELBからS3にRoute 53でフェイルオーバ設定 (2/3)
2) Routing Policyを「Failover」にして、設定します。
Active / Standby形式で、
フェイルーバさせたい事
を指定
通常時のレコードである
ことを「Primary」と設定
して指定
正常かに基いてFailoverさ
せるため「Yes」を指定
ELBの機能と連携できるため、
Route53のヘルスチェックは不不
要なため「No」を指定

56. ELBからS3にRoute 53でフェイルオーバ設定 (3/3)
3) 2個⽬目のレコードを同じNameでS3を指定するレコードを作成し、Secondaryとして設定します。
Active / Standby形式で、
フェイルーバさせたい事
を指定
切切替先のレコードである
ことを「Secondary」と
設定して指定