AWS Application Load Balancer – ALB Features

AWS Application Load Balancer – ALB

📌 Last Updated: June 2026

This post has been updated to include the latest ALB features including Mutual TLS (mTLS) support, gRPC protocol support, HTTP/2 end-to-end, Built-in Authentication (OIDC/Cognito), JWT Verification, Automatic Target Weights (ATW), Target Optimizer, URL/Host Header Rewrite, HTTP Header Modification, LCU Capacity Reservation, and VPC IPAM integration.

  • Application Load Balancer operates at layer 7 (application layer) and allows defining routing rules based on content across multiple services or containers running on one or more EC2 instances.
  • scales the load balancer as traffic to the application changes over time.
  • can scale to the vast majority of workloads automatically.
  • supports health checks, used to monitor the health of registered targets so that the load balancer can send requests only to the healthy targets.
  • supports HTTP, HTTPS, and gRPC protocols for listeners.

Application Load Balancer Components

  • A load balancer
    • serves as the single point of contact for clients.
    • distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple AZs, which increases the availability of the application.
    • one or more listeners can be added to the load balancer.
  • A listener
    • checks for connection requests from clients, using the configured protocol and port
    • rules defined determine, how the load balancer routes request to its registered targets.
    • each rule consists of a priority, one or more actions, and one or more conditions.
    • supported actions are
      • forward,
      • redirect,
      • fixed-response,
      • authenticate-oidc,
      • authenticate-cognito,
      • jwt-validation
    • supported rule conditions are
      • host-header
      • http-request-method
      • path-pattern
      • source-ip
      • http-header
      • query-string
    • when the conditions for a rule are met, its actions are performed.
    • a default rule for each listener must be defined, and optionally additional rules can be defined
  • Target group
    • routes requests to one or more registered targets, such as EC2 instances, using the specified protocol and port number
    • a target can be registered with multiple target groups.
    • health checks can be configured on a per target group basis.
    • health checks are performed on all targets registered to a target group that is specified in a listener rule for the load balancer.
    • target group supports the following target types:
      • EC2 instances (can be managed as a part of the ASG)
      • ECS tasks
      • Lambda functions
      • Private IP Addresses on AWS or On-premises over VPN or DX.
    • supports weighted target group routing
      • enables routing of the traffic forwarded by a rule to multiple target groups.
      • enables use cases like blue-green, canary and hybrid deployments without the need for multiple load balancers.
      • also enables zero-downtime migration between on-premises and cloud or between different compute types like EC2 and Lambda.
    • supports Slow Start Mode
      • allows newly registered targets to warm up before receiving their full share of traffic.
      • ALB linearly ramps up traffic over a configurable duration (30-900 seconds).
      • useful for applications that need time for caching, JIT compilation, or resource initialization.
  • When a load balancer receives a request, it evaluates the listener rules in priority order to determine which rule to apply and then selects a target from the target group for the rule action.
  • Listener rules can be configured to route requests to different target groups based on the content of the application traffic.
  • Routing is performed independently for each target group, even when a target is registered with multiple target groups.
  • Routing algorithm used can be configured at the target group level.
  • Supported routing algorithms:
    • Round Robin (default) – distributes requests evenly across targets
    • Least Outstanding Requests (LOR) – routes to the target with fewest pending requests
    • Weighted Random – used by Automatic Target Weights (ATW) for anomaly mitigation

Application Load Balancer Features

  • supports load balancing of applications using HTTP, HTTPS (Secure HTTP), and gRPC protocols
  • supports HTTP/2, which is enabled natively. Clients that support HTTP/2 can connect over TLS
  • supports end-to-end HTTP/2, enabling gRPC workloads between microservices or between gRPC-enabled clients and services (launched Oct 2020)
  • supports gRPC protocol natively
    • provides health checks that examine gRPC status codes
    • provides metrics for gRPC request count and access logs that differentiate gRPC requests
    • supports gRPC-specific response headers
    • requires HTTPS listener and gRPC protocol version for the target group
  • supports WebSockets and Secure WebSockets natively
  • supports Request tracing, by default.
    • request tracing can be used to track HTTP requests from clients to targets or other services.
    • Load balancer upon receiving a request from a client, adds or updates the X-Amzn-Trace-Id header before sending the request to the target
    • Any services or applications between the load balancer and the target can also add or update this header.
  • supports Sticky Sessions (Session Affinity) using load balancer generated cookies or application-based cookies, to route requests from the same client to the same target
  • supports SSL/TLS termination, to decrypt the request on ALB before sending it to the underlying targets.
    • an SSL certificate can be installed on the load balancer.
    • the load balancer uses this certificate to terminate the connection and then decrypt requests from clients before sending them to targets.
  • supports Mutual TLS (mTLS) authentication (launched Nov 2023)
    • enables mutual authentication between clients and the load balancer
    • ALB authenticates client X.509 certificates and performs revocation checks
    • supports certificates issued by third-party CAs or AWS Private Certificate Authority (ACM PCA)
    • simplifies authentication management and reduces the load on backend applications
    • available in all commercial AWS Regions and GovCloud (US) Regions
  • supports Built-in Authentication (OIDC and Cognito)
    • ALB can authenticate users before routing requests to backend targets
    • supports Amazon Cognito user pools for user management
    • supports any OpenID Connect (OIDC) compliant identity provider (Okta, Google, etc.)
    • handles the OAuth 2.0 flow, validates tokens, and forwards authenticated requests with user claims in HTTP headers
    • eliminates the need for authentication code in backend applications
  • supports JWT Verification (launched Nov 2025)
    • validates JSON Web Tokens (JWTs) included in request headers
    • validates token signatures, expiration times (‘exp’), issuer (‘iss’), and optional claims (‘nbf’, ‘iat’)
    • enables client credential flow without requiring application code modifications
    • configured as a listener rule action type (jwt-validation)
  • supports layer 7 specific features like X-Forwarded-For headers to help determine the actual client IP, port and protocol
  • automatically scales its request handling capacity in response to incoming application traffic.
  • supports hybrid load balancing,
    • If an application runs on targets distributed between a VPC and an on-premises location, they can be added to the same target group using their IP addresses
  • provides High Availability, by allowing you to specify more than one AZ and distribution of incoming traffic across multiple AZs.
  • integrates with ACM to provision and bind an SSL/TLS certificate to the load balancer thereby making the entire SSL offload process very easy
  • supports multiple certificates using Server Name Indication (SNI)
    • host multiple TLS secured applications behind a single ALB
    • ALB automatically selects the optimal TLS certificate for each client using a smart selection algorithm
  • supports IPv6 addressing, for an Internet-facing load balancer
  • supports Cross-zone load balancing, by default
  • supports Security Groups to control the traffic allowed to and from the load balancer.
  • provides Access Logs, to record all requests sent to the load balancer, and store the logs in S3 for later analysis in compressed format
  • provides Delete Protection, to prevent the ALB from accidental deletion
  • supports Connection Idle Timeout – ALB maintains two connections for each request one with the Client (front end) and one with the target instance (back end). If no data has been sent or received by the time that the idle timeout period elapses, ALB closes the front-end connection
  • integrates with CloudWatch to provide metrics, such as request counts, error counts, error types, and request latency
  • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configuration based on IP addresses, HTTP headers, and custom URI strings
  • integrates with CloudTrail to receive a history of ALB API calls made on the AWS account
  • supports Desync Mitigation Mode to protect applications from HTTP desync attacks
    • classifies requests based on threat level using the HTTP Desync Guardian library
    • modes: Defensive (default), Strictest, and Monitor
  • supports Outpost deployment for on-premises workloads
  • supports Local Zones for low-latency applications

Automatic Target Weights (ATW)

  • Launched November 2023 to detect and mitigate gray failures for targets behind ALB
  • A gray failure occurs when a target passes health checks but still returns errors to clients
  • ATW analyzes HTTP status codes and TCP/TLS error rates to identify anomalous targets
  • When underperforming targets are identified, ATW iteratively reduces traffic to the affected target
  • If the target recovers, ALB gradually increases traffic back to its original level
  • Uses the Weighted Random routing algorithm for anomaly mitigation
  • Configured at the target group level as a target group attribute
  • Complements active health checks by addressing partial failures that health checks cannot detect

Target Optimizer

  • Launched November 2025 to deliver optimal concurrency to each target
  • Allows you to enforce a maximum number of concurrent requests on a target
  • Ensures targets receive only the number of requests they can process
  • Achieves higher request success rate, better target utilization, and lower latency
  • Particularly useful for compute-intensive workloads (AI/ML inference, media processing)
  • Returns 503 errors when targets are at capacity rather than overloading them
  • Configured at the target group level

HTTP Header Modification

  • Launched November 2024 for enhanced traffic control and security
  • Provides three key capabilities:
    • Header Rename – rename ALB-generated TLS headers (mTLS and TLS headers) for seamless backend integration
    • Header Insertion – insert custom response headers including CORS and security headers like HSTS
    • Server Header Suppression – disable the ALB-generated “Server” header to reduce server-specific information exposure
  • Must be enabled on each listener individually

URL and Host Header Rewrite

  • Launched October 2025 for advanced request transformation
  • Enables modification of request URLs and Host Headers using regex-based pattern matching before routing to targets
  • Supports regex matches based on request parameters
  • Can rewrite both host headers and URL paths in a single rule
  • Eliminates the need for custom proxy layers or Lambda@Edge for URL transformations

VPC IPAM Integration

  • Launched March 2025 for predictable IP address management
  • Allows internet-facing ALBs to use IP addresses from Amazon VPC IPAM pools
  • Enables Bring Your Own IP (BYOIP) use cases for ALBs
  • ALB automatically switches to AWS-managed IP addresses when IPAM pool is depleted
  • Useful for organizations that need allowlisted or predictable IP addresses

LCU Capacity Reservation

  • Launched January 2025 to prepare for planned traffic spikes
  • Allows you to reserve a minimum capacity for your ALB proactively
  • Eliminates the need to open AWS support cases for pre-warming
  • Useful for planned events such as product launches, sales, or traffic migrations
  • Capacity is reserved at the regional level and distributed across AZs
  • Reserved capacity can be increased anytime; decreased up to two times per day
  • Charged per reserved LCU per minute, plus additional LCUs used beyond reservation

Resource Map

  • Launched March 2024 in the AWS Management Console
  • Displays all ALB resources and their relationships in a visual format on a single page
  • Provides clear understanding of ALB architecture (listeners, rules, target groups, targets)
  • Includes an Unhealthy Target Map view to display only unhealthy targets and associated resources
  • Useful for troubleshooting and architecture visualization

Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

Refer Blog Post @ Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

Application Load Balancer Benefits

  • Support for Path-based routing, where listener rules can be configured to forward requests based on the URL in the request. This enables structuring applications as smaller services (microservices), and route requests to the correct service based on the content of the URL.
  • Support for routing requests to multiple services on a single EC2 instance by registering the instance using multiple ports using Dynamic Port mapping.
  • Support for containerized applications. EC2 Container Service (ECS) can select an unused port when scheduling a task and register the task with a target group using this port, enabling efficient use of the clusters.
  • Support for monitoring the health of each service independently, as health checks are defined at the target group level and many CloudWatch metrics are reported at the target group level.
  • Attaching a target group to an Auto Scaling group enables scaling each service dynamically based on demand.
  • Support for built-in user authentication using OIDC or Amazon Cognito, eliminating custom authentication code.
  • Support for gRPC and end-to-end HTTP/2 workloads for modern microservice architectures.
  • Support for Mutual TLS (mTLS) for enhanced zero-trust security.

Application Load Balancer Listeners

  • A listener is a process that checks for connection requests, using the configured protocol and port
  • Listener supports HTTP & HTTPS protocol with Ports from 1-65535
  • ALB supports SSL Termination for HTTPS listeners, which helps to offload the work of encryption and decryption so that the targets can focus on their main work.
  • HTTPS listener must have at least one SSL server certificate on the listener
  • supports multiple TLS certificates using SNI (Server Name Indication) on a single HTTPS listener
  • WebSockets with both HTTP and HTTPS listeners (Secure WebSockets)
  • Supports HTTP/2 with HTTPS listeners
    • 128 requests can be sent in parallel using one HTTP/2 connection.
    • ALB can forward HTTP/2 end-to-end to targets (for gRPC) or convert to individual HTTP/1.1 requests
    • HTTP/2 uses front-end connections more efficiently resulting in fewer connections between clients and the load balancer.
    • Server-push feature of HTTP/2 is not supported
  • Each listener has a default rule, and can optionally define additional rules.
  • Each rule consists of a priority, one or more actions, one or more conditions, and optional transforms.
    • Priority – Rules are evaluated in priority order, from the lowest value to the highest value. The default rule has the lowest priority
    • Action – Supported action types: forward, redirect, fixed-response, authenticate-oidc, authenticate-cognito, jwt-validation
    • Condition – Supported conditions: host-header, path-pattern, http-request-method, source-ip, http-header, query-string
    • Transform – Supports URL rewrite and host header rewrite using regex patterns (launched Oct 2025)
  • Host Condition or Host-based routing
    • Host conditions can be used to define rules that forward requests to different target groups based on the hostname in the host header
    • This enables support for multiple domains using a single ALB for e.g. orders.example.com, images.example.com, registration.example.com
    • Each host condition has one hostname. If the hostname in
  • Path Condition or path-based routing
    • Path conditions can be used to define rules that forward requests to different target groups based on the URL in the request
    • Each path condition has one path pattern for e.g. example.com/orders, example.com/images, example.com/registration
    • If the URL in a request matches the path pattern in a listener rule exactly, the request is routed using that rule.

Advantages over Classic Load Balancer

  • Support for path-based routing, where rules can be configured for the listener to forward requests based on the content of the URL
  • Support for host-based routing, where rules can be configured for the listener to forward requests based on the host field in the HTTP header.
  • Support for routing based on fields in the request, such as standard and custom HTTP headers and methods, query parameters, and source IP address
  • Support for routing requests to multiple applications on a single EC2 instance. Each instance or IP address can be registered with the same target group using multiple ports
  • Support for registering targets by IP address, including targets outside the VPC for the load balancer.
  • Support for redirecting requests from one URL to another.
  • Support for returning a custom HTTP response.
  • Support for registering Lambda functions as targets.
  • Support for the load balancer to authenticate users of the applications through their corporate or social identities before routing requests.
  • Support containerized applications with ECS using Dynamic port mapping
  • Support monitoring the health of each service independently, as health checks and many CloudWatch metrics are defined at the target group level
  • Attaching the target group to an Auto Scaling group enables scaling of each service dynamically based on demand
  • Access logs contain additional information & stored in compressed format
  • Improved load balancer performance.
  • Support for SNI (multiple TLS certificates on a single listener)
  • Support for gRPC and end-to-end HTTP/2
  • Support for Mutual TLS (mTLS) authentication
  • Support for JWT verification at the load balancer
  • Support for URL and Host Header rewrite using regex

