Как проверить работу конечной точки AWS VPC (S3)?

Вы можете включить ведение журнала S3 и проверить, доступны ли файлы с вашего частного IP, а не с общедоступного. Если ваш журнал показывает, что частные IP-адреса обращаются к сегментам, вы настроили его правильно. Удачи!

Я нашел способ проверить использование конечной точки VPC.

1. Войдите в экземпляр AWS EC2 в VPC.
2. Настроить клиент aws cli
3. бегать aws ec2 describe-prefix-lists; для Windows PowerShell, Get-EC2PrefixList

Результат должен содержать идентификатор списка префиксов конечных точек VPC в атрибуте PrefixListId.

Для дополнительной проверки вы можете применить следующую политику к корзине S3:

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mybucket"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": [
            "vpc-121212"
          ]
        }
      }
    }
  ]
}

с вашим идентификатором vpc вместо vpc-121212. После этого вы сможете получить доступ к сегменту S3 только из данного VPC.

Я думаю, что самый простой способ - это проверить эти маршруты.

Вы можете проследить маршрут до s3 и посмотреть, находится ли внутренний IP-адрес шлюза NAT где-нибудь в выходных данных (например, на первом переходе).

Сначала проверьте внутренние IP-адреса шлюза NAT в приставка.

Пример вывода с установленной конечной точкой - 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

Я бы порекомендовал запустить экземпляр ec2 (с ролью IAM, разрешенной для перечисления сегментов s3) в подсети без доступа в Интернет.

В основном только 2 активных правила в таблице маршрутов (диапазон вашей подсети VPC и конечная точка s3).

Подключитесь к экземпляру и запустите команду:

aws s3 ls /**

Он должен завершиться ошибкой с тайм-аутом, потому что по умолчанию boto создает запрос на глобальный URL-адрес s3 (s3.amazonaws.com).

export AWS_DEFAULT_REGION=us-east-1** ## your region here
aws s3 ls /**

должен указать ваши сегменты в регионе us-east-1 (маршрутизатор vpc направит ваш запрос на s3.us-east-1.amazonaws.com).

Ваш экземпляр пересылает пакеты, предназначенные для S3, на локальный шлюз, а оттуда «маршрутизатор» VPC пересылает их на конечную точку S3. Конфигурация клиента или знания не требуются.

Вы можете настроить конечную точку S3 с очень ограниченным набором списков ACL, чтобы она отклоняла все запросы и наблюдала, как ваш клиент также получает ошибку.

Ответ @ m-glatki (который по какой-то причине является принятым) фактически неверен.

Прежде всего, вы должны явно включить интерфейс ec2 VPC, чтобы даже иметь возможность выполнять aws ec2 describe-prefix-lists звоните, иначе получите таймаут.

Во-вторых, даже если вы можете вызвать этот API, он не скажет вам, маршрутизируете ли вы свой трафик через эту конечную точку. Он просто предоставляет подробную информацию о конкретном списке префиксов (PL) в текущем регионе.

Что вам нужно сделать, так это связать конечную точку S3 VPC с таблицей маршрутов подсети и убедиться, что ваш экземпляр EC2 или группа безопасности службы разрешает выходное соединение через эту конечную точку (вы должны быть в порядке с правилом выхода по умолчанию «разрешить все»). Это направит трафик S3 через конечную точку, даже если к ней подключен шлюз NAT.

Вы можете убедиться, что ваш трафик не проходит через NAT, проверив связанные с ним журналы облачного наблюдения (см. BytesOutToDestination, BytesOutToSource, BytesInFromDestination, и BytesInFromSource метрики)

Также проверьте журналы ведра S3, как правильно указал @michael.