我们在私有子网中有一个实例，该实例具有托管 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
对于可能发生的事情您有什么想法吗？
答案1
我实际上也遇到了同样的问题，并设法以与 JustinHK 相同的方式解决了它。我已经联系了 AWS 以了解为什么会发生这种情况，因为我无法放过它，所以这应该有助于解释这种行为。以下是细分：
- 问题不在于流量无法到达目的地，而在于流量无法正确返回原点。
- 由于公共子网（NAT 网关所在的位置）有 2 个到达目的地的选项 - 通过 VPCE（VPC 端点）或通过 IGW（Internet 网关），因此当请求返回时，它不知道该选择哪一个。由于不知道该选择哪一个 - 它只是超时。
- 路由选择阻力最小的路径，因此在私有子网中添加 VPCE 使 VPCE 路由成为理想路由。不过这里值得一提的是，请求根本不会经过公共子网，因为它现在在私有子网中有一个 VPCE。
根据您正在运行的设置以及除了连接 S3 之外是否真的需要 IGW 做其他事情，可以从公共子网中删除 IGW，也可以删除私有子网和公共子网之间的 NAT 网关链接。这两个选项都应该在不破坏解决方案的情况下稍微清理路由表。
答案2
在私有子网中添加 S3 端点解决了该问题。
事实证明，我们的问题与访问 S3 有关。我们当时的设置是：
- 在公共子网中运行的 NAT 网关
- 公共子网中的 S3 端点（具有比互联网网关更高的路由优先级）
- 私有子网中的流量通过 NAT 的默认规则。
看来流量没有通过 NAT 路由到 S3，无论是通过公共互联网还是通过 S3 端点。我仍然不知道原因。
答案3
首先，显而易见的是：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 中的实施方式，它也不会受到许多错误配置的影响……因此，它有效这一事实并不能告诉您是否具有 Internet 连接。