Application Load Balancer Pricing

  • charged for each hour or partial hour that an ALB is running and the number of Load Balancer Capacity Units (LCU) used per hour.
  • An LCU is a metric for determining ALB pricing
  • An LCU defines the maximum resource consumed in any one of the dimensions (new connections, active connections, bandwidth and rule evaluations) the Application Load Balancer processes the traffic.
  • With LCU Capacity Reservation, you are charged per reserved LCU per minute, plus additional LCUs used per minute beyond the reserved amount.

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 are designing an application which requires websockets support, to exchange real-time messages with end-users without the end users having to request (or poll) the server for an update? Which ELB option should you choose?
    1. Use Application Load Balancer and enable comet support
    2. Use Classic Load Balancer which supports WebSockets
    3. Use Application Load Balancer which supports WebSockets
    4. Use Classic Load Balancer and enable comet support
  2. Which of the following Internet protocols does an AWS Application Load Balancer Support? Choose 2 answers
    A. ICMP
    B. UDP
    C. HTTP
    D. SNTP
    E. Websocket
  3. Your organization has configured an application behind ALB. However, Clients are complaining that they cannot connect to an Internet-facing load balancer. What cannot be the issue?
    1. Internet-facing load balancer is attached to a private subnet
    2. ALB Security Groups does not allow the traffic
    3. Subnet NACLs do not allow the traffic
    4. ALB was not assigned an EIP
  4. To protect your ALB from accidental deletion, you should
    1. enable Multi-Factor Authentication (MFA) protected access
    2. enable Delete Protection on the ALB
    3. enabled Termination Protection on the ALB
    4. ALB does not provide any feature to prevent accidental deletion
  5. Your organization is using ALB for servicing requests. One of the API request is facing consistent performance issues. Upon checking the flow, you find that the request flows through multiple services. How can you track the performance or timing issues in the application stack at the granularity of an individual request?
    1. Track the request using “X-Amzn-Trace-Id” HTTP header
    2. Track the request using “X-Amzn-Track-Id” HTTP header
    3. Track the request using “X-Aws-Track-Id” HTTP header
    4. Track the request using “X-Aws-Trace-Id” HTTP header
  6. A company wants to offload user authentication from their backend services. They want the ALB to handle authentication using their corporate identity provider which supports OpenID Connect. Which ALB action type should they configure?
    1. forward with custom headers
    2. authenticate-oidc
    3. redirect to identity provider
    4. fixed-response with authentication challenge
  7. An application team notices that one of their targets behind an ALB passes health checks but returns HTTP 500 errors for approximately 10% of requests. Which ALB feature helps mitigate this issue automatically?
    1. Weighted target group routing
    2. Least Outstanding Requests algorithm
    3. Automatic Target Weights (ATW)
    4. Slow Start Mode
  8. A company needs to ensure that only clients presenting valid X.509 certificates can access their application behind an ALB. Which ALB feature should they use?
    1. AWS WAF with custom rules
    2. Security group inbound rules
    3. Mutual TLS (mTLS) authentication
    4. OIDC authentication action
  9. A microservices team wants to route gRPC traffic between their services using ALB. What are the requirements? (Choose 2)
    1. Configure the listener protocol as HTTPS
    2. Configure the listener protocol as HTTP
    3. Set the target group protocol version to gRPC
    4. Enable WebSocket support on the listener
    5. Use an HTTP/1.1 target group
  10. Your application experiences sudden traffic spikes during planned product launches. You want to ensure ALB has sufficient capacity before the event. What should you do?
    1. Manually scale the backend targets
    2. Open an AWS support case for pre-warming
    3. Configure LCU Capacity Reservation for the ALB
    4. Deploy multiple ALBs behind Route 53

References

AWS Route 53

How Route 53 Routes Traffic

AWS Route 53

  • Route 53 is a highly available and scalable Domain Name System (DNS) web service.
  • Route 53 provides three main functions:
    • Domain registration
      • allows domain names registration
      • supports registration and management of 34+ new top-level domains (TLDs) including .app, .dev, .art, .forum, .health, and .realty
    • Domain Name System (DNS) service
      • translates friendly domains names like www.example.com into IP addresses like 192.0.2.1
      • responds to DNS queries using a global network of authoritative DNS servers, which reduces latency
      • can route Internet traffic to CloudFront, Elastic Beanstalk, ELB, or S3. There’s no charge for DNS queries to these resources
    • Health Checking
      • can monitor the health of resources such as web and email servers.
      • sends automated requests over the Internet to the application to verify that it’s reachable, available, and functional
      • CloudWatch alarms can be configured for the health checks to send notifications when a resource becomes unavailable.
      • can be configured to route Internet traffic away from resources that are unavailable
    • Security
      • supports both DNSSEC for domain registration and DNSSEC signing
      • supports AWS PrivateLink for API requests, allowing workloads to manage DNS infrastructure without using the public internet (announced Nov 2025)

How Route 53 Routes Traffic

Supported DNS Resource Record Types

  • A (Address) Format
    • is an IPv4 address in dotted decimal notation for e.g. 192.0.2.1
  • AAAA Format
    • is an IPv6 address in colon-separated hexadecimal format
  • CNAME Format
    • is the same format as a domain name
    • DNS protocol does not allow creation of a CNAME record for the top node of a DNS namespace, also known as the zone apex for e.g. the DNS name example.com registration, the zone apex is example.com, a CNAME record for example.com cannot be created, but CNAME records can be created for www.example.com, newproduct.example.com etc.
    • If a CNAME record is created for a subdomain, any other resource record sets for that subdomain cannot be created for e.g. if a CNAME created for www.example.com, no other resource record sets for which the value of the Name field is www.example.com can be created
  • MX (Mail Xchange) Format
    • contains a decimal number that represents the priority of the MX record, and the domain name of an email server
  • NS (Name Server) Format
    • An NS record identifies the name servers for the hosted zone. The value for an NS record is the domain name of a name server.
  • PTR Format
    • A PTR record Value element is the same format as a domain name.
  • SOA (Start of Authority) Format
    • SOA record provides information about a domain and the corresponding Amazon Route 53 hosted zone
  • SPF (Sender Policy Framework) Format
    • SPF records were formerly used to verify the identity of the sender of email messages, however is not recommended
    • Instead of an SPF record, a TXT record that contains the applicable value is recommended
  • SRV Format
    • An SRV record Value element consists of four space-separated values. The first three values are decimal numbers representing priority, weight, and port. The fourth value is a domain name for e.g. 10 5 80 hostname.example.com
  • TXT (Text) Format
    • A TXT record contains a space-separated list of double-quoted strings. A single string include a maximum of 255 characters. In addition to the characters that are permitted unescaped in domain names, space is allowed in TXT strings
  • HTTPS Format (New – Oct 2024)
    • HTTPS records are specific for use with the HTTP protocol and allow application owners to bind endpoint-specific information into the DNS reply.
    • Enables clients to discover the optimal HTTP protocol version (HTTP/2, HTTP/3) during the initial DNS resolution phase rather than in a subsequent connection step, reducing latency.
    • Supports two modes: AliasMode (aliases a DNS name to another DNS name) and ServiceMode (passes parameters like ALPN, port, ECH, and IP hints).
    • Supported for both public and private hosted zones.
  • SVCB (Service Binding) Format (New – Oct 2024)
    • SVCB records allow application owners to bind endpoint-specific information for any service, irrespective of protocol.
    • Similar to HTTPS records but the record name includes the port and protocol.
    • Supports AliasMode and ServiceMode with parameters like TLS ALPN, port number, ECH configuration, and IP hints.
    • Supported for both public and private hosted zones.
  • TLSA Format (New – Oct 2024)
    • TLSA records allow administrators to specify a public key fingerprint of the TLS certificate in DNS (DNS-based Authentication of Named Entities – DANE).
    • Enables a TLS client to verify using DNS that the certificate presented by a server is expected.
    • Helps prevent man-in-the-middle attacks and downgrade attacks, particularly useful for SMTP over TLS.
    • Requires DNSSEC to be enabled on the hosted zone.
    • Supported only for public hosted zones.
  • SSHFP (Secure Shell Fingerprint) Format (New – Oct 2024)
    • SSHFP records allow DNS servers to answer SSH client requests for SSH fingerprints with DNSSEC-signed records.
    • SSH client validates the fingerprint a server presents with those provided by the DNS server, mitigating man-in-the-middle attacks.
    • Requires DNSSEC to be enabled on the hosted zone and DNSSEC validation on the client.
    • Supported only for public hosted zones.

Alias Resource Record Sets

  • Route 53 supports alias resource record sets, which enables routing of queries to a CloudFront distribution, Elastic Beanstalk, ELB, an S3 bucket configured as a static website, or another Route 53 resource record set
  • Alias records are not standard for DNS RFC and are a Route 53 extension to DNS functionality
  • Alias record is similar to a CNAME record and is always of type A or AAAA
  • Alias record can be created both for the root domain or apex zone, such as example.com, and for subdomains, such as www.example.com. CNAME records can be used only for subdomains.
  • Route 53 automatically recognizes changes in the resource record sets that the alias resource record set refers to for e.g. for a site pointing to a load balancer, if the IP of the load balancer changes, it will reflect those changes automatically in the DNS answers without any changes to the hosted zone that contains resource record sets
  • Alias resource record set does not support TTL or Time to Live if it points to a CloudFront distribution, an ELB, or an S3 bucket. Underlying CloudFront, load balancer, or S3 TTLs are used.
  • Alias records are free to query and do not incur any charges.
  • Alias record supported targets
  • Alias records are not supported for
    • EC2 DNS
    • RDS endpoints.

Route 53 Alias vs CNAME

Refer to blog post @ Route 53 Alias vs CNAME

Route 53 CNAME vs Alias Records

Route 53 Hosted Zone

  • Hosted Zone is a container for records, which include information about how to route traffic for a domain (such as example.com) and all of its subdomains (such as www.example.com, retail.example.com, and seattle.accounting.example.com).
  • A hosted zone has the same name as the corresponding domain.
  • Routing Traffic to the Resources
    • Create a hosted zone with either a public hosted zone or a private hosted zone:
      • Public Hosted Zone – for routing internet traffic to the resources for a specific domain and its subdomains
      • Private hosted zone – for routing traffic within a VPC
    • Create records in the hosted zone
      • Records define where to route traffic for each domain name or subdomain name.
      • Name of each record in a hosted zone must end with the name of the hosted zone.
  • For public/private and private Hosted Zones that have overlapping namespaces, Route 53 Resolvers routes traffic to the most specific match.
  • IAM permissions apply only at the Hosted Zone level
  • Accelerated Recovery (New – Nov 2025)
    • Accelerated recovery for public hosted zones targets a 60-minute Recovery Time Objective (RTO) for DNS record changes during service disruptions in the US East (N. Virginia) Region.
    • Provides built-in failover of the Route 53 control plane to the Oregon Region (us-west-2).
    • When enabled, allows making changes to DNS records in public hosted zones even when the us-east-1 Region is unavailable.
    • Enhances business continuity for mission-critical applications that rely on DNS changes for failover.

Route 53 Health Checks

  • Route 53 health checks monitor the health and performance of the underlying resources.
  • Health check types
    • Health checks that monitor an endpoint, such as a web server.
      • Health checkers are located in locations around the world.
      • The health checker location and interval can be specified.
      • Health checker evaluates the health of the endpoint based
        • Response time
        • Specified failure threshold – Whether the endpoint responds to a number of consecutive health checks
      • The endpoint is considered healthy if more than 18% of health checkers report that an endpoint is healthy.
      • Health check is considered healthy if
        • HTTP and HTTPS health checks
          • TCP connection can be established within four seconds.
          • Returns 2xx or 3xx within two seconds after connecting.
        • TCP health checks
          • TCP connection can be established within ten seconds.
        • HTTP and HTTPS health checks with string matching
          • TCP connection can be established within four seconds.
          • Returns 2xx or 3xx within two seconds after connecting.
          • Route 53 searches the response body for the specified string which must appear entirely in the first 5,120 bytes of the response body or the endpoint fails the health check.
    • Calculated health checks – Health checks that monitor the status of other health checks.
      • Health check that does the monitoring is the parent health check, and the health checks that are monitored are child health checks.
      • One parent health check can monitor the health of up to 255 child health checks
    • Health checks that monitor the status of a CloudWatch alarm.
      • Route 53 monitors the data stream for the corresponding alarm instead of monitoring the alarm state.
  • Route 53 checks the health of an endpoint by sending an HTTP, HTTPS, or TCP request to the specified IP address and port.
  • For a health check to succeed, the router and firewall rules must allow inbound traffic from the IP addresses that the health checkers use.

Route 53 Routing Policies

Refer Blog post @ Route 53 Routing Policies

Route 53 Resolver

Refer Blog post @ Route 53 Resolver

Route 53 Global Resolver (New – GA March 2026)

  • Route 53 Global Resolver is an internet-reachable anycast DNS resolver that delivers easy, secure, and reliable DNS resolution for authorized clients from anywhere.
  • Provides DNS resolution for authenticated clients in on-premises data centers, branch offices, and remote locations through globally distributed anycast IP addresses.
  • Resolves both public internet domains and Route 53 private hosted zones, eliminating the need for separate split-DNS forwarding infrastructure.
  • Supports multiple DNS protocols including DNS over UDP (Do53), DNS-over-HTTPS (DoH), and DNS-over-TLS (DoT).
  • Includes built-in security controls:
    • DNS traffic filtering to block potentially malicious domains
    • Support for encrypted DNS queries
    • Centralized logging for auditing and compliance
    • Integration with Route 53 Resolver DNS Firewall rules (threat categories, content categories, and advanced DNS threat protection)
  • Anycast architecture automatically routes each query to the closest healthy AWS Region, providing built-in failover without client-side changes.
  • Deployed across multiple AWS Regions simultaneously (minimum two).
  • Supports adding and removing AWS Regions for flexible control over where DNS queries are resolved.
  • Available across 30+ AWS Regions with support for both IPv4 and IPv6 DNS query traffic.

Route 53 Profiles (New – April 2024)

  • Route 53 Profiles allows defining a standard DNS configuration and applying it to multiple VPCs in the same AWS Region.
  • A Profile can include:
    • Route 53 private hosted zone (PHZ) associations
    • Route 53 Resolver forwarding rules
    • Route 53 Resolver DNS Firewall rule groups
    • VPC endpoint associations
  • Profiles can be shared across AWS accounts using AWS Resource Access Manager (RAM).
  • Eliminates the need for per-VPC PHZ associations by allowing DNS configurations to be managed centrally.
  • Simplifies DNS management in multi-account environments by reducing operational complexity.
  • Supports consistent DNS Query Logging configuration at the Profile level with automatic propagation to all associated VPCs.
  • Supports granular IAM permissions for resource and VPC associations.
  • Supports AWS PrivateLink for private access to manage Profiles without going through the public internet.

Route 53 Split-view (Split-horizon) DNS

  • Route 53 Split-view (Split-horizon) DNS helps access an internal version of the website using the same domain name that is used publicly.
  • Both a private and public hosted zone can be maintained with the same domain name for split-view DNS.
  • Ensure that DNS resolution and DNS hostnames are enabled on the source VPC.
  • DNS queries will respond with answers based on the source of the request.
  • From within the VPC, answers will come from the private hosted zone, while public queries will return answers from the public hosted zone.

