Amazon ANS-C01: Automation, IaC and Network Operations — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concept
Infrastructure as Code for networking on AWS turns network topology, security policy and routing into declarative templates and deterministic lifecycle operations. CloudFormation templates (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) encode the desired state, while CloudFormation APIs—CreateStack, UpdateStack, DeleteStack, DescribeStacks and ChangeSet operations—apply changes atomically. Use nested stacks and modular templates to isolate networking domains (shared services, per-account application VPCs, ingress/egress zones) and StackSets to propagate consistent network stacks across AWS Organizations. Drift detection (DetectStackDrift) and change sets provide guardrails so automation can detect and require human review for out-of-band network changes.
Automation must also cover the parts of the network that CloudFormation cannot natively express or that require lifecycle hooks: cross-account resource sharing, on-prem integrations, and runtime configuration on hosts. CloudFormation custom resources (backed by Lambda) or CloudFormation modules can call APIs such as CreateResourceShare (AWS RAM) to share a Transit Gateway or subnet, or call Systems Manager (SSM) SendCommand to inject certificates or routing policies into instances. For Kubernetes in EKS, the AWS Load Balancer Controller is installed via Helm and managed through Service annotations; CloudFormation can provision the IAM role, OIDC provider and HelmRelease objects via AWS::EKS::Cluster and custom resources, but the runtime mapping of pod IPs to NLB target groups is handled by the controller.
Key services and configuration
There are primary AWS services and APIs you will use repeatedly when automating network operations: 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), and AWS Config (PutEvaluations, StartConfigurationRecorder). These services form a typical automation stack for secure, auditable networking.
When designing templates and automation, pay attention to specific resource attributes and controller annotations. For load balancers, choose the correct type and attributes: an NLB with TCP listeners preserves source IP and supports Proxy Protocol v2 via the CreateLoadBalancer/ModifyTargetGroupAttributes and setting “proxy_protocol_v2.enabled” on target groups; an ALB (Application Load Balancer) terminates TLS and inserts X-Forwarded-For headers for client IPs and supports gRPC/HTTP2 when configured with HTTPS listeners. For EKS you use annotations such as service.beta.kubernetes.io/aws-load-balancer-type: “nlb” or the AWS Load Balancer Controller’s Ingress/Service annotations to control TLS passthrough versus termination and to set target type to ip for direct pod targeting. For cross-account sharing and multi-account networks you will use AWS RAM to share Transit Gateways, and CloudFormation StackSets combined with delegated admin roles to create attachments and access in consumer accounts.
Design patterns and trade-offs
Two common, contrasting patterns are hub-and-spoke with Transit Gateway and shared-VPC via AWS RAM. Hub-and-spoke with a Transit Gateway centralizes routing, inspection and inter-VPC connectivity; it scales because attachments and route tables allow segmentation, and you can share the TGW using RAM so different accounts can create attachments without transferring full ownership. The trade-off is route propagation and route table limits: Transit Gateway route tables and attachment limits require planning and can introduce single points where policy must be enforced (use multiple route tables and AWS Network Firewall to isolate traffic). Shared VPC (VPC share with AWS RAM) places subnets in a host account and lets consumer accounts launch resources into those subnets, which simplifies central security controls for connectivity but reduces account-level autonomy and complicates per-business-unit network isolation because security group ownership and IAM boundaries must be carefully managed.
For ingress and TLS termination you must balance the need for end-to-end encryption against scale and client IP preservation. If you require TLS termination at the load balancer (for WAF, certificate centralization, and HTTP routing), ALB is the right tool; it adds X-Forwarded-For so application logging can capture client IPs, and ALB supports path- and host-based routing to multiple target groups. If you require true end-to-end TLS or mTLS where the load balancer must not decrypt traffic, use an NLB in TCP mode to pass through TLS to backend endpoints (pod or instance) and configure target type ip and externalTrafficPolicy: Local on Kubernetes to preserve source IP. For thousands of concurrent bidirectional gRPC connections with mTLS, an NLB forwarding raw TLS to pod ports combined with pods terminating mTLS provides scalability and true end-to-end encryption, while using the AWS Load Balancer Controller annotations to create the proper NLB listeners and target groups.
Common pitfalls and decision criteria
A frequent pitfall is confusing TLS termination location with client IP requirements: ALB provides X-Forwarded-For when it terminates TLS, but it does not preserve source IP to the target as NLB does. If you need both ALB features (host/path routing, WAF) and original source IP at the backend, consider using ALB for HTTP termination and forwarding to reverse proxies or sidecars that reconstruct source IPs from X-Forwarded-For, or use an architecture where an NLB passes through TLS to services that do mTLS and offload HTTP routing to in-cluster proxies. Another pitfall is misconfiguring cross-account permissions: when sharing a Transit Gateway or other network resource with RAM, ensure you use an explicit resource share and the correct IAM role and RAM principal; failing to do so yields opaque “permission denied” errors.
On compliance automation, do not store private keys or CA material unencrypted in plain text. Use SSM Parameter Store SecureString with a KMS key that has a minimal key policy allowing only the roles and principals that require access. Use AWS Config managed rules (for example, vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check) and where managed rules don’t cover your criteria, implement Lambda-backed Config rules that call PutEvaluations. Remediation should be automated via SSM Automation documents or Systems Manager Run Command that the Config remediation action can invoke, but always provide an alerting and approval path for high-risk changes.
Practical Problem: Use-Case Scenario
Company: ApexTelemetrics — challenge: provide a globally reachable EKS-hosted gRPC service that requires true end-to-end mutual TLS (client and server authenticate with mTLS), supports thousands of concurrent long-lived connections over TCP 443, must autoscale pods, and ensure that certificate distribution and rotation is automated and auditable.
Approach:
- Provision network and load balancer with CloudFormation: create an NLB via AWS::ElasticLoadBalancingV2::LoadBalancer configured with TCP listener on port 443 and target groups with targetType set to “ip” and health checks on TCP. Use CloudFormation CreateStack/UpdateStack and modular nested stacks for VPC, subnets and NLB. Use AWS Load Balancer Controller annotations on the EKS Service (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”) so each Service creates the NLB target group directly into pods.
- Ensure TLS passthrough and mTLS termination at pods: configure the EKS Service to forward TCP 443 directly to pod ports; implement a sidecar or envoy proxy inside each pod that performs mTLS termination with the client and enforces mutual authentication. Set externalTrafficPolicy: Local on the Service so source IP is preserved if needed, and use Pod-level autoscaling (Horizontal Pod Autoscaler) with Cluster Autoscaler to scale nodes and pods together.
- Automate certificate lifecycle and distribution: store CA and server certificate private keys in SSM Parameter Store SecureString encrypted by a KMS key. Create an AWS Lambda backed custom resource in CloudFormation to create SSM parameters during stack creation (CreateFunction with proper IAM role, then CloudFormation custom resource to call PutParameter). Use SSM Run Command or an immutable DaemonSet that pulls secrets from SSM via IAM role bound to the pod (via IRSA) to inject certificates into the sidecar. For rotation, schedule Lambda functions (CreateFunction + EventBridge rule) to generate new certs, PutParameter, and use SSM or Kubernetes Jobs to perform rolling restarts.
- Compliance and audit: enable AWS Config rules (managed rules such as vpc-flow-logs-enabled and custom Lambda-backed rules using PutEvaluations) to verify that the NLB listeners are TCP and that no ALB is terminating TLS for this service. Configure Config remediation to invoke SSM Automation documents if misconfiguration is detected and send findings to AWS Security Hub and CloudWatch Events. AWS rationale: NLB in TCP mode provides true TLS passthrough required for end-to-end mTLS and scales to thousands of concurrent connections with a small per-connection CPU footprint at the load balancer. Targeting pods via targetType=ip removes an extra hop and keeps autoscaling responsive. Storing and rotating keys in SSM Parameter Store secured by KMS provides centralized, auditable secrets management with IAM controls, and using CloudFormation plus Lambda custom resources and EventBridge ensures the whole lifecycle is codified, repeatable, and observable.
← Network Performance and Monitoring · All domains · Container and Serverless Networking →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →