Enhanced Networking

AWS VPC Lattice – Service-to-Service Networking

~ Last updated on : ~ Kiro Agent

AWS VPC Lattice – Application-Layer Service Networking

Amazon VPC Lattice is a fully managed application networking service that connects, secures, and monitors service-to-service and service-to-resource communication across multiple VPCs and AWS accounts — without requiring VPC peering, Transit Gateway, or complex networking configurations. VPC Lattice operates at the application layer (Layer 7), providing built-in service discovery, traffic management, access controls, and observability for modern distributed architectures.

VPC Lattice is the AWS-recommended replacement for AWS App Mesh (which reaches End of Life on September 30, 2026) and eliminates the need for sidecar proxies, simplifying service mesh patterns significantly.

Key Benefits

  • No network complexity — Connect services across VPCs and accounts without VPC peering, Transit Gateway, or CIDR coordination.
  • Application-layer routing — Route based on HTTP path, headers, methods, and query parameters.
  • Built-in security — IAM-based auth policies for service-to-service authorization without code changes.
  • Compute agnostic — Works with EC2, ECS, EKS, Fargate, and Lambda targets in a single service.
  • No sidecars required — Unlike App Mesh or Istio, VPC Lattice operates as infrastructure — no Envoy proxy injection needed.
  • Overlapping CIDR support — Services in VPCs with identical IP ranges can communicate seamlessly.
VPC Lattice — Cross-VPC Service Networking
VPC A (Account 1)
ECS Service
Lambda Function
→
VPC Lattice Service Network
IAM Auth | Routing Rules | Observability
Service A
Service B
→
VPC B (Account 2)
EKS Pods
EC2 Instances
No VPC Peering needed • No Transit Gateway • Layer 7 with weighted routing

VPC Lattice Architecture

VPC Lattice introduces a layered architecture with distinct components that separate concerns between network administrators and service owners.

Service Network

  • A service network is a logical boundary — a collection of services and resource configurations that can communicate with each other.
  • VPCs are associated with a service network to enable client connectivity.
  • Clients in an associated VPC can automatically discover and connect to all services/resources in the service network.
  • Service networks can be shared across accounts using AWS Resource Access Manager (RAM).
  • Auth policies can be attached at the service network level for coarse-grained access control.
  • Multiple service networks can be associated with a single VPC using VPC endpoints of type “service network.”
  • Service networks are Regional resources.

Services

  • A service represents an independently deployable application unit (microservice).
  • Similar to an Application Load Balancer — consists of listeners, rules, and target groups.
  • Each service gets a unique DNS name (FQDN) automatically registered in Route 53.
  • Custom domain names are supported with SSL/TLS certificates via ACM.
  • Services can be associated with one or more service networks.
  • Fine-grained auth policies can be attached at the individual service level.

Target Groups

  • A target group is a collection of compute resources that run your application.
  • Supported target types:
    • EC2 instances — Instance IDs
    • IP addresses — For any IP-addressable resource
    • Lambda functions — Serverless targets
    • Application Load Balancers — Existing ALB targets
    • Amazon ECS tasks — Direct ECS integration
    • Kubernetes Pods — Via AWS Gateway API Controller
  • Health checks are supported to route traffic only to healthy targets.
  • Targets can span multiple Availability Zones for high availability.

Listeners

  • A listener checks for incoming connection requests using a specified protocol and port.
  • Supported protocols: HTTP, HTTPS, TLS Passthrough (for end-to-end encryption).
  • gRPC is supported over HTTP/2.
  • Each listener has a default action and can have multiple rules.

Rules

  • Rules define how the listener routes requests to target groups.
  • Conditions can match on: HTTP method, path pattern, headers, and query parameters.
  • Actions include: forward to target group(s), with optional weighted routing for traffic splitting.
  • Rules have priorities — evaluated in order from lowest to highest number.
  • A default rule handles requests that don’t match any other rule.

Resource Configurations and Resource Gateways (GA at re:Invent 2024)

  • A resource configuration represents a TCP-based resource (e.g., RDS database, IP address, domain name) that can be shared across VPCs/accounts.
  • A resource gateway is a point of ingress into the VPC where the resource resides, spanning multiple Availability Zones.
  • Enables private cross-account access to databases and other TCP resources without NLB or PrivateLink Endpoint Services.
  • Resource configurations can be shared via AWS RAM and associated with service networks.

Key Features

Cross-VPC and Cross-Account Communication Without Peering

  • VPC Lattice enables service-to-service connectivity across VPCs and accounts without VPC peering, Transit Gateway, or PrivateLink endpoint services.
  • No CIDR coordination required — supports overlapping IP address ranges between VPCs.
  • Network address translation is handled transparently between IPv4 and IPv6 address spaces.
  • Services are shared across accounts using AWS Resource Access Manager (RAM).
  • VPC association with a service network is the only requirement for connectivity.

Weighted Routing (Traffic Splitting)

  • Forward rules support weighted target groups for traffic distribution.
  • Assign weights (0-999) to multiple target groups within a single rule to split traffic proportionally.
  • Use cases:
    • Blue/green deployments — Shift traffic gradually from old to new version.
    • Canary releases — Send a small percentage (e.g., 5%) to the new version for validation.
    • A/B testing — Split traffic between different service implementations.
  • Instant rollback by adjusting weights back to 100% on the stable target group.

Auth Policies with IAM (Authorization)

  • VPC Lattice uses IAM resource policies (auth policies) for service-to-service authorization.
  • Supports the standard IAM Principal-Action-Resource-Condition (PARC) model.
  • Auth policies can be applied at two levels:
    • Service network level — Coarse-grained (e.g., “only authenticated requests from my AWS Organization”).
    • Service level — Fine-grained (e.g., “only service A in account X can invoke POST /orders”).
  • Callers authenticate using AWS SigV4 (Signature Version 4) — the same signing protocol used for AWS API calls.
  • Supports conditions on: source VPC, source account, organization ID, request method, path.
  • Both layers (service network + service) must independently allow the request — defense in depth.

Mutual TLS (mTLS) and Encryption

  • VPC Lattice automatically generates and manages TLS certificates for each service via AWS Certificate Manager (ACM).
  • HTTPS listeners terminate TLS at the VPC Lattice data plane — callers do not need to manage certificates.
  • TLS Passthrough listeners (launched January 2025) enable end-to-end encryption — TLS is not terminated by VPC Lattice.
  • TLS Passthrough routes traffic based on the Server Name Indicator (SNI) field.
  • Supports mutual TLS (mTLS) for bidirectional authentication between client and service.
  • Client-side authentication uses SigV4 by default; mTLS adds certificate-based identity.

Observability (CloudWatch, Access Logs, X-Ray)

  • Access Logs — Detailed per-request logs including source/destination, latency, status codes, and error reasons.
    • Can be sent to: Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose.
    • Available at service level, resource level, and service network level.
  • CloudWatch Metrics — Automatically published metrics for services and target groups (request count, latency, HTTP status codes, healthy/unhealthy targets).
  • AWS X-Ray — Distributed tracing integration for end-to-end request tracking across services.
  • VPC Flow Logs — Can capture network-level traffic to/from VPC Lattice endpoints.
  • No additional inter-AZ data transfer charges — all cross-AZ traffic is included in data processing charges.

Service Discovery (DNS-Based)

  • Each VPC Lattice service gets an auto-generated FQDN in an AWS-managed Route 53 public hosted zone.
  • When a VPC is associated with a service network, DNS resolution routes traffic to VPC Lattice data plane endpoints.
  • Custom domain names are supported — configure CNAME/Alias records in your own hosted zones.
  • No service mesh sidecar or agent required for discovery.

Availability Zone Affinity

  • VPC Lattice preferentially routes traffic to targets in the same Availability Zone as the client.
  • If the local AZ is unhealthy, traffic is automatically distributed to other AZs.
  • Reduces latency and avoids cross-AZ data transfer costs.

On-Premises Access

  • VPC endpoints of type “service network” (powered by AWS PrivateLink) enable on-premises clients to access VPC Lattice services.
  • Traffic can flow over AWS Direct Connect or Site-to-Site VPN → VPC endpoint → VPC Lattice service network.
  • Also supports access via VPC Peering or Transit Gateway through the VPC endpoint.

Integration with Compute Services

Amazon ECS

  • ECS tasks can be registered directly as VPC Lattice target group targets.
  • Supports both Fargate and EC2 launch types.
  • VPC Lattice replaces the need for internal ALBs or service discovery with Cloud Map.
  • AWS provides a migration guide from App Mesh to VPC Lattice for ECS workloads.
  • Works alongside ECS Service Connect — choose VPC Lattice for cross-account/cross-VPC scenarios.

Amazon EKS (Kubernetes)

  • Native integration via the AWS Gateway API Controller — an implementation of the Kubernetes Gateway API.
  • Define VPC Lattice services using Kubernetes-native Gateway, HTTPRoute, and GRPCRoute resources.
  • The controller automatically maps Kubernetes resources to VPC Lattice services, target groups, and listeners.
  • Supports EKS Pod Identity for simplified IAM authentication — pods can sign requests with SigV4.
  • Works with self-managed Kubernetes clusters (not just EKS).
  • No sidecar injection required — unlike Istio or App Mesh.

AWS Lambda

  • Lambda functions can be registered as targets in VPC Lattice target groups.
  • Enables serverless backends to participate in the same service network as container/instance workloads.
  • VPC Lattice invokes Lambda synchronously when requests are routed to Lambda targets.
  • Lambda functions can also act as clients — calling other VPC Lattice services using their DNS names.

Amazon EC2

  • EC2 instances can be registered by instance ID or IP address in target groups.
  • Supports Auto Scaling Group integration for dynamic target registration.
  • Applications on EC2 access VPC Lattice services via DNS — no SDK or agent installation required.
  • Health checks validate target availability before routing traffic.

Mixed Compute Environments

  • A single VPC Lattice service can have multiple target groups with different compute types.
  • Example: Route 80% of traffic to EKS pods, 20% to Lambda for canary testing.
  • Enables gradual migration between compute platforms without client-side changes.

VPC Lattice vs App Mesh vs API Gateway vs PrivateLink vs ALB

Feature VPC Lattice App Mesh (EOL Sept 2026) API Gateway PrivateLink ALB
Primary Use Case Service-to-service networking across VPCs/accounts Service mesh with Envoy sidecars External/internal API management Private service exposure to consumers Load balancing within a VPC
Layer Layer 7 (HTTP/HTTPS/gRPC/TCP) Layer 7 (HTTP/gRPC/TCP) Layer 7 (REST/HTTP/WebSocket) Layer 4 (TCP/UDP) Layer 7 (HTTP/HTTPS/gRPC)
Cross-VPC Yes (native, no peering needed) Requires VPC connectivity (peering/TGW) Yes (via public/private endpoints) Yes (endpoint service model) No (single VPC only)
Cross-Account Yes (via AWS RAM) Limited (shared mesh) Yes (resource policies) Yes (allow-listed accounts) No
Sidecar Required No Yes (Envoy proxy) No No No
IAM Auth Policies Yes (SigV4, PARC model) No (mTLS only) Yes (IAM, Cognito, Lambda authorizers) No (network-level only) No (security groups only)
Weighted Routing Yes Yes Yes (canary deployments) No Yes (target group weights)
Service Discovery Built-in DNS (auto-generated FQDN) Cloud Map integration Custom domain + API endpoint DNS name of VPC endpoint DNS name of load balancer
Overlapping CIDRs Supported Not supported N/A Supported N/A (single VPC)
Provider Requirement None (service registration only) Envoy sidecar per service None NLB or GWLB required None
Pricing Model Per service/hour + data + requests Free (pay for Envoy compute) Per request + data transfer Per endpoint/hour + data Per hour + LCU
Status GA (active development) EOL September 30, 2026 GA (active development) GA (active) GA (active)

When to Choose Which

  • VPC Lattice — Service-to-service communication across VPCs/accounts with IAM-based authorization. Best for internal microservice architectures.
  • API Gateway — External-facing APIs, rate limiting, API keys, request/response transformation, developer portal. Not designed for east-west traffic.
  • PrivateLink — Exposing a specific service to consumers (SaaS model) or accessing AWS services privately. Requires NLB on provider side.
  • ALB — Load balancing within a single VPC. Use with VPC Lattice when ALB is a target group target.
  • App Mesh — Legacy only. Migrate to VPC Lattice or ECS Service Connect before September 2026.

Use Cases

Microservices Communication

  • Connect hundreds of microservices running on mixed compute (EC2, ECS, EKS, Lambda) without managing load balancers per service.
  • Apply consistent security policies across all service-to-service traffic.
  • Use weighted routing for safe deployments (blue/green, canary).
  • Centralized observability for all inter-service communication.

Multi-Account Architectures

  • Share services and resources across organizational units using AWS RAM.
  • Central platform team manages service networks; application teams own their services.
  • Enforce organization-wide auth policies at the service network level.
  • No need to manage VPC peering connections or Transit Gateway attachments between accounts.

Service Mesh Replacement (App Mesh Migration)

  • Replace AWS App Mesh (EOL September 30, 2026) without application code changes.
  • Eliminate Envoy sidecar proxies — reduces compute costs and operational complexity.
  • Migration pattern: Create VPC Lattice services → register targets → shift traffic → remove App Mesh resources.
  • For ECS workloads, AWS also offers ECS Service Connect as an alternative for intra-cluster communication.

Zero Trust Networking

  • Implement defense-in-depth with multiple security layers:
    1. VPC/service network association (network boundary)
    2. Security groups on VPC-to-service-network associations
    3. Service network auth policies (coarse-grained)
    4. Service-level auth policies (fine-grained)
  • Every request must be authenticated (SigV4) and authorized (IAM policy evaluation) — no implicit trust based on network position.

Multi-Tenant SaaS Applications

  • Isolate tenant resources in separate VPCs while maintaining inter-service connectivity through VPC Lattice.
  • Use auth policies to enforce tenant-specific access controls.
  • Resource configurations enable secure, private access to shared databases across tenant accounts.

Hybrid and On-Premises Connectivity

  • On-premises applications access VPC Lattice services via VPC endpoints (type: service network) over Direct Connect or VPN.
  • Consolidate hybrid connectivity through a single VPC endpoint rather than multiple PrivateLink endpoints.

Pricing

VPC Lattice pricing has three dimensions for services and separate pricing for resource access:

Service Pricing (US East – N. Virginia)

Dimension Price Notes
Service hourly charge $0.025/hour (~$18.25/month) Per provisioned service
Data processing $0.025/GB Request + response data combined; includes cross-AZ
HTTP requests $0.10 per 1M requests/hour (after first 300K free) First 300,000 requests/hour are free per service
TCP connections (TLS listeners) $0.10 per 1M connections/hour (after first 300K free) For TLS Passthrough listeners only

Resource Access Pricing

Dimension Price
Resource configuration hourly $0.10/resource/hour (consumer pays)
Data processed (consumer) $0.01/GB (first 1 PB), $0.006/GB (next 4 PB), $0.004/GB (5+ PB)
Data processed (provider) $0.006/GB

Key Pricing Notes

  • No inter-AZ charges — Cross-AZ data transfer is included in the data processing charge.
  • VPC associations are free — No charge for associating VPCs with service networks.
  • VPC endpoints (type: service network) are free — No additional charge for service network endpoints.
  • Free tier for requests — First 300,000 HTTP requests (or TCP connections) per hour per service are free.
  • Prices vary by Region — check the VPC Lattice pricing page for current rates.

AWS Certification Exam Practice Questions

Question 1: A company has microservices running in multiple AWS accounts across different VPCs with overlapping CIDR ranges. They need service-to-service communication with IAM-based authorization and no infrastructure changes to existing VPCs. Which solution meets these requirements with the LEAST operational overhead?

  1. Set up VPC peering between all VPCs and use security groups for authorization
  2. Deploy AWS Transit Gateway and configure route tables for inter-VPC communication
  3. Use Amazon VPC Lattice with a service network shared via AWS RAM and auth policies
  4. Create PrivateLink endpoint services with NLBs in each provider VPC
Show Answer

Answer: C –

VPC Lattice supports overlapping CIDRs, provides native cross-VPC/cross-account connectivity without peering or Transit Gateway, and offers IAM-based auth policies. VPC peering (A) doesn’t support overlapping CIDRs. Transit Gateway (B) requires CIDR coordination and doesn’t provide application-layer authorization. PrivateLink (D) requires NLBs and doesn’t offer IAM-based service-to-service auth policies.

Question 2: A development team wants to perform a canary deployment where 5% of traffic goes to a new version of their service running on Lambda, while 95% continues to the existing version on ECS Fargate. The services are in the same VPC. Which VPC Lattice feature enables this?

  1. Create separate services for each version with different DNS names
  2. Configure a listener rule with weighted target groups — 95% to ECS target group, 5% to Lambda target group
  3. Use auth policies to restrict 95% of callers to the old version
  4. Deploy two service networks and associate the VPC with both
Show Answer

Answer: B –

VPC Lattice supports weighted routing across target groups within a single listener rule. You can assign weights to multiple target groups containing different compute types (ECS and Lambda), enabling canary deployments without changing client code or DNS configuration.

Question 3: A service network owner wants to enforce that only authenticated requests from their AWS Organization can access any service in the service network, while individual service owners can apply more specific access controls. How should this be configured?

  1. Apply an auth policy at the service network level requiring aws:PrincipalOrgID condition, and let service owners apply service-level auth policies
  2. Configure security groups on each service to allow only organization IP ranges
  3. Use AWS WAF rules attached to the service network
  4. Create IAM roles in each account with cross-account trust policies
Show Answer

Answer: A –

VPC Lattice supports auth policies at both the service network level (coarse-grained) and the service level (fine-grained). Both policies must independently allow the request — this implements defense in depth. The service network policy can enforce organization-wide requirements while service owners add specific conditions for their services.

Question 4: A company is migrating from AWS App Mesh (reaching EOL September 2026) to VPC Lattice for their ECS microservices. Which statements about this migration are TRUE? (Select TWO)

  1. VPC Lattice requires Envoy sidecar proxies like App Mesh
  2. VPC Lattice eliminates the need for sidecar proxies, reducing compute overhead
  3. VPC Lattice provides IAM-based authorization that App Mesh did not offer
  4. VPC Lattice requires VPC peering for cross-VPC communication
  5. VPC Lattice only supports EKS workloads, not ECS
Show Answer

Answer: B, C

VPC Lattice operates as infrastructure without sidecar proxies (B is correct) — this reduces compute costs and eliminates proxy management. VPC Lattice provides IAM auth policies using SigV4 for service-to-service authorization (C is correct), which App Mesh did not offer (App Mesh relied on mTLS only). VPC Lattice does NOT require sidecars (A wrong), does NOT require VPC peering (D wrong), and supports ECS, EKS, Lambda, and EC2 (E wrong).

Question 5: An organization needs to provide private access to an Amazon RDS database from application VPCs in multiple AWS accounts without using VPC peering or Transit Gateway. Which VPC Lattice components are required? (Select THREE)

  1. VPC Lattice service with listeners and target groups
  2. Resource gateway in the VPC where the RDS database resides
  3. Resource configuration defining the RDS database endpoint
  4. Service network with VPC associations in consumer accounts
  5. Network Load Balancer in front of the RDS database
  6. AWS App Mesh virtual nodes for the database
Show Answer

Answer: B, C, D

For TCP resource access (like RDS), VPC Lattice uses resource gateways (B) as ingress points in the resource VPC, resource configurations (C) to define the resource, and service networks (D) for consumer VPC associations. This does NOT require a VPC Lattice service with listeners (A — that’s for HTTP services), an NLB (E — VPC Lattice removes this PrivateLink requirement), or App Mesh (F — which is deprecated).

Important Points for Certification Exams

  • VPC Lattice is a fully managed, Regional service — no infrastructure to deploy or manage.
  • It operates at Layer 7 (application layer) — not Layer 4 like PrivateLink.
  • Supports overlapping CIDRs — a key differentiator from VPC peering and Transit Gateway.
  • Auth policies use IAM and SigV4 — not API keys or Cognito tokens.
  • No sidecar proxies required — unlike App Mesh or Istio.
  • VPC Lattice is the recommended replacement for App Mesh (EOL September 30, 2026).
  • Resource configurations (GA 2024) extend VPC Lattice to TCP resources like databases.
  • Free tier includes 300,000 requests/hour per service.
  • No additional cross-AZ data transfer charges.
  • On-premises access is enabled via VPC endpoints of type “service network” over Direct Connect/VPN.

