プライベート ALB を外部から接続させるやり方例と注意ポイント
背景
普段はお客さんの拠点から Site to Site VPN 経由で接続して利用している ALB を
わけあって外部(インターネット)からも接続できるようにしてほしいという要望があった。
社内で対処方法の議論を行ったのでメモとして残すことにした。
前提
今回扱う構成は元々以下のような構成であった。
基本的にはお客さんの拠点を起点に VPN 網を通じて
AWS 環境にアクセスし、プライベートALB にアクセスすることで、業務で使用する
Webアプリケーションを利用する。
やり方その1 NLB追加
概要
ALB の前段にパブリックサブネットに配置した NLB を置くことで構成されている。
検索するとよく出てくるやり方であり、NLB を配置することにより固定のグローバルIP を通じたプライベートALB へのアクセスが可能になる。アクセス制限を行いたい場合は NLB にセキュリティグループで設定を加える。
注意点
ALBにアクセスする際のドメイン
アクセスする際はグローバルIP を宛先にアクセスすることになるため、これまでプライベートDNS のみで運用していた場合は、パブリックドメインの購入が必要になる。
固定IP(Elastic IP)の費用が増える
NLB に対して固定グローバルIP を付与するため、その分 Elastic IP の費用が増える。
マルチAZで可用性を高める場合、AZ数分の EIP を利用する必要がある。
NLB で単一の EIP を代表で使えないかといった質問については以下の rePost が参考になる。
やり方その2 Client VPN 導入
概要
Client VPN を使用して、外にいるクライアントからVPN接続でプライベートALBにアクセスさせる。インターネットからアクセスさせることを考えた際に、接続人数や規模感が少ない場合はこちらの構成も候補として挙げられる。
注意点
ALBにアクセスする際のドメイン
アクセスする際はプライベート環境でのアクセスになるため、これまでのプライベートドメインでのALBアクセスが可能である。
後述するが、Client VPN での参照先 DNSサーバーの設定の方が大事。
接続人数が増えると大変
今後接続する人数が増えるとなると、その分クライアント証明書の用意など運用の手間が増える。接続人数が少なく、会社のリモートワーク用端末から接続したいといった状況に利用することを考えた方が良い。
導入コスト
Client VPN 導入においては以下のポイントがよくある止まりポイントだと考える。
- Client VPN で使用するためのプライベートサブネットの選定
- CIDR範囲の制限(ブロックサイズが /22 以上、/12 以下)
- 認証認可周り
- クライアント証明書の運用管理
- AD認証するのか
- 多要素認証使うのか
- DNSサーバの指定
- クライアントの自宅ルーター指定のDNSで良いのか
- VPC or オンプレのDNS を参照させたいのか
- インターネット接続のルーティング
- 社内プロキシ経由させるのか
- VPC 上のインターネットゲートウェイ経由にさせたいか
- クライアント端末上のインターネット経由でも良いのか
以下の記事が Client VPN 構築時の注意点としてまとまっている。
やり方その3 CloudFront VPC Origin 導入
概要
2024/11のアップデートによる機能である「VPC Origin」機能を使用した構成である。
やり方その1 で紹介した NLB と流れが似ており、NLB の部分が CloudFront に置き換わったイメージである。この構成のメリットは固定のグローバルIP 費用が抑えられる点である。プライベートALB への変更は無く、前段に CloudFront を用意するだけで構成できる。
注意点
ALBにアクセスする際のドメイン
アクセスする際は CloudFront のドメインを宛先にアクセスすることになる。このドメインを直接指定することでアクセスするならば、ドメインを新規購入する必要は無い。しかし独自のドメインでアクセスしたい場合は、パブリックドメインの購入が必要になる。
独自のパブリックドメインの設定は、エイリアスレコードの登録をすることになる。
「独自パブリックドメイン」→「CloudFront のドメイン」
参考記事として以下の記事にて、同様の設定を行っている。
インターネットゲートウェイ必須
プライベートサブネットへのルーティングには使用しないが、CloudFront からアクセスされる関係上インターネットゲートウェイが必要になる。
閉域環境でもウイルス対策製品 SaaS を利用したり、Windows Update のためにインターネットゲートウェイを置いていることはあると思うので、あまり大きな問題にはなりにくい。
プライベートサブネットにプライベートIPアドレスの空き枠が必要
VPC Origin の仕組みは、パブリックサービスである CloudFront が、プライベートサブネット上に ENI(Elastic Network Interface)を作成しプライベートIPアドレスを使用する。
このプライベートIP アドレスを通じて、プライベートALBと通信している。
そのためENI 用でプライベートIP アドレスの空き枠が必要になる。
参考 : VPC Origin の前提条件
アクセス制限(グローバルIP制限)
この構成では、プライベートALBのセキュリティグループで CloudFront からの通信のみを許可する設定になる。次に CloudFront でアクセス制限をつけることになるが、CloudFront は CDN サービスであるため、独自にセキュリティグループをつけることはできない。
そこで、IP制限を挟みたいならば AWS WAF を使用することになる。以下の記事で同様のことを実施している。
また、CloudFront Functions を使ったやり方もある。
以下の記事を参考。
CloudFront での IP制限については以下の記事が全体的に参考になる。
やり方その4 AWS Global Accelerator 導入
概要
AWS Global Accelerator を配置し、固定で割り当てられる 2つの固定IP をプライベートALB に紐づけることでプライベートALB への外部アクセスを実現する。
AWS Global Accelerator は AWSグローバルネットワークを使用して、アプリケーションのネットワークパフォーマンスを最適化させるサービスである。例えば、世界中のユーザーがアクセスするインターネットアプリケーションに対して、最適なルートでトラフィックを誘導し、遅延を低減することができる。CloudFront と似ているが、目的が異なる。CloudFront はキャッシュサーバの役割があり、静的コンテンツのキャッシュが強い。一方で AWS Global Accelerrator はそもそものオリジンへ、遅延を少なく最適な経路でアクセスさせるというのが目的なので静的コンテンツだけでなく動的コンテンツ、そのほかWebサイト以外のサービスにも使える。
以下の記事が AWS Global Accelerator と CloudFront の違いについての解説が参考になる。
注意点
ALBにアクセスする際のドメイン
CloudFront と同じような形になる。アクセスする際は Global Accelerator のドメインを宛先にアクセスすることになる。このドメインを直接指定することでアクセスするならば、ドメインを新規購入する必要は無い。しかし独自のドメインでアクセスしたい場合は、パブリックドメインの購入が必要になる。
独自のパブリックドメインの設定は、エイリアスレコードの登録をすることになる。
「独自パブリックドメイン」→「Global Accelerator のドメイン」
参考記事として以下の記事にて、同様の設定を行っている。
アクセス制限(グローバルIP制限)
この構成も CloudFront の時と同様な形式をとる。
そこで、IP制限を挟みたいならば AWS WAF を使用することになる。以下の記事が参考になる。
まとめ
今回は 3つの例を紹介したが、いずれも得意不得意があるため、要件によって使い分ける必要がある。
特に今回のような接続方式を変える場合、アクセス時の名前解決の方式が一番注意するべきだと感じた。
個人的には、やり方3 で紹介した VPC Origin はコスパが良いのではないかと考えている。
CDN なので本来のキャッシュサーバの使い方としては異なっているが、今回のような外からプライベートリソースへアクセスできるといった観点での使用というのは発想としては面白いと感じる。
Discussion