Amazon Web Services ブログ

AWS PrivateLink による企業間プライベートネットワーク接続の例

こんにちわ。ソリューションアーキテクトの齋藤です。
本稿では、AWS PrivateLink による企業間プライベートネットワーク接続の例についてご紹介します。

AWSは、グローバルでは数百万、日本でも数十万のお客様にご利用いただいているクラウドサービスであり、昨今、企業でAWSクラウドの環境を持っている場合が多く、企業間のプライベートネットワーク接続を AWS 上で構築するケースも増えてきました。その際、オンプレミスで構築するような専用線を敷設し、双方でルーター、ファイアウォール設置して DMZ を構築するような手法をそのまま踏襲するのではなく、AWS のサービスに置き換えて設計する必要があります。
まず、企業間のプライベートネットワーク接続の際に考慮となるポイントはどんなものがあるでしょうか。以下のオンプレミスにおける接続例を見てみましょう。

onpremiss図1: オンプレミスにおける企業間プライベートネットワーク接続の構成例

上図は、企業 A と企業 B のデータセンター同士を専用線でプライベート接続している例です。企業Aから企業Bに対し、HTTP/HTTPS 通信、SFTP 通信を行う要件があります。前提条件・構成は、企業によって異なりますが、例として以下のように設定してみました。

  • 前提条件
    • 企業 A は、企業 B の提供する HTTP/HTTPS サービス、SFTP サーバーにインターネットを介さず、プライベートネットワーク経由でアクセスすること
    • Inbound 通信は、必要な通信のみを許可すること
    • 双方のプライベートネットワークアドレス帯の重複を考慮し、お互い合意をとった CIDR を DMZ に割り当て、NAT変換を行うこと
  • 構成
    • DMZ に配置した Firewall アプライアンスで、アドレス変換( NAT )とアクセスコントロールを設定
    • DMZ に配置ルーター同士で DMZ の CIDR のみを経路交換
    • DMZ 内のコンポーネントは冗長性を持ち、ここでは 専用線、Firewallアプライアンス、ルーターがそれぞれ冗長構成

このような前提条件・構成を AWS でどのように実現できるのか見て行きましょう。

AWS における企業間接続

AWS で前述のようなオンプレミスで実施している企業間接続を実現したい場合、重要なことは、 DMZ を作って、Firewall で NAT とアクセスコントロールを導入することではありません。連携したい企業とのネットワーク接続要件を最小限のアクセスでセキュアに実現することです。
AWS では、AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間の全てのトラフィックを AWS のネットワーク内に維持しながら、AWS 内にホストされているサービスに対するプライベート接続を提供することができます。サービス利用者側の VPC 内にあるかのようにサービス提供側の VPC 内のサービスにプライベートに接続するために使用できる、可用性が高くスケーラブルなテクノロジーです。Internet Gateway、NAT Gateway、VPC Peering、VPN 接続等も不要であるため、サービス提供側はリソースを外部ネットワークに公開するリスクを低減することができます。セキュリティグループ等で、アクセス制御することも可能です。

以下の図は、AWS PrivateLink を用いて、異なる AWS アカウントの VPC 間で、AWS リソースへのネットワークアクセスを提供している構成例です。ここでは、企業 B のホストするHTTP(S) サービス、SFTP サービスを企業 A にプライベート接続で提供しています。サービス利用者側(企業 A )は、Direct Connect Gateway, Transit Gateway で接続されたオンプレミス環境と AWS 環境を持っており、アクセス元となるクライアントは、オンプレミスのネットワーク、VPC に存在することを想定しています。

privatelink-overview

図2: AWS PrivateLink を用いた企業間プライベートネットワーク接続の構成例

サービス利用者側（企業A：Consumer）、サービス提供者側（企業B：Service Provider）それぞれの構成を解説していきます。

サービス提供者側（企業 B：Service Provider）

サービス提供側である企業 B は、Application Load Balancer でホストされるHTTP(S) サービスと Amazon EC2 でホストする SFTP サービスを企業 A に提供をしたいです。この 2 つのサービスに対するプライベートアクセスを AWS PrivateLink を介して提供するためには、Network Load Balancer (NLB) を構築し、NLB と関連づく AWS PrivateLink endpoint を作成、サービス利用者へアクセス権限を付与することで、別の AWS アカウントからのプライベートアクセスを実現します。NLB はレイヤー 4 で動作するロードバランサーで、Private Link endpoint 作成するために必要となるコンポーネントです。NLB は、HTTP/HTTPS(tcp/80,443) に対する接続リクエストを Application Load Balancer でホストされるHTTP(S) サービス、SFTP(tcp/22) に対する接続リクエストを、Amazon EC2 でホストする SFTP サービスにルーティングします。また、アクセスコントロールは、AWS PrivateLink におけるプリンシパルに対する許可設定、NLB に紐づくセキュリティグループで行います。

サービス利用者側（企業 A：Consumer）

サービス利用側は、企業 B から提供を受けた AWS PrivateLink のエンドポイントサービスから自社 AWS アカウントの VPC 内に VPC エンドポイントを作成することで対象のサービスへのプライベートアクセスができるようになります。作成した VPC エンドポイントに紐づくセキュリティグループでアクセスコントロールを行います。