Frequently Asked Questions

What is AWS VPC Lattice?

VPC Lattice is an application-layer networking service that connects services across VPCs and accounts without VPC peering or transit gateways. It handles service discovery, routing, access control, and observability at Layer 7.

How is VPC Lattice different from PrivateLink?

PrivateLink provides one-way private connectivity to a specific endpoint. VPC Lattice enables bidirectional service-to-service communication with built-in routing rules, IAM auth policies, weighted targets, and cross-account service mesh capabilities.

Does VPC Lattice replace App Mesh?

Yes, AWS recommends VPC Lattice as the successor to App Mesh. VPC Lattice is simpler (no sidecar proxies needed), supports cross-VPC/account natively, and integrates with IAM for access control.

Related Posts

References

AWS EC2 Networking – ENI, ENA & EFA

~ Last updated on : ~ jayendrapatil ~ 24 Comments

EC2 Network Features

EC2 Network covers a lot of features for low latency access, High Performance Computing, Enhanced Networking, ENA Express, Elastic Fabric Adapter, etc.

📌 Key Updates (2024-2026):

  • EC2-Classic fully retired (August 2023) – All instances now run in VPC only
  • Public IPv4 address charges – $0.005/IP/hour for ALL public IPv4 addresses (February 2024)
  • ENA Express – Up to 25 Gbps single-flow bandwidth using SRD protocol, now supports cross-AZ traffic (2026)
  • Network bandwidth – Up to 600 Gbps with C8gn/R8gn instances (6th gen Nitro Cards)
  • Jumbo frames – Cross-region VPC peering now supports up to 8500 bytes MTU (March 2025)
  • Instance Bandwidth Weighting – Adjust VPC/EBS bandwidth split by up to 25% (December 2024)

EC2 and VPC

  • All EC2 instances run exclusively within a VPC
  • EC2-Classic was fully retired in August 2023. All instances must be launched in a VPC.
  • Launching an EC2 instance within a VPC provides the following benefits
    • Assign static private IP addresses to instances that persist across starts and stops
    • Assign multiple IP addresses to the instances
    • Define network interfaces, and attach one or more network interfaces to the instances
    • Change security group membership for the instances while they’re running
    • Control the outbound traffic from the instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering)
    • Add an additional layer of access control to the instances in the form of network access control lists (ACL)
    • Run the instances on single-tenant dedicated hardware
    • Launch instances in IPv6-only, dual-stack, or IPv4-only subnets

EC2 Instance IP Addressing

  • Private IP address & Internal DNS Hostnames
    • Private IP address is the IP address that’s not reachable over the internet and can be resolved only within the network
    • When an instance is launched, the default network interface eth0 is assigned a private IP address and an internal DNS hostname, which resolves to the private IP address and can be used for communication between the instances in the same network only
    • Private IP address and DNS hostname cannot be resolved outside the network that the instance is in.
    • Private IP address behaviour
      • remains associated with the instance when it is stopped or rebooted
      • is disassociated only when the instance is terminated
    • An instance when launched can be assigned a private IP address or EC2 will automatically assign an IP address to the instance within the address range of the subnet
    • Additional private IP addresses, known as secondary private IP addresses can also be assigned. Unlike primary private IP addresses, secondary private IP addresses can be reassigned from one instance to another.
  • Public IP address and External DNS hostnames
    • A public IP address is reachable from the Internet
    • Each instance assigned a public IP address is also given an External DNS hostname.
    • External DNS hostname resolves to the public IP address outside the network and to the private IP address within the network.
    • Public IP address is associated with the primary Private IP address through NAT
    • Within a VPC, an instance may or may not be assigned a public IP address depending upon the subnet Assign Public IP attribute
    • Public IP address assigned to the pool is from the public IP address pool and is assigned to the instance, and not to the AWS account. It cannot be reused once disassociated and is released back to the pool
    • Public IP address behaviour
      • cannot be manually associated or disassociated with an instance
      • is released when an instance is stopped or terminated.
      • a new public IP address is assigned when a stopped instance is started
      • is released when an instance is assigned an Elastic IP address
      • is not assigned if there is more than one network interface attached to the instance
    • As of February 2024, all public IPv4 addresses incur a charge of $0.005 per IP per hour, whether attached to a service or not. This applies to both auto-assigned public IPs and Elastic IPs.
  • IPv6 Addresses
    • IPv6 addresses are globally unique and reachable over the Internet
    • An instance can be launched in an IPv6-only subnet (Nitro-based instances only), dual-stack subnet, or IPv4-only subnet
    • IPv6 addresses persist when an instance is stopped and started
    • IPv6 addresses are not charged, making them a cost-effective alternative to public IPv4
  • Multiple Private IP addresses
    • Multiple private IP addresses can be specified to the instances.
    • This can be useful in the following cases
      • Host multiple websites on a single server by using multiple SSL certificates on a single server and associating each certificate with a specific IP address.
      • Operate network appliances, such as firewalls or load balancers, that have multiple private IP addresses for each network interface.
      • Redirect internal traffic to a standby instance in case the instance fails, by reassigning the secondary private IP address to the standby instance.
    • Multiple IP addresses work with Network Interfaces
      • Secondary IP address can be assigned to any network interface, which can be attached or detached from an instance
      • Secondary IP address must be assigned from the CIDR block range of the subnet for the network interface
      • Security groups apply to network interfaces and not to IP addresses
      • Secondary private IP addresses that are assigned to ENIs attached to running or stopped instances.
      • Secondary private IP addresses that are assigned to a network interface can be reassigned to another one if you explicitly allow it.
      • Primary private IP addresses, secondary private IP addresses, and any associated Elastic IP addresses remain with the network interface when it is detached from an instance or attached to another instance.
      • Although the primary network interface cannot be moved from an instance, the secondary private IP address of the primary network interface can be reassigned to another network interface.
  • IP Prefix Delegation
    • Instead of assigning individual secondary IP addresses, you can assign IP address prefixes to network interfaces
    • IPv4 prefixes: /28 (16 IP addresses) can be assigned per prefix
    • IPv6 prefixes: /80 can be assigned per prefix
    • Significantly increases the number of IP addresses available per ENI
    • Particularly useful for container workloads (e.g., Amazon EKS with VPC CNI plugin) to increase pod density per node
    • Can be auto-assigned or manually specified when creating or modifying a network interface

