プライベートネットワーク経由でAWS S3にアクセスする7つのアーキテクチャの紹介

340件のシェア(そこそこ話題の記事)

はじめに

おはようございます、加藤です。AWS S3を利用したいが、セキュリティポリシーや送信元のハードウェア・ソフトウェアの都合でパブリックネットワークを使用できない・使用すると脆弱な場合にはプライベートネットワーク経由でS3にアクセスする必要があります。
今回は、この要件を実現する7つの方法をご紹介します。(現時点で私が思いつく全ての方法ですが、他にもあればコメントを頂けると嬉しいです)

社内からアドバイスを貰い、+2つの方法が追加されました。 また、Client VPNはENIを生成するという性質上、DX・Site-to-Site VPNとは大きく挙動が異なる為、全ての方法にClient VPNの接続経路を載せるのを辞めました。

注意事項

紹介する方法を利用する事で、可用性の低下やSPOFが発生する場合があります。ご注意ください。
このブログでは、具体的な構築手順については紹介せずアーキテクチャの紹介のみです。

SFTPを使用可能な場合のアーキテクチャです。AWS Transfer for SFTPがPrivate Linkに対応している為、VPC内にElastic Network Interface(ENI)を作成し、経由してアクセスする事でプライベートネットワークのみでS3へアクセスできます。
また、ENIにはSecurity Groupが付くので送信元IPアドレスで通信を制御する事が可能です。
vpce-xxxx-xxxx.server.transfer.${AWS_REGION}.vpce.amazonaws.comという形式のエンドポイントDNS名が払い出されるので、クライアントはこの名前に対してアクセスします。
SFTPというプロトコル制約がついてしまいますが、フルマネージド・シンプル・送信元制御が可能と3点揃っています。大規模な利用でなければ、このアーキテクチャを選択するのが良いでしょう。

[アップデート]Transfer for SFTP が PrivateLink に対応したので、アカウント間のファイル共有に使ってみる

方法2: HTTP Proxy on EC2

AWS CLIやAWS SDKを使用してアクセスしたい場合のアーキテクチャで、プロトコルはHTTPSです。VPC内にSquid等をインストールして、HTTPプロキシの役割を持つEC2インスタンスを構築します。合わせて、S3のVPC Endpointを構築しておくことでS3のVPC Endpointを経由してアクセスする事でプライベートネットワークのみでS3へアクセスします。
S3のVPC EndpointはGateway型なので、アクセスはパブリックIPアドレスに対して行われます。Gateway型は、ルーティングを捻じ曲げる仕組みであり、通常はオンプレミスからの通信を与えません。このアーキテクチャの様にプロキシを経由させる事で、VPC内のリソースからの通信となりGateway型VPC Endpointの効果を受ける事ができます。
このアーキテクチャの注意点は、AWS IAMへの通信です。対象のアカウントにIAMユーザーが存在し、そのアクセスキー・シークレットアクセスキーを利用している場合は問題ありません。問題となるのはAssume RoleやMFAを使用している場合です。この場合は、クライアントからIAMにアクセスする必要があります。その為、今回のアーキテクチャではNat GatewayとInternet Gatewayを作成し、IAMへのアクセスルートを確保しています。オンプレミス側からインターネットへアクセスルートを確保する事でも対応が可能です。
データプレーンは、常にプライベートネットワーク経由だが、コントロールプレーンは場合によってはインターネット経由が必要となります。

Direct Connectプライベート接続でS3へアクセスする高可用性な構成

方法3: Storage Gateway (File Gateway)

SMB2&3、NFS3&4.1を使用してアクセスしたい場合のアーキテクチャです。方法2とほぼ同じで、プロキシサーバがFile Gatewayに置き換わりました。SMBの場合は、ゲスト認証(ユーザーを特定せず1つのパスワードを使用)とMicrosoft Active Directoryを使用する事で個人認証が可能です。
このアーキテクチャは、性能要件に注意する必要があります。Storage Gatewayを動作させる為のEC2インスタンスの最低スペックとして、vCPU 4つ以上が必須です。
また、書き込みスループット (ファイルサイズ 6 MB 超): 125 MiB/秒 (0.9 Gbps) を実現する為の推奨スペックが下記の表です。

(https://docs.aws.amazon.com/ja_jp/storagegateway/latest/userguide/Performance.html#performance-fgw)

項目
ルートディスク 80 GB io1、4,000 IOPS
キャッシュディスク 512 GiB EBS キャッシュ、io1、1,500 個のプロビジョンド IOPS
最小ネットワークパフォーマンス 1 Gbps
Amazon EC2 インスタンスタイプ c5.4xlarge

このスペックで東京リージョンの場合、1117.67[USD/月]費用が発生します。必要な性能はケース・バイ・ケースですが、大規模な利用の際に選択するアーキテクチャであると考えています。(実際に使用した経験がないので、何かあればコメント頂きたいです)
SMB、NFSと今までファイルサーバーとして慣れ親しんだプロトコルで利用できるのがこのアーキテクチャの最大の特徴です。

[Storage Gateway] Windows で S3 オブジェクト保存!ファイルゲートウェイで SMB プロトコルがサポートされました

方法4: S3 Sync on EC2

方法1〜3までのアーキテクチャはプロトコルが指定されていました。このアーキテクチャはEC2インスタンス上に任意のアプリケーションをデプロイする事で、クライアントから自由なプロトコルでアクセスする事が可能です。(FTPを使いたいなら、FTPサーバーをデプロイする)
EC2インスタンスからS3へはS3 Sync等を使い同期させます。Cronで定期実行させれば良いでしょう。リアルタイムでの反映を行いたい場合は、EC2インスタンス上で変更を検知するとS3 Syncが実行される様に設定する必要があります。
S3アクセスの頻度が少ないのであれば、頑張って仕組みを作らずに、踏み台サーバーにSCPでファイルを転送してAWS CLIでPushなどの方法で十分でしょう。

方法5: Public Direct Connect

このアーキテクチャは一応紹介しますが、S3にプライベートネットワーク経由でアクセスしたいという目的の為だけに構築するのは煩わしすぎるし、オンプレミスネットワークに与える影響も大きく気軽に利用するアーキテクチャではありません。
AWS Direct Connect(Public)を利用すると、AWSのパブリックエンドポイントに対して、通常はパブリックネットワークを経由してアクセスしますが、閉域網経由でアクセスが可能になります。
これは、AWSからCustomer Gatewayに対してBGPでパブリックエンドポイントのIPアドレスが広告される事によって実現されます。閉域網ではありますが、パブリックIPアドレスの通信になるので、Customer GatewayはパブリックIPアドレスを持つ必要があり、プライベートIPアドレスのままでは通信ができないのでNAPTを行います。このパブリックIPアドレスは自分が所有する物を使用するか、AWSから払い出しを受けます(/31)。

Q. AWS Direct Connect で使用できる AWS のサービスはどれですか?
Amazon Elastic Compute Cloud (EC2)、Amazon Virtual Private Cloud (VPC)、Amazon Simple Storage Service > (S3)、Amazon DynamoDB など、AWS のすべてのサービスを AWS Direct Connect とともに使用できます。
よくある質問 - AWS Direct Connect | AWS

上記のドキュメントどおり、(Public DXを接続したリージョン内の)全てのサービスに対してプライベートネットワーク経由でのアクセスが可能となり、VPCとは無関係の話しなので、VPC Endpointなどを構築する必要がありません。

このアーキテクチャについては、検証を行うにも敷居が非常に高くインターネット上にもあまり情報がありません。下記のブログとドキュメントを元に机上で構成しています。

AWS Solutions Architect ブログ: Direct Connectを利用して専用線経由でS3やDyamoDBへアクセスする (AWS Direct Connect のパブリック接続)

方法6: AWS Client VPN

このアーキテクチャはClient VPNのVPC内にENIを生成し、Clientからの通信はそのENIからの通信、つまりVPC内からの通信として扱われる事を利用したアーキテクチャです。方法2では、VPC内からの通信として扱う為に、HTTPプロキシを構築していました。しかし、Clien VPNの場合は、前述の通りVPN内からの通信なのでHTTPプロキシを構築する必要がありません。
ENIにはSecurity Groupが付きますが、ここで制御が可能なのはアウトバウンド通信のみなのでご注意ください。

Client VPN endpoints support security groups. Security groups can be used to limit access to applications. Note that the security group only controls the traffic egress from the VPC associated ENIs. To limit the traffic that can route through the VPC associated ENI(s), restrictive authorizations can be used.
Introducing AWS Client VPN to Securely Access AWS and On-Premises Resources | Networking & Content Delivery

方法7: ソフトウェアVPN(送信元NAPT)

このアーキテクチャは方法2の亜種です。VPC内にVyOS等をインストールして、ソフトウェアVPNの役割を持つEC2インスタンスを構築します。方法2と同様に、合わせて、S3のVPC Endpointを構築しておくことでS3のVPC Endpointを経由してアクセスする事でプライベートネットワークのみでS3へアクセスします。
この際に戻りの通信がEC2インスタンスに戻ってくる様にSource NAPTを行う設定を行ってください。

まとめ

方法 プロトコル マネージド おすすめ度
方法1: AWS Transfer for SFTP & AWS PrivateLink SFTP フルマネージド ★★★★★
方法2: HTTP Proxy on EC2 HTTPS(AWS CLI, SDK) セルフマネージド ★★★
方法3: Storage Gateway (File Gateway) SMBv2, v3 and/or NFSv3, v4.1 セルフマネージド ★★
方法4: S3 Sync on EC2 Any セルフマネージド ★★★★
方法5: Public Direct Connect HTTPS(AWS CLI, SDK) フルマネージド
方法6: AWS Client VPN HTTPS(AWS CLI, SDK) フルマネージド ★★★
方法7: ソフトウェアVPN(送信元NAPT) HTTPS(AWS CLI, SDK) SFTP セルフマネージド ★★★

ここまで紹介した方法をまとめて見ました。おすすめ度については一応つけていますが、個人的なアーキテクチャ思想も含まれてのランキングなので、選定はこのおすすめ度は気にせず、ユースケースに対して何が適切かで選択して頂きたいです。
解説やこの表で触れていませんが、Client VPNを行った上で、AWS Transfer for SFTP & AWS PrivateLinkなどの複合的な構成も可能です。

あとがき

プライベートネットワーク経由でAWS S3にアクセスする方法を、5つのアーキテクチャパターンで紹介しました。最近良くある質問なので、知識の整理も兼ねてまとめてみました。
インターネットVPNが許容される = 暗号化されていればパブリックネットワークがOKなら、そもそもHTTPSで良いんじゃ無いか?というツッコミどころはあるのですが、実際にそういうポリシーに何回も直面して来たので意味があると考えて記載しています。
そして、AWS Transfer for SFTPが改めて画期的な新機能だと、改めて認識する事ができました。