S3：本地访问应选网关型还是接口型终端节点

两种 S3 终端节点在设计评审中看起来可以互换，但客户端一旦离开站点，行为就完全不同。网关终端节点是 VPC 内的路由表集成，因此来自站点 VPN 的请求永远不会以私有目的地的身份到达它。接口终端节点把私有地址放在网络接口上，混合路径确实可以到达那里。接下来的一切都取决于你选择了这两种中的哪一种。

按网络入口判断，而不是按服务名称

从流量产生的位置开始，因为终端节点类型回答的正是这个问题。受支持 VPC 环境中的工作负载可以使用网关终端节点，永远不需要自己的私有地址。本地站点的工作负载需要一个可以路由到的私有地址，而这正是接口终端节点提供的。如果设计同时混用两者，两种终端节点类型可以在同一个 VPC 中共存，这是正常安排而不是重复。

混用它们不是问题。假定一种类型能覆盖另一种才是问题。

在做任何选择之前先对客户端分类。VPC 内的工作区、NAT 网关后的容器和分支机构的应用程序是三种不同的来源，只有最后一种会强制使用混合入口。把这一分类写在终端节点清单旁边，好让下一位评审者看清每个终端节点为何存在。

接口路径从头到尾需要什么

接口终端节点提供对私有地址的可达性，而可达性只是四项要求之一。本地网络需要通往这些地址的路由，VPC 一侧需要回程路径，终端节点的安全组必须放行源地址段，两者之间的任何检查设备都必须允许该流量通过。通往 VPC 中某台实例的路由并不能证明这四项中的任何一项。

从远端往回推。确认终端节点的网络接口存在于你预期的子网中，然后确认它的安全组放行的是真实的本地地址段而不是占位符。接着检查隧道或线路是否在同一方向上承载回程路径。检查是人们容易跳过的一步，因为允许连接的中转设备仍然可能丢弃更大的响应体，而那看起来像吞吐问题而不是策略问题。

用可用的最小授权操作来测试，而不是用大文件下载。故障出现得更早，需要解释的流量也更少。

DNS 跟随查询来源，而不是跟随 VPC

已存在的终端节点本身不会重定向任何东西。应用程序收到的是解析器返回的名称，而解析器按照它被允许看到的视图来回答。VPC 内的实例和办公室的笔记本提出两个不同的问题，却都能得到正确但不同的答案。验证一个就对另一个下结论，正是让通过的测试变成失败的部署的原因。

把终端节点的私有 DNS 设置当作设计的一部分来读，而不是当作上线后再勾选的选项。

如果办公室的解析器必须看到 VPC 的视图，这条路径就必须有意构建，通常通过入站解析器终端节点实现。从应用程序自身的上下文发起查询，并记录是哪个解析器作答。在 VPC 内堡垒主机上收集到的结果只描述堡垒机的视图，别的什么也说明不了。

权限与可达性是两回事

可达的终端节点会为不允许主体发起的请求返回错误，而这个错误说明系统正按设计工作。身份策略、桶策略以及任何终端节点策略都在各自的层面评估。网络访问从来没有授予过权限。

用两个结果来接受设计：一次成功的无害授权调用，以及对被排除的身份或桶的一次预期拒绝。

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

在每项结果旁边记录终端节点名称、解析出的目的地和策略上下文，因为之后一次 DNS 变更就可能让整个结论失效。在准备任何资源之前，比较两种终端节点当前的费用和运维负担。接口终端节点买到的是混合私有入口，它不是普遍必需，而对 VPC 内的工作负载来说网关路径往往仍是更好的答案。选择是按客户端做出的，并且始终可以重新审视。