AWS PrivateLinkをメンテナンスラインとして使う #reinvent

AWS re:Invent 2017

#AWS

大瀧隆太

2017.12.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
AWSの年次イベントre:Invent 2017で発表されたPrivateLink for Customer and Partner Serviceは異なるAWSアカウントやVPCにプライベート接続を提供する新しい機能です。PrivateLinkの設定手順は以下のブログ記事を参照ください。

ユースケースとしては、SaaSを提供するマルチテナント構成やCIDRが重複するVPCでの通信などがありますが、今回はSSHやRDPなどEC2のメンテナンスラインとしてPrivateLinkを使う用途についてあーだこーだと語ってみたいと思います。

メンテナンスラインとしてPrivateLinkを使うメリット

最も大きなメリットは、異なるVPC間でCIDRの重複を許容できる点でしょう。例えば、複数のユーザーのAWS環境を一括で運用するようなマルチテナントを構成したいとき、従来インターネットを介さないプライベートなVPC間接続を実現するためにVPCピア接続を利用していました。

VPCピア接続では、ユーザーのVPCと運用サーバーを置くVPCでCIDRの調整が必要で、ユーザーによてCIDRの切り方は様々ですし、Direct Connectなどでオンプレミスのネットワークと繋がっているとCIDRの調整は難しいことが多いです。PrivateLinkであれば、運用サーバーを置くVPCのCIDRの調整が不要になり設計工数が削減できますし、従来調整できなかった構成でも運用が可能になります。また、VPCピア接続はその名の通りVPCを相互接続するための機能なので、メンテナンス用途ではユーザーのVPC→運用サーバーのVPC方向の通信が不要で、かつセキュリティ面で懸念になることが多いです。PrivateLinkは通信の方向は片方向に限定できるため、メンテナンス用途に向いていると見ることもできます。

メンテナンスラインとしてのPrivateLinkの設計

まずはPrivateLinkの仕様を確認し、メンテナンスラインの設計パターンを挙げてみます。PrivateLinkはAWS ELB(ロードバランササービス)のひとつであるNetwork Load Balancer(NLB)へのエンドポイントとして動作するため、NLBが必須でありその要件を満たす必要があります。

NLBはL4ロードバランサとしてTCPの特定のポートをListenし、受信するトラフィックをターゲットグループと呼ばれるインスタンス(ないしIPアドレス)のグループに転送します。また、ロードバランササービスですので、受信トラフィックはアルゴリズムに基づいてグループ内で分散されます。一度転送したトラフィックはセッションが切れない限り維持されますが、ELBのアイドルタイムアウトが350秒なので、SSHの場合はKeepAliveなどの対応が有効かもしれません。

SSHやRDPで特定のインスタンスに接続する用途の場合、負荷分散は不要なのでターゲットグループには1インスタンスないし1IPのみ登録します。複数のターゲットグループを1つのNLBで扱う ^*1ためにはそれぞれリスナーポートを用意する必要があるため、接続させるインスタンスの数だけターゲットグループとNLBのリスナーを作成します。以下のようなイメージです。

NLBが設定できれば、PrivateLinkはポート番号そのまま、NLBにトラフィックを転送するだけなので設計に際しての考慮事項はほとんどありません。運用VPCのインスタンスからは、例えばVPCエンドポイントの8022番ポートにSSH接続するとNLBを経由してグループ1のインスタンスの22番ポート、8023番ポートではグループ2のインスタンスの22番ポートに転送されます。

$ ssh -p 8022 ec2-user@vpce-1234567890abcde-12345678.vpce-svc-xxxxxxxxxxxxxxx.us-east-1.vpce.amazonaws.com
Last login: Sat Dec  9 00:15:15 2017 from 172.31.25.250

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
No packages needed for security; 1 packages available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-31-31-84 ~]$

RDPでもポート番号が異なるだけで、設定の考え方は共通です。ポート番号でインスタンスを区別することになるので、SSHであればssh_configファイルなどでポート番号ごとにエイリアスを設定すると実用的になると思います。

セキュリティの注意点

NLBにはセキュリティグループが設定できないため、ターゲットグループのEC2のセキュリティグループでリモートアクセスの制限を行うことになります。NLBから転送されるトラフィックのソースIPにはいくつかパターンがあるため、それらを意識してセキュリティグループを設定する必要があります。以下のブログ記事が詳しいです。

AWS Network Load Balancer(NLB)のソースIPとターゲットのセキュリティグループ留意点まとめ｜ Developers.IO

ターゲットグループがインスタンスタイプの場合はPrivateLink経由のトラフィックはソースIPがNLBのIPアドレス、それ以外(VPC内およびDirect Connect経由のオンプレミスからNLBを経由する場合)はソースIPがクライアントのIPアドレスになりますので、NLBのIPアドレスのSSHやRDP接続を許可し、その他のアドレスは必要に応じて追加すれば良いでしょう。

一方でターゲットグループがIPタイプの場合は、NLBを経由するトラフィックのソースIPが全てNLBのIPアドレスになるため、PrivateLink経由とNLBに直接アクセスする場合で区別ができない点に注意しましょう。