Skip to content

How to verify that VPC traffic to S3 is going through your S3 gateway?

Gateway endpoints for Amazon S3 are a must-have whenever your EC2 instances send and receive traffic from S3, because they allow the traffic to stay within the AWS network, hence better security, bandwidth, throughput, and costs. They can easily be created, and added to your VPC route tables.

But how do you verify that traffic is indeed going through the S3 gateway, and not crossing the outer internet?

Using traceroute, you can probe the routes and see whether you are directly hitting the S3 servers (i.e. no intermediate gateway). In this example, the instance is running from a VPC located in us-east-1:

Terminal window
$ traceroute -n -T -p 443 s3.us-east-1.amazonaws.com
traceroute to s3.us-east-1.amazonaws.com (52.216.215.72), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 52.216.215.72 0.890 ms 0.916 ms 0.892 ms
Terminal window
$ traceroute -n -T -p 443 s3.amazonaws.com
traceroute to s3.amazonaws.com (52.217.139.232), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 52.217.139.232 0.268 ms 0.275 ms 0.252 ms

Both outputs produce the expected result, i.e. no intermediary gateway. This is what would happen if you were accessing a bucket located in the us-east-1 region.

Let’s see what happens if we try to access an S3 endpoint located in another zone:

Terminal window
$ traceroute -n -T -p 443 s3.eu-west-1.amazonaws.com
traceroute to s3.eu-west-1.amazonaws.com (52.218.25.211), 30 hops max, 60 byte packets
1 * * *
2 240.4.88.37 0.275 ms 240.0.52.64 0.265 ms 240.4.88.39 0.215 ms
3 240.4.88.49 0.205 ms 240.4.88.53 0.231 ms 240.4.88.51 0.206 ms
4 100.100.8.118 1.369 ms 100.100.6.96 0.648 ms 240.0.52.57 0.233 ms
5 240.0.228.5 0.326 ms * *
6 240.0.32.16 0.371 ms 240.0.48.30 0.362 ms *
7 * 240.0.228.31 0.251 ms *
8 * * *
9 * * 240.0.32.27 0.392 ms
10 * * *
11 * 242.0.154.49 1.321 ms *
12 * * 52.93.28.131 1.491 ms
13 * * 100.100.6.108 1.286 ms
14 100.92.212.7 67.909 ms 52.218.25.211 67.356 ms 67.929 ms

As you can see, the route is completely different, and as expected does not hit straight to the S3 endpoint.

TL;DR: make sure your route tables are correct, and only point to S3 buckets located in the same region.