Route 53 DNSSEC

  • DNSSEC – Domain Name System Security Extensions, a protocol for securing DNS traffic, helps protect a domain from DNS spoofing man-in-the-middle attacks.
  • DNSSEC works only for public hosted zones.
  • Route 53 supports DNSSEC signing as well as DNSSEC for domain registration.
  • With DNSSEC enabled for a domain, the DNS resolver establishes a chain of trust for responses from intermediate resolvers.
  • The chain of trust begins with the TLD registry for the domain (your domain’s parent zone) and ends with the authoritative name servers at your DNS service provider.
  • With DNSSEC enabled, Route 53 creates a key-signing key (KSK) using customer managed key in AWS KMS that supports DNSSEC. The customer-managed key must meet the following requirements:
    • must be in the US East (N. Virginia) Region
    • must be an asymmetric customer managed key with an ECC_NIST_P256 key spec.

Route 53 Resolver DNS Firewall

  • Route 53 Resolver DNS Firewall provides protection for outbound DNS requests from the VPCs and can monitor and control the domains that the applications can query.
  • DNS Firewall can filter and regulate outbound DNS traffic for the VPC.
  • Reusable collections of filtering rules can be created in DNS Firewall rule groups and be associated with the VPC, with the activity monitored in DNS Firewall logs and metrics.
  • A primary use of DNS Firewall protections is to help prevent DNS exfiltration of the data. DNS exfiltration can happen when a bad actor compromises an application instance in the VPC and then uses DNS lookup to send data out of the VPC to a domain that they control.
  • DNS Firewall can be configured to
    • deny access to the domains that you know to be bad and allow all other queries to pass through OR
    • deny access to all domains except for the ones that you explicitly trust.
  • DNS Firewall is a feature of Route 53 Resolver and doesn’t require any additional Resolver setup to use.
  • Firewall Manager can be used to centrally configure and manage the DNS Firewall rule group associations for the VPCs across the accounts in an Organization. Firewall Manager automatically adds associations for VPCs that come into the scope of the Firewall Manager DNS Firewall policy.
  • DNS Firewall Advanced (New – Nov 2024)
    • DNS Firewall Advanced provides intelligent, real-time protection against advanced DNS threats.
    • Detects DNS tunneling attacks by inspecting DNS payload characteristics including request timestamps, frequency, query string length, and response sizes.
    • Identifies Domain Generation Algorithm (DGA) based threats, including dictionary-based DGAs used by attackers to evade detection in malware command-and-control communications.
    • Supports threat domain categories (e.g., Malware, Spam, Phishing) for DNS query blocking based on DNS threat types.
    • Supports content domain categories (e.g., Adult Content, Gambling, Not-safe-for-work domains) for granular content filtering.
    • Works alongside existing DNS Firewall domain list rules for comprehensive defense-in-depth.

Route 53 Application Recovery Controller (ARC)

  • Route 53 Application Recovery Controller helps manage and coordinate recovery for applications across AWS Regions and Availability Zones.
  • Zonal Shift
    • Zonal shift allows shifting traffic for a supported resource away from an impaired Availability Zone to healthy AZs in the same Region.
    • All zonal shifts are temporary and must be set initially to expire within three days (72 hours), but can be updated to set a new expiration.
  • Zonal Autoshift
    • Zonal autoshift allows AWS to automatically shift traffic away from an AZ when AWS detects a potential failure there.
    • Operates on the principle of static stability, where the application is pre-scaled across multiple AZs to handle the complete loss of capacity in any single zone.
    • Practice runs are initiated to ensure that shifting traffic during an autoshift is safe for the application.
  • Routing Control
    • Routing controls are simple on/off switches that allow failover of traffic from one replica to another.
    • Enables highly available data plane operations for multi-Region failover.

Route 53 Logging

  • DNS Query Logging
    • DNS Query logs contain information like
      • Domain or subdomain that was requested
      • Date and time of the request
      • DNS record type (such as A or AAAA)
      • Route 53 edge location that responded to the DNS query
      • DNS response code, such as NoError or ServFail
    • Route 53 will send DNS Query logs to CloudWatch Logs.
    • DNS Query Logging is only available for public hosted zones. Use Resolver Query logging for private hosted zones.
    • Query logs contain only the queries that DNS resolvers forward to Route 53 and do not include the entries cached by DNS resolvers.
  • Resolver Query Logging
    • Resolver Query logging logs the following queries
      • Queries that originate in specified VPCs, as well as the responses to those DNS queries.
      • Queries from on-premises resources that use an inbound Resolver endpoint.
      • Queries that use an outbound Resolver endpoint for recursive DNS resolution.
      • Queries that use Route 53 Resolver DNS Firewall rules to block, allow, or monitor domain lists.
    • Resolver query logging logs only unique queries, not queries that Resolver is able to respond to from the cache.
    • Resolver query logs include values such as the following:
      • AWS Region where the VPC was created
      • The ID of the VPC that the query originated from
      • The IP address of the instance that the query originated from
      • The instance ID of the resource that the query originated from
      • The date and time that the query was first made
      • The DNS name requested (such as prod.example.com)
      • The DNS record type (such as A or AAAA)
      • The DNS response code, such as NoError or ServFail
      • The DNS response data, such as the IP address that is returned in response to the DNS query
      • A response to a DNS Firewall rule action
    • Route 53 will send Resolver Query logs to

Route 53 Resolver Endpoints – DNS Delegation (New – June 2025)

  • Route 53 Resolver endpoints now support DNS delegation for private hosted zones.
  • Allows delegating the authority for a subdomain from on-premises infrastructure to the Route 53 Resolver cloud service and vice versa.
  • Uses standard name server (NS) records for delegation, eliminating the need for conditional forwarding rules across the organization.
  • Simplifies hybrid DNS management by providing a cloud-native experience across namespaces in AWS and on-premises infrastructure.
  • Supports Resolver endpoints with DNS64 on inbound endpoints and IPv6 forwarding through IGW on outbound endpoints for IPv4/IPv6 hybrid network management.

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. What does Amazon Route53 provide?
    1. A global Content Delivery Network.
    2. None of these.
    3. A scalable Domain Name System
    4. An SSH endpoint for Amazon EC2.
  2. Does Amazon Route 53 support NS Records?
    1. Yes, it supports Name Service records.
    2. No
    3. It supports only MX records.
    4. Yes, it supports Name Server records.
  3. Does Route 53 support MX Records?
    1. Yes
    2. It supports CNAME records, but not MX records.
    3. No
    4. Only Primary MX records. Secondary MX records are not supported.
  4. Which of the following statements are true about Amazon Route 53 resource records? Choose 2 answers
    1. An Alias record can map one DNS name to another Amazon Route 53 DNS name.
    2. A CNAME record can be created for your zone apex.
    3. An Amazon Route 53 CNAME record can point to any DNS record hosted anywhere.
    4. TTL can be set for an Alias record in Amazon Route 53.
    5. An Amazon Route 53 Alias record can point to any DNS record hosted anywhere.
  5. Which statements are true about Amazon Route 53? (Choose 2 answers)
    1. Amazon Route 53 is a region-level service
    2. You can register your domain name
    3. Amazon Route 53 can perform health checks and failovers to a backup site in the event of the primary site failure
    4. Amazon Route 53 only supports Latency-based routing
  6. A customer is hosting their company website on a cluster of web servers that are behind a public-facing load balancer. The customer also uses Amazon Route 53 to manage their public DNS. How should the customer configure the DNS zone apex record to point to the load balancer?
    1. Create an A record pointing to the IP address of the load balancer
    2. Create a CNAME record pointing to the load balancer DNS name.
    3. Create a CNAME record aliased to the load balancer DNS name.
    4. Create an A record aliased to the load balancer DNS name
  7. A user has configured ELB with three instances. The user wants to achieve High Availability as well as redundancy with ELB. Which of the below mentioned AWS services helps the user achieve this for ELB?
    1. Route 53
    2. AWS Mechanical Turk
    3. Auto Scaling
    4. AWS EMR
  8. How can the domain’s zone apex for example “myzoneapexdomain.com” be pointed towards an Elastic Load Balancer?
    1. By using an AAAA record
    2. By using an A record
    3. By using an Amazon Route 53 CNAME record
    4. By using an Amazon Route 53 Alias record
  9. You need to create a simple, holistic check for your system’s general availability and uptime. Your system presents itself as an HTTP-speaking API. What is the simplest tool on AWS to achieve this with?
    1. Route53 Health Checks (Refer link)
    2. CloudWatch Health Checks
    3. AWS ELB Health Checks
    4. EC2 Health Checks
  10. Your organization’s corporate website must be available on www.acme.com and acme.com. How should you configure Amazon Route 53 to meet this requirement?
    1. Configure acme.com with an ALIAS record targeting the ELB. www.acme.com with an ALIAS record targeting the ELB.
    2. Configure acme.com with an A record targeting the ELB. www.acme.com with a CNAME record targeting the acme.com record.
    3. Configure acme.com with a CNAME record targeting the ELB. www.acme.com with a CNAME record targeting the acme.com record.
    4. Configure acme.com using a second ALIAS record with the ELB target. www.acme.com using a PTR record with the acme.com record target.
  11. A company wants to prevent DNS exfiltration from their VPCs. They need to block DNS queries to known malicious domains and detect DNS tunneling attempts. Which Route 53 feature should they use? (New)
    1. Route 53 Health Checks with CloudWatch Alarms
    2. Route 53 Resolver DNS Firewall with DNS Firewall Advanced
    3. Route 53 DNSSEC Signing
    4. Route 53 Traffic Flow policies
  12. An organization manages DNS configurations across 200+ VPCs in multiple AWS accounts. They need to standardize private hosted zone associations, Resolver forwarding rules, and DNS Firewall rule groups across all VPCs. Which feature simplifies this? (New)
    1. Route 53 Traffic Flow
    2. AWS Organizations Service Control Policies
    3. Route 53 Profiles
    4. Route 53 Resolver Rules shared via RAM individually
  13. A company wants to improve the security of SMTP email between their mail servers. They need DNS to provide TLS certificate fingerprints so sending servers can verify the receiving server’s identity. Which DNS record type should they use? (New)
    1. SSHFP record
    2. HTTPS record
    3. SVCB record
    4. TLSA record
  14. A company has remote offices and on-premises data centers that need secure DNS resolution for both public internet domains and Route 53 private hosted zones without deploying Route 53 Resolver endpoints in each location. Which service should they use? (New)
    1. Route 53 Resolver with outbound endpoints in every Region
    2. A self-managed recursive DNS resolver
    3. Route 53 Global Resolver
    4. Route 53 Profiles with AWS PrivateLink
  15. A company wants to ensure they can continue making DNS record changes during a regional outage in us-east-1. Which Route 53 feature should they enable? (New)
    1. Route 53 Multi-Value Answer routing
    2. Route 53 Application Recovery Controller
    3. Route 53 Accelerated Recovery for public hosted zones
    4. Route 53 Health Checks with Failover routing

Further Reading

Amazon OpenSearch Service – Search & Analytics

Amazon OpenSearch

  • Amazon OpenSearch Service is a managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud.
  • is the successor to Elasticsearch Service and supports OpenSearch and legacy Elasticsearch OSS.
  • is a fully open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analysis.
  • OpenSearch provides
    • instance types with numerous configurations of CPU, memory, and storage capacity, including cost-effective Graviton instances
    • Up to 3 PB of attached storage
    • Cost-effective UltraWarm and cold storage for read-only data
    • Integration with AWS IAM, VPC, VPC Security Groups
    • Encryption at Rest and in Transit
    • Authentication with Cognito, HTTP basic, or SAML authentication for OpenSearch Dashboards
    • Index-level, document-level, and field-level security
    • Multi-AZ setup with node allocation across two or three AZs in the same AWS Region
    • Dedicated master nodes to offload cluster management tasks
    • Automated snapshots to back up and restore OpenSearch Service domains
    • Integration with CloudWatch for monitoring, CloudTrail for auditing, S3, Kinesis, and DynamoDB for loading streaming data into OpenSearch Service.

OpenSearch Service Domain

  • An OpenSearch Service domain is synonymous with an OpenSearch cluster.
  • Domains are clusters with specified settings, instance types, instance counts, and storage resources.
  • automates common administrative tasks, such as performing backups, monitoring instances and patching software once the domain is running.
  • uses a blue/green deployment process when updating domains. Blue/green typically refers to the practice of running two production environments, one live and one idle, and switching the two as software changes are made.
  • All domains configured for multiple AZs have zone awareness enabled to ensure shards are distributed across AZs.

OpenSearch Security

  • OpenSearch Service domains support encryption at rest through AWS Key Management Service (KMS), node-to-node encryption over TLS, and the ability to require clients to communicate with HTTPS.
  • supports only symmetric encryption KMS keys, not asymmetric ones.
  • encrypts all indices, log files, swap files, and automated snapshots.
  • does not encrypt Manual snapshots and slow & error logs.
  • can be configured to be accessible with an endpoint within the VPC or a public endpoint accessible to the internet.
  • Network access for VPC endpoints is controlled by security groups and for public endpoints, access can be granted or restricted by IP address.
  • supports integration with Cognito, to allow the end-users to log-in to OpenSearch dashboards through enterprise identity providers such as Microsoft Active Directory using SAML 2.0, Cognito User Pools, and more.

OpenSearch Storage Tiers

  • OpenSearch Service supports three integrated storage tiers, Hot, UltraWarm and Cold.
  • Hot tier is powered by data nodes which are used for indexing, updating, and providing the fastest access to data.
  • UltraWarm nodes complement the hot tier by providing a fully managed, low-cost, read-only, warm storage tier for older and less-frequently accessed data.
  • UltraWarm uses S3 for storage and removes the need to configure a replica for the warm data.
  • Cold storage is a fully-managed lowest cost storage tier that makes it easy to securely store and analyze the historical logs on-demand.
  • Cold storage helps fully detach storage from compute when they are not actively performing analysis of their data and keep the data readily available at low cost.

OpenSearch Cross-Cluster Replication

  • Cross-cluster replication helps automate copying and synchronizing indices from one cluster to another at low latency in the same or different AWS Regions.
  • Domains participating in cross-cluster replications need to meet the following criteria:
    • Participating domains should be on Elasticsearch version 7.10
    • Participating domains need to have encryption in transit enabled
    • Participating domains need to have Fine-Grained Access Control (FGAC) enabled
    • Participating domains versions should adhere to the same rules as rolling version upgrade
  • Current implementation of cross-cluster replication does not support Ultrawarm or Cold Storage.

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.

References

Amazon_OpenSearch

AWS ElastiCache Redis (Valkey) vs Memcached – When to Use Which

AWS ElastiCache Redis vs Memcached

AWS ElastiCache Redis (Valkey) vs Memcached – When to Use Which