Elastic IP Addresses

  • An Elastic IP address is a static IPv4 address designed for dynamic cloud computing.
  • An elastic IP address can help mask the failure of an instance or software by rapidly remapping the address to another instance in the account.
  • The elastic IP address is associated with the AWS account and it remains associated with the account until released explicitly
  • An elastic IP address is NOT associated with a particular instance
  • An instance launched in a non-default VPC is assigned only a private IP address unless a public address is specifically requested or the subnet public IP attribute is enabled
  • When an Elastic IP address is assigned to an instance, the public IP address is disassociated with the instance
  • For an instance, without a public IP address, to communicate to the internet it must be assigned an Elastic IP address
  • When the Elastic IP address is dissociated the public IP address is assigned back to the instance. However, if a secondary network interface is attached to the instance, the public IP address is not automatically assigned
  • Elastic IP Address Pricing (Updated February 2024)
    • All public IPv4 addresses (including EIPs) are now charged at $0.005 per IP per hour (~$3.60/month), whether in-use or idle
    • This replaces the previous model where only unused EIPs were charged
    • AWS Free Tier includes 750 hours of public IPv4 address usage per month for the first 12 months
    • You are NOT charged for IP addresses you own and bring to AWS using BYOIP (Bring Your Own IP)
    • Consider migrating to IPv6 to reduce costs
  • All AWS accounts are limited to 5 EIPs per Region (soft limit, can request increase)
  • Elastic IP supports tagging for cost allocation and organization

Elastic Network Interfaces (ENI)

  • Elastic Network Interfaces (ENIs) are virtual network interfaces that can be attached to instances running in a VPC
  • ENI consists of the following
    • A primary private IPv4 address
    • One or more secondary private IPv4 addresses
    • One Elastic IP address per private IPv4 address
    • One public IPv4 address, which can be auto-assigned to the elastic network interface for eth0 when an instance is launched
    • One or more IPv6 addresses
    • One or more security groups
    • A MAC address
    • A source/destination check flag
    • A description
    • IPv4 prefixes (/28) and IPv6 prefixes (/80) for prefix delegation
  • ENI can be created without being attached to an instance
  • ENI can be attached to an instance, detached from that instance and attached to another instance. Attributes of an ENI like elastic IP address, private IP address follow the ENI and when moved from one instance to another instance, all traffic to the ENI will be routed to the new instance.
  • An instance in VPC always has a default primary ENI attached (eth0) with a private IP address assigned from the VPC range and cannot be detached
  • Additional ENI (eth1-ethn) can be attached to the instance and the number varies depending upon the instance type
  • Most important difference between eth0 and eth1 is that eth0 cannot be dynamically attached or detached from a running instance.
  • Primary ENIs (eth0) are created automatically when an EC2 instance is launched and are also deleted automatically when the instance is terminated unless the administrator has changed a property of the ENI to keep it alive afterwards.
  • Multiple elastic network interfaces are useful for use cases:
    • Create a management network
      • Primary ENI eth0 handles backend with more restrictive control
      • Secondary ENI eth1 handles the public facing traffic
    • Licensing authentication
      • Fixed MAC address associated with a license authentication
    • Use network and security appliances in your VPC
      • configure a third-party network and security appliances (load balancers, NAT, proxy) with the secondary ENI
    • Create dual-homed instances with workloads/roles on distinct subnets.
    • Create a low-budget, high-availability solution
      • If one of the instances serving a particular function fails, its elastic network interface can be attached to a replacement or hot standby instance pre-configured for the same role in order to rapidly recover the service
      • As the interface maintains its private IP, EIP, and MAC address, network traffic will begin flowing to the standby instance as soon as it is attached to the replacement instance
  • ENI Best Practices
    • ENI can be attached to an instance when it’s running (hot attach), when it’s stopped (warm attach), or when the instance is being launched (cold attach).
    • Primary (eth0) interface can’t be detached
    • Secondary (ethN) ENI can be detached when the instance is running or stopped.
    • ENI in one subnet can be attached to an instance in another subnet, but the same AZ and same VPC
  • When launching an instance from the CLI or API, both the primary (eth0) and additional elastic network interfaces can be specified
  • Launching an Amazon Linux or Microsoft Windows Server instance with multiple network interfaces automatically configures interfaces, private IP addresses, and route tables on the operating system of the instance.
  • A warm or hot attach of an additional ENI may require bringing up the second interface manually, configure the private IP address, and modify the route table accordingly.
  • Instances running Amazon Linux or Microsoft Windows Server automatically recognize the warm or hot attach and configure themselves.
  • Attaching another ENI to an instance is not a method to increase or double the network bandwidth to or from the dual-homed instance.
  • ENA Queue Allocation (2025) – EC2 now supports flexible ENA queue allocation per ENI, enabling efficient load-balancing of network traffic across available queues on each network interface.

Placement Groups

  • EC2 Placement groups determine how the instances are placed on the underlying hardware.
  • AWS provides three types of placement groups
    • Cluster – clusters instances into a low-latency group in a single AZ
    • Partition – spreads instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions
    • Spread – strictly places a small group of instances across distinct underlying hardware to reduce correlated failures
  • On-Demand Capacity Reservations in Cluster Placement Groups (2025)
    • CPG-ODCRs provide assured capacity with low latency and high throughput within a Cluster Placement Group
    • Supports sharing and targeting capabilities for cross-account usage
    • Can be scheduled up to 120 days in advance with future-dated capacity reservations

Network Maximum Transmission Unit – MTU

  • MTU of a network connection is the size, in bytes, of the largest permissible packet that can be transferred over the connection.
  • The larger the MTU of the connection the more the data can be transferred in a single packet
  • Largest ethernet packet size supported over most of the internet is 1500 MTU
  • Jumbo Frames
    • Jumbo frames are Ethernet frames that allow more than 1500 bytes of data by increasing the payload size per packet and thus increasing the percentage of the packet that is not packet overhead.
    • Fewer packets are needed to send the same amount of usable data
    • Jumbo frames should be used with caution for Internet-bound traffic or any traffic that leaves a VPC.
    • Packets are fragmented by intermediate systems, which slows down this traffic.
  • Maximum supported MTU for an instance depends on its instance type
  • All EC2 instance types support 1500 MTU, and many current instance sizes support 9001 MTU or Jumbo frames
  • Traffic is limited to a maximum MTU of 1500 in the following cases:
    • Traffic over VPN connections
    • Traffic over an internet gateway
  • Updated MTU Support (March 2025):
    • Cross-region VPC peering now supports jumbo frames up to 8500 bytes MTU (previously limited to 1500)
    • EC2 now supports full instance bandwidth for inter-region VPC peering traffic and to AWS Direct Connect
    • Transit Gateway supports 8500 MTU for all attachments
    • Intra-region VPC peering continues to support 9001 MTU (jumbo frames)
  • For instances that are collocated inside a placement group, jumbo frames help to achieve the maximum network throughput possible, and they are recommended in this case.

