Global AcceleratorのALBはInternalがおすすめ!

はじめに

こんにちは。インフラ担当の平田です。

先日案件で初めてGlobal Accelerator + ALBの構築を行いました。 Global AcceleratorにALBを紐づける際の構成で学んだことをまとめたいと思います。

AWS Global Acceleratorとは

AWS Global Acceleratorは、AWSグローバルネットワークを使用して、アプリケーションのネットワークパフォーマンスを最適化させるサービスです。 世界中のユーザーがアクセスするインターネットアプリケーションに対して、最適なルートでトラフィックを誘導し、遅延を低減します。 クライアントに最も近いリージョンのエンドポイントへトラフィックを自動的に振り分け、また静的なIPアドレスを提供します。 これにより、アプリケーションのグローバルな可用性が向上し、ユーザー体験が改善されます。

CloudFrontとは違うん?と思われるかもしれませんが、下記記事が勉強になりましたので紹介せさせていただきます。

tech.nri-net.com

詳細についてはここでは触れませんが、要約すると次の3つがポイントです。

  • CloudFrontはキャッシュを使い、できるだけ近くからコンテンツを返すことで通信する距離自体を最小化するため一番効果を発揮するのは、画像などキャッシュ可能な静的コンテンツ
  • Global Acceleratorはあくまでオリジンに必ずアクセスさせる必要があるという前提で、その通信経路の最適化によるレイテンシーを小さくするサービスのため、動的なサイトなどに効果的
  • CloudFrontの対応プロトコルがHTTP/Sなのに対して、Global AcceleratorはTCP/UDPと対応プロトコルが広くなっている

次のサイトではGlobal Acceleratorを利用する場合と通常のアクセスのレスポンスタイムをリージョンごとにシュミレーションすることが可能です。

試しにやってみた結果です。

Global Accelerator通信テスト

北部バージニア(us-east-1)リージョンを参考に見ると、通常の通信では1822msなのに対し、Global Acceleratorを利用すると381msです。 通信速度が大幅に削減されていることがわかります。Global Acceleratorすごい!

ということで、構築していきました。

先に結論

これから構築する上でつまずいた箇所などを紹介しようと思うのですが、いちいち読んでられない方のために先に結論です。

最終的な構成

ポイントは3つです。

  • ALBはInternalとし、Private Subnetに設置する
  • ALBのセキュリティグループにはGlobal Acceleratorからのみ通信を許可する
  • EC2などのサーバーはALBからのみ通信を許可する

Global Accelerator + ALBの構築を行う場合、ALBはInternalで構築します。 また、ALBのセキュリティグループにはGlobal Acceleratorからの通信を許可してあげる必要があります。 Global Acceleratorを構築すると、自動的に「Global Accelerator」という名称でセキュリティグループが作成されます。 ALBのセキュリティグループでは、Global Acceleratorのセキュリティーグループからの通信を許可するインバウンドルールを作成します。

セキュリティグループの許可

道のり

では最終的な構成に行き着くまでの過程をお伝えします。

ALBにパブリックアクセスできてしまう問題

構築にあたり特に何も考えていなかった私は図のように、Publiuc Subnetに外部ALBを用いて構築していました。

当初の構成

この構成でも問題なく、通信することは可能です。 しかし、このままだとALBに直接アクセスできてしまうことに気づきました。

外部からALBにアクセスできる

外部ALBはPublic Subnetに配置いることに加え、ALBのセキュリティグループでは全ての通信を許可するインバウンドルールを設定していたからです。 この段階で、ALBのセキュリティグループにGlobal Acceleratorからのみの通信を許可するインバウンドルールを設定することで、セキュリティは向上します。

しかし、Global AcceleratorはALBをInternalとしてに置くことができます。

AWS Global Accelerator で Network Load Balancer、内部 Application Load Balancer、または Amazon EC2 インスタンスエンドポイントを追加すると、プライベートサブネットをターゲットにすることで、インターネットトラフィックが Virtual Private Cloud (VPC) のエンドポイントとの間で直接やり取りできるようになります。ロードバランサーまたは EC2 インスタンスを含む VPC には、VPC がインターネットトラフィックを受け入れることを示すために、インターネットゲートウェイが接続されている必要があります。ただし、ロードバランサーまたは EC2 インスタンスにパブリック IP アドレスは必要ありません。また、サブネットに関連付けられたインターネットゲートウェイルートも必要ありません。(Google翻訳)

また、AWS Summitのセッションで次のような話がありました。

AGA(Global Accelerator)はVPC内にあるプライベートサブネットのALBやEC2インスタンスに対して直接接続することができます。 インターネットを使うというのはサービス を提供する側から考えると様々なエンドユーザーからアクセスされる可能性があり、例えば悪意のあるクライアントからのアクセスも含まれます。 直接接続できる面を減らすということは 大きな意味を持ちます。

AWS Summitより引用

オリジンを隠匿する意味でも、ALBはInternalとし、Private Subnetに置くべきと考えます。

ALBをInternalにしたときのセキュリティグループのインバウンドルールはどうする問題

ALBをInternalにすることでオリジンの隠匿には成功しましたが1つ問題がありました。 セキュリティグループにインバウンドルールを追加するのですが、何をソースとするかということでした。 これはGlobal Acceleratorのセキュリティグループからのアクセスを許可しました。 最初にも説明しましたが、Global Acceleratorを作成すると、自動的に「Global Accelerator」という名前でセキュリティグループが生成されます。 このセキュリティグループからの通信のみ許可するインバウンドルールをALBのセキュリティグループに作成しました。

セキュリティグループの許可

改めて完成系です。

最終的な構成

おわりに

いつもはCloudFrontのオリジンとして、ALBを設定したことしかなかった私にとってとても勉強になりました。

Global Accelerator + ALBを構築するにあたっては次の2点を意識しましょう。

  • オリジンを隠匿するためALBはInternalで構築し、Private Subnetに設置する
  • ALBのセキュリティグループにはGlobal Acceleratorのセキュリティグループからのインバウンドルールを作成する

今後も学習を深めながら、AWSにおけるベストプラクティスを追求し、最適な構成を目指していきたいと思います。