📅 Published June 2026: Covers Valkey 9.0 (full-text search, durability), Valkey 8.2 (vector search), ElastiCache Serverless pricing, Redis OSS Extended Support, and updated exam guidance for SAA-C03 and DVA-C02.

Overview

Amazon ElastiCache is a fully managed, in-memory caching service that supports three engines: Valkey, Redis OSS, and Memcached. While all three serve as high-performance key-value stores, they differ significantly in features, architecture, and use cases. This guide provides a comprehensive comparison to help you choose the right engine for your workload.

Engine Overview

Valkey (Recommended for New Workloads)

  • Valkey is an open-source, high-performance key-value datastore stewarded by the Linux Foundation.
  • Created in March 2024 as a community-driven fork of Redis OSS 7.2 after Redis Inc. changed its licensing to a non-open-source model.
  • Backed by 40+ companies including AWS, Google, Microsoft, Oracle, and Ericsson.
  • Drop-in replacement for Redis OSS — fully compatible with existing Redis clients and commands.
  • AWS actively recommends Valkey for all new workloads due to:
    • 33% lower Serverless pricing and 20% lower node-based pricing compared to Redis OSS/Memcached.
    • Active open-source development with rapid innovation (Bloom filters, vector search, full-text search, durability).
    • BSD license — no copyleft restrictions.
  • Supports all Redis OSS features plus: vector search (8.2+), Bloom filters (8.1+), full-text search (9.0+), durability via Multi-AZ transactional log (9.0+), and hash field expiration (9.0+).

Redis OSS (Maintenance Track)

  • Redis OSS 7.2 is the last fully open-source version of Redis supported on ElastiCache.
  • As of March 2025, Redis 8.0 is licensed under AGPLv3 — a copyleft license that many organizations cannot use.
  • ElastiCache versions 4 and 5 for Redis OSS reached end of standard support on January 31, 2026. Extended Support available (at 80-160% premium) through January 31, 2029.
  • Redis OSS 6 reaches End of Life on January 31, 2027.
  • AWS recommends migrating existing Redis OSS workloads to Valkey — zero-downtime, in-place upgrades are supported.
  • Supports complex data types (strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLog, geospatial, streams), persistence, replication, Pub/Sub, Lua scripting, and cluster mode.

Memcached

  • Memcached is a fully open-source (BSD licensed), high-performance, distributed memory object caching system.
  • Designed for simplicity — pure key-value caching with a multi-threaded architecture.
  • Ideal for simple caching use cases where advanced data structures, persistence, and replication are not needed.
  • Supports only simple data types (strings and objects up to 1 MB).
  • Multi-threaded — can utilize multiple CPU cores on a single node, unlike Valkey/Redis which are single-threaded (with I/O multithreading in Valkey).
  • No replication, no automatic failover, no persistence (node-based), no Pub/Sub.
  • Supports horizontal scaling by adding/removing nodes from the cluster.

Detailed Comparison Table

Feature Valkey / Redis OSS Memcached
Data Types Complex — strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLog, geospatial, streams, Bloom filters (Valkey 8.1+) Simple — strings and objects only
Persistence Yes — RDB snapshots + AOF. Valkey 9.0 adds durability via Multi-AZ transactional log No — data lost on node restart (node-based)
Replication Yes — up to 5 read replicas per shard No
Multi-AZ with Automatic Failover Yes — automatic failover to read replica No — requires application-level redundancy
Clustering / Data Partitioning Yes — cluster mode with up to 500 shards Yes — client-side sharding across nodes
Pub/Sub Yes — including Sharded Pub/Sub (7.2+) No
Lua Scripting Yes — Lua scripts and Functions (7.2+) No
Backup & Restore Yes — automated daily snapshots + manual snapshots Serverless only (not available for node-based clusters)
Encryption at Rest Yes (4.0.10+) No
Encryption in Transit (TLS) Yes (4.0.10+) Yes (1.6.12+)
Compliance (HIPAA, FedRAMP, PCI DSS) Yes Yes (1.6.12+ for HIPAA/FedRAMP)
Multi-threaded No (single-threaded with I/O multithreading in Valkey) Yes — utilizes multiple CPU cores
Geospatial Indexing Yes (4.0.10+, polygon queries in Valkey 9.0) No
Vector Search Yes (Valkey 8.2+) — microsecond latency, 95%+ recall No
Full-Text Search Yes (Valkey 9.0+) — hybrid text + vector search No
Sorted Sets / Leaderboards Yes No
Data Tiering (SSD) Yes (6.2+ with r6gd nodes) — 5x more storage, 60%+ cost savings No
Global Datastore (Cross-Region) Yes — fully managed cross-region replication No
Authentication AUTH token + RBAC (Role-Based Access Control, 6.0+) SASL authentication
Max Item Size 512 MB per key 1 MB per item (default)

ElastiCache Serverless

ElastiCache Serverless (GA November 2023) eliminates infrastructure management for all three engines. It automatically scales compute, memory, and network to match demand with no nodes to provision or manage.

Feature Serverless for Valkey Serverless for Redis OSS Serverless for Memcached
Availability SLA 99.99% 99.99% 99.99%
Multi-AZ Yes (default) Yes (default) Yes (default)
Backup & Restore Yes Yes Yes
Minimum Data Storage 100 MB (90% lower) 1 GB 1 GB
Max Throughput 5 million RPS (Valkey 8.0+) 5 million RPS 5 million RPS
Zero Downtime Maintenance Yes Yes Yes
IPv6 / Dual-Stack Yes Yes Yes
Create Time < 1 minute < 1 minute < 1 minute

Key Serverless Benefit: Memcached Serverless now includes backup & restore, which is NOT available for node-based Memcached clusters. This resolves one of Memcached’s traditional limitations.

Pricing Comparison (US East – N. Virginia)

ElastiCache Serverless Pricing

Dimension Valkey Redis OSS Memcached
ECPU (per million) $0.0023 $0.0034 $0.0034
Data Storage (per GB-hour) $0.084 $0.125 $0.125
Min Data Metered 100 MB 1 GB 1 GB
Savings vs Redis/Memcached 33% lower Baseline Baseline

Node-Based Pricing (On-Demand, cache.r7g.large)

Dimension Valkey Redis OSS Memcached
On-Demand (per hour) $0.1402 $0.1752 $0.218
Savings vs Redis OSS 20% lower Baseline
Reserved (1-yr, All Upfront) Up to 55% off On-Demand Up to 55% off On-Demand Up to 55% off On-Demand
Extended Support Premium N/A 80% (Yr 1-2), 160% (Yr 3) N/A

Cost Optimization Tips:

  • Migrate Redis OSS → Valkey for immediate 20-33% savings with zero-downtime, in-place upgrades.
  • Existing Redis OSS Reserved Instances automatically apply to Valkey nodes in the same instance family — you get 20% more value.
  • Use Database Savings Plans (1-year commitment) for additional savings on Serverless.
  • Use Data Tiering (r6gd nodes) for workloads accessing <20% of data frequently — 60%+ cost savings.
  • Backup storage: $0.085 per GiB/month for all engines.

Decision Guide – When to Use Which

Choose Valkey (Recommended Default) When:

  • Starting any new caching workload — Valkey is the default recommendation.
  • You need complex data structures (sorted sets, lists, hashes, streams).
  • You need persistence, backup/restore, or durability for data protection.
  • You need high availability with Multi-AZ automatic failover.
  • You need Pub/Sub for real-time messaging.
  • You need Lua scripting or server-side Functions for atomic operations.
  • You need leaderboards, ranking, or rate limiting.
  • You need session management with automatic expiration.
  • You need geospatial queries (nearby search, distance calculations).
  • You need vector similarity search for AI/ML recommendations (Valkey 8.2+).
  • You need full-text search within your cache layer (Valkey 9.0+).
  • You need cross-region replication (Global Datastore).
  • You want the lowest cost option (33% cheaper Serverless, 20% cheaper node-based).

Choose Memcached When:

  • You need the simplest possible caching model — just key-value GET/SET.
  • You need multi-threaded performance on large nodes with multiple cores.
  • You need horizontal scaling with simple add/remove node operations.
  • You are caching database query results or rendered HTML fragments.
  • You don’t need persistence — data can be easily regenerated from the source.
  • You don’t need replication or automatic failover (or use Serverless for HA).
  • Your objects are simple strings/blobs and you don’t need complex data operations.
  • You have an existing Memcached application and don’t want to change client code.

Common Use Case Mapping

Use Case Recommended Engine Why
Session store Valkey Persistence + TTL + replication prevent session loss
Gaming leaderboard Valkey Sorted sets with O(log N) ranking operations
Real-time chat / messaging Valkey Pub/Sub + Lists for message queues
AI recommendation engine Valkey 8.2+ Native vector search with microsecond latency
Database query caching Valkey or Memcached Both work; Valkey preferred for persistence
Simple object caching (HTML, API responses) Memcached Simple key-value with multi-threaded throughput
Rate limiting Valkey Atomic INCR with TTL expiration
Geospatial (nearby stores, riders) Valkey GEOADD, GEORADIUS, polygon queries (9.0)
Durable cache / primary datastore Valkey 9.0 Multi-AZ transactional log for zero data loss
Large-scale ephemeral caching Memcached Multi-threaded, simple horizontal scaling

DAX vs ElastiCache – When to Use Which

DynamoDB Accelerator (DAX) and ElastiCache are both in-memory caching solutions, but they serve different purposes:

Criteria DAX ElastiCache
Purpose Accelerate DynamoDB reads General-purpose in-memory cache for any data source
Data Source DynamoDB only Any (RDS, APIs, DynamoDB, files, etc.)
Code Changes Minimal — drop-in DynamoDB client replacement Requires cache-aside logic in application
Latency Microseconds (single-digit) Microseconds to sub-millisecond
Write Caching Write-through (automatic) Application-managed invalidation
Best For Read-heavy DynamoDB workloads with hot keys Aggregated results, computed data, session stores, leaderboards

Exam Tip: If the question mentions DynamoDB with read-heavy workloads and hot partitions, choose DAX. If the question involves caching from multiple sources, complex data structures, or Pub/Sub, choose ElastiCache.

AWS Certification Exam Relevance

  • SAA-C03 (Solutions Architect Associate): Frequently tests ElastiCache engine selection (Redis/Valkey vs Memcached), caching strategies (lazy loading, write-through), Multi-AZ failover, and DAX vs ElastiCache decision making.
  • DVA-C02 (Developer Associate): Tests session management with ElastiCache, caching patterns, TTL strategies, and integration with Lambda/API Gateway.
  • SAP-C02 (Solutions Architect Professional): Tests Global Datastore for cross-region caching, data tiering, and advanced caching architectures.
  • Key Exam Themes:
    • Memcached = simple, multi-threaded, no persistence, no replication.
    • Redis/Valkey = complex data types, persistence, replication, Multi-AZ, Pub/Sub, backup/restore.
    • DAX = DynamoDB-specific, microsecond reads, drop-in replacement, no code changes.
    • ElastiCache Serverless = no capacity planning, auto-scaling, pay-per-use.
    • Valkey = recommended for new workloads, lower cost, open-source.

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 company is building a gaming application that needs a real-time leaderboard with millions of players. The leaderboard must support efficient ranking, score updates, and range queries. Which ElastiCache solution should a solutions architect recommend?
    1. ElastiCache for Memcached with client-side sorting
    2. ElastiCache for Valkey using Sorted Sets
    3. ElastiCache for Memcached with application-layer ranking
    4. ElastiCache for Redis OSS with simple key-value pairs

    Answer: b. Valkey/Redis Sorted Sets provide O(log N) ranking operations with ZADD, ZRANK, and ZRANGE commands, making them ideal for leaderboards. Memcached does not support sorted sets.

  2. A startup wants to deploy an in-memory cache with the lowest possible cost and no infrastructure management. They have unpredictable traffic patterns and their average dataset is 500 MB. Which option provides the MOST cost-effective solution?
    1. ElastiCache Serverless for Redis OSS
    2. ElastiCache node-based cluster for Valkey with reserved instances
    3. ElastiCache Serverless for Valkey
    4. ElastiCache Serverless for Memcached

    Answer: c. ElastiCache Serverless for Valkey offers 33% lower pricing than Redis OSS and Memcached Serverless, with a minimum metered storage of only 100 MB (vs 1 GB for others). For unpredictable traffic, Serverless auto-scales without overprovisioning.

  3. A company has a DynamoDB table experiencing hot partition reads. Read latency must be reduced to microseconds. Which caching solution requires the LEAST application code changes?
    1. ElastiCache for Valkey with cache-aside pattern
    2. ElastiCache for Memcached with lazy loading
    3. DynamoDB Accelerator (DAX)
    4. ElastiCache for Valkey with write-through caching

    Answer: c. DAX is a drop-in replacement for the DynamoDB client — it requires minimal code changes (just change the endpoint). ElastiCache requires implementing cache-aside or write-through logic in the application.

  4. A solutions architect needs to choose a caching engine for a web application. The requirements are: multi-threaded performance, simple key-value caching of database query results, no need for persistence, and the ability to horizontally scale by adding nodes. Which engine is MOST appropriate?
    1. ElastiCache for Valkey in cluster mode
    2. ElastiCache for Memcached
    3. ElastiCache for Redis OSS with read replicas
    4. DynamoDB Accelerator (DAX)

    Answer: b. Memcached matches all stated requirements: multi-threaded, simple key-value, no persistence needed, and horizontal scaling by adding/removing nodes. While Valkey could work, it adds complexity that isn’t needed here.

  5. A company is migrating from ElastiCache for Redis OSS version 5. They received an Extended Support notification with 80% premium charges. What is the MOST cost-effective long-term migration path?
    1. Pay for Extended Support to avoid migration effort
    2. Upgrade to Redis OSS 7.2
    3. Migrate to ElastiCache for Valkey using in-place upgrade
    4. Move to Amazon MemoryDB for Redis

    Answer: c. Migrating to Valkey provides 20% lower node-based pricing (or 33% lower Serverless), active development, and avoids Extended Support premiums (80-160%). In-place upgrades from Redis OSS to Valkey are zero-downtime.

  6. A development team needs an in-memory caching solution that supports: persistence for disaster recovery, Multi-AZ failover for high availability, encryption at rest and in transit for compliance, and Pub/Sub for real-time notifications. Which combination of ElastiCache features meets ALL requirements? (Select TWO)
    1. ElastiCache for Memcached with SASL authentication
    2. ElastiCache for Valkey with Multi-AZ enabled
    3. ElastiCache for Valkey with encryption at rest and in-transit enabled
    4. ElastiCache for Memcached with TLS encryption
    5. ElastiCache for Memcached with backup enabled

    Answer: b, c. Only Valkey/Redis OSS supports persistence, Multi-AZ automatic failover, encryption at rest, AND Pub/Sub together. Memcached lacks persistence (node-based), replication, failover, encryption at rest, and Pub/Sub.

  7. An e-commerce application requires a cache that can serve as a durable primary datastore with microsecond read latency and zero data loss during failures. Which ElastiCache option should a solutions architect recommend?
    1. ElastiCache for Redis OSS 7.2 with AOF persistence
    2. ElastiCache for Valkey 8.0 with daily backups
    3. ElastiCache for Valkey 9.0 with synchronous durability
    4. ElastiCache for Memcached Serverless

    Answer: c. Valkey 9.0 introduces durability via a Multi-AZ transactional log with synchronous writes designed for zero data loss. Traditional RDB/AOF persistence can lose recent writes during failures.

