VPC 上の EC2 から AWS サービスに対してプライベートな通信をしたい場面はよくあります。
例えばシステムの要件で「インターネットを経由した通信は禁止！」と言われた際には、その要件に適応する構成を検討する必要があります。
最初に勘違いされがちなのは「 AWS 上の EC2 と S3 のサービスなのだから、当然 AWS 内で通信できると思っていた…」ということです。EC2 は論理ネットワークである VPC の中に存在するため、接続するための設定を定義しない限り勝手に外の AWS サービスと連携することはできません。
その接続方法は複数あり、要求内容によって選択される手段は変わります。
今回は VPC 内にある EC2 から AWS サービスの１つである S3 へのアクセスを可能にする接続方法のうち利用頻度の高い3つのプライベート通信方法についてご紹介します。
1. 前提とする要件
今回は以下の前提の環境を元に、それぞれの接続方法を確認します。
| 項 | 内容 |
|---|---|
| 1 | 自社で構築した VPC 上に EC2 ( Windows OS )が稼働している。 |
| 2 | EC2 の Windows OS 環境上から AWS コマンドラインインターフェイス (以降 CLI)を使ってS3に接続したい。 |
| 3 | 接続はインターネットを経由しないプライベートな通信を実施したい。 |
| 4 | S3の操作権限はすべての操作が実行できるようにしたい。 |
AWS コマンドラインインターフェイス (AWS CLI)
AWS Command Line Interface (AWS CLI) は、コマンドラインシェルでコマンドを使用して AWS サービスとやり取りするためのオープンソースツールです。Windows では、Windows コマンドプロンプトまたは PowerShell でコマンドを実行します。利用するには EC2 のOS 上で AWS CLI をインストールする必要があります。
この要件を満たすべく、3つのパターンを紹介します。
| パターン | 内容 |
|---|---|
| 1 | インターネットゲートウェイ( IGW )経由での S3 アクセス |
| 2 | ゲートウェイ型 VPC エンドポイント経由での S3 アクセス |
| 3 | インターフェース型 VPC エンドポイント経由での S3 アクセス |
2. パターン 1：インターネットゲートウェイ（IGW ）を経由した通信
パターン 1 はインターネットゲートウェイ（IGW ）を経由してS3 にアクセスする方法です。
EC2 から AWS サービスへの通信が IGW を経由していると「通信がインターネットを通っている」と思われがちですが、AWS 公式見解として、以下の記載があります。
| 区分 | 内容 |
|---|---|
| 質問 | 2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? |
| 回答 | いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。 |
AWS グローバルネットワークに通信が留まるのでインターネットは経由していません。今回の前提が「接続はインターネットを経由しないプライベートな通信を実施したい。」であるなら、その要件を満たしています。
注意点として、AWSサービスとのプライベート通信を実施したい場合は、インターネットとの通信自体ができない閉域環境を要件として求められることが多いです。その要件がある場合は、この後に記載のある VPCエンドポイントを利用した残りの2つの方法をご確認ください。
検討するべきセキュリティ対策
IGW を VPC にアタッチすることで、インターネット側からの通信が可能になりますが、IGWが アタッチされていることに伴うセキュリティ対策は重要になります。例えば EC2 レベルであればセキュリティグループ、subnet レベルであればネットワークACLの設定により通信を制御します。また、AWS Network Firewall を利用してネットワーク保護を実施することも効果的です。
次に、このパターンにおける設定の手順とポイントをご紹介します。
| 項 | 手順 | 区分 |
|---|---|---|
| 2.1. | EC2 に対する S3 へのアクセス権限付与 | 設定 |
| 2.2. | VPC に IGW をアタッチ | 設定 |
| 2.3. | サブネットのルートテーブルに IGW へのルートを追記 | 設定 |
| 2.4. | EC2 にパブリック IP を付与 | 設定 |
| 2.5. | EC2 起動後に OS 上から S3 へ CLI でアクセス | 動作確認 |
| 2.6. | 参考：アクセスルートの確認 | 動作確認 |
| 2.7. | 参考：接続時に利用する IP アドレス | 動作確認 |
2.1. EC2 に対する S3 へのアクセス権限付与
EC2 が S3 にアクセスする際のアクセス権限（認可）はIAMポリシーで設定可能です。
今回は「S3の操作権限はすべての操作が実行できるようにしたい。」という要件があるので「AmazonS3FullAccess」というIAM ポリシーを設定したIAM ロールをEC2にアタッチします。これでEC2 に S3 に対するフルアクセス権が付与されます。「AmazonS3FullAccess」のポリシー自体は JSON コードで記載されており、以下の通りです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"s3-object-lambda:*"
],
"Resource": "*"
}
]
}
このポリシーは AWS 管理のポリシーなので、自分で JSON コードを記載する必要はありません。
2.2. VPC に IGW をアタッチ
EC2 が S3 と通信するための出口をVPCに作成する必要があります。
今回の場合は IGW となり、IGW を作成して VPC にアタッチします。
これで VPC から外部への出口が作成されます。
2.3. サブネットのルートテーブルに IGW へのルートを追記
VPC に IGW への出口ができたとしても、その出口に対するルートを記載しないと利用できません。EC2 が存在するサブネットのルートテーブルに IGW への経路を追記します。
これにより、VPC の CIDR 範囲の通信以外は IGW にルーティングされます。
2.4. EC2 にパブリックIPを付与
IGW 経由で通信をするためには、EC2 自体がパブリックIPを所持する必要があります。
EC2 を起動する際に「パブリック IP の自動割り当て」を有効化することで、起動時に EC2 の ENI にパブリック IP が割り当てられます。
これで、EC2 が IGW 経由で通信可能となります。
2.5. EC2 起動後に OS 上から S3 へ CLI でアクセス
EC2 起動後に Windows OS 上から PowerShell を起動し、CLI コマンドを実行すると S3 にアクセスできます。
バケットの参照やバケット作成も実施でき、S3 のフルアクセス権限で操作できることが確認できます。
PS C:\Users\Administrator> aws s3 ls s3://test-us-west-bt
2024-03-16 15:06:06 6 test01.txt
2024-03-16 15:11:40 5 test2.txt
PS C:\Users\Administrator> aws s3 mb s3://test-us-west-bt-6
make_bucket: test-us-west-bt-6
PS C:\Users\Administrator>
2.6. 参考：アクセスルートの確認
実際に想定通りの経路で通信できているのか確認するためのサービスとして VPC の機能の１つ「Network Manager」があります。その中の「Reachability Analyzer」を利用すると、送信元と送信先の間の通信経路を可視化できます。万一、設定に問題があって疎通できない場合は、その問題解決に寄与します。
今回の構成の場合は、以下の通り送信元を EC2 、送信先を IGW に設定して確認することで、疎通に問題ないことを確認できました。
上記だと Reachability Analyzer の効果があまり感じにくいと思いますので、あえてエラーを起こしてみます。今回の構成でルートテーブルから IGW へのルートを削除した場合の結果が以下の通りです。
きっちりと、ルートテーブルに問題があることを突き止めてくれます。非常に有用な機能なのでご活用ください。
2.7. 参考：接続時に利用するIPアドレス
nslookup でバケットのドメイン名から IP アドレスを確認すると、以下の通りパブリック IP アドレスが設定されていることが分かります。
PS C:\Users\Administrator> nslookup test-us-west-bt.s3.us-west-1.amazonaws.com
サーバー: ip-10-0-0-2.us-west-1.compute.internal
Address: 10.0.0.2
権限のない回答:
名前: s3-r-w.us-west-1.amazonaws.com
Addresses: 3.5.162.108
3.5.163.174
52.219.192.74
52.219.193.82
52.219.194.26
52.219.194.186
3.5.160.124
3.5.161.117
Aliases: test-us-west-bt.s3.us-west-1.amazonaws.com
nslookupコマンド
ドメイン名から IP アドレスを確認することができるコマンドです。
3. パターン 2：ゲートウェイ 型 VPC エンドポイントを経由した通信
ただ、セキュアな通信を実施したい場合、IGW をアタッチして通信するのは得策ではありません。インターネットへのアクセスが不要な場合はIGWをアタッチせずに AWS サービスと通信をしたいところです。
そんなときに利用できるのが VPC エンドポイントです。
IGW をアタッチせずに AWS サービスへの通信が可能になります。
VPC エンドポイントは「ゲートウェイ型」と「インタフェース型」の2通りがあります。
まずは「ゲートウェイ型」から紹介します。
以下がゲートウェイ型 VPC エンドポイントを利用した接続図です。VPC にゲートをアタッチしたり、ルートテーブルにルートを追記するなど、IGW の利用方法と似ています。IGW の代わりに VPC エンドポイントを VPC にアタッチするイメージです。
次に、このパターンにおける設定の手順とポイントをご紹介します。
| 項 | 手順 | 区分 |
|---|---|---|
| 3.1. | EC2 に対する S3 へのアクセス権限付与 | 設定 |
| 3.2. | VPC へのゲートウェイ型 VPC エンドポイントのアタッチ | 設定 |
| 3.3. | サブネットのルートテーブルに ゲートウェイ型 VPC エンドポイントへのルートを追記 | 設定 |
| 3.4. | EC2 起動後に OS 上から S3 へ CLI でアクセス | 動作確認 |
| 3.5. | 参考：アクセスルートの確認 | 動作確認 |
| 3.6. | 参考：接続時に利用する IP アドレス | 動作確認 |
3.1. EC2 に対するS3へのアクセス権限付与
EC2 が S3 にアクセスする際のアクセス権限（認可）は IAM ポリシーで設定可能です。
※2.1.と同様の内容です。
3.2. VPC へのゲートウェイ型 VPC エンドポイントのアタッチ
VPC にゲートウェイ型VPCエンドポイントをアタッチする必要があります。
VPC サービスのエンドポイント画面から「エンドポイントを作成」を選択して作成します。
AWS サービスごとにエンドポイントが存在するので、「 S3 」で絞り込みます。
以下の4つが表示されるので、タイプ「 Gateway 」を選択します。
VPC エンドポイントをアタッチする対象VPCと、VPC エンドポイントにルーティングさせたいサブネットへアタッチされたルートテーブルを選択します。VPC エンドポイントを作成すると、ここで指定したルートテーブルに VCP エンドポイントへのルートが自動的に追加されます。
最後にVPC エンドポイントポリシーを設定します。
標準の「フルアクセス」を選択すると、すべての通信を通します。
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
例えば、この VPC エンドポイント経由で通信した場合は、特定のバケットしかアクセスできないようにする設定は以下となります。必要に応じて接続範囲を最小化してセキュリティを高めることができます。この例では「 test-us-west-bt 」がアクセスを許可するバケット名です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow-bucket",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": [
"arn:aws:s3:::test-us-west-bt",
"arn:aws:s3:::test-us-west-bt/*"
]
}
]
}
上記の設定を実施することで、VPC エンドポイントが作成されます。
3.3. サブネットのルートテーブルに ゲートウェイ型 VPC エンドポイントへのルートを追記
この追記は VPC エンドポイントを作成する際に対象のルートテーブルを選択することで自動的に実施されます。VPC サービスのルートテーブル画面で確認すると以下の通り追記されています。
3.4. EC2 起動後に OS 上から S3 へ CLI でアクセス
EC2 起動後に Windows OS 上から PowerShell を起動し、CLI コマンドを実行すると S3 にアクセスできます。
今回は VPC エンドポイントポリシーで「 test-us-west-bt 」というバケットのみのアクセスを許可しています。そのため、例えば以下のように他のバケットにアクセスしたり、新しいバケットを作成するコマンドはすべてエラーとなります。
PS C:\Users\Administrator> aws s3 ls s3://test-us-west-bt2
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
PS C:\Users\Administrator> aws s3 mb s3://test-us-west-bt6
make_bucket failed: s3://test-us-west-bt6 An error occurred (AccessDenied) when calling the CreateBucket operation: Access Denied
PS C:\Users\Administrator>
このようにゲートウェイ型 VPC エンドポイントは、IGW を経由しないプライベートな通信を可能とします。そして、VPC エンドポイントポリシーで制御を実施することができるメリットもあります。
3.5. 参考：アクセスルートの確認
「 Network Manager 」の「 Reachability Analyzer 」を利用して、疎通経路と問題がないかのチェックを実施します。今回の構成の場合は、以下の通り送信元を EC2、送信先をゲートウェイ型 VPC エンドポイントに設定して確認することで、疎通に問題ないことを確認できました。
3.6. 参考：接続時に利用するIPアドレス
nslookup でバケットのドメイン名から IP アドレスを確認すると、以下の通りパブリック IP アドレスが設定されていることが分かります。
PS C:\Users\Administrator> nslookup test-us-west-bt.s3.us-west-1.amazonaws.com
サーバー: ip-10-1-0-2.us-west-1.compute.internal
Address: 10.1.0.2
権限のない回答:
名前: s3-r-w.us-west-1.amazonaws.com
Addresses: 52.219.194.50
52.219.194.74
52.219.220.114
52.219.220.130
52.219.220.202
52.219.221.26
3.5.163.155
52.219.193.154
Aliases: test-us-west-bt.s3.us-west-1.amazonaws.com
これはルートテーブルで送信先として設定されたゲートウェイ型VPCエンドポイント用のマネージドプレフィックスリストで定義されている CIDR 範囲の IP アドレスとなります。
ゲートウェイ型 VPC エンドポイントは接続のためにパブリック IP アドレスを利用していますが、IGW をアタッチしていなくても利用できる特殊な設定となっています。
マネージドプレフィックスリスト
AWS マネージドプレフィックスリストは、AWS サービスの IP アドレス範囲一式です。AWS が作成と管理を行い、AWS アカウントを所有していれば誰でも使用できます。AWS マネージドプレフィックスリストを作成、変更、共有、削除することはできません。
4. パターン 3：インターフェース型 VPC エンドポイントを経由した通信
次に「インタフェース型」を紹介します。
以下がインタフェース型 VPC エンドポイントを利用した接続図です。ゲートウェイ型と違って、サブネットの中にエンドポイントが作成されます。
次に、このパターンにおける設定の手順とポイントをご紹介します。
| 項 | 手順 | 区分 |
|---|---|---|
| 4.1. | EC2 に対する S3 へのアクセス権限付与 | 設定 |
| 4.2. | インタフェース型 VPC エンドポイントにアタッチするセキュリティグループ作成 | 設定 |
| 4.3. | インタフェース型 VPC エンドポイントの作成 | 設定 |
| 4.4. | EC2 起動後に OS 上からS3へ CLI でアクセス | 動作確認 |
| 4.5. | 参考：アクセスルートの確認 | 動作確認 |
4.1. EC2 に対する S3 へのアクセス権限付与
EC2 が S3 にアクセスする際のアクセス権限（認可）は IAM ポリシーで設定可能です。
※2.1と同様の内容です。
4.2. インタフェース型 VPC エンドポイントにアタッチするセキュリティグループ作成
インタフェース型 VPC エンドポイントはセキュリティグループを設定する必要があります。
今回は CLI で S3 にアクセスする必要があり、許可が必要なプロトコルは https（ポート：443）です。
また、セキュリティ的な対策として、ソースには EC2 の ENI にアタッチされているセキュリティグループを設定します。こうすることで、対象のセキュリティグループが設定されている EC2 からの通信のみを許可して受信することができるようになります。
4.3. インタフェース型 VPC エンドポイントの作成
インタフェース型 VPC エンドポイントを作成する必要があります。
VPC サービスのエンドポイント画面から「エンドポイントを作成」を選択して作成します。
AWS サービスごとにエンドポイントが存在するので、「 S3 」で絞り込みます。
以下の4つが表示されるので、タイプ「 interface 」を選択します。
VPC エンドポイントをアタッチする対象 VPC と、VPC エンドポイントを作成するサブネットを選択します。また、先ほどゲートウェイ型 VPC エンドポイント用に作成したセキュリティグループを選択します。
最後に VPC エンドポイントポリシーを設定します。
この設定はゲートウェイ型エンドポリシーと同じです。
例えば、この VPC エンドポイント経由で通信した場合は、特定のバケットしかアクセスできないようにする設定は以下となります。必要に応じて接続範囲を最小化してセキュリティを高めることができます。この例では「 test-us-west-bt 」がアクセスを許可するバケット名です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow-bucket",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": [
"arn:aws:s3:::test-us-west-bt",
"arn:aws:s3:::test-us-west-bt/*"
]
}
]
}
上記の設定を実施することで、VPCエンドポイントが作成されます。
4.4. EC2 起動後に OS 上から S3 へ CLI でアクセス
EC2 起動後に OS 上から CLI でアクセスしますが、注意点としては、コマンド実行時にはエンドポイントURLを追記する必要があります。
エンドポイント URL は対象のインターフェース型 VPC エンドポイントの詳細情報を確認して DNS 名に記載された URL を確認します。
今回の例だと「*.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com」です。DNS 名を使用してリソースにアクセスする場合は「*」を適切な内容に置き換える必要があります。
「 bucket 」「 accesspoint 」「 control 」などがありますが、今回接続するのは S3 のバケットですので「 bucket 」と記載します。
そのため、エンドポイント URL として記述する内容は「https://bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com」となります。また、リージョン名も記載する必要があります。例えば今回は北カリフォルニアで実施しているので、リージョン情報は「 us-west-1 」となります。
バケット「 test-us-west-bt 」の情報を取得する場合のコマンドは以下となります。
IGW やゲートウェイ型 VPC エンドポイントの際との違いを比較して記載します。
| 区分 | 内容 |
|---|---|
| IGW | aws s3 ls s3://test-us-west-bt/ |
| ゲートウェイ型 VPCエンドポイント |
aws s3 ls s3://test-us-west-bt/ |
| インタフェース型 VPCエンドポイント |
aws s3 ls s3://test-us-west-bt/ --endpoint-url https://bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com --region us-west-1 ※aws s3 ls s3://バケット名/ --endpoint-url 対象のURL --region リージョン情報 |
実行結果は以下の通りです。問題なく対象のS3バケットにアクセスできます。
今回はゲートウェイ型の時と同様に、VPC エンドポイントポリシーで「 test-us-west-bt 」というバケットのみのアクセスを許可しています。そのため、例えば以下のように他のバケットにアクセスしたり、新しいバケットを作成するコマンドは、ゲートウェイ型の時と同様にエラーとなります。
PS C:\Users\Administrator> aws s3 ls s3://test-us-west-bt/ --endpoint-url https://bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com --region us-west-1
2024-03-16 15:06:06 6 test01.txt
2024-03-16 15:11:40 5 test2.txt
PS C:\Users\Administrator> aws s3 ls s3://test-us-west-bt2/ --endpoint-url https://bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com --region us-west-1
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
PS C:\Users\Administrator> aws s3 mb s3://test-us-west-bt6/ --endpoint-url https://bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com --region us-west-1
make_bucket failed: s3://test-us-west-bt6/ An error occurred (AccessDenied) when calling the CreateBucket operation: Access Denied
PS C:\Users\Administrator>
このようにインタフェース型 VPC エンドポイントは、IGW を経由しないプライベートな通信を可能とします。そして、VPC エンドポイントポリシーで制御を実施することができるメリットもあります。更にセキュリティグループをアタッチすることで、送信元を限定することも可能で、セキュリティの高い構成を作成できます。
4.5. 参考：アクセスルートの確認
「 Network Manager 」の「 Reachability Analyzer 」を利用して、疎通経路と問題がないかのチェックを実施します。今回の構成の場合は、以下の通り送信元を EC2、送信先をインタフェース型 VPC エンドポイントに設定して確認することで、疎通に問題ないことを確認できました。
4.6. 参考：接続時に利用するIPアドレス
nslookup でインタフェース型 VPC エンドポイントのドメイン名から IP アドレスを確認すると、「10.2.2.4」という設置したサブネット内のプライベート IP アドレスが設定されていることが分かります。
PS C:\Users\Administrator> nslookup bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com
サーバー: ip-10-2-0-2.us-west-1.compute.internal
Address: 10.2.0.2
権限のない回答:
名前: bucket.vpce-0ab367bd79ee990e4-pqm2b6wa.s3.us-west-1.vpce.amazonaws.com
Address: 10.2.2.4
PS C:\Users\Administrator>
5. 特徴の比較
VPC 内のリソースから AWS サービスにプライベートな通信をする3つの方法をご紹介しました。これまで説明した内容を整理すると以下の通りです。
| 機能 | インターネット ゲートウェイ経由 |
ゲートウェイ型 VPCエンドポイント経由 |
インタフェース型 VPCエンドポイント経由 |
|---|---|---|---|
| プライベート通信 | 〇 | 〇 | 〇 |
| プライベート空間 | × | 〇 | 〇 |
| エンドポイントの位置 | VPC にアタッチ | VPC にアタッチ | Subnet 内に作成 |
| 接続DNS名 | Amazon S3 DNS 名 | Amazon S3 DNS 名 | エンドポイント固有のAmazon S3 DNS 名 |
| 使用するIPアドレス | パブリック IP | パブリック IP | プライベート IP |
| エンドポイントにおけるセキュリティグループの利用 | × | × | 〇 |
| エンドポイントポリシーの利用 | × | 〇 | 〇 |
プライベート通信が可能ということで IGW も比較対象に入っていましたが、AWS のベストプラクティス集である AWS Well-Architected フレームワークでは以下の記述があります。
| 区分 | 内容 |
|---|---|
| フレームワークの柱 | セキュリティの柱 |
| ID | SEC05-BP02 すべてのレイヤーでトラフィックを制御する |
| 内容 | 一部の AWS サービスは、インターネットにアクセスして API 呼び出しをする (AWS API エンドポイント がある) ためのコンポーネントが必要です。その他の AWS サービスは VPC エンドポイント を Amazon VPC 内で使用します。 Amazon S3 や Amazon DynamoDB を含む多くの AWS サービスは VPC エンドポイントをサポートしており、このテクノロジーは次で一般化されています。 AWS PrivateLink.AWS のサービス、サードパーティーのサービス、および他の VPC セキュリティでホストされる独自のサービスにアクセスするには、このアプローチを使用することが推奨されます。 AWS PrivateLink のすべてのネットワークトラフィックは、グローバルな AWS バックボーンにとどまり、インターネットにトラバースすることはありません。接続を開始できるのは、サービスのプロバイダーではなくサービスのコンシューマーのみです。外部サービスアクセスに AWS PrivateLink を使用することにより、インターネットなしでエアギャップ VPC を作成することができるため、外部の脅威ベクトルから VPC を保護するのに役立ちます。 |
上記の通り、「外部の脅威ベクトルから VPC を保護する」ために、インターネットアクセスが不要な場合は、インタフェース型 VPC エンドポイントを利用することがベストプラクティス構成として推奨されています。なお、AWS PrivateLinkという用語が出てきていますが、この機能でインタフェース型エンドポイントが提供されています。
また、コスト面に関してもパブリックデータ転送コストの削減になる点も、考慮点の１つとなっています。
| 区分 | 内容 |
|---|---|
| フレームワークの柱 | コストの柱 |
| ID | COST08-BP02 データ転送コストを最適化するコンポーネントを選択する |
| 内容 | VPC エンドポイントを使用すれば、VPC とサポート対象の AWS サービスとの間にプライベート接続を確立できます。これで、データ転送コストが発生する可能性のある公開インターネットの使用を回避できます。 |
| 区分 | 内容 |
|---|---|
| フレームワークの柱 | コストの柱 |
| ID | COST08-BP03 データ転送コストを削減するサービスを実装する |
| 内容 | VPC エンドポイント により、プライベートネットワークを利用して AWS のサービス間の接続が可能になり、パブリックデータ転送と NAT ゲートウェイ のコストを削減できます。 ゲートウェイ VPC エンドポイント では、時間単位の料金は発生せず、 Amazon S3 と Amazon DynamoDB がサポートされます。 インターフェイス VPC エンドポイント は、 AWS PrivateLink によって提供され、時間単位の料金と GB あたりの使用料がかかります。 |
AWS Well-Architected フレームワーク
AWS Well-Architected フレームワークは、AWS のソリューションアーキテクト( SA )が、AWSのサービス開始から10年以上に渡り、様々な業種業界、数多くのお客様のアーキテクチャ設計および検証を手伝ってきた経験から作成したクラウド活用のベストプラクティス集です。
AWS PrivateLink
AWS PrivateLink は、仮想プライベートクラウド (VPC) とサポートされている AWS のサービス、他の AWS アカウント によってホストされているサービス、およびサポートされている AWS Marketplace のサービス間のプライベート接続を確立します。サービスと通信するのに、インターネットゲートウェイ、NAT デバイス、AWS Direct Connect 接続、および AWS Site-to-Site VPN 接続は不要です。AWS PrivateLink を使用するには、サービスの名前とサブネットを指定して、VPC で インタフェース型VPC エンドポイントを作成します。これによって Elastic Network Interface がサブネットに作成され、これがサービスへのトラフィックのエントリポイントとなります。
そのため、インターネット接続が不要なプライベート環境においては、IGW ではなく、2種類のVPCエンドポイントのどちらかの利用が推奨されます。
それでは VPC エンドポイントのどちらを利用するか検討する必要があります。
VPC エンドポイントを選択するにあたり、上記以外に影響がある特徴について記述します。
| 項 | 特徴 |
|---|---|
| 5.1. | 対応しているAWSサービス数の違い |
| 5.2. | 料金の違い |
| 5.3. | ハイブリッド環境における利用可否 |
5.1. 対応している AWS サービス数の違い
まずは対応サービスの違いです。
実はゲートウェイ型 VPC エンドポイントは2つのサービスにしか対応していません。「 S3 」と「 DynamoDB 」です。それ以外のサービスではインタフェース型を選択する必要があります。今回は「 S3 」を接続先サービスとした例だったため利用できましたが、その他の AWS サービスが対象の場合は、ほとんど利用できない訳です。
それ以外の AWS サービスに関しては、必然的にインタフェース型のエンドポイントを利用することになります。
EC2 をプライベート空間で利用する場合によく利用するサービスとしては以下のようなサービスがあります。サーバの起動・停止を自動化したり、メモリ使用率やディスク使用率といったメトリクス情報を取得したりするサービスです。プライベート空間で利用するにはインタフェース型 VPC エンドポイントの利用が必要になります。
| AWSサービス | 用途 | 対象のエンドポイント |
|---|---|---|
| Systems Managers | EC2の管理機能 | com.amazonaws.region.ssm |
| CloudWatch | EC2のログ・メトリクス収集 | com.amazonaws.region.monitoring |
また、インタフェース型 VPC エンドポイントについての注意点としては、リージョンごとに対応している内容が異なります。AWS サービス自体もリージョンによって異なりますが、エンドポイントも同じです。例えば AWS サービスは提供されているけれど、それに対応するインタフェース型 VPC エンドポイントが準備されていないということはあり得ます。「大阪リージョンに 2 つのアップデート」の記事を見るとわかる通り、大阪リージョン開設時には対応できていないインタフェース型 VPC エンドポイントも多々ありました。その為、要件としてインタフェース型 VPC エンドポイントを利用する必要がある場合は、対象のリージョンで対応しているか確認することが重要です。
| 機能 | AWSサービス数 | インタフェース型 VPCエンドポイント数 |
ゲートウェイ型 VPCエンドポイント |
|---|---|---|---|
| 米国東部 （バージニア北部） |
236 | 256 | 3 |
| アジアパシフィック （東京） |
212 | 198 | 3 |
| アジアパシフィック （大阪） |
125 | 85 | 2 |
5.2. 料金の違い
料金には明確な違いがあります。VPC エンドポイントの料金のみを比較すると以下の通りとなります。ゲートウェイ型 VPC エンドポイントが無料なのに対して、インタフェース型 VPC エンドポイントは有料となります。
| 機能 | 料金(USD/時間) | 補足 |
|---|---|---|
| ゲートウェイ型 VPC エンドポイント | 無料 | |
| インタフェース型 VPC エンドポイント | 0.014 USD | 各アベイラビリティーゾーンにプロビジョニングされる時間ごとに課金 |
インタフェース型 VPC エンドポイントは、例えば1か月の利用料にすると月額で1,512円かかる計算になります。
| 料金(USD/時間) | 料金(円/時間) 150円/USD想定 |
料金(円/月) 30日/月前提 |
|---|---|---|
| 0.014 USD | 2.1 円 | 1,512 円 |
また、例えば3つのアベイラビリティゾーンを指定してインタフェース型 VPC エンドポイントを作成した場合は、3倍の4,536円必要になります。インタフェース型はプライベート環境では複数の AWS サービスで利用することが多いので、料金面は非常に注意が必要です。
インタフェース型 VPC エンドポイントを作成する際には、以下のように対象とするサブネットを選択します。ここで選択したサブネットにエンドポイントが作成されます。この例では3つのサブネットを選択しています。
構成としては以下のようになります。3つのエンドポイントが作成されるので、×3の課金が発生します。
また、インターフェース型 VPC エンドポイントに関しては、AWS リージョンで 1 か月に処理されるデータ容量に対しても課金が発生します。
| AWS リージョンで 1 か月に処理されるデータ | 処理データ 1 GB あたりの料金 (USD) |
|---|---|
| 最初の 1 PB | 0.01 USD |
| 次の 4 PB | 0.006 USD |
| 5 PB以上のもの | 0.004 USD |
このようにインタフェース型 VPCエンドポイントには課金が発生するため、コスト面での注意が必要です。
5.3 ハイブリッド環境における利用可否
料金の違いのみを見ると、S3 ではゲートウェイ型 VPC エンドポイントを利用した方がよく思えますが、他にも判断要素があります。オンプレと AWS をプライベート通信で接続して利用するハイブリッド構成の場合です。
この場合、オンプレ側から S3 にアクセスさせたい場合は、ゲートウェイ型 VPC エンドポイントは対応不可です。インタフェース型 VPC エンドポイントを利用する必要があります。
ハイブリット環境の場合は、この仕様が決め手になります。
なお、オンプレからDirectConnect経由でAWSに接続して、VPC を経由せずに 直接 AWSサービスへ通信する方法もあります。パブリック VIF を利用する方法です。VPC を利用しない AWS サービスを利用する場合など、利用場面があります。
6．まとめ
ここまで、VPC 内のリソースから AWS サービスにプライベートな通信をする3つの方法について確認してきました。最初に前提とした要件は以下の通りです。
| 項 | 内容 |
|---|---|
| 1 | 自社で構築したVPC上にEC2(Windows OS)が稼働しています。 |
| 2 | EC2のWindowsOS環境上からAWS コマンドラインインターフェイス (以降 CLI)を使ってS3に接続したい。 |
| 3 | 接続はインターネットを経由しないプライベートな通信を実施したい。 |
| 4 | S3の操作権限はすべての操作が実行できるようにしたい。 |
その後、プライベート通信を実現する各サービスの特徴を説明してきましたが、その内容を簡単にまとめたのが以下の表です。
| 機能 | インターネット ゲートウェイ経由 |
ゲートウェイ型 VPC エンドポイント経由 |
インタフェース型 VPC エンドポイント経由 |
|---|---|---|---|
| プライベート通信 | 〇 | 〇 | 〇 |
| プライベート空間 | × | 〇 | 〇 |
| エンドポイントの位置 | VPC にアタッチ | VPC にアタッチ | Subnet 内に作成 |
| 接続DNS名 | Amazon S3 DNS 名 | Amazon S3 DNS 名 | エンドポイント固有のAmazon S3 DNS 名 |
| 使用するIPアドレス | パブリック IP | パブリック IP | プライベート IP |
| エンドポイントにおけるセキュリティグループの利用 | × | × | 〇 |
| エンドポイントポリシーの利用 | × | 〇 | 〇 |
| エンドポイント料金 | 無料 | 無料 | 有料 |
| 利用可能サービス | インターネット経由で接続可能な AWS サービス | S3, DynamoDBのみ | S3, DynamoDBを含むインタフェース型VPCエンドポイントに対応しているAWSサービス |
| オンプレからのアクセス | － | × | 〇 |
今回は VPC 内のリソースから AWS サービス( S3 )にプライベートな通信をする方法についてまとめた内容でした。この投稿で説明した通りVPC エンドポイントというサービスがありますが、2つの種類があり、要件により使い分ける必要があります。条件を理解した上で、最適なサービスをご利用ください。