このように、AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間で必要な通信のみを許可するプライベートアクセスを実現することができます。また、お互いの VPC の CIDR 割り当てに依存しないため、IP の重複を考慮する必要もなく、DMZ を新たに構築する必要もありません。ここでは、企業 A から企業 B へのアクセス方向の例を挙げましたが、逆向きの場合は、同様のことを企業 A と B で入れ替えて実施することで、双方向にサービスの提供を行うことができます。

手順・構成方法

ここからは、具体的な手順の例として、以下の図のような ALB でホストされる HTTP サービス、Amazon EC2 でホストする SFTP サービスを、AWS PrivateLink で、別の AWS アカウントの VPC に提供する方法を紹介します。

sample-architecture-procedure

AWS Account B (Service Provider) NLB の設定

ここでは、NLB の構築方法については省略しますが、以下のように、TCP/80 は ALB の属するターゲットグループ、TCP/22 は SFTP サーバーの属するターゲットグループにルーティングするリスナー設定を持つ NLB があり、これを別の AWS アカウントの VPC に AWS PrivateLink でプライベート接続を提供していきます。

NLB で使用するセキュリティグループでは以下のように、AWS Account A(Consumer) 側のアクセス元となるサーバーの CIDR を指定してアクセス許可を行います。

AWS Account B(Service Provider) PrivateLink Endpoint の作成

次に、PrivateLink Endpoint の作成を行います。AWS マネジメントコンソールの VPC のメニューのエンドポイントサービスから、エンドポイントサービスを作成を選択すると以下のような画面となりますので、対象の NLB を選択します。

作成を行うと、以下のように、エンドポイントサービスが作成されます。「サービス名」が提供先で必要な情報となります。また、NLB の存在するアベイラビリティゾーンがリストされていますが、提供先で作成する VPC エンドポイントも同じアベリラビリティゾーン ID である必要があるため、合わせて伝える必要があります。

次に「プリンシパルを許可」のタブを開き、提供先となる AWS アカウントからの利用を許可します。

ここでは、AWS アカウント A の ID を指定するため、プリンシパルで arn:aws:iam::[AWS Account ID]:root のように記述します。事前に提供先の AWS アカウント ID は確認しておきましょう。

これで AWS アカウント B 側でのPrivate Link の作成は完了です。

AWS Account A(Consumer) VPC endpoint の作成

次に、AWS Account A 側での作業を行います。
AWS マネジメントコンソールの VPC のメニューから エンドポイント＞エンドポイントの作成を行います。
サービスカテゴリは、「その他のエンドポイントサービス」を選択し、サービス名で、AWS アカウント B 側で作成したエンドポイントサービスのサービス名を入力し、サービスの検証を行います。検証が成功すれば、そのまま設定を進めていきます。

エンドポイントを作成する VPC を選択すると、作成可能なアベイラビリティゾーンとサブネットが選択可能になります。ここで選択可能なアベイラビリティゾーンは、サービス提供側の NLB の存在するアベイラビリティゾーンであるため、エンドポイントを作成するサブネットのアベイラビリティゾーンは事前に確認しておきましょう。

エンドポイントに対し、セキュリティグループを設定しますので、事前に必要な通信を許可するセキュリティグループを作成しておきましょう。

 

AWS Account B(Service Provider) PrivateLink の承諾

承認設定で、特定のプリンシパルに許可を付与して自動的にすべての接続リクエストを承諾するか、手動で承諾するかエンドポイントサービスにアクセスできる AWS プリンシパルを制御できます。ここではデフォルトのままなので、手動で承諾します。

AWS Account A 側で、VPC エンドポイントを作成すると状態が承諾待ちになります。以下のように、AWS Account B 側でエンドポイントリクエストの承諾を完了することで、利用可能な状態となります。

AWS Account B 側

 

AWS Account A 側

 

AWS Account A(Consumer) 動作確認

それでは、AWS Account A にあるクライアントである EC2 インスタンスからアクセス確認をしてみます。アクセス先は VPC エンドポイントの DNS 名に対して行います。

HTTP リクエスト

[ssm-user@ip-10-2-11-30 ~]$ curl http://vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com
ip-10-1-22-193.ec2.internal (レスポンス結果)

SFTP アクセス

[ssm-user@ip-10-2-11-30 ~]$ sftp sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com
sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com's password:
Connected to vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com.
sftp>

AWS Account A の VPC 内にある EC2 インスタンスから、VPC 内のアドレスを持つ VPC エンドポイントを経由して、AWS Account B のVPC 内でホスティングされているサービスにアクセスをすることができました。

まとめ

本稿では、AWS PrivateLink を利用した 企業間プライベートネットワーク接続の例をご紹介しました。AWS PrivateLink を用いることで、必要最小限のアクセス許可で、お互いの VPC の CIDR の重複を考慮することなく、企業間プライベートネットワーク接続を構築することが可能です。
オンプレミス同士の接続を AWS クラウド同士の接続に移行をご検討されている際には、AWS Well-Architected Framework において、「最小特権の原則に則った設計の一部として、可能な限り、ネットワークピアリングよりもポイントツーポイントフローを優先します。」と記述がある通り、AWS PrivateLink をまずご検討いただくことをお勧めします。

本稿が、AWSにおける企業間プライベートネットワーク接続をご検討されている方のお役に立てば幸いです。