Enhanced Networking

  • Enhanced networking results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability, and lower jitter.
  • EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) on supported instance types
    • SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization
  • Two mechanisms for enhanced networking:
    • Elastic Network Adapter (ENA) – supports network speeds of up to 100 Gbps (up to 600 Gbps on network-optimized instances). All instances built on the AWS Nitro System use ENA.
    • Intel 82599 Virtual Function (VF) interface – uses the Intel ixgbevf driver, supports up to 10 Gbps. Only for legacy Xen-based instance types (C3, C4, R3, I2, M4, D2).
  • All current-generation instances support enhanced networking via ENA
  • Enhanced networking is available only within a VPC

ENA Express

  • ENA Express is an enhanced networking feature that uses the AWS Scalable Reliable Datagram (SRD) protocol to improve network performance
  • SRD is a high-performance network transport protocol that uses dynamic routing to increase throughput and minimize tail latency
  • Key Benefits:
    • Increases maximum single-flow bandwidth from 5 Gbps up to 25 Gbps (up to the aggregate instance limit)
    • Reduces tail latency by up to 93% (P99.9) during periods of high network load
    • Detects and avoids congested network paths through multi-pathing
    • Handles packet reordering and most retransmits in the network layer, freeing the application layer
  • How it works:
    • Enabled per network interface attachment via API call or AWS Console toggle
    • Sending instance initiates SRD communication if both sender and receiver have ENA Express enabled
    • Falls back to standard ENA transmission if the receiving instance does not support ENA Express
    • Works transparently with TCP and UDP protocols
  • Scope:
    • Originally supported traffic within the same Availability Zone only
    • May 2026: ENA Express now supports cross-AZ traffic within a Region, delivering up to 25 Gbps single-flow bandwidth between AZs
  • Supported on a wide range of instance types (120+ instance types as of 2025)
  • ENA Express traffic cannot be sent in a Local Zone
  • Best suited for workloads requiring high single-flow throughput; for workloads needing lowest latency with high PPS during non-congestion, standard enhanced networking may be preferable

Instance Bandwidth Weighting

  • Launched December 2024 – allows adjusting the VPC networking and EBS bandwidth allocation on EC2 instances
  • Customers can shift bandwidth by up to 25% between VPC and EBS in either direction
  • When increasing bandwidth for one service (e.g., VPC), the available bandwidth for the other (EBS) is reduced by the same absolute amount
  • Useful for workloads that are either network-intensive or storage-intensive but not both simultaneously
  • Burst bandwidth remains the same for the selected option on most instance types

Network Bandwidth Capabilities (2025-2026)

  • Network-optimized instances now support up to 600 Gbps network bandwidth:
    • C8gn – Graviton4-based, up to 600 Gbps (GA June 2025)
    • R8gn – Graviton4-based, up to 600 Gbps (GA September 2025)
    • M8gn – Graviton4-based, up to 600 Gbps (GA December 2025)
    • R8in/R8idn – Intel-based, up to 600 Gbps (2026)
  • These instances feature 6th generation AWS Nitro Cards
  • Previous generation network-optimized instances (C6in, R6in, R6idn) support up to 200 Gbps

