re:Invent 2023: AWS ELBチームが語る可用性とセキュリティの内部設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Enhance your app’s security & availability with Elastic Load Balancing (NET318)
この動画では、AWSのElastic Load Balancingの可用性とセキュリティについて、内部の詳細や設計思想が語られます。Jon ZobristとSathya Rameshanが、スケーリング、ヘルスチェック、オペレーションの観点から可用性を解説し、IPベースのアクセス制御やTLS 1.3、FIPSサポートなどのセキュリティ機能を紹介します。また、最新のmutual TLS機能やGateway Load Balancerの活用法など、ここでしか聞けない貴重な情報が満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Elastic Load Balancingの可用性とセキュリティ：Jon ZobristとSathya Rameshanによる概要
みなさん、こんにちは。「Elastic Load Balancingでアプリのセキュリティと可用性を向上させる」へようこそ。私はJon Zobristで、ELBのカスタマーサクセスを率いています。一緒にいるのは、プロダクトを率いるSathya Rameshanです。今日は、可用性とセキュリティという2つのトピックについてお話しします。私たちがどのように考え、製品に組み込んでいるか、 そしてお客様がそれらをどのように活用できるかについて説明します。プレゼンテーションを通じて、異なるセクションを表すアイコンを使用します：内部の詳細、私たちの考え方、 過去1年程度で発表した新機能や今年のre:Inventで発表したもの、お客様自身のアーキテクチャに適用できる設計上の考慮事項、そしてドキュメントへのリンクをQRコードで表示します。スキャンしたい方のために、QRコードが表示されたら少し間を置きます。
このセッションの後、サービスとしての可用性とセキュリティについて私たちがどのように考えているか、それらを製品にどのように組み込んでいるか、そして過去1年間に発表した新機能で今日何ができるかについて、よく理解していただけるはずです。では、早速始めましょう。ちなみに、 下のQRコードは、最近公開したベストプラクティスサイトです。現在、セキュリティのベストプラクティスを掲載していますので、ぜひご覧ください。Elastic Load Balancing特有のものですが、可用性に関するものもまもなく公開予定です。可用性については、スケーリング、ヘルス、オペレーションの3つの領域をカバーします。
Elastic Load Balancerのスケーリングメカニズム：ALB、NLB、GWLBの違い
Elastic Load Balancerは、事実上どんな規模のワークロードもサポートできるようにスケールします。私たちがどのようにそれを行い、システムがどのように機能するかについてお話しします。私たちが行っていることの1つは冗長性の確保であり、お客様がどのように同じことを実現できるかについても説明します。 Application Load Balancerは、まず上方向に、そして外側にスケールします。ロードバランサーを作成してトラフィックを送信し始めると、トラフィックの増加を検知し、 現在のサイズのノードをより大きなものに置き換えます。使用している最大のノードサイズに達すると、外側へのスケーリングを開始し、各Availability Zoneにさらにノードを追加します。
覚えておくべき重要なポイントは、私たちが積極的にスケールアップするということです。数秒でスケーリングをトリガーし、数分で容量を提供し、トラフィックが増え続ける場合は積極的にスケールアップを続けます。一方で、スケールダウンは非常に慎重に行います。日中と夜間のパターンが正弦波のような場合でも、スケールダウンしないようにゲートを設けています。日中にスケールアップし、夜にスケールダウンする場合、実際にはロードバランサーをスケールダウンしません。これは、トラフィックの非常に一般的な挙動であり、変更を最小限に抑えることでワークロードをよりスムーズに保つことができるからです。もう1つ重要なのは、複数の次元でスケーリングすることです。トラフィックのほぼすべての次元でスケーリングするので、Auto Scalingでどのように活用できるかについてお話しします。
Network Load BalancerとGateway Load Balancerは、AWS Hyperplaneを利用しているため、若干異なるスケーリングシステムを使用しています。Hyperplaneは、EC2のソフトウェア定義ネットワークと結びついたElastic Network Interfaceを使用して、1つのIPアドレスから多数の異なるホストにトラフィックを透過的に分散させるシステムです。Hyperplaneの主な利点は、静的IPアドレスを取得できることです。つまり、ロードバランサーの存続期間中、そのENIは変更されず、IPも変わりません。また、永続的なフローも得られます。これは、フローが通過中に障害や何かが起こっても、フローに影響を与えないことを意味します。同じ理由で、透過的なスケーリングも得られます。フローを継続させながら、それをサポートするすべてのホストを実際に交換することができ、フローに影響を与えません。
私たちは、Network Load BalancerとGateway Load Balancerで、これを常に行っています。トラフィックが増加すれば拡張し、減少すれば縮小するという具合に、日常的に行われています。Network Load Balancerの場合、Application Load Balancerとの重要な違いは、Availability Zone（AZ）ごとに独立して拡張することです。Hyperplaneは非常にゾーン単位の構造で、他のゾーンを認識しません。ゾーン内では、Hyperplaneのすべてがそのゾーン内に留まります。そのため、Network Load BalancerとGateway Load Balancerは、そのゾーンで検出されたトラフィックに基づいて、異なるゾーンで透過的に拡張されます。ALBと同様に、積極的に拡張し、慎重に縮小しますが、これは透過的に行われます。そのため、ホストを変更する際も、確立されたフローには影響がありません。新しいフローも、リスクなく確立され続けます。
過剰プロビジョニングとAuto Scalingの戦略
過剰プロビジョニングについて触れましたが、どの程度過剰にプロビジョニングするかを決める際に考慮するのは、「常に少なくとも1つのAZ分の余剰容量を確保したい」ということです。その理由は2つあります。
まず、トラフィックが急増した場合に使用できます。スケーリングをトリガーする際に、すでに少し余分な容量があるので、それを使用できます。スケーリングは数秒でトリガーされ、数分で容量が提供されます。もう1つの理由は、ターゲットや他の場所で障害が発生し、そのゾーンから退避する必要がある場合、他のゾーンに待機している容量があることを確信できるからです。つまり、問題が発生したり、あるゾーンから退避したりする場合、他のゾーンはすでにElastic Load Balancing用に拡張されています。
自分のワークロードでこれを行うにはどうすればよいでしょうか？同じような概念が適用され、事前プロビジョニングや過剰プロビジョニングを行うことができます。私たちがそれを行う方法は、実際には「このくらいのホストが必要だ」と見積もるのではなく、閾値を下げることです。この例では、CPUの閾値を使用し、35%まで下げています。つまり、CPUが35%を超えると、スケールアップがトリガーされます。また、複数の次元も使用しています。Application Load Balancerの場合、ターゲットごとのリクエスト数に基づいてスケーリングポリシーを作成し、希望する正確なリクエスト数を目標にすることができます。それを超えると、Auto Scalingがより多くのホストをプロビジョニングします。
この場合、CPUの閾値が35%で、ターゲットごとのリクエスト数が50です。これは、おそらくその3分の1ほど多い、つまり75リクエストくらいが私たちのフリートにとって健全だと考えられる数字です。しかし、3つのAZを使用しているため、1つのAZ分を過剰プロビジョニングしたいと考えています。そのため、この数字を下げて、より早くスケールするようにしています。もちろん、これはすべてのケースに当てはまる単純な計算ではありません。そのため、負荷テストを行い、保有するホスト数で何ができるかを確認することは、過剰プロビジョニングの量を決定する上で依然として重要な部分です。
スケールダウンを慎重に行う方法は2つあります。1つは、クールダウンを設定することです。つまり、「12時間はクールダウンしない。スケールアップしたら、12時間はスケーリングしない」というようにします。もう1つは、スケールダウンのしきい値を下げることです。35%を目標とするのではなく、35%を超えたらトリガーを発動し、15%を下回った場合にスケールダウンするというようにします。
ヘルスチェックとフェイルオーバーメカニズム
ここからは、プラットフォームに組み込まれている可用性機能について、私たちが行っていることと、皆さんができることについてお話しします。ヘルスチェック、昨年リリースした2つの機能（ターゲットグループのフェイルオープンとDNSフェイルオーバーのしきい値）、Application Load Balancerのクロスゾーンオフ、異常検知、そして今年リリースしたいくつかの機能について説明します。
ターゲットに対するヘルスチェックと同様に、私たちはすべてのロードバランサーノードのヘルスチェックを行っています。ロードバランサーの各IPは、内部システムから常にヘルスチェックを受けています。頻繁にヘルスチェックを行い、障害を検知すると、新しい健全なノードに置き換えて、トラフィックを復旧させます。ターゲットグループのヘルスチェックを設定する際には、タイミングとしきい値の2つの領域があります。タイミングには、ヘルスチェックの頻度、健全および不健全と判断するためのヘルスチェックの間隔が含まれます。そして、不健全および健全な状態のしきい値があります。これはNetwork Load BalancerとApplication Load Balancerで同じです。
秒数を正確に設定でき、不健全カウントと健全カウントを個別に設定できます。ヘルスチェックに何を含めるべきか、どの依存関係を含めるべきかを考える際、私がいつも問うのは、「この依存関係が失敗した場合、それでもリクエストやレスポンスをクライアントに送りたいですか？」ということです。答えがイエスなら、おそらくそれをヘルスチェックから除外できます。しかし、ノーなら、クライアントのニーズに完全に応答できないターゲットにリクエストを送らないように、 ヘルスチェックに含めた方がよいでしょう。
最後に、HTTPヘルスチェックは一般的にTCPヘルスチェックよりも優れています。TCPヘルスチェックは単純なハンドシェイクのみを行うため、オペレーティングシステムとリスナーが起動していても、アプリケーションが実際に応答できない状態でもTCPヘルスチェックは通過してしまいます。一方、HTTPヘルスチェックは、アプリケーションが実際に起動して動作していることをより深いレベルで確認できます。
ターゲットグループのfail-openとDNSフェイルオーバー
昨年リリースした最初の機能について話しましょう。これはターゲットグループのfail-openしきい値です。皆さんのターゲットグループには初日からこのしきい値が設定されていますが、100%になっています。fail-openとは何でしょうか？fail-openとは、ターゲットグループ内のすべてのターゲットを、健全かどうかに関わらず健全であるかのように扱うことです。現在、しきい値を変更していない場合、fail-openをトリガーするには、すべてのターゲットがヘルスチェックに失敗する必要があります。
これは過負荷シナリオで役立ちます。トラフィックが急増してターゲットに過負荷がかかり、失敗し始める場合などです。問題は、ターゲットが失敗するにつれて、Application Load Balancerがそれらへのリクエストのルーティングを停止し、ますます少ないターゲットに集中していくことです。最終的にすべてのターゲットが不健全になり、そしてfail-openします。これがデフォルトの100%の動作です。私たちは、これを見直し、ワークロードに適した値に変更することを強くお勧めします。
この概念を説明するために、例を考えてみましょう。この例では、50%のルーティングfail-openしきい値があり、10個のターゲットがあります。そのうち90%が健全です。Application Load Balancer (ALB)とNetwork Load Balancer (NLB)は何をするでしょうか？健全なターゲットにのみルーティングします。状況が悪化し、より多くのターゲットが失敗し始めても、しきい値を超えない限り、トラフィックを送信するターゲットを絞り続けます。最終的にしきい値を超えると（ここでは6つのターゲットが不健全になり、健全なのは40%のみ）、fail-openし、すべてのターゲットに対して健全であるかのようにトラフィックを送信し始めます。
これにより、顧客体験を損なうことなく過負荷から回復できる可能性があります。もしそれらのターゲットが実際にいくつかのリクエストに応答できる場合です。繰り返しになりますが、これは過負荷シナリオで役立つので、デフォルトの100%から変更することを検討してください。ターゲットグループがfail-openしている場合、障害をルーティングするための次の手段はDNSです。Elastic Load BalancerにはRoute 53ヘルスチェックがあります。内部および外部のすべてのELBには、サービスに無料で付属するRoute 53ヘルスチェックがあります。このヘルスチェックは、IPが不健全になるかヘルスチェックに失敗した場合、それらをDNSから削除します。
ターゲットグループのfail-openしきい値を低く設定している場合、ゾーンに影響がある場合でも、そのゾーンだけでDNSのフェイルアウェイがトリガーされない可能性があります。つまり、例えば1つのゾーンのターゲットグループがDNS fail-openのしきい値を超えると、すべてのゾーンがfail-openし始めます。すべてのゾーンがfail-openすると、Route 53ヘルスチェックに失敗し、そのトラフィックを別のエンドポイントや場所にリダイレクトする必要が本当に出てきます。
ALBを使用していて、別のALBがある場合（おそらく別のリージョンにあり、Route 53で既にフェイルオーバーを設定済みの場合）、このより低いしきい値でクロスゾーンを有効にすると役立ちます。しかし、フェイルオーバー先がない場合は、クロスゾーンを無効にすることを検討するとよいでしょう。これの主な利点は、1つのゾーンで問題が発生した場合、他のゾーンは引き続きトラフィックを受け取ることができ、問題のあるゾーンだけが待機状態になることです。これは、Availability Zoneからフェイルアウェイするのに役立ちます。 このしきい値のデフォルト値は、フェイルオープンのしきい値とは別で、100%です。ゾーンから脱出するために、これをより低い値に変更することをお勧めします。繰り返しになりますが、別のリージョンの別のロードバランサーや別のサービスなど、フェイルオーバー先がある場合を除いて、これはクロスゾーンを無効にした場合に最も効果的です。
Application Load Balancerのクロスゾーン無効化とゾーナルシフト
Application Load Balancerのクロスゾーン無効化について簡単に説明しましょう。これは昨年リリースした機能で、その名の通りクロスゾーンロードバランシングをオフにできます。つまり、トラフィックがあるゾーンに入ってきた場合、ロードバランサーからそのゾーンを離れることはありません。そのゾーンのロードバランサーノードは、同じゾーン内にのみトラフィックを送信します。これの利点は、ゾーン単位の分離が可能になり、ゾーンの障害が発生した場合にフロントドアから簡単にフェイルアウェイできることです。これを検討する際の重要なポイントは、十分な容量があるか、そしてターゲットが必要とするすべてのリソース、すべての依存関係が各ゾーンで利用可能かどうかです。
理想的には、すべてのゾーンで同じ数のターゲットを持ち、同じ方法でスケールできる状態で、クロスゾーンを無効にして使用できます。そうでない場合、クロスゾーンを無効にすると、一部のターゲットが処理できる以上のトラフィックを受け取るというアンバランスな状況になる可能性があります。これは、 Route 53 Application Recovery Controllerのゾーナルシフト機能とうまく連携します。ゾーナルシフトを使用すると、Route 53に「このロードバランサーのDNSからこのゾーンを削除してください」と指示できます。実際、Route 53のヘルスチェックが失敗し始めると、同じIPからフェイルアウェイするので、これは常に行われています。しかし、ゾーナルシフトを使えば、これを設定できます。テストのために使用したり、他のアラームやゾーンから脱出するきっかけとなる何かがあった場合に使用したりできます。
これにより、Route 53の高可用性コントロールプレーンを使用して、簡単にシグナルを送り、「このロードバランサーについて、このゾーンから完全に脱出してください」と指示することができます。ゾーンについて話している間に、 今年リリースしたばかりの機能について説明しましょう。Network Load Balancerのゾーナルアフィニティです。これは名前の通りの機能です。クライアントが存在するゾーンが、そのリクエストに対してRoute 53のDNSレコードが返すゾーンになります。つまり、クライアントがEC2にあり、ゾーン単位である場合、NLBに接続すると、100%のゾーナルアフィニティか、85%を選択できます。デフォルトでは、すべてのDNSレコードが0%のゾーナルアフィニティになっています。クロスゾーントラフィックのレイテンシーを低減したりコストを節約したりしたい場合、これによってゾーン内にトラフィックを保持できます。これは、Route 53のDNSヘルスチェックやゾーナルシフトとも連携します。そのゾーンからフェイルアウェイすることもでき、トラフィックは他のゾーンにシフトします。85%の設定が最も有用です。これは15%をクロスゾーンに保持するので、何かが起こってそのゾーンからフェイルアウェイする場合でも、既に15%のトラフィックがクロスゾーンに流れているため、驚くことはありません。100%の設定も、本当にそのゾーンに分離したい場合には良い設定ですが、ぜひ確認してみてください。
異常検知と自動ターゲットウェイト：グレーな障害への対応
次に、異常について話しましょう。ヘルスチェックは、ハードな障害を検出するのに適しています。何かが壊れたり、依存関係が機能しなくなったり、ヘルスチェックに失敗したり、到達不能になったり、クラッシュしたりした場合に分かります。しかし、多くの障害はグレーな障害で、パフォーマンスが低下したり、期待通りに動作していない状態です。Elastic Load Balancingでは内部的に、ロードバランサーのすべてのノードを監視し、互いに比較するシステムを持っています。もし1つのノードが外れ値であれば、それを新しい健全なノードに事前に置き換えます。
これらの置き換えを行う際、そしてスケーリングを行う際も同様ですが、私たちはグレースフルな置き換え戦略を使用します。これは、新しいノードを起動し、DNSに登録し、古いノードをDNSから削除し、ドレインさせるというものです。接続が5分間ゼロになるまでドレインさせます。場合によっては長時間ドレインさせることもあります。このシステムは、多くのグレーな障害から私たちを救い、すべての顧客の可用性を向上させるのに役立ってきました。そこで、ターゲットに対しても同様のことができれば素晴らしいと考えました。
そこで今年、Application Load Balancer用の自動ターゲットウェイトを導入しました。これは、ターゲットのレスポンスを監視し、エラーを返すターゲットや接続できないターゲットからトラフィックを離すものです。例えば、あるバックエンドが500エラーを返し始め、他のバックエンドはそうでない場合、私たちは迅速にそのターゲットからトラフィックを離します。そして、乗算的な増減を使用するので、トラフィックを大幅に減らします。これはヘルスチェックではありません。ヘルスチェックの失敗を引き起こすものではありません。また、完全にゼロにはしません。なぜなら、そのターゲットが回復したときに検出し、トラフィックを戻せるように、いくらかのリクエストを送り続ける必要があるからです。
そのターゲットが回復し始めたら、ゆっくりと加算的に増やしていきます。すぐに100%の分配に戻すのではなく、有効なトラフィックと有効なレスポンスを返し続ける限り、少しずつ増やしていきます。この機能の素晴らしい点は、Application Load Balancerのすべてのターゲットグループ、すべてのルーティングアルゴリズムで有効になっていることです。つまり、今日Application Load Balancerとターゲットグループをお持ちであれば、2つのメトリクスがあります。1つは異常なホストを検出したかどうかを示すもので、ターゲットグループのゾーンメトリクスを見て、この異常ホスト数メトリクスがゼロより大きい場合、調査して「なぜElastic Load Balancingがこのホストに問題があると判断したのか」を確認できます。そして、「はい、問題を見つけました。このホストを置き換えることができます」と言えるかもしれませんし、発生した問題の根本原因を特定できるかもしれません。
この機能が表示されている場合は、ターゲットの重みに基づいてルーティングするように機能をオンにすることをお勧めします。これにより、それらのターゲットからトラフィックが移動します。これはターゲットの最大50%に対して行われます。重要なポイントは、この数にはunhealthyなターゲットも含まれることです。つまり、ターゲットの半分がunhealthyな場合、異常検知は行いません。 残りの50%からトラフィックを移動させることはしません。なぜなら、実際の容量がすでに縮小されているため、さらに減らしたくないからです。この機能を有効にして「ターゲットにリクエストを送信しなかった」と判断した場合、リクエストを送信しなかったターゲットの数を示すメトリクスが発行されます。これが「mitigated host count」です。テストや社内ユーザーの間では、health checkだけでは不十分な場合に、障害のあるターゲットを検出して置き換えるのに非常に効果的でした。
可用性設定のベストプラクティスとDevOpsアプローチ
こちらはこの機能の詳細についての「What's New」投稿へのQRコードです。この機能はNetwork Load Balancerでも実装されていますが、少し異なります。 Hyperplaneを使用しているため、トラフィックが通過する際のホストの可視性が高くなっています。Network Load BalancerやGateway Load Balancerのhealth checkは、実際のトラフィックが通過するのと同じENIを通過するからです。health checkシステムは、すべての内部Hyperplaneシステムのホップを通過するトラフィックを追跡します。これらの内部health checkのいくつかが合格しない場合、このシステムは実際にそのゾーンからトラフィックを移動させます。
これは同じRoute 53 health checkを使用して行われ、失敗するとそのAZがDNSから削除され、クライアントがhealthyなAZにルーティングされるよう支援します。Network Load BalancerやElastic Load Balancingのすべてのアベイラビリティーゾーンがunhealthyな場合、DNSレコードはfail openになります。これは、トラフィックを受け取るための別のゾーン、別のload balancer、または別のリソースがRoute 53で設定されている場合にのみ有用です。
では、これまで議論してきたアベイラビリティ設定のベストプラクティスを振り返りましょう。health checkについて話しましたが、重要なポイントは、すでに使用していることです。設定を変更したい場合もあるでしょう。target groupとRoute 53にはfail openとfail overのオプションがあります。デフォルトは100%ですが、これを下げることを強くお勧めします。重要な点は、target groupのfail openのしきい値をDNSのfail overよりも低く設定する必要があることです。つまり、DNSのしきい値がトリガーされる前に、target groupのfail openがまず発生する必要があります。DNSのhealth checkの後にtarget groupのfail openを設定することはできません。これは前提条件なのです。
また、Route 53のAPIを通じてゾーンからのテストや障害切り離しを可能にするゾーナルシフトについても説明しました。そして、Application Load Balancerのクロスゾーン機能についても触れました。これは、障害のあるゾーンからトラフィックを切り離すのに非常に役立ちます。
さて、これからは可観測性について話し、いくつかのメカニズムを見ていきます。AWSのDevOps文化とその考え方、運用とシステムの可視化、そしてAWSでのデプロイメントの方法について説明します。 ご存知かもしれませんが、私たちはDevOpsモデルに従っています。私たちにとって、これは主にコードを書いた開発者が本番環境でそのコードをサポートするということを意味します。つまり、Elastic Load Balancingのようなシステムを構築した場合、本番環境で何か問題が発生すれば、あなたが通知を受け、オンコール対応することになります。
運用の可視化：カナリア、メトリクス、アラート
そのため、私たちは開発者に不要な呼び出しで迷惑をかけることを最小限に抑えたいと考えています。例えば、ヘルスチェックを行い、問題のある部分を迂回するなど、自動的に軽減できることは積極的に行います。人間が実際に何かをする必要がある場合にのみ、アラートを出します。システムを本番環境に投入する前の重要なステップとして、私たちはランブックを作成します。何か想定外のことが起きた場合は、週次の運用会議でこれらのランブックを見直します。ランブックは深夜3時でも理解しやすいものでなければなりません。真夜中にシステムのアラートで起こされた開発者が、実際に理解して対処できるものである必要があるからです。
運用の可視化については、3つの領域に分けています。まず、人工的なトラフィックを送信したり、システムを人工的に使用したりして、一部の機能が正常に動作していることを示すカナリアがあります。次に、顧客体験の質や処理量、実行状況を示すメトリクスがあります。そして、オペレーターに問題修正を促すページングやアラートがあります。
最初のカナリアは、データプレーンカナリアです。Elastic Load Balancingの場合、すべてのリージョン、すべてのゾーンにデータプレーンカナリアを配置しています。リージョン内の各データプレーンカナリアは、すべてのゾーン、すべてのロードバランサータイプ、すべてのトラフィックタイプ（IPv6、IPv4、TCP、UDP、HTTP、HTTPSなど）に対してトラフィックを送信します。このシステムは非変更型で、変更を加えません。システムに加えられる変更はすべてテストに対して透過的でなければならず、テストは常に実行されています。エラーや問題が検出された場合、私たちにページが送られ、すぐに対応してそのゾーンから切り離す必要があるかどうかを確認したり、自動軽減策が正常に機能しているかを確認したりすることができます。
もう一つのカナリアは、コントロールプレーンのカナリアです。これは、すべてのリージョン、すべてのゾーンで、あらゆるタイプのロードバランサーとトラフィックに対して実行する完全なライフサイクルテストです。新しいロードバランサーを起動し、設定します。トラフィックの送信が正常に機能することを確認し、変更を加えて、その変更が正しく適用されたことを確認します。そして、削除して、すべてが適切にクリーンアップされたことを確認します。これを毎分、すべてのゾーンのすべてのロードバランサーに対して実行しています。何か問題が発生した場合、これは「顧客がロードバランサーを作成できない可能性がある」といった最初の警告の一つとなります。
メトリクスを見る際、私たちはそれらを2つのカテゴリーに分類します。ポジティブメトリクスがあり、これらはワークロードがどれだけうまく機能しているかを示します。リクエスト数、トラフィック量、ログからの成功コードなどは、システムが実際に機能していることを示す有用な指標です。これらがゼロになったり、CloudWatch異常検出を使用して異常な範囲を外れたりした場合にアラームを設定したいかもしれません。そして、ネガティブメトリクスがあります。ネガティブメトリクスは通常、何かが壊れているか予期せぬ動作をしていることを示します。Elastic Load Balancingの場合、これはよく5xx、TLSネゴシエーションエラー、バックエンド接続エラーなどです。他のシステムでは、データベースエラーなどがあるかもしれません。メトリクスを見る際、これは先ほどの午前3時のシナリオに戻ります。
最初に見るべきものの一つは、ゾーン性です。私たちはすべてをゾーン同士が可能な限り分離されるように構築しており、一つのゾーンに障害が発生しても他のゾーンには影響しないことを想定しています。私がお客様によく言うのは、5xxや他の問題でアラートを受け取った場合、Elastic Load Balancing (ELB)のメトリクスをゾーン次元で見て、それが1つのゾーンだけで発生しているのか、すべてのゾーンで見られるのかを確認することです。強力なゾーン分離があるため、すべてのゾーンで見られる場合、直感に反するかもしれませんが、ロードバランサーが原因である可能性は低くなります。1つのゾーンでのみ見られる場合、高優先度のケースをオープンして「これらのエラーが発生しており、サービスに影響を与えています。助けてください」と言うべきかもしれません。そうすれば、サポートはそれが1つのノードであるかどうかを迅速に確認し、ノードを適切に交換できます。
ダッシュボードとデプロイメント戦略
ELB 5xxなどのネガティブメトリクスにアラートを設定する際、いくつか念頭に置くべきことがあります。主要なメトリクスを持ち、その主要なメトリクスのほぼすべての側面にアラートを設定したいでしょう。しかし、1つのメトリクスの1つのデータポイントだけでアラートを設定したくはありません。そのため、私は一般的に1分などの短いデータポイントを多数使用し、M of Nのようなものを活用します。例えば、7回中5回、10回中8回など、問題を検出できるようにします。これは連続している必要はありません。また、内部でも推奨していますが、2つ以上のアラートレベルを設けています。1つは「何か問題があるかもしれないが、誰かを起こす必要はなさそう。自動システムが修正するかもしれない」というレベルです。そして、もう1つは「これはかなり深刻になっている。すぐに人が対応する必要がある」というより高いレベルです。これらが私たちにページを送るように設定しているものです。
この例では、5xxの下限しきい値を10%に設定し、10分中7回としています。これにより、頻度は低いものの長く続くエラーを捉えることができ、その時間帯が日中の人が対応できるかもしれません。そして、25%のしきい値では、より短い時間枠を設定していますが、それでも1つのデータポイントだけではありません。これは人々にページを送り、「エラー率が急激に上昇しています。今すぐ確認する必要があります 顧客に影響を与えている可能性があるため」と伝えるものです。オペレーターにアラートを送る際の対応方法を考える時、私たちは自動的な緩和策を好みます。しかし、重要なのは、アラートが実行可能であることです。メトリクスにアラートを設定してページを受け取った場合、「これは実行可能だったか」を判断する良い方法は、ランブックを見ることです。ランブックがない場合、本当に実行可能なのでしょうか？実行可能であれば、ランブックを作成する必要があるでしょう。しかし、対処できることが何もない場合は、人々にページを送るべきではありません。
私たちは、runbookを使って事前にすべてを計画します。新しいシステムを本番環境に導入したり、大きな変更を行う際には、運用準備レビューを実施します。その一環として、「どのようなアラームを設定し、どのような主要指標を監視するか」を確認し、それらが適切に設定されているかを確認します。また、「それらが機能しなくなった場合のrunbookは何か」も確認します。さらに、自動エスカレーションも行っています。エンジニアがページングを受けても進展がない場合、エスカレーションするよう訓練されていますが、チケットが解決されないか、解決に向けて進展していることを示すステータスに更新されない場合、システムが自動的にエスカレーションするよう設定しています。
もう一つの重要な要素はダッシュボードです。私たちは定期的に運用レビューを行っており、これはチームレベルで実施しています。毎週、各チームが運用レビューを行い、ダッシュボードを確認します。ダッシュボードはトピックごとにグループ化されており、「これはシステムのこの部分です。ここに関連するすべての指標があります」と確認し、「これがレベル1の問題として定義した線、これが次のレベルの問題として定義した線」という形で表示されています。そこで、アラートを受けていないものがあれば、「なぜアラートが来なかったのか」を掘り下げて調査します。アラームを見逃したのか、閾値が間違っていたのかもしれません。また、顧客への影響があったかどうかも確認します。
CloudWatch dashboardsを使用することができ、これは私たちがApplication Load Balancer用に作成したCloudWatch dashboardのスクリーンショットです。処理されたバイト数や、リクエストの総数など、ポジティブなワークロードの指標が表示されています。また、それらの時系列データも表示されています。さらに、2xx、3xx、4xx、5xxなどのレスポンスコードも表示されています。これは、私たちが確認するような内容で、「20分間5xxのスパイクがあったのに、アラームが鳴らなかった」というようなことを見つけることができます。そうしたら、そのアラームを確認し、なぜアラームが鳴らなかったのかを調べます。CloudWatch dashboardsは素晴らしいツールです。皆さんにも使用をお勧めします。私たちは社内でこれらを非常に気に入っており、常に活用しています。
セキュリティの多層防御アプローチ
デプロイメントについて話しましょう。十分な数の顧客がいる場合、ダウンタイムに適した時間はないということは皆さんもご存知だと思います。デプロイメントによってダウンタイムが発生することを想定することはできません。そのため、私たちはそのようなことはしません。変更を加える際には、スムーズなプロセスを心がけ、ダウンタイムを発生させないことを重視しています。特に意図的なダウンタイムを設けるのに適した時間というのは、実際にはありません。
私たちはブラストラディウスを採用しており、非常に小さなクラスター、おそらく1台のサーバーか小規模なサーバークラスターから始めます。そして、徐々に拡大していき、メトリクスのフィードバックループを緊密に監視します。ヘルスメトリクスとポジティブデータの両方が良好であることを確認します。処理量に変化がなく、何も落ちていないことを確認したいのです。ネガティブなメトリクスについては、大きなスパイクが発生していないことを確認します。
デプロイメントを拡大する際は、同じ日に同じリージョンの複数のAvailability Zoneにデプロイすることはありません。デプロイメントストライプを使用し、同じ日にus-east-1とus-east-2にデプロイするようなことはしません。デプロイメントのスピードが上がり、自信がつくにつれて、徐々にスケールアップしていきます。多くのリージョンとホストにデプロイする必要があるからです。厳格な変更管理を行っており、変更内容を計画し、作成したランブックに従って変更を実施します。
ほとんどの変更は自動化を重視し、Code Pipelineのようなツールを使ってデプロイします。これはすべてCI/CDで、継続的インテグレーションと完全自動化により、人間が各ステップを監視したり次のデプロイメントレベルをトリガーしたりする必要がありません。サービスを所有するチームが起きていて、警戒しており、デスクにいる可能性が高い時間帯にデプロイするように変更しました。これにより、迅速に対応し、必要に応じてより多くのエンジニアを巻き込むことができます。そのため、通常は月曜日から木曜日の午前9時から午後5時までの間にデプロイを行います。
ここで振り返ってみましょう。私たちは影響を予想してデプロイすることはありません。デプロイで間違いを犯し、影響を受けた可能性のある顧客と話をする際、よく聞かれる質問の1つは「次回デプロイする時は教えてください」というものです。私たちは「そのようなことはしていません」と答えます。デプロイメントが影響を与えないようにする必要があります。影響を与えるデプロイメントがあった場合は、Correction of Errorsドキュメントを作成します。これは、何が起こり、なぜ起こったのかを検証するイベント後のフォローアップドキュメントです。
また、ヘルスチェックなどの自動緩和策についても話しました。Auto Scaling groupsは「ターゲットが異常になったので、自動的に置き換えました。人間を巻き込む必要はありませんでした」と言えるので非常に優れています。人間を巻き込むべき場合について議論し、ランブックで計画を立て、理解しやすく推論しやすいものにする方法について説明しました。定期的に運用をレビューします。各チームは週に1回の定例会議を持ち、自分たちの運用ダッシュボードを確認します。これらは組織全体に伝わり、最終的にはすべてのサービスの主要な高レベルメトリクスをレビューします。
転送中の暗号化：TLS 1.3とFIPSサポート
以上で可用性に関する私のパートは終わりです。次はSathyaに引き継ぎ、セキュリティについて話してもらいます。ありがとうございました。はい、ありがとうJon。私はSathya Ramaseshanで、Elastic Load Balancingの製品リーダーを務めています。アジェンダを簡単に振り返ります。Jonが使用したものと非常によく似たフォーマットを使用します。セキュリティに関する実装の内部詳細について説明します。ここでの意図は、セキュリティにおける共通の課題を解決する際の私たちの思考プロセスを共有することです。その後、私たちがリリースした機能について説明します。これらは、セキュリティ要件を満たすために設定できる機能です。
凡例の要約はJonが言ったのと同じです。ここで強調したい2点は、内部の詳細を示すAWSユーザーアイコンと、機能を示すロケット打ち上げアイコンです。これらは該当するスライドに表示されます。それでは始めましょう。まず、AWSロードバランサーの主要な設計コンポーネントについてお話ししたいと思います。2つあります。1つはコントロールプレーンです。例えるなら、船長のようなものです。ここにはビジネスロジックが存在し、 APIを通じてオンボーディングされ、コントロールプレーンがそれを設定に変換してワーカーにプッシュダウンします。
ワーカー、つまり船のエンジンに当たるのが、データプレーンです。 データプレーンは、受信するすべてのトラフィックに対するすべてのビジネスロジックを処理する複数のコンピュートノードで構成されています。この比喩をまとめると、サービスは船のようなもので、Elastic Load Balancingに相当します。コントロールプレーンは船長、データプレーンはエンジンのようなものです。これらの用語を最初に説明したのは、この後の話で使用するためです。同じ認識を持っていただきたいと思います。
セキュリティに関しては、 ロードバランサーにおいて多層防御を考えることをお勧めします。これは、ネットワーク層のコントロールとアプリケーション層のコントロールの両方を持つ、層状のセキュリティアプローチです。ロードバランシングに関しては、5つの領域で考えることをお勧めします。
1つ目はIPベースのアクセス制御で、これは粒度の粗いネットワークレベルのアクセス制御です。2つ目は通信時の暗号化で、中間者攻撃を防ぎます。3つ目は信頼できる認証で、認証や認可などのより細かい粒度のアプリケーション層アクセス制御が含まれます。4つ目は設定の正確さです。セキュアなアーキテクチャを構築・実装した後でも、誤った設定によって脆弱性が生じる可能性があるため、これを事前に防ぐ必要があります。最後に、さらに高いセキュリティ態勢を実現するために、サードパーティのソリューションやカスタムソリューションを使用して防御を拡張することをお勧めします。
これらの各ポイントについて詳しく説明し、私たちが内部で行っていることや、設定可能な機能についてお話しします。まずはIPベースのアクセス制御から始めましょう。私たちのサービスは、多くのクラウドサービスと同様に、分散コンピューティングを基盤としており、リソースは複数のアベイラビリティーゾーンにある様々な物理サーバーから提供されます。セキュリティの観点からは、これは私たちのリソースが消費しているすべてのIPを完全に把握する必要があることを意味します。これを実現するために、コントロールプレーンとデータプレーンでセキュリティグループを使用しています。
セキュリティグループは、シンプルで簡単、そして直感的に設定できるため、私たちは非常に重宝しています。 また、Network Load Balancer (NLB) でのセキュリティグループが顧客からの最も要望の高い機能の一つだと聞いていたので、今年の8月に早々にこの機能をリリースしました。NLBにセキュリティグループを設定することで、信頼できる既知の承認済みIPアドレスからのトラフィックのみをロードバランサーが受け取るようにフィルタリングできます。これはIPv4とIPv6の両方のトラフィックに対応しています。
さらに、セキュリティグループの参照機能を有効にし、ターゲットグループがロードバランサーからのトラフィックのみを受け取るようにロックすることができるようになりました。これにより、アプリケーションへの不要なアクセスを防ぎ、潜在的な脆弱性の露出を防ぐことができます。Kubernetesユーザーの場合、AWS Load Balancer Controllerを使用してこれを設定できます。
次に、転送中の暗号化を使用したディフェンス・イン・デプスについて説明します。これは私たちが重点的に取り組んできた分野です。ロードバランサーはほとんどのAWSアプリケーションの玄関口であるため、この部分に特に注力してきました。玄関口で強力な暗号化を行うことで、その背後にあるすべてのものにその恩恵が及ぶと考えています。
この分野での私たちの取り組みは、実は数年前のTLS Heartbleed問題を皆さんと一緒に経験したときに始まりました。TLSのソフトウェア実装に起因するいくつかのアルゴリズムに欠陥があることがわかりました。耐久性のある解決策を求めて、私たちは独自のTLSライブラリを構築し、2015年にオープンソース化しました。このライブラリはs2nと呼ばれています。s2nは小さく、高速で、シンプルさを優先して設計されました。TLS Heartbleed問題の主な原因となったTLSの稀にしか使用されない暗号、オプション、拡張機能の一部を実装していません。
私たちはこのライブラリを継続的に検証し、高いセキュリティ態勢を維持していることを確認しています。ライブラリを深く所有していることで、遭遇した問題に迅速に対応することができます。 s2nを導入した後、今年の3月にApplication Load Balancer (ALB)でTLS 1.3をリリースしました。現在、ALBとNLBの両方がTLS 1.3をサポートしており、どちらもs2nを使用しています。
TLS 1.3には、TLS 1.2と比べて大きく分けて2つの利点があります。1つ目は、TLS 1.2に含まれていたセキュリティの低い暗号方式を除外することで、より強力な暗号化を提供することです。2つ目は、Perfect Forward Secrecyを必須としていることです。
もう1つの利点はパフォーマンスです。TLS 1.3では、TLSハンドシェイクを1ラウンドトリップで完了させることができるため、レイテンシーが低減され、結果としてパフォーマンスが向上します。Perfect Forward Secrecyは、長期的な秘密鍵が何らかの理由で漏洩した場合でも、セッション鍵が安全に保たれることを保証します。ロードバランサーでTLS 1.3を設定する際には、7つの事前定義されたセキュリティポリシーから選択することができます。
TLSに関連して、もう1つ私たちによく寄せられるリクエストはロードバランサーでFIPSを有効にすることでした。これを実現するために、まず独自の暗号化モジュールをFIPS向けに作成しました。このモジュールはAWS Libcrypto（AWS-LC）と呼ばれ、今年の4月に公開されました。これはオープンソースで、AWS Cryptographyが所有・管理しています。AWS LibcryptoはBoringSSLをフォークして作られましたが、さまざまなパフォーマンス向上が施されています。例えば、いくつかのアルゴリズムの速度を上げました。内部テストでは、このモジュールを使用することで、Amazon S3のハンドシェイクレイテンシーが27%減少したことが確認されています。最近、10月にNISTからFIPS 140-3認証を取得し、継続的な検証を計画しているので、このモジュールが提供する新機能や改良点を簡単に導入できるようになります。
AWS-LCの準備が整ったことで、先週ALBとNLBの両方でFIPSサポートを開始しました。これを実現するために、s2nとAWS-LCを統合しました。s2nはTLSハンドシェイク部分、つまりクライアントとロードバランサー間のメッセージ交換を処理し、AWS-LCは基盤となる暗号化を担当します。TLS 1.3と同様に、事前定義されたセキュリティポリシーを柔軟に使用でき、8つのオプションから選択できます。ここで最後に強調したいのは、FIPSを通じてエンドツーエンドのTLS接続も可能にしたことです。エンドツーエンド接続が必要な場合は、ターゲットへのTLSを設定でき、ロードバランサーとターゲット間の接続にAWS-LCモジュールを使用します。
Application Load Balancerでのmutual TLS実装
次のトピックに移りましょう。信頼性の高い認証についてです。先ほど、セキュリティグループをアーキテクチャにどのように実装しているかを説明した図をご覧いただきました。しかし、コントロールプレーンとデータプレーン内には、特定のノードを共有する複数のエージェントが存在します。必要なものだけにアクセスを与えるという精神に基づき、アーキテクチャ内にはエージェント間で相互TLSを確立する箇所があります。 相互TLSを使用して2つのエージェント間のトラフィックを暗号化し認証しており、これは私たちにとって非常に有用です。
ALBでのmutual TLSが顧客から強く求められていることも承知しています。そして嬉しいことに、先日Dave Brownのイノベーションセッションでこの機能をローンチしました。これにより、X.509証明書ベースのアイデンティティ認証を安全にロードバランサーにオフロードできるようになりました。サードパーティのCAとAWS Private CAの両方をサポートしています。サードパーティのCAサポートにより、既存のmutual TLS実装をALBに簡単に移行できます。失効のサポートも提供しており、必要に応じて侵害された証明書へのアクセスをブロックする堅牢な方法があります。また、ターゲットにプロキシされるリクエストに証明書のメタデータを提供し、これを使って認可ロジックを構築できます。最後に、新しい接続ログを導入し、必要に応じて接続のトラブルシューティングや監査に使用できるようになりました。
これはmutual TLSに関する「What's New」投稿のQRコードです。スマートフォンでアクセスしたい方のために、数秒間停止します。ここからmutual TLSについてさらに詳しく説明します。まずセットアップから始めましょう。ロードバランサーでmutual TLSを設定するには、まずtrust storeと呼ばれるリソースを作成する必要があります。これはロードバランサーに導入された新しいリソースです。2つのコンポーネントがあります。1つ目はCA証明書バンドルです。
これは基本的にルート証明書、または中間証明書とルート証明書、あるいは一連の中間証明書です。これをPEM形式でtrust storeにアップロードします。次に、失効リストを設定できます。この手順はオプションですが、失効機能をサポートするために、よく知られたCRL（Certificate Revocation List）形式を使用しています。次に、このtrust storeをALBリスナーにアタッチします。そして、verify modeでmutual TLSをオンにするだけです。
セットアップが完了すると、クライアント証明書を受け取ったとき、ALBは信頼チェーンをたどり、trust storeで設定されたルートに解決されることを確認します。失効チェックが有効になっている場合は、そのチェックを実行します。この時点ですべてがパスすれば、ユーザーは認証され、ユーザーとロードバランサー間にTLS暗号化された接続が確立されます。その後、証明書を解析し、HTTP headerの形で証明書メタデータを追加し、それをターゲットにプロキシします。
これらのヘッダーを見ると、最初の4つはsubject、issuer、serial number、validityです。ほとんどの顧客はこれらを使って認証ロジックを構築すると思いますが、カスタムフィールドが必要な場合は、リーフ証明書も含めているので、それを解析して認証ロジックを構築できます。次に、設定の正確性に移ります。先ほど述べたように、最も安全なアーキテクチャを構築し実装した後でも、設定ミスによって脆弱性が生じる可能性があります。そこで私たちが考えているのは、設定ミスを避けるために、可能な限り人間のアクセスをどのように制限するかということです。
設定ミスを防ぐためのIAMポリシーとセキュリティ条件キー
私たちが通常行っているのは、静的な認証情報のような、セキュリティ態勢を低下させる可能性のあるパターンを避け、代わりにIAMロールを使用することです。IAMロールは、デプロイメントステージやdev/testの環境に限定された一時的または短期的な認証情報を持っています。これにより、本番環境の認証情報を本番環境内に保持し、セキュアなリソースへの人間のアクセスを制限しています。とはいえ、私たちは皆複雑なサービスを運用しており、時にはロードバランサーやその他のリソースを設定するために、人間によるアクセスが必要になることがあります。そのため、エンジニアに過度の負担をかけずに、設定ミスを防ぐ方法を考えています。
その答えは、特定のアクションを実行するために一定の条件が満たされる必要があるガードレールを設けることです。これはIAMポリシーによく似ていますね。 実際、私たちは設定ミスを防ぐためにIAMポリシーを広範に使用しています。 私たち自身の経験と、設定ミスが大きな問題点であるというお客様からのフィードバックに基づいて、ロードバランサーのセキュリティを向上させるための5つの追加条件キーを導入することにしました。これが設定ミスの問題を解決する持続可能なソリューションだと考えています。
ここで一歩下がって考えてみると、これまで説明してきた機能はすべて、ロードバランサーが受け取る実際のトラフィックから保護するためのものでした。これは設定ミスを防ぐためのコントロールプレーン保護です。具体的には、すでに説明した2つの機能リリースに関連する、セキュアなIAMポリシーの条件キーのうち2つについて説明します。1つ目はセキュリティグループです。承認されたセキュリティグループの短いリストを含むIAMポリシーを作成できるようになりました。これにより、新しくプロビジョニングされるロードバランサーや変更される既存のロードバランサーが、これらのセキュリティグループの1つを使用することが保証されます。これらのセキュリティグループは、 中央のネットワーキングチームや監査・コンプライアンスチームから提供されることがあります。
このポリシーが設定されれば、ロードバランサーが信頼できる既知の承認されたIPからのトラフィックのみを受け取ることが確実になります。このポリシーでは、リソースとして*を使用していますが、特定のロードバランサーのARNを使用することもできます。これにより、同じアカウントで運用している複数のチームが、それぞれのセキュリティ要件を厳密に満たす方法でこれらのポリシーを使用できます。
次に説明したい機能は、TLSポリシーの条件キーです。これはセキュリティグループの機能と同様に動作します。基本的には、IAMポリシーでTLSセキュリティポリシーのリストを設定し、新しいロードバランサーや変更された既存のロードバランサーが、設定したポリシーを使用するようにできます。 この例では、私たちが持っているTLS 1.3ポリシーのいくつかを示しています。これを使用すれば、新しくプロビジョニングされるすべてのロードバランサーに常にTLS 1.3ポリシーが適用されることが保証されます。
この特定の機能を使って、創造的なことができます。 例えば、FIPS準拠の要件がある場合、名前に「FIPS」が含まれるTLSポリシーを指定するだけで、スピンアップされるすべてのロードバランサーがFIPS準拠であることが保証されます。さらに、変更するロードバランサーにもFIPSポリシーが適用されます。全体として、これらのIAMポリシーを対応するセキュリティ機能と組み合わせて使用することで、アーキテクチャ全体のセキュリティ態勢を向上させることを強くお勧めします。
次に、すべてを結びつける例としてアーキテクチャの例を説明します。インターネット上にクライアントがいるVPCがあるとしましょう。 VPCにインターネットゲートウェイを配置します。次に、パブリックサブネットをプロビジョニングします。ロードバランサーは常にパブリックサブネットに配置します。ここではApplication Load Balancer（ALB）を例として使用しています。 そして、ターゲットをプライベートサブネットに配置します。ALBにセキュリティグループを適用して、信頼できる既知のIPからのみアクセスできるようにします。また、ターゲットにもセキュリティグループを参照させ、 ALBからのトラフィックのみを受け取るようにターゲットをロックします。
ロードバランサーでTLSを有効にし、s2nを使用します。相互TLSは、クライアントを認証できる新機能です。 認証の分野では、OIDCベースのユーザー認証を行うためにAmazon Cognitoとの統合があります。これに興味がある方もいらっしゃるかもしれません。 もう一つのセキュリティ統合として、レイヤー7の保護を追加したい場合に使用できるAWS WAFとの統合があります。 設定ミスを防ぐためのIAMについて話しましたが、監査の分野では、AWS ConfigとAWS CloudTrailとの統合もあります。Configを使用して設定の変更をポーリングし、CloudTrailを使用して監査の観点からアカウントのアクティビティを確認できます。
最後のトピックに移りましょう。サードパーティソリューションを使用してディフェンスインデプスを拡張する方法です。前のスライドで、ALBとWAFの統合について紹介しました。これは非常に人気のある統合であり、私たちが好む方式でもあります。異なるサービスを挿入してセキュリティ態勢を拡張または改善できるからです。Gateway Load Balancerは、まさにこの目的のために構築されました。 サードパーティのアプライアンスを使用してセキュリティ態勢を拡張するためです。
Gateway Load Balancerによるサードパーティセキュリティアプライアンスの統合
背景は次のとおりです。数年前、多くのお客様から、既存のセキュリティアプライアンスを使用したいという要望がありました。これは、それらに精通していることや、既存の投資を維持したいという理由からでした。セキュリティアプライアンスとは、ファイアウォール、侵入検知システム、侵入防止システムなどを指します。私たちは、サードパーティのアプライアンスを簡単に展開でき、AWSで望むように拡張でき、AWS本来のサービスと同様の可用性を持つ、スケーラブルな統合方法を提供したいと考えました。
これを念頭に置いて、2020年にGateway Load Balancerを多数のパートナー統合とともにリリースしました。AWS内でも、AWS Network FirewallはGateway Load Balancerを基盤として使用しています。比較すると、ALBとNLBはその背後にあるアプリケーションと、それらに向けられたトラフィックのセキュリティを提供します。一方、Gateway Load Balancerは補完的なサービスで、サードパーティのセキュリティアプライアンスを使用してVPC全体のトラフィックのセキュリティを提供します。
時々、これをGWLBと呼ぶこともあります。GWLBはプロトコルに依存しないバンプインザワイヤのレイヤー3ゲートウェイであり、レイヤー4ロードバランサーです。ルートテーブルでネクストホップを設定するため、レイヤー3ゲートウェイとなります。
Gateway Load Balancer（GWLB）は、ターゲットのヘルスチェックに加えて、接続レベルのロードバランシングを行うレイヤー4ロードバランサーです。バンプインザワイヤの実装には、カプセル化と脱カプセル化にGeneveを使用しています。GWLBは水平スケーリングと耐障害性を提供し、アプライアンスの高可用性を維持します。VPCやアカウントをまたいで動作する能力があり、優れたアーキテクチャの柔軟性を提供します。さらに、パートナーがアプライアンスをAMIではなくサービスとして提供することを可能にし、個々のAMIのメンテナンス、アップグレード、スケーリングの必要性を排除します。
GWLBは2つのモードで使用できます。1つ目はワンアームモードです。 このモードでは、ソースからのトラフィックはGateway Load Balancerエンドポイントに行き、そしてGateway Load Balancerに向かいます。このパターンは、トラフィックがエンドポイントからロードバランサーに流れる現在のPrivateLinkと同じです。その後、トラフィックはターゲットにロードバランスされます。戻りのパスは同じルートを逆順にたどります。ターゲットに向かうトラフィックが単一のインターフェースを使用するため、これをワンアームモードと呼びます。Gateway Load Balancerが双方向のトラフィックを見ることができ、ステートフルな検査を行えるため、これが推奨される構成です。また、実装も比較的簡単です。
2つ目はツーアームモードです。この構成では、ソースからのトラフィックはエンドポイントに行き、ロードバランサーに向かい、ターゲットにロードバランスされた後、異なるインターフェースを通じてアプライアンスを出て目的地に到達します。Eth 0から入り、Eth 1から出ます。この構成はより複雑ですが、より高い柔軟性を提供します。主な利点は5タプルを変更できることです。ターゲットでNATなどの操作を行いたい場合、それが可能です。ただし、トラフィックがGateway Load Balancerに戻るとき、アプライアンスは5タプルをGateway Load Balancerが最初に観察したものに戻す必要があることを忘れないでください。
ユースケースの観点から見ると、主要なユースケースはイントラネット検査です。このシナリオでは、トラフィックはInternet Gateway (IGW)を通ってエンドポイントに到達します。そこからGateway Load Balancerに転送され、アプライアンスで検査されます。トラフィックが戻る際は、エンドポイントに戻り、その後目的地に向かいます。 もう一つの人気のあるユースケースまたはトポロジーは、Gateway Load BalancerをTransit Gateway (TGW)と組み合わせることです。この設定により、インターネットとVPC間の両方の検査が可能になります。インターネット検査の場合、トラフィックはVPC 4を通過し、上部のGateway Load Balancerとアプライアンスのペアに向かいます。アプライアンスを設定して、よく知られたインターネットの脅威から保護することができます。下部の設定はEast-West検査を処理し、East-Westトラフィックの検査ニーズに合わせて異なる設定を行うことができます。
Gateway Load BalancerがVPCやアカウントをまたいで機能する能力により、複数のVPCで使用できる中央アプライアンスVPCの作成が可能になります。これは重要な利点であり、一般的なアーキテクチャパターンです。ローンチ以来、私たちはこれらのVPC間およびインターネットのユースケースに焦点を当ててきました。しかし、より多くの顧客がGateway Load Balancerを採用するにつれて、特にハイブリッド展開において、オンプレミス環境からのトラフィックをクラウドネイティブな方法で検査したいというフィードバックを受けました。
この需要に対応するため、今年の初めに、Gateway Load Balancerと仮想ゲートウェイの統合をローンチしました。 これは2つのユースケースをサポートしています。1つ目は、VPNを通過するトラフィックで、オンプレミストラフィックがIPSecで暗号化されたインターネット接続を使用するケースです。Virtual Private Gateway (VGW)に到達し、Gateway Load Balancerエンドポイントに転送され、その後ロードバランサーを経て、最終的にアプライアンスターゲットに到達します。 2つ目のユースケースはDirect Connectと統合します。プライベート接続が必要な場合、オンプレミス環境とAWS環境の間でDirect Connectを使用できます。このシナリオでは、オンプレミスからのトラフィックがDirect Connectゲートウェイを通過し、VGWを経て、最終的にアプライアンスターゲットに到達します。
先ほど述べたように、Gateway Load Balancerはパートナー重視の製品です。Palo Alto NetworksやFortinetの高度なセキュリティソリューション、NetScoutの分析機能、Terraformのようなオーケストレーションツールなど、いくつかのパートナー統合があります。これらの統合はすべてAWS Marketplaceで利用可能です。以上で、このプレゼンテーションを終了します。ご参加いただき、ありがとうございました。 皆様のフィードバックを大変重視しておりますので、お時間がある際に、このセッションのアンケートにご回答いただければ幸いです。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion