Amazon ANS-C01: Network Performance and Monitoring — 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.
Enhanced networking and low-latency fabric
Enhanced networking in AWS is the set of OS- and hypervisor-level features that significantly increase packets-per-second, reduce latency and CPU overhead, and expose higher throughput per virtual interface. The primary technologies are the Elastic Network Adapter (ENA), which provides SR-IOV-based high-performance networking for most modern EC2 instance families, and the Elastic Fabric Adapter (EFA), which is an OS-bypass RDMA-like device designed for HPC and tightly-coupled MPI/libfabric workloads. To enable ENA you confirm the instance type supports ENA and the Linux AMI has the ENA driver; programmatically you can enable or query it with EC2 API calls such as RunInstances with InterfaceType=efa when needed, or ModifyInstanceAttribute for ena support. EFA is attached by creating a network interface with InterfaceType=efa (aws ec2 create-network-interface –interface-type efa) or launching instances with an EFA-enabled network interface; the instance must run a supported kernel and the libfabric/efa kernel module and typically be placed in a cluster placement group to get the lowest intra-host latency and highest bisection bandwidth.
Placement groups affect performance by controlling instance placement within the underlying networking fabric. A cluster placement group biases instances onto a single rack or a low-latency network domain to enable maximum east-west bandwidth and consistent latency — this is required for many EFA use-cases. A spread placement group enforces host-level spread to avoid correlated failures but does not improve latency. For bursty high-throughput scenarios, instance family and vCPU count define baseline networking bandwidth quotas; for example, certain instance sizes advertise up to 25 Gbps or 100 Gbps, but packet processing and TCP stacks can become bottlenecks without ENA/EFA. When architecting for thousands of concurrent TCP connections (gRPC over TLS, for example), choose instance types with high concurrent connection capacity, enable ENA, and prefer NLB / target-type=ip for direct pod addressing when running in EKS to avoid node port bottlenecks.
Key services and configuration for observability and enforcement
Monitoring network health and diagnosing bottlenecks relies on a combination of VPC Flow Logs, CloudWatch metrics, Traffic Mirroring, and Reachability/Access analyzers. VPC Flow Logs provide per-flow metadata (src/dst IP, ports, packets, bytes, action) that you can send to CloudWatch Logs or S3 and query with CloudWatch Logs Insights to find high-volume prefixes or top talkers. For live packet-level inspection, Traffic Mirroring lets you create a mirror target and a filter and then create sessions (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) to copy traffic from ENIs to an inspection appliance running in EC2 or to AWS Network Packet Broker partners.
CloudWatch exposes the relevant metrics for different layers: EC2 instance metrics such as NetworkIn/NetworkOut and NetworkPacketsIn/NetworkPacketsOut, Application Load Balancer metrics under AWS/ApplicationELB like RequestCount, ActiveConnectionCount and ClientTLSNegotiationErrorCount, Network Load Balancer metrics under AWS/NetworkELB such as ProcessedBytes and NewFlowCount, and AWS/DirectConnect metrics for virtual interface BytesIn/BytesOut. Use CloudWatch Alarms and Contributor Insights on flow logs to detect saturating flows. For path and configuration validation, Reachability Analyzer (via the EC2 API StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) lets you model and test end-to-end packet paths through route tables, NACLs, security groups, and VPN/Direct Connect attachments, while Network Access Analyzer helps detect unintended network access paths across your VPCs and AWS Organizations.
Design patterns and trade-offs around load balancing and secure access
When you require true end-to-end TLS with mutual TLS at the backend while supporting thousands of gRPC connections, a Network Load Balancer in TCP mode is the preferred pattern. An NLB preserves client source IP by default and can be created by the AWS Load Balancer Controller for EKS services using annotations such as service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” and target-type=ip to send directly to pod IPs. Using TCP passthrough on port 443 means the backend pod terminates mutual TLS (client and server cert verification), so traffic is never decrypted in the load balancer, preserving two-way authentication. This pattern scales connection counts well because the NLB is designed for millions of concurrent connections and low per-connection overhead.
For architectures that require TLS termination at the load balancer and path-based routing to multiple target groups, the Application Load Balancer is the right choice because it supports HTTP/2 and gRPC, path-based routing, and host-based rules. To provide accurate client IP logging when the ALB terminates TLS, ensure the backend application parses X-Forwarded-For headers (ALB injects them automatically) or use the PROXY protocol with NLB if you need source IP preservation at the TCP layer. If you use Global Accelerator to provide static anycast front-end IPs and want to prevent clients from bypassing the accelerator and hitting the ALB URL directly, lock down the ALB’s security group to accept inbound only from the accelerator’s static IPs (the two static addresses assigned to the accelerator) so direct internet access is denied.
For multi-account shared services with strict per-business-unit controls and scale, AWS PrivateLink (VPC Endpoint Services backed by internal NLBs) is often the most secure and scalable pattern. The shared-services VPC publishes services via Network Load Balancer endpoints (aws ec2 create-network-interface with target groups) and exposes them as a VPC Endpoint Service. Consumer accounts create interface endpoints in their VPCs that attach to the provider’s NLB; the provider controls access via endpoint policies and security groups, and traffic never traverses a centralized routing plane. Transit Gateway is appropriate when you need full routing visibility and transitive connectivity, but it centralizes routing and is less granular for per-service access control than PrivateLink.
Common pitfalls and decision criteria
A frequent mistake is assuming instance advertised bandwidth is unlimited; instance families and sizes set hard network limits and scaling should consider split across ENIs and placement in cluster placement groups for consistent performance. Another pitfall is relying solely on CloudWatch NetworkIn/NetworkOut without correlating VPC Flow Logs to attribute traffic to a particular VPC, subnet, or business unit; Flow Logs and Traffic Mirroring are necessary to isolate which virtual interface or application is causing Direct Connect saturation. Also avoid terminating TLS at the ALB when mutual TLS is required end-to-end—if policy requires the backend see the client cert, choose TLS passthrough with NLB or perform TLS bridging with proper cert validation but be explicit about where trust is established.
When diagnosing intermittent saturation on shared physical links like Direct Connect, correlate metrics across layers: AWS/DirectConnect metrics for virtual interfaces, VPC Flow Logs for per-subnet/ENI byte counts, and EC2 Network* metrics for instance-level behavior. Use Reachability Analyzer to validate whether asymmetric routing or mistaken route propagation is causing return-path issues, and use Traffic Mirroring to capture packet dumps for deep protocol inspection.
Practical Problem: Use-Case Scenario
AcmeIoT faces an issue where vending machines worldwide must connect over gRPC with mutual TLS to an EKS-hosted backend, connections must number in the thousands, the service must stay encrypted end-to-end, and backend pods scale dynamically with the Cluster Autoscaler and HPA.
Create an AWS LoadBalancer of type Network Load Balancer for the Kubernetes Service, using the AWS Load Balancer Controller and annotations to specify NLB and target-type=ip (service.beta.kubernetes.io/aws-load-balancer-type: “nlb” and service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: “ip”). Configure a TCP listener on port 443 so the NLB performs pure TCP passthrough; do not configure TLS certificates on the NLB.
Implement mutual TLS termination and validation in the application pods. Each pod should present a server certificate and validate client certificates, using a short-lived certificate rotation process integrated with AWS Secrets Manager or SSM Parameter Store. Ensure pod IPs are reachable by using target-type ip and that the health checks are TCP or gRPC health checks configured on the target group.
Ensure high connection scale by choosing instances with ENA support and sufficient network bandwidth, enable ENA (confirm with the ENA driver in the AMI and use aws ec2 modify-instance-attribute to enable ena-support where needed), and deploy pods across multiple nodes with the Cluster Autoscaler scaling nodes based on pod requests. Use placement groups for tightly-coupled clusters needing consistent latency and deploy sufficient node counts across AZs.
Monitor and validate using CloudWatch and VPC Flow Logs. Create CloudWatch metrics and alarms for NLB ActiveFlowCount/NewFlowCount and EKS worker EC2 NetworkIn/Out. Use VPC Flow Logs to identify any top-talkers and Reachability Analyzer (StartNetworkInsightsAnalysis/CreateNetworkInsightsPath) to validate routing paths during autoscaling events. If you need packet-level debugging, create Traffic Mirroring sessions to an inspection instance.
AWS rationale: a Network Load Balancer in TCP mode preserves source IP, supports massive concurrent connections, and allows end-to-end TLS because it does not terminate TLS. Target-type ip with the AWS Load Balancer Controller integrates with EKS autoscaling semantics so new pod IPs are registered as targets dynamically. ENA and proper instance sizing provide the raw networking capacity to handle thousands of concurrent TLS connections without host CPU exhaustion, and the combination of CloudWatch, VPC Flow Logs, Reachability Analyzer, and Traffic Mirroring provides the observability required to detect and remediate saturation or routing issues.
← Content Delivery and Edge Networking · All domains · Automation →
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 →