Related Posts

References

AWS Transfer Family

AWS Transfer Family

  • AWS Transfer Family is a fully managed file transfer service that enables secure transfer of files into and out of AWS storage services.
  • AWS Transfer Family supports transferring data from or to Amazon S3 and Amazon EFS.
  • AWS Transfer Family supports transferring data over the following protocols:
    • Secure File Transfer Protocol (SFTP) – version 3
    • File Transfer Protocol Secure (FTPS)
    • File Transfer Protocol (FTP)
    • Applicability Statement 2 (AS2) – for B2B EDI document exchange
    • Browser-based transfers – via Transfer Family web apps
  • Transfer Family provides the following benefits:
    • A fully managed service that scales in real-time with elastic compute infrastructure and built-in autoscaling.
    • Compatible with existing applications with no need to modify them or run any file transfer protocol infrastructure.
    • A fully managed, serverless File Transfer Workflow service that makes it easy to set up, run, automate, and monitor the processing of files.
    • Supports connectors for outbound file transfers to remote SFTP and AS2 servers.
  • Transfer Family supports up to 3 AZs and is backed by an auto-scaling, redundant fleet for connection and transfer requests.
  • Transfer Family supports multiple identity provider options:
    • Service Managed – user identities stored within the service (supported for SFTP-only server endpoints).
    • Microsoft Active Directory – integration with AWS Directory Service.
    • LDAP – Lightweight Directory Access Protocol integration.
    • Custom Identity Providers – modular solution to integrate any identity provider with granular per-user controls, separating authentication logic from session configuration.
  • Transfer Family supports Amazon S3 Access Points for granular access to shared datasets.
  • For FTP and FTPS data connections, the port range used for the data channel is 8192–8200.

Endpoint Types

  • Transfer Family supports the following endpoint types:
    • Public – publicly accessible endpoint that listens for traffic over port 22 (SFTP only).
    • VPC – endpoint hosted within a VPC for greater control over access.
      • Can be configured as Internet Facing with Elastic IP addresses attached.
      • Can be configured as Internal for private access only within the VPC.
      • Supports Security Groups for source IP filtering.
      • Supports shared VPC environments.
      • Required for FTPS and FTP protocols.
  • FIPS-enabled endpoints are available for compliance requirements.

AS2 Protocol Support

  • Applicability Statement 2 (AS2) is a business-to-business (B2B) messaging protocol used to exchange Electronic Data Interchange (EDI) documents.
  • Transfer Family AS2 capabilities enable secure exchange of AS2 messages at scale while maintaining compliance and interoperability with trading partners.
  • AS2 provides data protection through encryption and peer authentication via digital certificates.
  • Key AS2 components:
    • Agreements – Bilateral trading partner agreements that define the relationship between two parties exchanging messages. Combines server, local profile, partner profile, and certificate information.
    • Profiles – Local and partner profiles that identify the sender and receiver.
    • Certificates – Used for encryption and signing of AS2 messages.
    • Connectors – Required for sending files to an externally hosted AS2 server.
  • AS2 messages are sent and received over HTTPS.
  • Integrates with AWS B2B Data Interchange for EDI document transformation and generation.

SFTP Connectors

  • SFTP connectors provide fully managed functionality to transfer files between remote SFTP servers and Amazon S3.
  • SFTP connectors can send files from Amazon S3 to an external partner-owned SFTP server and retrieve files from a partner’s SFTP server.
  • SFTP connectors authenticate to remote servers using credentials stored in AWS Secrets Manager.
  • SFTP connectors support two egress types:
    • Service Managed – uses AWS managed infrastructure for routing.
    • VPC (VPC_LATTICE) – routes traffic through your VPC using Amazon VPC Lattice, enabling connections to:
      • Private SFTP servers accessible only within a VPC.
      • Servers in shared VPCs.
      • On-premises systems connected over AWS Direct Connect.
      • Partner-hosted servers connected through VPN tunnels.
  • SFTP connectors support PGP encryption for encrypting/decrypting files before sending to remote partners.
  • SFTP connectors can list files stored on remote SFTP servers, enabling file retrieval workflows when file names are not known in advance.

Transfer Family Web Apps

  • Transfer Family web apps provide a no-code, fully managed browser-based experience for secure file transfers to and from Amazon S3.
  • Web apps enable authenticated users to perform file operations including listing, uploading, downloading, and deleting files through a web browser.
  • Web apps are integrated with AWS IAM Identity Center and Amazon S3 Access Grants, enabling fine-grained access controls that map corporate identities directly to S3 datasets.
  • Web apps are customizable to reflect company branding.
  • Supports HIPAA eligibility, PCI, and other compliance certifications.
  • One web app unit can provide up to 250 unique sessions per 5-minute period. Multiple units can be provisioned based on peak workload volumes.
  • Deployable with a few clicks in the Transfer Family console, generating a shareable URL.

Managed Workflows (MFTW)

  • Managed File Transfer Workflows (MFTW) is a fully managed, serverless workflow service that automates processing of uploaded files.
  • MFTW can automate processing steps such as:
    • Copying and tagging
    • Scanning and filtering
    • Compressing/decompressing
    • Encrypting/decrypting
    • Custom processing via Lambda functions
  • MFTW provides end-to-end visibility for tracking and auditability.
  • Workflows are triggered automatically in response to file uploads.
  • Supports both nominal (success) and exception handling steps.

Security and Encryption

  • Transfer Family supports encryption at rest using:
    • AWS KMS (Key Management Service) managed keys
    • Amazon S3 server-side encryption (SSE-S3)
    • Customer Managed Keys with Amazon EFS
  • Encryption in transit via SSH (SFTP), TLS (FTPS, AS2), and HTTPS (web apps).
  • Supports TLS 1.2 for secure communication.
  • IAM policies control access to S3 buckets and EFS file systems.
  • CloudTrail provides granular auditing of user and API activity.
  • Security Groups and Network ACLs control network-level access for VPC endpoints.

Monitoring and Logging

  • Transfer Family supports two logging mechanisms for CloudWatch:
    • JSON Structured Logging (Recommended) – provides comprehensive, queryable log format with detailed activity types (AUTH_FAILURE, CONNECTED, DISCONNECTED, ERROR, OPEN, CLOSE, DELETE, MKDIR, RENAME, etc.).
    • Logging via a Logging Role – legacy logging mechanism.
  • CloudWatch metrics track server performance and transfer activity.
  • CloudWatch alarms can trigger notifications or automated actions based on thresholds.
  • CloudTrail logging is available for Transfer Family web apps.

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 solutions architect must provide a fully managed replacement for an on-premises solution that allows employees and partners to exchange files. The solution must be easily accessible to employees connecting from on-premises systems, remote employees, and external partners. Which solution meets these requirements?
    1. Use AWS Transfer Family for SFTP to transfer files into and out of Amazon S3.
    2. Use AWS Snowball Edge for local storage and large-scale data transfers.
    3. Use Amazon FSx to store and transfer files to make them available remotely.
    4. Use AWS Storage Gateway to create a volume gateway to store and transfer files to Amazon S3.
  2. A company exchanges EDI documents with multiple trading partners. The company needs a fully managed B2B file transfer solution that supports AS2 protocol, provides non-repudiation through message disposition notifications (MDNs), and stores transferred files in Amazon S3. Which AWS service meets these requirements?
    1. AWS DataSync with S3 as the destination
    2. AWS Transfer Family with AS2 protocol configured
    3. Amazon MQ with file transfer broker
    4. AWS Storage Gateway File Gateway
  3. A company needs to provide non-technical business users with a simple web interface to upload and download files from Amazon S3 without requiring SFTP clients or AWS Console access. The solution must integrate with the company’s existing corporate directory for authentication. Which approach should a solutions architect recommend?
    1. Create a custom web application using S3 pre-signed URLs
    2. Use Amazon WorkDocs for file sharing
    3. Deploy AWS Transfer Family web apps integrated with AWS IAM Identity Center and S3 Access Grants
    4. Use Amazon AppStream 2.0 to stream an S3 browser application
  4. A company needs to automate file transfers between a partner’s SFTP server (accessible only via VPN) and Amazon S3. The partner’s server is not accessible from the public internet. Which solution meets these requirements with the LEAST operational overhead?
    1. Deploy an EC2 instance with an SFTP client in the VPC and schedule cron jobs
    2. Use AWS DataSync with a private VIF over Direct Connect
    3. Use AWS Transfer Family SFTP connectors with VPC-based (VPC_LATTICE) egress type
    4. Set up an AWS Lambda function with VPC access to connect to the SFTP server
  5. A company uses AWS Transfer Family for SFTP file transfers. The security team requires detailed, queryable audit logs of all file operations including authentication failures, file opens, deletes, and disconnections. Which logging approach should be configured?
    1. Enable CloudTrail data events for the Transfer Family server
    2. Configure S3 server access logging on the destination bucket
    3. Enable JSON structured logging for the Transfer Family server in CloudWatch
    4. Set up VPC Flow Logs on the server endpoint’s network interface

References

AWS DataSync

AWS DataSync

  • AWS DataSync is an online data movement service that simplifies, automates, and accelerates moving data between on-premises storage, other cloud providers, and AWS Storage services.
  • DataSync provides end-to-end security, including encryption and integrity validation.
  • DataSync automates both the management of data-transfer processes and the infrastructure required for high-performance and secure data transfer.
  • DataSync uses a purpose-built network protocol and a parallel, multi-threaded architecture to accelerate the transfers.
  • A DataSync agent is a VM or EC2 instance that AWS DataSync uses to read from or write to a storage system. Agents are commonly used when copying data from on-premises storage to AWS.
  • For transfers between AWS storage services (same or cross-region), no agent is required — data remains within the AWS network.
  • DataSync transfer is described by a Task and a Task Execution is an individual run of a DataSync task.
  • A task can be configured for locations (source and destination), schedule and how it treats metadata, deleted files, and permissions.
  • Task scheduling automatically runs tasks on the configured schedule with hourly, daily, or weekly options.
  • Each time a task is started it performs an incremental copy, transferring only the changes from the source to the destination.
  • If a task is interrupted, for instance, if the network connection goes down or the agent is restarted, the next run of the task will transfer missing files, and the data will be complete and consistent at the end of this run.
  • AWS DataSync can be used with the Direct Connect link to access public service endpoints or private VPC endpoints.
  • The amount of network bandwidth that AWS DataSync will use can be controlled by configuring the built-in bandwidth throttle.
  • DataSync supports both IPv4 and IPv6 addresses for connecting with the service and for data transfers with supported data sources.

DataSync Task Modes

  • DataSync tasks run in one of two modes: Enhanced mode or Basic mode.
  • Enhanced mode
    • Transfers virtually unlimited numbers of files or objects with higher performance than Basic mode.
    • Optimizes the data transfer process by listing, preparing, transferring, and verifying data in parallel.
    • Supports transfers between Amazon S3 locations, cross-cloud transfers (Azure Blob, Google Cloud Storage, Oracle Cloud Object Storage) without an agent, and transfers between NFS/SMB file servers and Amazon S3 using an Enhanced mode agent.
    • Not subject to the same file/object count quotas as Basic mode.
  • Basic mode
    • Transfers files or objects between AWS storage and all other supported DataSync locations.
    • Subject to quotas on the number of files, objects, and directories in a dataset.
    • Sequentially prepares, transfers, and verifies data, making it slower than Enhanced mode for most workloads.

DataSync Supported Locations

  • Network File System (NFS) file servers
  • Server Message Block (SMB) file servers
  • Hadoop Distributed File System (HDFS)
  • Object storage systems
  • Amazon S3 (including S3 on Outposts)
  • Amazon EFS file systems
  • Amazon FSx for Windows File Server file systems
  • Amazon FSx for Lustre file systems
  • Amazon FSx for OpenZFS file systems
  • Amazon FSx for NetApp ONTAP file systems
  • Microsoft Azure Blob Storage
  • Google Cloud Storage
  • Oracle Cloud Object Storage
  • Other S3-compatible cloud storage (Wasabi, DigitalOcean Spaces, etc.)

⚠️ Note: AWS Snowcone devices were discontinued effective November 12, 2024. DataSync on Snowcone is no longer available for new orders. Existing customers had support until November 12, 2025. Use DataSync online transfers or AWS Data Transfer Terminal as alternatives.

Cross-Cloud Transfers

  • DataSync Enhanced mode supports agentless cross-cloud transfers, enabling direct data movement between other cloud providers and Amazon S3 without deploying a DataSync agent.
  • Supported cross-cloud sources include Microsoft Azure Blob Storage, Google Cloud Storage, Oracle Cloud Object Storage, and other S3-compatible storage services.
  • Cross-cloud transfers provide higher performance and scalability compared to agent-based Basic mode transfers.
  • Simplifies multi-cloud data migration and data pipeline workflows.

DataSync Manifests

  • DataSync supports manifests, enabling users to provide a definitive list of source files or objects to be transferred by a task.
  • Using manifests, task execution times can be decreased by specifying only the files or objects that need to be processed.
  • The maximum allowable size for a manifest file with Enhanced mode tasks is 20 GB.
  • Useful for scenarios with hundreds of millions of objects where only a specific subset needs to be transferred.

DataSync Task Reports

  • Task reports provide detailed JSON-formatted output files about what DataSync attempts to transfer, skip, verify, and delete during a task execution.
  • Reports include a summary and detailed reports for files transferred, skipped, verified, and deleted.
  • Task reports are generated after the completion of transfer tasks and stored in an Amazon S3 bucket.
  • Useful for tracking and auditing data transfers, monitoring chain of custody, and troubleshooting transfer errors.

DataSync Security Features

  • DataSync integrates with AWS Secrets Manager for credential management across all location types, including HDFS, Amazon FSx for Windows File Server, and Amazon FSx for NetApp ONTAP.
  • Supports VPC endpoint policies for fine-grained access control and FIPS-enabled VPC endpoints in FIPS-enabled AWS Regions.
  • Data is encrypted in transit using TLS.
  • Supports Kerberos authentication for enhanced SMB file transfer security.
  • Location configurations can be updated without recreating locations, simplifying credential rotation and maintenance.

DataSync Agents

  • An agent is required for transfers between on-premises storage and AWS.
  • No agent is needed for transfers between AWS storage services (same or cross-region) — data remains in the AWS network.
  • Enhanced mode supports agentless cross-cloud transfers (Azure Blob, Google Cloud Storage, Oracle Cloud Object Storage to Amazon S3).
  • Enhanced mode agents are available for on-premises NFS/SMB to Amazon S3 transfers with improved performance.
  • Version 1 DataSync agents were discontinued on December 7, 2023 — affected agents must be replaced.

