CloudFormationを使用してVPCエンドポイントをVPCに追加し、s3の使用を許可しました。ルートはAWSコンソールに表示されますが、EC2インスタンスのローカルルーティングテーブルには表示されません。
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.29.4.129 0.0.0.0 UG 0 0 0 eth0
169.254.169.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
172.29.4.128 0.0.0.0 255.255.255.128 U 0 0 0 eth0
VPCのEC2インスタンスが、使用可能なインターネット接続ではなく、実際にS3のVPCエンドポイントを使用していることを確認するにはどうすればよいですか?
VPCエンドポイントの使用状況を確認する方法を見つけました。
aws ec2 describe-prefix-lists
; for Windows PowerShell 、Get-EC2PrefixList
結果のPrefixListId
属性には、VPCエンドポイントプレフィックスリストIDが含まれているはずです。
追加の検証のために、次のポリシーをS3バケットに適用できます。
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::mybucket"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": [
"vpc-121212"
]
}
}
}
]
}
vpc-121212の代わりにvpc IDを使用します。その後、特定のVPCからのみS3バケットにアクセスできるようになります。
S3ロギングをオンにして、ファイルがパブリックではなくプライベートIPからアクセスされているかどうかを確認できます。ログにプライベートIPがバケットにアクセスしていることが示されている場合は、正しく設定しました。幸運を!
インターネットにアクセスせずにサブネットでec2インスタンス(s3バケットの一覧表示を許可されたIAMロールを使用)を起動することをお勧めします。
基本的に、ルートテーブルの2つのアクティブルールのみ(VPCサブネット範囲とs3エンドポイント)。
インスタンスに接続してコマンドを実行します。
aws s3 ls /**
Botoはデフォルトでグローバルs3 url(s3.amazonaws.com)へのリクエストを作成するため、タイムアウトで失敗するはずです。
export AWS_DEFAULT_REGION=us-east-1** ## your region here
aws s3 ls /**
us-east-1リージョンのバケットをリストする必要があります(vpc routerはリクエストをs3.us-east-1.amazonaws.comにルーティングします)。
私はまっすぐな方法は実際にそれらのルートを調査することだと思います。
Tracerouteからs3にアクセスして、NATゲートウェイの内部IPが出力の最初のホップなど)にあるかどうかを確認できます。
まず、NAT console のゲートウェイ内部IPを確認します。
エンドポイントが設定された出力例-ゲートウェイIPは表示されません。これはあなたが見たいものです。
$ traceroute -n -T -p 443 s3.amazonaws.com
traceroute to s3.amazonaws.com (52.216.204.93), 30 Hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 52.216.204.93 0.662 ms 0.668 ms 0.637 ms
NAT(最初のホップを参照)を経由する別の宛先の出力例
$ traceroute -n -T -p 443 serverfault.com
traceroute to serverfault.com (151.101.129.69), 30 Hops max, 60 byte packets
1 172.20.10.188 0.206 ms 0.147 ms 0.145 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 100.65.13.49 0.956 ms 100.65.13.113 1.253 ms *
8 52.93.28.209 1.083 ms 52.93.28.231 1.213 ms 52.93.28.235 1.151 ms
9 100.100.4.38 1.770 ms 100.100.4.46 2.089 ms 100.100.4.36 1.723 ms
10 103.244.50.242 1.136 ms 100.100.4.44 1.702 ms 2.738 ms
11 151.101.129.69 1.013 ms 103.244.50.244 1.745 ms 151.101.129.69 1.142 ms
インスタンスはS3宛てのパケットをローカルゲートウェイに転送し、そこからVPC「ルーター」がS3エンドポイントにパケットを転送します。クライアントの設定や知識は必要ありません。
S3エンドポイントを非常に制限的なACLのセットで構成して、すべてのリクエストを拒否し、クライアントがエラーを受信することを確認することもできます。
@ m-glatkiの答え(何らかの理由で受け入れられている)は実際には正しくありません。
まず、ec2 VPCインターフェイスを明示的に有効にして、aws ec2 describe-prefix-lists
呼び出し、それ以外の場合はタイムアウトになります。
次に、そのAPIを呼び出すことができたとしても、そのエンドポイントを経由してトラフィックをルーティングしているかどうかはわかりません。現在のリージョンの特定のプレフィックスリスト(PL)に関する詳細を提供するだけです。
あなたがしなければならないことは、S3 VPCエンドポイントをサブネットのルートテーブルに関連付け、EC2インスタンスまたはサービスのセキュリティグループがそのエンドポイント経由の下り接続を許可していることを確認することです(デフォルトの「すべて許可」下りルールで問題ないはずです)。これは、NATゲートウェイが接続されている場合でも、エンドポイント経由でS3トラフィックをルーティングします。
関連するcloudwatchログを確認することで、トラフィックがNATを介してルーティングされていないことを確認できます(BytesOutToDestinationを参照)BytesOutToSource、BytesInFromDestination、およびBytesInFromSource メトリック)
@michaelが正しく指摘したように、S3バケットのログも確認してください。