Elastic Fabric Adapter – EFA

  • An Elastic Fabric Adapter (EFA) is a network device that can be attached to the EC2 instance to accelerate High Performance Computing (HPC) and machine learning applications.
  • EFA helps achieve the application performance of an on-premises HPC cluster, with the scalability, flexibility, and elasticity provided by AWS.
  • EFA provides lower and more consistent latency and higher throughput than the TCP transport traditionally used in cloud-based HPC systems.
  • EFA enhances the performance of inter-instance communication which is critical for scaling HPC and machine learning applications.
  • EFA is optimized to work on the existing AWS network infrastructure and it can scale depending on application requirements.
  • EFAs provide all of the same traditional IP networking features as ENAs, and they also support OS-bypass capabilities. OS-bypass enables HPC and machine learning applications to bypass the operating system kernel and to communicate directly with the EFA device.
  • EFA uses the AWS Scalable Reliable Datagram (SRD) protocol to increase network throughput utilization
  • EFA Updates (2024-2026):
    • Cross-subnet communication (July 2024) – EFA now supports traffic across subnets for both existing and new instances. Requires security group rules to allow cross-subnet traffic.
    • EFA-only interface (October 2024) – New interface type that decouples EFA from ENA. Allows standalone EFA devices on secondary interfaces without requiring IP addresses, solving IPv4 address exhaustion and IP routing challenges for AI/ML clusters.
    • New EFA observability metrics (September 2025) – Metrics for retransmitted packets/bytes, retransmit timeout events, impaired remote connections, and unresponsive remote receiver events.
    • NIXL support with EFA (March 2026) – Accelerates LLM inference at scale through increased KV-cache throughput, reduced inter-token latency, and optimized KV-cache memory utilization.
    • Kubernetes Dynamic Resource Allocation for EFA (May 2026) – Amazon EKS supports DRA for EFA, simplifying RDMA configuration for AI/ML and HPC workloads.
    • SageMaker HyperPod EFA-only support (June 2026) – Dedicated EFA devices without traditional ENA for IP networking in SageMaker clusters.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user is launching an EC2 instance in the US East region. Which of the below mentioned options is recommended by AWS with respect to the selection of the availability zone?
    1. Always select the US-East-1-a zone for HA
    2. Do not select the AZ; instead let AWS select the AZ
    3. The user can never select the availability zone while launching an instance
    4. Always select the AZ while launching an instance
  2. You have multiple Amazon EC2 instances running in a cluster across multiple Availability Zones within the same region. What combination of the following should be used to ensure the highest network performance (packets per second), lowest latency, and lowest jitter? Choose 3 answers
    1. Amazon EC2 placement groups (would not work for multiple AZs. Defaults to Cluster)
    2. Enhanced networking (provides network performance, lowest latency)
    3. Amazon PV AMI (Needs HVM)
    4. Amazon HVM AMI
    5. Amazon Linux (Can work on other flavors of Unix as well)
    6. Amazon VPC (Enhanced networking works only in VPC)
  3. Regarding the attaching of ENI to an instance, what does ‘warm attach’ refer to?
    1. Attaching an ENI to an instance when it is stopped
    2. Attaching an ENI to an instance when it is running
    3. Attaching an ENI to an instance during the launch process
  4. Can I detach the primary (eth0) network interface when the instance is running or stopped?
    1. Yes, You can.
    2. You cannot
    3. Depends on the state of the interface at the time
  5. By default what are ENIs that are automatically created and attached to instances using the EC2 console set to do when the attached instance terminates?
    1. Remain as is
    2. Terminate
    3. Hibernate
    4. Pause
  6. Select the incorrect statement
    1. In Amazon VPC, the private IP addresses only returned to Amazon EC2 when the instance is terminated
    2. In Amazon VPC, an instance retains its private IP addresses when the instance is stopped.
    3. In Amazon VPC, an instance does NOT retain its private IP addresses when the instance is stopped
    4. In Amazon VPC, the private IP address is associated exclusively with the instance for its lifetime
  7. To ensure failover capabilities, consider using a _____ for incoming traffic on a network interface”.
    1. primary public IP
    2. secondary private IP
    3. secondary public IP
    4. add on secondary IP
  8. Which statements are true about Elastic Network Interface (ENI)? (Choose 2 answers)
    1. You can attach an ENI in one AZ to an instance in another AZ
    2. You can change the security group membership of an ENI
    3. You can attach an instance to two different subnets within a VPC by using two ENIs
    4. You can attach an ENI in one VPC to an instance in another VPC
  9. A user is planning to host a web server as well as an app server on a single EC2 instance, which is a part of the public subnet of a VPC. How can the user setup to have two separate public IPs and separate security groups for both the application as well as the web server?
    1. Launch a VPC instance with two network interfaces. Assign a separate security group to each and AWS will assign a separate public IP to them. (AWS cannot assign public IPs for instance with multiple ENIs)
    2. Launch VPC with two separate subnets and make the instance a part of both the subnets.
    3. Launch a VPC instance with two network interfaces. Assign a separate security group and elastic IP to them.
    4. Launch a VPC with ELB such that it redirects requests to separate VPC instances of the public subnet.
  10. An organization has created multiple components of a single application for compartmentalization. Currently all the components are hosted on a single EC2 instance. Due to security reasons the organization wants to implement two separate SSLs for the separate modules although it is already using VPC. How can the organization achieve this with a single instance?
    1. Create a VPC instance, which will have both the ACL and the security group attached to it and have separate rules for each IP address.
    2. Create a VPC instance, which will have multiple network interfaces with multiple elastic IP addresses.
    3. You have to launch two instances each in a separate subnet and allow VPC peering for a single IP.
    4. Create a VPC instance, which will have multiple subnets attached to it and each will have a separate IP address.
  11. Your system automatically provisions EIPs to EC2 instances in a VPC on boot. The system provisions the whole VPC and stack at once. You have two of them per VPC. On your new AWS account, your attempt to create a Development environment failed, after successfully creating Staging and Production environments in the same region. What happened?
    1. You didn’t choose the Development version of the AMI you are using.
    2. You didn’t set the Development flag to true when deploying EC2 instances.
    3. You hit the soft limit of 5 EIPs per region and requested a 6th. (There is a soft limit of 5 EIPs per Region for VPC on new accounts. The third environment could not allocate the 6th EIP)
    4. You hit the soft limit of 2 VPCs per region and requested a 3rd.
  12. A user has created a VPC with a public subnet. The user has terminated all the instances, which are part of the subnet. Which of the below mentioned statements is true with respect to this scenario?
    1. The user cannot delete the VPC since the subnet is not deleted
    2. All network interface attached with the instances will be deleted
    3. When the user launches a new instance it cannot use the same subnet
    4. The subnet to which the instances were launched with will be deleted
  13. A company wants to reduce AWS costs after learning about the new public IPv4 address charges. Which combination of approaches would help minimize public IPv4 costs? (Choose 2 answers)
    1. Migrate workloads to IPv6-only subnets where possible (IPv6 addresses are free and eliminate the need for public IPv4)
    2. Use more Elastic IP addresses instead of auto-assigned public IPs (Both EIPs and auto-assigned public IPs are now charged equally at $0.005/IP/hour)
    3. Use NAT Gateway with private subnets for outbound-only internet access (Reduces number of public IPs needed; instances use private IPs)
    4. Switch from VPC to EC2-Classic networking (EC2-Classic was fully retired in August 2023)
  14. Which of the following is a feature of ENA Express? (Choose 2 answers)
    1. Increases maximum single-flow bandwidth from 5 Gbps to 25 Gbps
    2. Requires application code changes to use SRD protocol
    3. Reduces tail latency (P99.9) for network traffic between EC2 instances
    4. Works only with EFA-enabled instances
  15. A machine learning team needs to scale their training cluster to thousands of instances but is running out of private IPv4 addresses. Which EFA feature should they use?
    1. EFA cross-subnet communication
    2. EFA-only network interfaces (EFA-only interfaces decouple EFA from ENA, allowing standalone EFA devices without requiring IP addresses)
    3. ENA Express with SRD protocol
    4. IP prefix delegation on ENIs
  16. An application requires high single-flow network throughput between EC2 instances across Availability Zones. Which feature should be enabled?
    1. Enhanced networking with Intel 82599 VF
    2. Elastic Fabric Adapter (EFA)
    3. ENA Express (ENA Express supports cross-AZ traffic as of May 2026, delivering up to 25 Gbps single-flow bandwidth)
    4. Jumbo frames (9001 MTU)

References

AWS EC2 Network – Enhanced Networking

~ Last updated on : ~ jayendrapatil ~ 9 Comments

EC2 Enhanced Networking

  • Enhanced networking results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability and lower jitter
  • EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) only on supported instance types
    • SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization
  • There is no additional charge for using enhanced networking.
  • Enhanced networking is supported only in a VPC.
  • All current-generation instances built on the AWS Nitro System use ENA for enhanced networking by default.
  • Amazon Linux AMIs, Ubuntu HVM AMIs, and Windows Server AMIs already have the ENA module installed with the attributes set and do not require any additional configurations.
  • It can be enabled for other OS distributions by installing the module with the correct attributes configured
  • Enhanced Networking is supported using
    • Elastic Network Adapter (ENA)
      • The Elastic Network Adapter (ENA) supports network speeds of up to 200 Gbps for supported instance types (e.g., C6in, R6in, M6in instances). Some accelerated instances like P4d support up to 400 Gbps.
      • All Nitro-based instances use ENA for enhanced networking.
      • The following Xen-based instances also use ENA: H1, I3, G3, m4.16xlarge, P3, P3dn, and R4.
      • ENA is the recommended and standard adapter for all current-generation workloads.
    • Intel 82599 Virtual Function (VF) interface
      • The Intel 82599 Virtual Function interface supports network speeds of up to 10 Gbps for supported instance types.
      • Supported only on previous-generation instance types: C3, C4, D2, I2, M4 (excl. m4.16xlarge), and R3.
      • These are all previous-generation instances. AWS recommends migrating to current-generation Nitro-based instances with ENA for better performance.

ENA Express

  • ENA Express is powered by AWS Scalable Reliable Datagram (SRD) technology, a high-performance network transport protocol.
  • ENA Express increases the maximum single flow bandwidth from 5 Gbps up to 25 Gbps within the same Region, up to the aggregate instance limit.
  • Reduces tail latency: up to 50% reduction in P99 latency and up to 85% reduction in P99.9 latency compared to TCP.
  • Works transparently with existing TCP and UDP applications — no code changes required.
  • SRD distributes packets across different network paths and dynamically adjusts when congestion is detected.
  • Handles packet reordering on the receiving end and most retransmits in the network layer.
  • Cross-AZ support (May 2026): ENA Express now supports traffic between instances in different Availability Zones within the same Region, delivering up to 25 Gbps single-flow bandwidth.
  • Requirements:
    • Both sending and receiving instances must be supported instance types.
    • Both instances must have ENA Express enabled on their network interface attachment.
    • The network path must not include middleware boxes.
    • Linux instances require ENA driver version 2.2.9 or higher for full bandwidth; version 2.8+ for metrics.
  • ENA Express is available on supported 6th generation and later instance types (e.g., m6i, m6a, c6i, r6i, and newer).
  • If ENA Express is not supported on both ends, communication falls back to standard ENA transmission.
  • Note: For workloads requiring high packets-per-second with lowest latency during uncongested periods, standard enhanced networking (without ENA Express) may be more appropriate.