ℹ️ Note: DataSync Discovery was discontinued on May 20, 2025 and is no longer available as a DataSync feature.

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 company is migrating its applications to AWS. Currently, applications that run on-premises generate hundreds of terabytes of data that is stored on a shared file system. The company is running an analytics application in the cloud that runs hourly to generate insights from this data. The company needs a solution to handle the ongoing data transfer between the on-premises shared file system and Amazon S3. The solution also must be able to handle occasional interruptions in internet connectivity. Which solutions should the company use for the data transfer to meet these requirements?
    1. AWS DataSync
    2. AWS Migration Hub
    3. AWS Snowball Edge Storage Optimized
    4. AWS Transfer for SFTP
  2. A company needs to transfer 500 million objects from Google Cloud Storage to Amazon S3 with minimal operational overhead. The transfer should be completed as fast as possible without deploying any infrastructure. Which approach best meets these requirements?
    1. Deploy a DataSync agent on a Google Cloud VM and use Basic mode tasks
    2. Use DataSync Enhanced mode with agentless cross-cloud transfer directly from Google Cloud Storage to Amazon S3
    3. Use AWS Transfer Family with SFTP to pull data from Google Cloud Storage
    4. Use S3 Batch Operations to copy from Google Cloud Storage
  3. A company uses AWS DataSync to replicate data between Amazon S3 buckets in different AWS Regions. The dataset contains over 100 million objects and the company needs improved transfer performance and scalability. Which DataSync configuration should be used?
    1. Use Basic mode with multiple parallel tasks
    2. Deploy a DataSync agent in each Region
    3. Use Enhanced mode for the S3-to-S3 transfer task
    4. Enable S3 Transfer Acceleration on both buckets
  4. An organization needs to transfer only a specific set of 10,000 files from an on-premises NFS server containing millions of files to Amazon S3. They want to minimize the time spent scanning the source. Which DataSync feature should they use?
    1. Task filtering with include patterns
    2. DataSync manifests to specify the exact list of files to transfer
    3. Schedule the task during off-peak hours
    4. Use Enhanced mode with no manifest
  5. A security team requires detailed audit reports of all files transferred, skipped, and deleted during a DataSync task execution for compliance purposes. Which DataSync feature provides this capability?
    1. CloudWatch Logs integration
    2. AWS CloudTrail data events
    3. DataSync task reports
    4. Amazon S3 server access logs

References

CloudFront vs Global Accelerator – CDN vs Anycast

AWS CloudFront vs Global Accelerator

AWS CloudFront vs Global Accelerator

  • Global Accelerator and CloudFront both use the AWS global network and its edge locations around the world.
  • Both services integrate with AWS Shield for DDoS protection.
  • Both services operate from AWS edge locations (Points of Presence), but with different scale:
    • CloudFront uses 750+ PoPs in 100+ cities across 50+ countries, plus 1,140+ Embedded PoPs in 300+ cities.
    • Global Accelerator uses 130 PoPs in 95 cities across 53 countries.
  • Performance
    • CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery).
    • Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions.
  • Use Cases
    • CloudFront is a good fit for HTTP use cases, including web content delivery, API acceleration, video streaming, and serverless edge compute.
    • Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or VoIP, as well as for HTTP use cases that require static IP addresses or deterministic, fast regional failover.
  • Caching
    • CloudFront supports Edge caching with Regional Edge Caches (RECs) and Origin Shield for optimized cache-hit ratios.
    • Global Accelerator does not support Edge Caching. It routes traffic over the AWS backbone to the optimal regional endpoint.
  • Static IP Addresses
    • CloudFront now supports Anycast Static IPs (launched Nov 2024), providing a dedicated set of static IP addresses for allowlisting, zero-rating, and apex domain support.
    • Global Accelerator provides two static anycast IPv4 addresses (and optionally two IPv6 addresses with dual-stack) per accelerator, serviced by independent network zones for fault tolerance.
  • Protocol Support
    • CloudFront supports HTTP and HTTPS (with TLSv1.3), WebSocket, and gRPC.
    • Global Accelerator supports TCP and UDP at the transport layer, enabling broader protocol coverage including non-HTTP workloads.
  • Failover
    • CloudFront supports origin failover for GET and HEAD requests using origin groups with primary and secondary origins.
    • Global Accelerator provides instant, deterministic failover across AWS Regions based on continuous health monitoring (TCP, HTTP, HTTPS health checks).
  • Edge Compute
    • CloudFront offers edge compute via CloudFront Functions (lightweight, sub-millisecond execution at all edge locations) and Lambda@Edge (general-purpose serverless compute).
    • Global Accelerator does not provide edge compute capabilities.
  • IP Address Management
    • CloudFront supports Bring Your Own IP (BYOIP) through VPC IPAM integration for both IPv4 (/24) and IPv6 (/48) address ranges (launched Nov 2025).
    • Global Accelerator supports BYOIP allowing up to two /24 IPv4 address ranges per accelerator.
  • Security
    • CloudFront integrates with AWS WAF, AWS Shield (Standard and Advanced), and supports field-level encryption, signed URLs/cookies, and Origin Access Control (OAC).
    • Global Accelerator integrates with AWS Shield (Standard and Advanced) for DDoS protection but does not support WAF integration.

Key Feature Differences (Summary Table)

Feature CloudFront Global Accelerator
Type Content Delivery Network (CDN) Network layer traffic accelerator
Caching Yes (Edge + Regional Edge Caches + Origin Shield) No
Protocols HTTP, HTTPS, WebSocket, gRPC TCP, UDP
Static IPs Yes (Anycast Static IPs – Nov 2024) Yes (2 IPv4 + 2 IPv6 with dual-stack)
Edge Compute CloudFront Functions + Lambda@Edge No
WAF Integration Yes No
VPC Origins Yes (private ALB/NLB/EC2) No
Custom Routing No Yes (deterministic EC2 routing)
Health Checks Origin failover (GET/HEAD only) TCP, HTTP, HTTPS (instant regional failover)
Dual-Stack (IPv6) Yes Yes (dual-stack accelerators with NLB endpoints)
BYOIP Yes (via VPC IPAM, IPv4 + IPv6) Yes (up to two /24 IPv4 ranges)
Kubernetes Integration No native integration Yes (AWS Load Balancer Controller CRDs)

Recent Feature Updates (2024-2026)

CloudFront Updates

  • Anycast Static IPs (Nov 2024) – Dedicated static IP addresses for allowlisting, zero-rating traffic with ISPs, and apex domain support. IPv6 support added Nov 2025.
  • VPC Origins (Nov 2024) – Connect CloudFront directly to private ALBs, NLBs, or EC2 instances in private subnets without public internet exposure. Cross-account support added Nov 2025.
  • Embedded Points of Presence (Feb 2024) – PoPs deployed directly within ISP networks for large-scale video streaming and game downloads, with 1,140+ Embedded PoPs in 300+ cities.
  • Flat-Rate Pricing Plans (Nov 2025) – Bundled CDN, WAF, DDoS protection, bot management, Route 53, CloudWatch Logs, edge compute, and S3 storage into predictable monthly pricing with no overage charges.
  • Tag-Based Cache Invalidation (May 2026) – Native support to tag cached objects and invalidate by tag directly through the CloudFront API.
  • BYOIP via VPC IPAM (Nov 2025) – Bring your own IPv4 and IPv6 addresses to CloudFront using IPAM’s BYOIP for global services.
  • CloudFront KeyValueStore (Nov 2023) – Low-latency global data store for CloudFront Functions enabling dynamic edge decisions without code redeployment.
  • Simplified Console Experience (Jun 2025) – New user-friendly interface with automated certificate provisioning and DNS configuration.

Global Accelerator Updates

  • Kubernetes Integration (Jan 2026) – AWS Load Balancer Controller now supports Global Accelerator through declarative Kubernetes CRDs for managing accelerators, listeners, and endpoint groups.
  • Expanded Region Support – Now supports 33 AWS Regions including Mexico (Central), Asia Pacific (Malaysia, Thailand, Taipei) as of Oct 2025.
  • Dual-Stack NLB Endpoints (Nov 2023) – IPv6 traffic routing directly to dual-stack NLB endpoints for end-to-end IPv6 connectivity.
  • Client IP Preservation for NLB (Aug 2023) – Maintains source IP address for packets arriving at NLB endpoints configured behind Global Accelerator.
  • Dual-Stack NLB Support for Standard Accelerators (Mar 2024) – Adding dual-stack NLBs to standard accelerators.

When to Use Which

  • Choose CloudFront when:
    • Delivering cacheable web content (images, videos, static files)
    • Accelerating APIs and dynamic HTTP/HTTPS content
    • Needing edge compute (CloudFront Functions or Lambda@Edge)
    • Requiring WAF integration for application-layer security
    • Serving content from private origins via VPC Origins
    • Needing bundled security (WAF + Shield + CDN) with flat-rate pricing
  • Choose Global Accelerator when:
    • Running non-HTTP workloads (gaming/UDP, IoT/MQTT, VoIP)
    • Needing deterministic, instant multi-region failover
    • Requiring static IP addresses as fixed entry points (since its inception)
    • Using custom routing to deterministically route users to specific EC2 instances (e.g., multiplayer gaming matchmaking)
    • Needing Kubernetes-native management of global traffic acceleration
    • Running multi-region S3 workloads via S3 Multi-Region Access Points
  • Use both together when:
    • Needing CDN caching for web content AND fast failover for backend APIs
    • Building multi-tier applications with both HTTP and non-HTTP components

AWS CloudFront vs Global Accelerator

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 company wants to improve the availability and performance of its stateless UDP-based workload. The workload is deployed on Amazon EC2 instances in multiple AWS Regions. What should a solutions architect recommend to accomplish this?
    1. Place the EC2 instances behind Network Load Balancers (NLBs) in each Region. Create an accelerator using AWS Global Accelerator. Use the NLBs as endpoints for the accelerator.
    2. Place the EC2 instances behind Application Load Balancers (ALBs) in each Region. Create an accelerator using AWS Global Accelerator. Use the ALBs as endpoints for the accelerator.
    3. Place the EC2 instances behind Network Load Balancers (NLBs) in each Region. Create a CloudFront distribution with an origin that uses Route 53 latency-based routing to route requests to the NLBs.
    4. Place the EC2 instances behind Application Load Balancers (ALBs) in each Region. Create a CloudFront distribution with an origin that uses Route 53 latency-based routing to route requests to the ALBs.
  2. A media company delivers live streaming video to millions of global viewers. They need to reduce buffering during peak events while keeping origin infrastructure costs low. Which AWS service is the best fit?
    1. AWS Global Accelerator with NLB endpoints in each Region
    2. Amazon CloudFront with Origin Shield enabled and Embedded Points of Presence for large-scale delivery
    3. Amazon CloudFront with Global Accelerator as the origin
    4. AWS Global Accelerator with custom routing to direct viewers to specific EC2 instances
  3. A gaming company wants to route players to specific EC2 game server instances based on matchmaking logic. The application uses UDP and players are distributed globally. Which solution provides the lowest latency and deterministic routing?
    1. Amazon CloudFront with Lambda@Edge for routing logic
    2. AWS Global Accelerator with standard routing and NLB endpoints
    3. AWS Global Accelerator with custom routing accelerator mapping ports to specific EC2 instances
    4. Amazon Route 53 latency-based routing with health checks
  4. A company requires its web application origin servers to remain in private subnets with no public internet access, while still serving global users with low latency. Which solution meets these requirements?
    1. AWS Global Accelerator with private NLB endpoints
    2. Amazon CloudFront with VPC Origins pointing to private ALB/NLB/EC2 instances
    3. Amazon CloudFront with an origin in a public subnet protected by Security Groups
    4. AWS Global Accelerator with EC2 instances using Elastic IP addresses
  5. A company needs static IP addresses for their content delivery to satisfy partner allowlisting requirements. Previously this was only available with Global Accelerator. Which CloudFront feature now addresses this requirement?
    1. CloudFront Origin Access Control (OAC)
    2. CloudFront Anycast Static IPs
    3. CloudFront Dedicated IP Custom SSL
    4. CloudFront BYOIP via VPC IPAM
  6. A company running a multi-region application on Kubernetes (EKS) wants to add global traffic acceleration with automatic failover. They prefer managing infrastructure declaratively through Kubernetes resources. Which approach is most operationally efficient?
    1. Create Global Accelerator manually via AWS Console and add EKS NLB endpoints
    2. Use the AWS Load Balancer Controller with Global Accelerator CRDs to declaratively manage accelerators through Kubernetes
    3. Use Amazon CloudFront with Route 53 failover routing
    4. Use Amazon Route 53 with latency-based routing and health checks

References

AWS Gateway Load Balancer – GWLB for Appliances

AWS Gateway Load Balancer GWLB

AWS Gateway Load Balancer – GWLB

  • Gateway Load Balancer helps deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems (IDS/IPS), and deep packet inspection systems.
  • GWLB and its registered virtual appliance instances exchange application traffic using the GENEVE (Generic Network Virtualization Encapsulation) protocol on port 6081.
  • operates at Layer 3 of the OSI model, the network layer.
  • transparently passes all Layer 3 traffic through third-party virtual appliances, and is invisible to the source and destination of the traffic.
  • combines a transparent network gateway (that is, a single entry and exit point for all traffic) and distributes traffic while scaling the virtual appliances with the demand.
  • listens for all IP packets across all ports and forwards traffic to the target group that’s specified in the listener rule.
  • runs within one AZ and is recommended to be deployed in multiple AZs for greater availability. If all appliances fail in one AZ, scripts can be used to either add new appliances or direct traffic to a GWLB in a different AZ.
  • subnets cannot be removed after the load balancer is created. To remove a subnet, you must create a new load balancer.
  • is architected to handle millions of requests/second, volatile traffic patterns, and introduces extremely low latency.
  • does not perform TLS termination and does not maintain any application state. These functions are performed by the third-party virtual appliances it directs traffic to and receives traffic from.
  • maintains stickiness of flows to a specific target appliance using 5-tuple (default), 3-tuple, or 2-tuple.
    • 5-tuple (default) – source IP, destination IP, protocol, source port, destination port
    • 3-tuple – source IP, destination IP, transport protocol
    • 2-tuple – source IP, destination IP
  • supports a maximum transmission unit (MTU) size of 8500 bytes. GENEVE encapsulation adds 68 bytes, so appliances must support at least 8,568 bytes MTU.
  • does not support IP fragmentation and does not generate ICMP “Destination Unreachable: fragmentation needed and DF set” messages, so Path MTU Discovery (PMTUD) is not supported.
  • supports cross-zone load balancing, which is disabled by default. You pay charges for inter-AZ data transfer if enabled.
  • supports both IPv4 and dual-stack (IPv4 and IPv6) IP address types. In dual-stack mode, GWLB encapsulates both IPv4 and IPv6 client traffic with an IPv4 GENEVE header.
  • supports asymmetric flows when the load balancer processes the initial flow packet and the response flow packet is not routed through the load balancer. Asymmetric routing is not recommended as it can reduce network performance.

