Amazon ANS-C01: 自动化、IaC 与网络运维 — 学习指南

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

属于 AWS Advanced Networking Specialty ANS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

核心概念

AWS 网络的基础设施即代码 (Infrastructure as Code) 将网络拓扑、安全策略和路由转化为声明式模板和确定性的生命周期操作。CloudFormation 模板（AWS::EC2::VPC、AWS::EC2::Subnet、AWS::EC2::RouteTable、AWS::EC2::TransitGateway、AWS::EC2::TransitGatewayAttachment、AWS::ElasticLoadBalancingV2::LoadBalancer、AWS::EC2::VPCEndpoint、AWS::EC2::NetworkAcl、AWS::EC2::SecurityGroup）编码所需的状态，而 CloudFormation API——CreateStack、UpdateStack、DeleteStack、DescribeStacks 和 ChangeSet 操作——则原子化地应用变更。使用嵌套堆栈和模块化模板来隔离网络域（共享服务、各账户的应用 VPC、入口/出口区域），并使用 StackSets 在 AWS Organizations 中部署一致的网络堆栈。漂移检测 (DetectStackDrift) 和变更集提供了护栏，使自动化能够检测出带外网络变更并要求人工审查。

自动化还必须覆盖 CloudFormation 无法原生表达或需要生命周期挂钩的部分：跨账户资源共享、本地集成以及主机上的运行时配置。CloudFormation 自定义资源（由 Lambda 支持）或 CloudFormation 模块可以调用 CreateResourceShare (AWS RAM) 等 API 来共享 Transit Gateway 或子网，或者调用 Systems Manager (SSM) SendCommand 向实例中注入证书或路由策略。对于 EKS 中的 Kubernetes，AWS Load Balancer Controller 通过 Helm 安装并通过 Service 注解进行管理；CloudFormation 可以通过 AWS::EKS::Cluster 和自定义资源来预置 IAM 角色、OIDC 提供商和 HelmRelease 对象，但 pod IP 到 NLB 目标组的运行时映射由控制器处理。

关键服务与配置

在自动化网络操作时，您会反复使用一些主要的 AWS 服务和 API：CloudFormation (CreateStack, UpdateStack, DetectStackDrift)、AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare)、AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute)、Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes)、AWS Lambda (CreateFunction, AddPermission, Invoke)、Systems Manager (PutParameter, SendCommand, CreateDocument) 和 AWS Config (PutEvaluations, StartConfigurationRecorder)。这些服务构成了安全、可审计网络自动化的典型技术栈。

在设计模板和自动化时，需要注意特定的资源属性和控制器注解。对于负载均衡器，选择正确的类型和属性：带有 TCP 侦听器的 NLB 会保留源 IP，并通过 CreateLoadBalancer/ModifyTargetGroupAttributes 以及在目标组上设置 “proxy_protocol_v2.enabled” 来支持 Proxy Protocol v2；ALB (Application Load Balancer) 会终止 TLS，为客户端 IP 插入 X-Forwarded-For 标头，并在配置了 HTTPS 侦听器时支持 gRPC/HTTP2。对于 EKS，您可以使用 service.beta.kubernetes.io/aws-load-balancer-type: “nlb” 等注解或 AWS Load Balancer Controller 的 Ingress/Service 注解来控制 TLS 是直通还是终止，并将目标类型设置为 ip 以直接定位 pod。对于跨账户共享和多账户网络，您将使用 AWS RAM 共享 Transit Gateway，并结合 CloudFormation StackSets 和委托管理员角色在消费者账户中创建附件和访问权限。

设计模式与权衡

两种常见且形成对比的模式是：使用 Transit Gateway 的中心辐射型（hub-and-spoke）模式和通过 AWS RAM 实现的共享 VPC 模式。使用 Transit Gateway 的中心辐射型模式可以集中化路由、检查和 VPC 间连接；它具有良好的扩展性，因为附件和路由表允许分段，而且您可以使用 RAM 共享 TGW，这样不同的账户就可以创建附件而无需转移全部所有权。其权衡之处在于路由传播和路由表限制：Transit Gateway 的路由表和附件限制需要规划，并且可能引入必须强制执行策略的单点（使用多个路由表和 AWS Network Firewall 来隔离流量）。共享 VPC（通过 AWS RAM 共享 VPC）将子网放置在宿主账户中，并允许消费者账户在这些子网中启动资源，这简化了连接的集中式安全控制，但降低了账户级别的自主性，并使按业务单元进行网络隔离变得复杂，因为必须仔细管理安全组所有权和 IAM 边界。

对于入口和 TLS 终止，您必须在端到端加密的需求与扩展性和客户端 IP 保留之间取得平衡。如果您需要在负载均衡器上终止 TLS（用于 WAF、证书集中管理和 HTTP 路由），ALB 是正确的工具；它会添加 X-Forwarded-For，以便应用程序日志可以捕获客户端 IP，并且 ALB 支持基于路径和主机的路由到多个目标组。如果您需要真正的端到端 TLS 或 mTLS，即负载均衡器不得解密流量，请使用 TCP 模式的 NLB 将 TLS 直通到后端端点（pod 或实例），并在 Kubernetes 上配置目标类型为 ip 和 externalTrafficPolicy: Local 以保留源 IP。对于数千个带有 mTLS 的并发双向 gRPC 连接，NLB 将原始 TLS 流量转发到 pod 端口，并结合 pod 自身终止 mTLS 的方案，既提供了可扩展性，也实现了真正的端到端加密，同时使用 AWS Load Balancer Controller 注解来创建正确的 NLB 侦听器和目标组。

常见陷阱与决策标准

一个常见的陷阱是混淆 TLS 终止位置与客户端 IP 需求：当 ALB 终止 TLS 时，它会提供 X-Forwarded-For，但它不像 NLB 那样将源 IP 保留到目标。如果您同时需要 ALB 的功能（如基于主机/路径的路由、WAF）和后端的原始源 IP，可以考虑使用 ALB 进行 HTTP 终止，然后转发到反向代理或 sidecar，由它们从 X-Forwarded-For 中重建源 IP；或者采用一种架构，让 NLB 将 TLS 直通到执行 mTLS 的服务，并将 HTTP 路由卸载到集群内的代理。另一个陷阱是错误配置跨账户权限：当使用 RAM 共享 Transit Gateway 或其他网络资源时，请确保使用显式的资源共享以及正确的 IAM 角色和 RAM 主体；否则会导致不透明的“permission denied”错误。

在合规性自动化方面，不要将私钥或 CA 材料以未加密的明文形式存储。应使用 SSM Parameter Store SecureString，并配合一个拥有最小化密钥策略的 KMS 密钥，该策略仅允许需要访问的角色和主体。使用 AWS Config 托管规则（例如，vpc-flow-logs-enabled、restricted-common-ports、security-group-rule-check），当托管规则无法满足您的标准时，可以实施调用 PutEvaluations 的、由 Lambda 支持的 Config 规则。修复操作应通过 SSM Automation 文档或 Systems Manager Run Command 实现自动化，Config 修复操作可以调用它们，但对于高风险变更，务必提供告警和审批路径。

实践问题：用例场景

公司：ApexTelemetrics — 挑战：提供一个全球可达、托管在 EKS 上的 gRPC 服务，该服务要求真正的端到端双向 TLS（客户端和服务器使用 mTLS 进行身份验证），支持数千个基于 TCP 443 的并发长连接，必须能自动扩缩 Pod，并确保证书的分发和轮换是自动化的且可审计的。

方法：

使用 CloudFormation 配置网络和负载均衡器：通过 AWS::ElasticLoadBalancingV2::LoadBalancer 创建一个 NLB，为其配置 TCP 443 端口的侦听器，以及将 targetType 设置为 “ip” 并进行 TCP 健康检查的目标组。使用 CloudFormation 的 CreateStack/UpdateStack 和模块化的嵌套堆栈来创建 VPC、子网和 NLB。在 EKS Service 上使用 AWS Load Balancer Controller 注解 (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”)，以便每个 Service 直接将流量路由到 Pod，从而创建 NLB 目标组。
确保 TLS 直通并在 Pod 中进行 mTLS 终止：配置 EKS Service 将 TCP 443 流量直接转发到 Pod 端口；在每个 Pod 内部署一个 sidecar 或 envoy 代理，用于与客户端执行 mTLS 终止并强制执行双向认证。在 Service 上设置 externalTrafficPolicy: Local，以便在需要时保留源 IP，并使用 Pod 级别的自动扩缩（Horizontal Pod Autoscaler）配合 Cluster Autoscaler 来同步扩展节点和 Pod。
自动化证书生命周期和分发：将 CA 和服务器证书的私钥存储在由 KMS 密钥加密的 SSM Parameter Store SecureString 中。在 CloudFormation 中创建一个由 AWS Lambda 支持的自定义资源，以便在堆栈创建期间创建 SSM 参数（使用适当的 IAM 角色创建 CreateFunction，然后使用 CloudFormation 自定义资源调用 PutParameter）。使用 SSM Run Command 或一个不可变的 DaemonSet，通过绑定到 Pod 的 IAM 角色（通过 IRSA）从 SSM 中拉取密钥，并将证书注入到 sidecar 中。对于轮换，可以调度 Lambda 函数（CreateFunction + EventBridge 规则）来生成新证书、调用 PutParameter，并使用 SSM 或 Kubernetes Jobs 执行滚动重启。
合规性与审计：启用 AWS Config 规则（如 vpc-flow-logs-enabled 等托管规则，以及使用 PutEvaluations 的自定义 Lambda 支持规则），以验证 NLB 侦听器是 TCP 类型，并且没有 ALB 为此服务终止 TLS。配置 Config 修复操作，以便在检测到错误配置时调用 SSM Automation 文档，并将发现结果发送到 AWS Security Hub 和 CloudWatch Events。 AWS 理由：TCP 模式下的 NLB 提供了端到端 mTLS 所需的真正 TLS 直通能力，并且能够扩展到数千个并发连接，同时在负载均衡器上每个连接的 CPU 占用很小。通过 targetType=ip 直接将目标指向 Pod，移除了一个额外的网络跳数，并保持了自动扩缩的响应性。将密钥存储在由 KMS 保护的 SSM Parameter Store 中并进行轮换，提供了集中化、可审计且受 IAM 控制的密钥管理。而使用 CloudFormation 加上 Lambda 自定义资源和 EventBridge，确保了整个生命周期都被代码化、可重复且可观察。

← 网络性能与监控 · 所有领域 · 容器与 Serverless 网络 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →