はじめに
2021/2/3のアップデートで、インターフェイス型のS3 VPCエンドポイントがリリースされました。
これにより、プロキシサーバ無しで閉域（DirectConnect、VPN）経由でS3利用が可能になりました。
上記図引用元：Amazon S3 and interface VPC endpoints (AWS PrivateLink)
ということで、実際にやってみたいと思います。
今回は、DirectConnect環境は準備できなかったので、AWS ClientVPNと組み合わせて環境を準備し、
オンプレミス環境（Windows Subsystem for Linux (WSL1)にAWS CLIインストールしたもの）から、
PrivateLink経由でのS3アップロードをテストしてみました。
なお、AWS ClientVPNの構築部分は、以前の記事を参考にして構築しておりますが、今回改めては触れていません。
$ aws --version
aws-cli/2.0.17 Python/3.7.3 Linux/4.4.0-19041-Microsoft botocore/2.0.0dev21
PrivateLink for Amazon S3
- PrivateLinkとは、AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイントです。
VPCエンドポイントって何よ、というのは以下ユーザーガイド参照。
VPC エンドポイントは、VPC およびサポートされている AWS のサービスと、AWS PrivateLink を利用した VPC エンドポイントサービスとの間のプライベート接続を可能にします。VPC エンドポイントは、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要としません。VPC のインスタンスは、サービスのリソースと通信するためにパブリック IP アドレスを必要としません。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れません。
やってみる（環境構築）
AWSClientVPN経由でローカル環境から、VPCからPrivateLink経由でのS3アクセスする構成を作成しました。
PrivateLink for S3 ではプライベート DNS 名は利用できないため、
今回は、Provided DNSを使うパターン（パターン①）と、
インターネット上のパブリックDNSを使う場合(パターン②)の2通り試してみました。
なお、今回パターン②で、インターネット接続については、
NATゲートウェイ配置しているPublicSubnetのルートテーブルで、無理やり制御しているのですが、
もし、実際に運用する場合はここで制御する方がいいよ！みたいなのがあれば、コメント頂けると大変ありがたいです。
環境構築（パターン①：Amazon Provided DNSを使用する）
全体構成（アーキテクチャ）
①-1.PrivateLink for S3 エンドポイントの作成
VPC 管理コンソールから [エンドポイント] - [エンドポイントの作成] をクリックします。
エンドポイントの作成でサービスカテゴリに AWSサービス を選択し、s3 で検索すると Gateway および Interface 2つのタイプが見つかりますので、 Interface を選択します。
エンドポイントを作成する VPC および AZ を選択します。
※インターフェース型のエンドポイントは AZ ごとに 0.01 USD の料金が発生します。
セキュリティグループを選択しPrivateLinkのENIに割り当て、 [エンドポイントの作成] をクリックします。
メモ
※セキュリティグループ周りについて、自分の不勉強で少しハマりました。
- セキュリティグループについて、本構成でデフォルトセキュリティグループを選択すると通信できなくなります。
- 理由として、デフォルトセキュリティグループは、特徴として、ソースに自身のセキュリティーグループが指定されているからです。
これは、デフォルトセキュリティグループが指定されたインスタンスからのインバウンド通信のみ許可する という意味になりますので、今回の構成では別のセキュリティグループを作成しましょう（HTTPS：443の通信を許可してあげればOKです。）
参考：AWSのセキュリティグループの許可ソースにセキュリティグループを設定するパターンとは
- エンドポイントのステータスが保留から使用可能になれば、作成完了です。
①-2.Client VPNエンドポイント DNSサーバー設定
- Client VPN エンドポイントの変更画面より設定を行います。
[ DNS サーバーを有効にする ] にチェックを入れ、指定する DNS サーバーの IP アドレスを入力します。 - 今回は、Amazon Provided DNS(VPC CIDRの末尾を.2 にした値)を設定します。
①-3.CS3へのアクセス確認
AWS ClientVPNに接続した後、インターネットに接続できないことを確認します。
PrivateLink for S3 ではプライベート DNS 名が利用できまないため、エンドポイント固有の DNS 名を利用する必要があります。
①-1で確認した、S3エンドポイント固有のDNS名を利用します。
ローカルPCで名前解決すると、プライベートIPが返ってくることが確認できます。
$ dig vpce-[DNS名].s3.ap-northeast-1.vpce.amazonaws.com +short
10.0.0.179
また、AWS CLIにてエンドポイントURLを—endpoint-url パラメータとして指定し、バケット一覧を取得出来ていることが確認できました。
$ aws s3 vpce-[DNS名].s3.ap-northeast-1.vpce.amazonaws.com +shortaws s3 --endpoint-url https://bucket.vpce-[DNS名].s3.ap-northeast-1.vpce.amazonaws.com --region ap-northeast-1 ls
メモ
アクセスするS3が存在するリージョンについて、--regionパラメータとして指定してあげましょう。
参考：[AWS] VPC Endpoint で S3 にアクセスするときはリージョン指定に注意が必要な件
- 次に、特定のバケットに対しての10Mのファイル（10M.dumy）をアップロードを試してみます。
まず10MBのダミーファイルを作成します。
$ dd if=/dev/zero of=10M.dumy bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.256005 s, 41.0 MB/s
coralreaf@coralreaf-sheepwing:~$ ls -lh | grep 10M
-rwxrwxrwx 1 coralreaf coralreaf 10M Feb 22 21:24 10M.dumy
$ ls -lh | grep 10M
-rwxrwxrwx 1 coralreaf coralreaf 10M Feb 22 21:24 10M.dumy
- 作成したダミーファイル（10M.dumy）を、S3バケット（coralreaf-dev-data）にアップロードします。
$ aws s3 --endpoint-url https://bucket.vpce-[DNS名].s3.ap-northeast-1.vpce.amazonaws.com --region ap-northeast-1 cp 10M.dumy s3://coralreaf-dev-data/
- マネジメントコンソールで確認します。
- ダミーファイル（10M.dumy）が対象S3バケット（coralreaf-dev-data）にアップロードされていることが確認できました。
環境構築（パターン②：パブリックDNSを使用する）
全体構成（アーキテクチャ）
今回はNATゲートウェイを配置したPublicSubnetのルートテーブルで、パブリックDNS(8.8.8.8)宛ての通信のみに制御しました。
②-1.PrivateLink for S3 エンドポイントの作成
- PrivateLink for S3 エンドポイントの作成手順はパターン①と同様ですので、パターン①の手順をもとに作成します。
②-2.Client VPNエンドポイント DNSサーバー設定
- Client VPNエンドポイント のDNSサーバーのアドレスを、GoogleパブリックDNSのアドレス（8.8.8.8）に変更します。
②-3.Publicサブネットのルートテーブル編集
NATゲートウェイが配置されているPublicサブネットのルートテーブルについて、デフォルトルートを削除して、 GoogleパブリックDNSのアドレス（8.8.8.8）宛ての通信のみ設定します。
AWS ClientVPNに接続した後、インターネットに接続できないこと(ping 1.1.1.1)、また、パブリックDNSに接続出来ること(ping 8.8.8.8)を確認します。
ローカルPCでS3エンドポイント固有のDNS名の名前解決して、プライベートIPが返ってくることも確認し、
AWS CLIにて、S3バケット一覧を取得出来ていることについても、確認できました。
最後に
今回、セキュリティグループ周りで結構ハマってしまい、解決するまで時間かかってしまいました。
ただ上手くいかないと、色々調べたり、試したり、もがいている中で色々な事を学ぶことが出来るので、
やはり自分で手を動かすと得られるものが大きいなと感じました。
これからも色々なAWSサービスについて、出来るだけ自分で試していきたいと思います。
※今回でいうと、AWS Loftを初めて利用させてもらったり、VPC ReachabilityAnalyze使ってみたり、
自分の中で初めて触れるものも多く、とても勉強になりました。