Gateway Load Balancer TCP Idle Timeout

  • GWLB creates a flow entry in its flow table when it sees the first packet of a flow and maintains traffic symmetry by coupling each flow entry to one backend target appliance.
  • When packets for a flow stop, the flow is considered idle and the idle timer starts. GWLB removes the flow entry after the idle time expires.
  • TCP idle timeout is configurable from 60 seconds to 6000 seconds (default: 350 seconds). (Launched September 2024)
  • Configuring the timeout helps align GWLB with firewall appliances (e.g., Palo Alto, Fortinet, Cisco, Check Point) that often default to 3600 seconds, preventing traffic disruptions for long-lived idle flows.
  • TCP idle timeout can only be updated when using 5-tuple stickiness. When using 3-tuple or 2-tuple stickiness, the default 350-second timeout is used.
  • UDP idle timeout is fixed at 120 seconds and cannot be changed.
  • TCP keepalive packets reset the idle timeout timer.
  • Existing flows are not impacted when the timeout value is changed; the new value applies only to new flow entries.
  • CloudWatch metrics RejectedFlowCount and RejectedFlowCount_TCP help monitor when flows are rejected due to flow table exhaustion.

Gateway Load Balancer Target Failover

  • Target Failover allows GWLB to rebalance existing flows to a healthy target when the original target fails or is deregistered. (Launched October 2022)
  • By default, GWLB continues to send existing flows to failed or drained targets (no failover).
  • When enabled, reduces failover time when a target becomes unhealthy and allows graceful patching or upgrading of appliances during maintenance windows.
  • Can be configured per target group via the target group attributes.

Gateway Load Balancer Health Checks

  • GWLB supports configurable health check parameters for target groups. (Enhanced February 2023)
  • HealthCheckIntervalSeconds – configurable from 5 to 300 seconds (default: 10 seconds).
  • UnhealthyThresholdCount – defaults to 2, meaning GWLB takes a target out of the target group after 2 missed health checks, reducing target failure detection time.
  • Supports configuring HTTP response codes that determine target health.
  • Supports HTTP, HTTPS, and TCP health check protocols.

Gateway Load Balancer Endpoint – GWLBE

  • GWLB uses Gateway Load Balancer endpoints – GWLBE to exchange traffic across VPC boundaries securely.
  • A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity between virtual appliances in the service provider VPC and application servers in the service consumer VPC.
  • One GWLB can be connected to many GWLBEs.
  • GWLB is deployed in the same VPC as the virtual appliances.
  • Virtual appliances are registered with a target group for the GWLB.
  • Traffic to and from a GWLBE is configured using route tables.
  • Traffic flows from the service consumer VPC over the GWLBE to the GWLB in the service provider VPC, and then returns to the service consumer VPC.
  • GWLBE and the application servers must be created in different subnets. This enables you to configure the GWLBE as the next hop in the route table for the application subnet.
  • GWLBE supports both IPv4 and IPv6 traffic end-to-end. (Launched December 2022)
  • GWLBE can be specified as the next-hop in the Virtual Private Gateway (VGW) route table, enabling inspection of traffic entering a VPC from on-premises via VPN or Direct Connect without Transit Gateway overhead. (Launched August 2023)
  • GWLBE can be used as a VPC Traffic Mirroring target, enabling centralized traffic monitoring appliances deployed behind GWLB. (Launched May 2022)

Gateway Load Balancer Flow

AWS Gateway Load Balancer GWLB

Traffic from the internet to the application (blue arrows)

  • Traffic enters the service consumer VPC through the internet gateway.
  • Traffic is sent to the GWLBE, as a result of VPC ingress routing.
  • Traffic is sent to the GWLB for inspection through the security appliance.
  • Traffic is sent back to the GWLBE after inspection.
  • Traffic is sent to the application servers (destination subnet).

Traffic from the application to the internet (orange arrows):

  • Traffic is sent to the Gateway Load Balancer endpoint due to the default route configured on the application server subnet.
  • Traffic is sent to the GWLB for inspection through the security appliance.
  • Traffic is sent back to the GWLBE after inspection.
  • Traffic is sent to the internet gateway based on the route table configuration.
  • Traffic is routed back to the internet.

Gateway Load Balancer High Availability

AWS Gateway Load Balancer HA

Gateway Load Balancer LCU Reservations

  • Load Balancer Capacity Unit (LCU) Reservation allows proactively setting a minimum bandwidth capacity for the GWLB, complementing its existing ability to auto-scale based on traffic patterns. (Launched April 2025)
  • Useful for preparing for sharp traffic increases due to planned events such as traffic migrations or product launches.
  • Capacity is reserved at the regional level and is evenly distributed across availability zones.
  • Ensure enough evenly distributed targets in each AZ before enabling LCU reservation.
  • CloudWatch metrics PeakBytesPerSecond and ReservedLCUs can be used to monitor utilization.

Gateway Load Balancer Deployment Architectures

  • Distributed model – GWLB and GWLBE in same VPC as applications; inspection happens locally per VPC.
  • Centralized model with Transit Gateway – GWLB deployed in a shared security VPC; spoke VPCs route traffic through Transit Gateway to the inspection VPC. Requires Transit Gateway appliance mode to ensure flow symmetry.
  • Centralized model with AWS Cloud WAN Service Insertion – AWS Cloud WAN service insertion (launched June 2024) simplifies integrating GWLB-backed security appliances into global networks without static routes, supporting both same-segment and cross-segment traffic inspection.
  • VGW Ingress Routing model – Direct steering of on-premises ingress traffic (via VPN/Direct Connect) through GWLBE for inspection without requiring Transit Gateway.

Amazon VPC Route Server Integration

  • Amazon VPC Route Server (GA April 2025) enables dynamic routing within VPC using BGP, providing an alternative to static route table management for appliance-based architectures.
  • Virtual appliances (firewalls) behind GWLB can peer with VPC Route Server via BGP, enabling dynamic route propagation and automatic active/standby failover using AS-path prepending.
  • Reduces manual route management overhead and enables faster failover compared to static routing approaches.

AWS Gateway Load Balancer vs Network Firewall

AWS Network Firewall vs Gateway Load Balancer

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 company uses third-party firewall appliances for traffic inspection across multiple VPCs. The firewalls are deployed in a centralized security VPC. The company needs to automatically scale the firewall fleet based on traffic demand while maintaining flow symmetry to the same appliance. Which AWS service should the company use?
    1. AWS Network Firewall
    2. Network Load Balancer with UDP listener
    3. AWS Gateway Load Balancer
    4. Application Load Balancer with IP targets

    Answer: 3. GWLB is designed specifically to deploy, scale, and manage third-party virtual appliances while maintaining flow stickiness.

  2. A security team has deployed firewall appliances behind a Gateway Load Balancer. The firewalls have a TCP idle timeout of 3600 seconds. Users report intermittent connectivity issues for long-running database connections that go idle. What should the team do to resolve this issue?
    1. Enable cross-zone load balancing on the GWLB
    2. Configure the GWLB TCP idle timeout to a value higher than the firewall’s timeout (e.g., 3700 seconds)
    3. Switch from 5-tuple to 2-tuple flow stickiness
    4. Enable Target Failover on the GWLB target group

    Answer: 2. The configurable TCP idle timeout (60-6000 seconds) allows alignment with the firewall’s timeout to prevent flows from being rerouted to different targets.

  3. A company wants to inspect traffic entering their VPC from on-premises networks via AWS Direct Connect. They want to use third-party firewall appliances behind a Gateway Load Balancer without using Transit Gateway. What feature enables this?
    1. VPC Peering with GWLBE as route target
    2. Virtual Private Gateway ingress routing to GWLBE
    3. AWS PrivateLink with GWLBE
    4. VPC Flow Logs with GWLB integration

    Answer: 2. VGW ingress routing support (August 2023) allows specifying GWLBE as the next-hop in the VGW route table.

  4. An organization needs to perform maintenance on firewall appliances registered as Gateway Load Balancer targets. They want existing connections to be gracefully moved to healthy targets when an appliance is deregistered. Which feature should they enable?
    1. Connection Draining
    2. Target Failover
    3. Cross-zone load balancing
    4. Deregistration Delay

    Answer: 2. Target Failover allows GWLB to rebalance existing flows to healthy targets when the original target fails or is deregistered.

  5. A company wants to centralize network traffic monitoring using third-party tools deployed behind a Gateway Load Balancer. They need to mirror traffic from EC2 instances in spoke VPCs to the monitoring appliances. What is the recommended approach?
    1. Configure VPC Flow Logs to the GWLB target group
    2. Use VPC Traffic Mirroring with GWLBE as the mirror target
    3. Enable packet capture on the GWLB listener
    4. Configure Transit Gateway flow logs to the monitoring VPC

    Answer: 2. GWLBE can be used as a VPC Traffic Mirroring target, enabling centralized traffic monitoring behind GWLB.

  6. A company expects a significant traffic spike next week due to a planned migration event. They want to ensure their Gateway Load Balancer can handle the increased load immediately without waiting for auto-scaling. What should they do?
    1. Increase the number of registered targets
    2. Enable cross-zone load balancing
    3. Configure LCU Reservations on the GWLB
    4. Create additional GWLB endpoints in more AZs

    Answer: 3. LCU Reservations (April 2025) allow proactively setting a minimum bandwidth capacity for the GWLB to prepare for planned traffic increases.

  7. Which of the following are valid flow stickiness options for AWS Gateway Load Balancer? (Select TWO)
    1. 5-tuple (source IP, destination IP, protocol, source port, destination port)
    2. 4-tuple (source IP, destination IP, source port, destination port)
    3. 2-tuple (source IP, destination IP)
    4. 1-tuple (source IP only)
    5. 6-tuple (includes VLAN ID)

    Answer: 1, 3. GWLB supports 5-tuple (default), 3-tuple, and 2-tuple flow stickiness.

References

AWS Shield

AWS Shield

  • AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS.
  • AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency.
  • AWS Shield now provides two key capabilities: AWS Shield network security director (preview) for proactive network posture analysis and AWS Shield Advanced for managed DDoS protection.
  • AWS Shield detects the following classes of attacks:
    • Network Volumetric Attacks (Layer 3)
      • This is a sub category of infrastructure layer attack vectors.
      • These vectors attempt to saturate the capacity of the targeted network or resource, to deny service to legitimate users.
    • Network Protocol Attacks (Layer 4)
      • This is a sub category of infrastructure layer attack vectors.
      • These vectors abuse a protocol to deny service to the targeted resource.
      • A common example of a network protocol attack is a TCP SYN flood, which can exhaust connection state on resources like servers, load balancers, or firewalls.
      • A network protocol attack can also be volumetric for e.g., a larger TCP SYN flood may intend to saturate the capacity of a network while also exhausting the state of the targeted resource or intermediate resources.
    • Application Layer Attacks (Layer 7)
      • This category of attack vector attempts to deny service to legitimate users by flooding an application with queries that are valid for the target, such as web request floods.

AWS Shield Tiers

AWS Shield Standard

  • provides automatic protections to all customers at no additional charge.
  • defends against the most common, frequently occurring network and transport layer DDoS attacks that target websites or applications.
  • with CloudFront and Route 53, comprehensive availability protection against all known infrastructure (Layer 3 and 4) attacks is provided.
  • uses techniques such as deterministic packet filtering and priority-based traffic shaping to automatically mitigate basic network layer attacks.
  • provides always-on network flow monitoring, which inspects incoming traffic to AWS services and applies a combination of traffic signatures, anomaly algorithms, and other analysis techniques to detect malicious traffic in real time.
  • sets static thresholds for each AWS resource type but does not provide customized protection for individual applications.

AWS Shield Advanced

  • is a managed service that helps protect the application against external threats, like DDoS attacks, volumetric bots, and vulnerability exploitation attempts.
  • provides additional detection and mitigation against large and sophisticated DDoS attacks, near real-time visibility into attacks.
  • protects resources including Amazon CloudFront distributions, Amazon Route 53 hosted zones, AWS Global Accelerator standard accelerators, Elastic IP addresses, Application Load Balancers, and Classic Load Balancers.
  • EC2 instances and Network Load Balancers can be protected by association with protected Elastic IP addresses.
  • allows up to 1,000 resources per resource type per AWS account.
  • provides integration with AWS WAF at no additional charge. Shield Advanced subscribers receive up to 50 billion AWS WAF requests per calendar month for WAF-protected resources.
  • also gives 24×7 access to the AWS Shield Response Team (SRT) and protection against DDoS related spikes in the EC2, ELB, CloudFront, AWS Global Accelerator and Route 53 charges.
  • provides DDoS cost protection to safeguard against scaling charges resulting from DDoS-related usage spikes on protected resources.
  • in addition to the network and transport layer attacks, it also detects application layer (Layer 7) attacks such as HTTP floods or DNS query floods by baselining traffic on the application and identifying anomalies.
  • is available globally on all CloudFront, Global Accelerator, and Route 53 edge locations.
  • includes centralized protection management using Firewall Manager (included at no extra cost with Shield Advanced subscription), that can automatically
    • configure policies covering multiple accounts and resources
    • audit accounts to find new or unprotected resources, and ensure that Shield Advanced and AWS WAF protections are universally applied.
  • provides complete visibility into DDoS attacks with near real-time notification through CloudWatch and detailed diagnostics on the AWS WAF and AWS Shield console or APIs.

Shield Advanced – Customized Detection

  • provides customized detection based on traffic patterns to protected Elastic IP addresses, ELB, CloudFront, Global Accelerator, and Route 53 resources.
  • uses additional monitoring techniques for individual regions and resources to detect smaller DDoS attacks and alert about them.
  • detects application layer DDoS attacks by baselining incoming traffic and identifying anomalies.

Shield Advanced – Health-Based Detection

  • uses health check data from Route 53 to improve responsiveness, detection accuracy, and mitigation speed.
  • associate a Route 53 health check with a Shield Advanced-protected resource through the console or API.
  • enables Shield Advanced to detect attacks faster using lower traffic thresholds, improving application DDoS resilience and preventing false alerts.
  • resource health status is also available to the SRT to help prioritize remediation of unhealthy applications.
  • can be used with all Shield Advanced-supported resource types.

Shield Advanced – Protection Groups

  • allows you to bundle resources into protection groups, treating multiple resources as a single unit for detection and mitigation.
  • grouping resources improves detection accuracy, reduces false positives, simplifies automatic protection of newly created resources, and accelerates mitigation.
  • for example, if an application has four CloudFront distributions, they can be added to one protection group for unified detection and protection.
  • reporting can be collected at the protection group level for a holistic view of overall application health.

Shield Advanced – Proactive Engagement

  • provides proactive engagement from the SRT after DDoS events are detected.
  • when enabled, if a Route 53 health check shows your protected resource as unhealthy during a DDoS attack, the SRT contacts you directly.
  • can be enabled for network and transport layer events on Elastic IP and Global Accelerator resources, and for application layer attacks on CloudFront distributions and Application Load Balancers.

