Экземпляр в частной подсети AWS со шлюзом NAT не может получить доступ к сервисам AWS

У нас есть экземпляр в частной подсети с управляемым шлюзом NAT. В этом случае мы можем получить доступ к Интернету:

$ curl https://www.google.com/
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en"><head>...

Однако мы не можем получить доступ к конечной точке Cloudwatch, например следующее время ожидания: (РЕДАКТИРОВАТЬ: Моя ошибка, не конечная точка cloudwatch, а сайт, на котором хранятся скрипты мониторинга Cloudwatch.)

$ curl https://cloudwatch.s3.amazonaws.com

Проблема не в DNS:

$ dig cloudwatch.s3.amazonaws.com
cloudwatch.s3.amazonaws.com. 2303 IN    CNAME   s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com.   1   IN  A   54.231.72.59

Есть идеи о том, что может происходить?

У меня действительно была такая же проблема, и мне удалось решить ее так же, как это сделал JustinHK ниже. Я обратился в AWS, чтобы понять, почему это произошло, потому что я не мог отказаться от этого, поэтому это должно помочь с объяснением поведения. Вот разбивка:

Проблема не в том, что трафик не может достигнуть пункта назначения, а в том, что трафик не может правильно вернуться в исходную точку.
Поскольку общедоступная подсеть (где находится шлюз NAT) имеет 2 варианта доступа к месту назначения - либо через VPCE (конечную точку VPC), либо через IGW (Интернет-шлюз), она не знает, какой из них выбрать, когда запрос возвращаюсь обратно. Поскольку он не знает, какой выбрать - просто время ожидания.
Маршрутизация выбирает путь наименьшего сопротивления, поэтому добавление VPCE в частную подсеть сделало маршрут VPCE идеальным. Хотя здесь стоит упомянуть, что запрос вообще не проходит через общедоступную подсеть, поскольку теперь у него есть VPCE в частной подсети.

В зависимости от используемой вами настройки и от того, действительно ли вам нужен IGW для чего-либо еще, кроме связи с S3, можно либо отбросить IGW из общедоступной подсети, либо сбросить связь шлюза NAT между частной и общедоступной подсетями. Оба эти варианта должны немного очистить таблицы маршрутизации, не нарушая при этом решения.

Добавление конечной точки S3 в частную подсеть решило проблему.

Оказывается, наша проблема была связана с доступом к S3. Наша установка в то время была:

Шлюз NAT, работающий в публичной подсети
Конечная точка S3 в общедоступной подсети (с более высоким приоритетом маршрутизации, чем интернет-шлюз)
Правило по умолчанию для трафика в частных подсетях, проходящего через NAT.

Похоже, что трафик не направлялся через NAT к S3 ни через общедоступный Интернет, ни через конечную точку S3. Я до сих пор не знаю почему.

Во-первых, очевидное: cloudwatch.s3.amazonaws.com не является одной из конечных точек Cloudwatch.

Конечные точки Cloudwatch представлены в виде monitoring.[aws-region].amazonaws.com.

Например, в us-west-2 регион, конечная точка https://monitoring.us-west-2.amazonaws.com.

http://docs.aws.amazon.com/general/latest/gr/rande.html#cw_region

Кроме того, даже если ваша маршрутизация, NAT или сеть иным образом настроены неправильно, разрешение DNS невосприимчиво ко многим неправильным настройкам из-за того, как оно реализовано в VPC ... поэтому тот факт, что он работает, не говорит вам, есть ли у вас подключение к Интернету , В основном.