Elastic Fabric Adapter (EFA)

  • An Elastic Fabric Adapter (EFA) is a network device for Amazon EC2 instances to accelerate AI/ML, and High Performance Computing (HPC) applications.
  • EFA provides lower and more consistent latency and higher throughput than TCP transport for inter-instance communication.
  • Supports Message Passing Interface (MPI) for HPC and NVIDIA Collective Communications Library (NCCL) for ML workloads, scaling to thousands of cores or GPUs.
  • Available as an optional EC2 networking feature at no additional cost on supported instance types.
  • EFA uses OS-bypass capabilities to provide low-latency, high-bandwidth RDMA-like networking.
  • EFA decoupled from ENA (October 2024): AWS introduced a new interface type that decouples EFA from ENA, enabling dedicated high-bandwidth, low-latency networking crucial for scaling AI/ML workloads.
  • EFA-only interfaces (June 2026): Amazon SageMaker HyperPod supports EFA-only network interfaces without ENA for IP networking, enabling dedicated accelerator networking.
  • Supported on instances like P4d (400 Gbps), P5, Trn1, Trn2, Hpc6a, Hpc7a, Hpc7g (200 Gbps), and others.
  • EFA is ideal for tightly coupled workloads requiring high internode communication bandwidth.

ENA Enhanced Networking Requirements

  • Instance must be in a VPC (EC2-Classic was fully retired in August 2023)
  • An HVM virtualization type AMI
  • Instance must be based on the Nitro System (for current-generation instances)
  • For Xen-based instances (H1, I3, G3, m4.16xlarge, P3, R4): must have ENA module installed and enaSupport attribute enabled
  • Supported instance types: All Nitro-based instances (5th generation and later: C5, M5, R5, C6i, M6i, R6i, C7g, M7g, R7g, C8g, M8g, etc.)
  • Enhanced networking cannot be managed from the Amazon EC2 console — use AWS CLI or CloudShell

Intel 82599 VF Enhanced Networking Requirements (Previous Generation)

  • VPC (EC2-Classic was fully retired in August 2023)
  • An HVM virtualization type AMI
  • Instance kernel version
    • Linux kernel version of 2.6.32+
    • Windows: Server 2008 R2+
  • Appropriate Virtual Function (VF) driver
    • Linux – should have the ixgbevf module installed and that sriovNetSupport attribute set for the instance
    • Windows – Intel 82599 Virtual Function driver
  • Supported instance types (previous generation only): C3, C4, D2, I2, M4 (excl. m4.16xlarge), and R3.
  • Note: AWS recommends migrating to current-generation Nitro-based instances with ENA for significantly better networking performance (up to 200 Gbps vs. 10 Gbps).

Enhanced Networking vs. ENA Express vs. EFA

  • Enhanced Networking (ENA/VF): Higher PPS, lower latency, lower jitter using SR-IOV. Available on all Nitro instances. Best for general workloads requiring consistent network performance.
  • ENA Express: Uses SRD protocol on top of ENA. Increases single-flow bandwidth to 25 Gbps and significantly reduces tail latency. Best for workloads with large data transfers or latency-sensitive applications. Available on 6th gen+ instances.
  • Elastic Fabric Adapter (EFA): Network device providing OS-bypass RDMA-like capabilities. Best for HPC (MPI) and AI/ML (NCCL) workloads requiring ultra-low latency inter-node communication. Available on specific compute/GPU instances.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have multiple Amazon EC2 instances running in a cluster across multiple Availability Zones within the same region. What combination of the following should be used to ensure the highest network performance (packets per second), lowest latency, and lowest jitter? Choose 3 answers
    1. Amazon EC2 placement groups (Cluster placement groups are within a single AZ, would not work for multiple AZs)
    2. Enhanced networking (provides network performance, lowest latency)
    3. Amazon PV AMI (Requires HVM)
    4. Amazon HVM AMI (Requires HVM)
    5. Amazon Linux (Can be on others as well)
    6. Amazon VPC (works only in VPC; EC2-Classic was retired August 2023)
  2. A group of researchers is studying the migration pattern of a beetle that eats and destroys grain. The researchers must process massive amounts of data and run statistics. Which one of the following options provides the high performance computing for this purpose.
    1. Configure an Autoscaling Scaling group to launch dozens of spot instances to run the statistical analysis simultaneously
    2. Launch AMI instances that support SR-IOV in a single Availability Zone
    3. Launch compute optimized (C4) instances in at least two Availability Zones
    4. Launch enhanced network type instances in a placement group
  3. A company is running a latency-sensitive financial trading application on EC2 instances. They need to maximize single-flow bandwidth between two instances in the same Availability Zone. Which feature should they enable?
    1. Enhanced networking with Intel 82599 VF
    2. Elastic Fabric Adapter (EFA)
    3. ENA Express (ENA Express uses SRD to increase single-flow bandwidth from 5 Gbps to 25 Gbps and reduces tail latency)
    4. Placement group with standard ENA
  4. A machine learning team needs to scale their distributed training workload across hundreds of GPU instances with the lowest possible inter-node latency. Which networking feature is most appropriate?
    1. ENA Express with SRD protocol
    2. Enhanced networking with cluster placement groups
    3. Elastic Fabric Adapter (EFA) (EFA provides OS-bypass, RDMA-like capabilities optimized for MPI and NCCL workloads at scale)
    4. Multiple Elastic Network Interfaces
  5. Which of the following statements about ENA Express are correct? (Choose 2)
    1. ENA Express uses AWS Scalable Reliable Datagram (SRD) protocol to improve network performance (Correct – SRD is the underlying protocol)
    2. ENA Express requires application code changes to work
    3. ENA Express only works with TCP traffic
    4. ENA Express can increase single-flow bandwidth from 5 Gbps up to 25 Gbps (Correct – major benefit of ENA Express)
  6. A company wants to migrate from C3 instances to improve network performance. Which statement is correct regarding the migration?
    1. C3 instances support ENA with speeds up to 100 Gbps
    2. C3 instances use Intel 82599 VF (up to 10 Gbps) and should be migrated to current-generation Nitro instances with ENA for up to 200 Gbps (C3 is previous gen with VF; current gen instances offer significantly better networking)
    3. C3 instances cannot use enhanced networking
    4. C3 instances already support ENA Express

References