Anti-DDoS Managed Rule Group (AMR) for AWS WAF

  • Launched in June 2025, the Anti-DDoS Managed Rule Group (AWSManagedRulesAntiDDoSRuleSet) is an AWS Managed Rule for AWS WAF that automatically detects and mitigates application layer (L7) DDoS events within seconds.
  • As of March 26, 2026, the Anti-DDoS AMR is the default solution for protection against HTTP request flood attacks, superseding the legacy Layer 7 Auto Mitigation (L7AM) feature.
  • Existing Shield Advanced customers can continue using the legacy L7AM but are encouraged to adopt the Anti-DDoS AMR for faster detection (seconds vs. minutes).
  • The AMR learns traffic patterns and establishes baselines for each protected resource within minutes of activation.
  • Uses machine learning models to identify traffic anomalies and assigns suspicion scores to requests for use in mitigations.
  • Supports resources behind Amazon CloudFront, Application Load Balancer (ALB), and API Gateway.
  • For Shield Advanced customers, the AMR is included in the subscription. It is also available as a pay-as-you-go alternative for non-Shield Advanced customers.
  • Provides configurable sensitivity settings and URI-path-specific protection.
  • When a DDoS event is detected, the AMR adds labels (event-detected, ddos-request) to requests for custom downstream handling.

DDoS Attack Flow Logs (2026)

  • Announced May 2026, AWS Shield Advanced now provides DDoS attack flow logs for forensic analysis and compliance.
  • Captures critical packet-level details during active attacks, including:
    • Source and destination IP addresses
    • Ports and protocols
    • Packet and byte counts
    • Source country information
  • Log data is automatically published to your chosen destination (Amazon S3, CloudWatch Logs, or Amazon Data Firehose) at 5-minute intervals during active attacks.
  • Enables you to pinpoint attack sources, verify mitigations, and feed existing analysis pipelines.
  • Helps organizations reconstruct attack patterns and verify mitigation effectiveness without additional infrastructure.

AWS Shield Network Security Director (Preview)

  • Announced June 2025, AWS Shield network security director is a new capability that provides proactive network security posture analysis.
  • Discovers resources across AWS accounts, identifies connectivity between resources, and determines which network security services and configurations are in place.
  • Key capabilities:
    • Network Topology Visualization – provides a complete view of your AWS environment with resource connectivity, security configurations, and potential security issues. Resources are grouped by tags and connectivity patterns.
    • Prioritized Findings Dashboard – assigns severity levels (NONE, INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL) based on identified network security issues, considering network context, AWS best practices, and threat intelligence.
    • Remediation Recommendations – provides step-by-step instructions to fix identified misconfigurations in services like AWS WAF, VPC security groups, and VPC network ACLs.
    • Amazon Q Integration – analyze network security issues using natural language through Amazon Q Developer.
  • Supports multi-account analysis (added December 2025).
  • Findings are available in AWS Security Hub (added March 2026).
  • Does not require a Shield Advanced subscription.

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. Which AWS service has inbuilt DDoS protection?
    1. AWS Shield
    2. AWS CloudWatch
    3. AWS EC2
    4. AWS Inspector
  2. A media company has monetized their APIs to external third parties. During the last month, the platform has come under DDoS attacks multiple times leading to scaling of underlying instances and cost incurred. Which AWS service would help provide cost protection against such spikes, if such situations do occur in the future?
    1. AWS Systems Manager
    2. AWS WAF
    3. AWS Shield Advanced
    4. AWS Inspector
  3. A company is hosting an important revenue generating application. On the last few occasions, the application has come under large DDoS attacks. As a result of this, a lot of users were complaining about the slowness of the application. You need to now avoid these situations in the future and now require 24×7 support from AWS if such situations do occur in the future. Which of the following service can help in this regard?
    1. AWS Shield Advanced
    2. AWS Inspector
    3. AWS WAF
    4. AWS Systems Manager
  4. A company wants to automatically detect and mitigate Layer 7 DDoS attacks on their web application within seconds without manual rule configuration. Which solution provides the fastest automated response?
    1. AWS WAF rate-based rules
    2. AWS Shield Standard
    3. AWS WAF Anti-DDoS Managed Rule Group (AMR)
    4. AWS Network Firewall
  5. A security team needs packet-level visibility into DDoS attack traffic targeting their Shield Advanced-protected resources for forensic analysis. Which feature should they enable?
    1. VPC Flow Logs
    2. AWS CloudTrail
    3. Shield Advanced DDoS Attack Flow Logs
    4. AWS WAF logging
  6. An organization wants to proactively identify missing or misconfigured network security services across their AWS accounts and receive remediation guidance. Which AWS Shield capability should they use?
    1. Shield Advanced Protection Groups
    2. AWS Firewall Manager
    3. AWS Shield Network Security Director
    4. AWS Security Hub
  7. A company has multiple CloudFront distributions serving their e-commerce application and wants Shield Advanced to treat them as a single unit for DDoS detection and mitigation. What feature should they use?
    1. AWS WAF rule groups
    2. AWS Firewall Manager policies
    3. Shield Advanced Protection Groups
    4. CloudFront origin groups
  8. A company wants the AWS Shield Response Team (SRT) to automatically contact them when a DDoS event is detected and their application becomes unhealthy. What must they configure? (Choose 2)
    1. Enable Proactive Engagement in Shield Advanced
    2. Associate a Route 53 health check with the protected resource
    3. Configure AWS CloudWatch alarms
    4. Subscribe to AWS Business Support only

References

AWS ACM – Certificate Manager & SSL/TLS

AWS Certificate Manager

AWS Certificate Manager – ACM

  • AWS Certificate Manager (ACM) helps easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services and internal connected resources.
  • ACM removes the time-consuming manual process of purchasing, uploading, and renewing SSL/TLS certificates.
  • ACM can help quickly request a certificate, deploy it on ACM-integrated AWS resources, such as ELB, CloudFront distributions, APIs on API Gateway, and AWS App Runner, and handle certificate renewals.
  • ACM supports importing third-party certificates into the ACM management system.
  • ACM also supports the creation of private certificates for the internal resources and manages the certificate lifecycle centrally via AWS Private Certificate Authority (AWS Private CA), previously known as ACM Private CA.
  • ACM certificates are regional resources.
  • Public ACM certificates are now valid for 198 days (reduced from 395 days in Feb 2026) to comply with the CA/Browser Forum mandate.
  • ACM automatically renews managed certificates before expiry — no customer intervention is required.
  • ACM supports Certificate Transparency (CT) logging for public certificates, which helps detect misissued certificates.

AWS Certificate Manager

ACM Certificate Validity

  • As of February 2026, all new and renewed public ACM certificates have a default validity of 198 days (previously 395 days/13 months).
  • This change complies with the CA/Browser Forum mandate requiring certificates to be no longer than 200 days starting March 15, 2026.
  • Existing certificates with 395-day validity continue to be valid until they renew or expire.
  • ACM continues to auto-renew certificates before expiry — renewal is attempted 45 days before expiration.
  • The CA/Browser Forum has approved further reductions: 47-day certificate lifetimes will phase in by March 2029.
  • Exportable public certificates retain a 395-day validity period.

ACM Domain Validation Methods

  • DNS Validation — ACM uses CNAME records to validate domain ownership. Supports automatic renewal and is recommended for domains hosted in Route 53.
  • Email Validation — ACM sends validation emails to registered domain contacts. Requires manual action for each renewal.
  • HTTP Validation (Apr 2025) — Available for certificates used with CloudFront. Uses HTTP redirects to prove domain ownership and supports automatic renewal similar to DNS validation. Does not support wildcard certificates.

ACM Exportable Public Certificates

  • Launched in June 2025, ACM now supports exportable public SSL/TLS certificates that can be used on any workload — including EC2 instances, containers, on-premises hosts, and non-AWS environments.
  • You can export the certificate along with its private key for deployment anywhere.
  • Exportable public certificates are valid for 395 days.
  • ACM automatically renews exportable certificates 45 days before expiration.
  • Pricing: $15 per fully qualified domain name (FQDN), $149 per wildcard name.
  • Certificates created prior to June 17, 2025 cannot be exported.
  • This eliminates the previous limitation that ACM certificates could only be used with integrated AWS services.

AWS Workload Credentials Provider

  • Launched in June 2026, AWS Workload Credentials Provider is a lightweight client-side tool that automates the deployment of exported ACM certificates.
  • It periodically retrieves certificates and their private keys, writes them to configured paths, and optionally runs a command to reload dependent services (e.g., web servers).
  • Works across both AWS and non-AWS workloads.
  • Also supports local caching of secrets from AWS Secrets Manager.
  • Eliminates the need for manual certificate deployment after ACM renewal.

ACM Integrated Services

  • Elastic Load Balancing (ELB) — Deploy ACM certificates on Application, Network, and Classic Load Balancers.
  • Amazon CloudFront — Deploy ACM certificates on CloudFront distributions. Certificate must be requested/imported in US East (N. Virginia) region.
  • Amazon API Gateway — Use ACM certificates for custom domain names.
  • Amazon Elastic Kubernetes Service (EKS) — Use ACM with AWS Controllers for Kubernetes (ACK) to issue and export TLS certificates to Kubernetes workloads (Dec 2025).
  • Amazon Cognito — Use ACM certificates for custom domains.
  • AWS Elastic Beanstalk — Deploy ACM certificates on Elastic Beanstalk environments.
  • AWS Nitro Enclaves — Public ACM certificates can be installed on EC2 instances connected to Nitro Enclaves.
  • AWS CloudFormation — ACM certificates can be provisioned as CloudFormation template resources.
  • AWS Amplify — When connecting a custom domain, Amplify issues an ACM certificate automatically.
  • Amazon OpenSearch Service — Use ACM certificates with custom domain endpoints.
  • AWS Network Firewall — ACM certificates for TLS inspection (decryption and re-encryption).
  • AWS App Runner — Use ACM certificates for custom domains.

ACM Post-Quantum TLS Support

  • As of April 2025, ACM endpoints support ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) for hybrid post-quantum key agreement.
  • This protects against “harvest now, decrypt later” attacks where encrypted traffic is stored for future decryption by quantum computers.
  • Hybrid post-quantum TLS combines ML-KEM with traditional key exchange methods for defense-in-depth.
  • AWS plans to deploy ML-KEM support to all AWS services with HTTPS endpoints over time.

ACM Certificate Authority Changes

  • Starting August 2024, public certificates issued from ACM terminate at the Starfield Services G2 root (previously cross-signed with Starfield Class 2).
  • This change aligns with AWS’s move to its own certificate authority infrastructure.
  • As of June 11, 2025, ACM no longer issues certificates with the “TLS Web Client Authentication” (clientAuth) Extended Key Usage (EKU) to align with Chrome Root Program requirements.
  • Customers using ACM certificates for mutual TLS (mTLS) client authentication should use AWS Private CA certificates instead.

ACM Limitations

  • Does not provide certificates for anything other than the SSL/TLS protocols.
  • Cannot use certificates for email encryption.
  • Cannot request certificates for Amazon-owned domain names such as those ending in amazonaws.com, cloudfront.net, or elasticbeanstalk.com.
  • Cannot download the private key for a non-exportable ACM certificate (certificates created before June 17, 2025).
  • Cannot directly install non-exportable certificates on EC2 instances (unless connected to Nitro Enclaves or using exportable certificates).
  • ACM certificates are regional resources — you cannot copy a certificate between regions. To use a certificate with ELB for the same FQDN in more than one region, you must request or import a certificate for each region.
  • With CloudFront, you must request or import the certificate in the US East (N. Virginia) region.
  • ACM no longer issues certificates with clientAuth EKU — use AWS Private CA for mTLS client certificates.
  • HTTP validation does not support wildcard certificates.

AWS Private Certificate Authority (AWS Private CA)

  • AWS Private CA (previously ACM Private Certificate Authority) is a managed private CA service for creating and maintaining internal PKI.
  • Enables issuance of private certificates for internal resources without the overhead of managing your own CA.
  • Secured with AWS-managed hardware security modules (HSMs).
  • Supports short-lived certificates, certificate revocation lists (CRLs), and OCSP.
  • Integrated with ACM for certificate lifecycle management.
  • Use AWS Private CA for mTLS client authentication, IoT device certificates, and internal service mesh communication.

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 company hosts an online shopping portal in the AWS Cloud. The portal provides HTTPS security by using a TLS certificate on an ELB. Recently, the portal suffered an outage because the TLS certificate expired. A SysOps administrator must create a solution to automatically renew certificates to avoid this issue in the future. What is the MOST operationally efficient solution that meets these requirements?
    1. Request a public certificate by using AWS Certificate Manager. Associate the certificate from ACM with the ELB. Write a scheduled AWS Lambda function to renew the certificate every 18 months.
    2. Request a public certificate by using AWS Certificate Manager. Associate the certificate from ACM with the ELB. ACM will automatically manage the renewal of the certificate.
    3. Register a certificate with a third-party certificate authority (CA). Import this certificate into AWS Certificate Manager. Associate the certificate from ACM with the ELB. ACM will automatically manage the renewal of the certificate.
    4. Register a certificate with a third-party certificate authority (CA). Configure the ELB to import the certificate directly from the CA. Set the certificate refresh cycle on the ELB to refresh when the certificate is within 3 months of the expiration date.
  2. A company needs to deploy TLS certificates on multiple EC2 instances running web servers that are NOT behind a load balancer. The security team wants to use ACM to manage the certificates centrally. What is the recommended approach?
    1. Import third-party certificates into ACM and manually install them on EC2 instances.
    2. Use ACM certificates with Nitro Enclaves on each EC2 instance.
    3. Request exportable public certificates from ACM and use AWS Workload Credentials Provider to automate deployment.
    4. Install certificates directly from the ACM console onto EC2 instances.
  3. A company is migrating to shorter TLS certificate lifetimes. They currently use ACM-managed certificates with CloudFront and want to ensure zero downtime during certificate renewals. Which domain validation method should they choose? (Select TWO)
    1. DNS validation with CNAME records in Route 53
    2. Email validation with manual approval
    3. HTTP validation for CloudFront distributions
    4. Import certificates manually before expiration
    5. Use AWS Private CA for public-facing websites
  4. A company needs to secure internal microservices communication using mutual TLS (mTLS). They previously used ACM public certificates with the clientAuth EKU. After June 2025, this approach no longer works. What should they use instead?
    1. Import third-party certificates with clientAuth into ACM.
    2. Use AWS Private Certificate Authority (AWS Private CA) to issue private certificates with clientAuth EKU.
    3. Request exportable public certificates from ACM for mTLS.
    4. Use self-signed certificates on each service instance.
  5. A company runs Kubernetes workloads on Amazon EKS and needs to automate TLS certificate provisioning for pod-level encryption. Which ACM feature enables this?
    1. Associate ACM certificates directly with EKS pods using IAM roles.
    2. Use AWS App Mesh for automatic certificate injection.
    3. Use ACM with AWS Controllers for Kubernetes (ACK) to issue and export certificates to Kubernetes Secrets.
    4. Deploy Nitro Enclaves on EKS worker nodes.

References