Route 53

AWS Route 53

How Route 53 Routes Traffic
~ Last updated on : ~ jayendrapatil ~ 21 Comments

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

AWS Route 53 Routing Policy

~ Last updated on : ~ jayendrapatil ~ 7 Comments

AWS Route 53 Routing Policy

AWS Route 53 routing policy determines how AWS would respond to the DNS queries and provides multiple routing policy options.

Simple Routing Policy

  • Simple routing policy is a simple round-robin policy and can be applied when there is a single resource doing the function for the domain e.g. web server that serves content for the website.
  • Simple routing helps configure standard DNS records, with no special Route 53 routing such as weighted or latency.
  • Route 53 responds to the DNS queries based on the values in the resource record set e.g. IP address in an A record.
  • Simple routing does not allow the creation of multiple records with the same name and type, but multiple values can be specified in the same record, such as multiple IP addresses.
  • Route 53 displays all the values to resolve it recursively in random order and the resolver displays the values for the client. The client then chooses a value and resends the query.
  • Simple routing policy does not support health checks, so the record would be returned to the client even if it is unhealthy.
  • With Alias record enabled, only one AWS resource or one record can be specified in the current hosted zone.
  • Simple routing can be used to create records in a private hosted zone.

Weighted Routing Policy

  • Weighted routing policy helps route traffic to different resources in specified proportions (weights) e.g., 75% to one server and 25% to the other during a pilot release
  • Weights can be assigned between any number from 0 to 255 inclusive.
  • Weighted routing policy can be applied when there are multiple resources that perform the same function e.g., webservers serving the same site
  • Weighted resource record sets allow associating multiple resources with a single DNS name.
  • Weighted routing policy use cases include
    • load balancing between regions
    • A/B testing and piloting new versions of software
  • To create a group of weighted resource record sets, two or more resource record sets can be created that has the same combination of DNS name and type, and each resource record set is assigned a unique identifier and a relative weight.
  • When processing a DNS query, Route 53 searches for a resource record set or a group of resource record sets that have the specified name and type.
  • Route 53 selects one from the group. The probability of any one resource record set being selected depends on its weight as a proportion of the total weight for all resource record sets in the group for e.g., suppose www.example.com has three resource record sets with weights of 1 (20%), 1 (20%), and 3 (60%)(sum = 5). On average, Route 53 selects each of the first two resource records sets one-fifth of the time and returns the third resource record set three-fifths of the time.
  • Weighted routing policy supports health checks.
  • Weighted routing can be used to create records in a private hosted zone.

Latency-based Routing (LBR) Policy

  • Latency-based Routing Policy helps respond to the DNS query based on which data center gives the user the lowest network latency.
  • Latency-based routing policy can be used when there are multiple resources performing the same function and Route 53 needs to be configured to respond to the DNS queries with the resources that provide the fastest response with the lowest latency.
  • A latency resource record set can be created for the EC2 resource in each region that hosts the application. When Route 53 receives a query for the corresponding domain, it selects the latency resource record set for the EC2 region that gives the user the lowest latency. Route 53 then responds with the value associated with that resource record set for e.g., you might have web servers for example.com in the EC2 data centers in Ireland and in Tokyo. When a user browses example.com from Singapore, Route 53 will pick up the data center (Tokyo) which has the lowest latency from the user’s location
  • Latency between hosts on the Internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements performed over a period of time, and the measurements reflect these changes for e.g. if the latency from the user in Singapore to Ireland improves, the user can be routed to Ireland
  • Latency-based routing cannot guarantee users from the same geographic will be served from the same location for any compliance reason
  • Latency resource record sets can be created using any record type that Route 53 supports except NS or SOA.
  • Latency-based routing policy supports health checks.
  • Latency-based routing can be used to create records in a private hosted zone.

Failover Routing Policy

  • Failover routing policy allows active-passive failover configuration, in which one resource (primary) takes all traffic when it’s healthy and the other resource (secondary) takes all traffic when the first isn’t healthy.
  • Route 53 health checking agents will monitor each location/endpoint of the application to determine its availability.
  • Failover routing policy is applicable for Public hosted zones only.
  • Failover routing can be used to create records in a private hosted zone.

Geolocation Routing Policy

  • Geolocation routing policy helps respond to DNS queries based on the geographic location of the users i.e. location from which the DNS queries originate.
  • Geolocation routing policy use cases include
    • localization of content and presenting some or all of the website in the user’s language
    • restrict distribution of content to only the locations in which you have distribution rights.
    • balancing load across endpoints in a predictable, easy-to-manage way, so that each user location is consistently routed to the same endpoint.
  • Geolocation routing policy allows geographic locations to be specified by continent, country, or by state (only in the US)
  • Geolocation record sets, if created, for overlapping geographic regions for e.g. continent, and then for the country within the same continent, priority goes to the smallest geographic region, which allows some queries for a continent to be routed to one resource and queries for selected countries on that continent to a different resource
  • Geolocation works by mapping IP addresses to locations, which might not be mapped to an exact geographic location.
  • A default resource record set can be created to handle these queries and also the ones which do not have an explicit record set created.
  • Route 53 returns a “no answer” response for queries from those locations if a default resource record set is not created.
  • Two geolocation resource record sets that specify the same geographic location cannot be created.
  • Route 53 supports the edns-client-subnet extension of EDNS0 (EDNS0 adds several optional extensions to the DNS protocol.) to improve the accuracy of geolocation routing.
  • Geolocation routing can be used to create records in a private hosted zone. For private hosted zones, Route 53 responds to DNS queries based on the AWS Region of the VPC that the query originated from.

Geoproximity Routing Policy

  • Geoproximity routing helps route traffic to the resources based on the geographic location of the users and the resources.
  • Geoproximity routing can be configured with a bias to optionally choose to route more traffic or less to a given resource. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource.
  • A positive bias (1 to 99) increases the size of the geographic region, routing more traffic to the resource. A negative bias (-1 to -99) shrinks the region.
  • Route 53 supports specifying the resource location using the AWS Region, AWS Local Zone group, or latitude and longitude coordinates.
  • Geoproximity routing is now available as a standard routing policy for DNS records in both public and private hosted zones (expanded in January 2024), in addition to being available through Route 53 Traffic Flow.
  • Route 53 Traffic flow supports geoproximity routing for AWS Local Zones (since October 2023), enabling reduced latency for end users connecting to applications in their nearest Local Zone.
  • Geoproximity routing supports health checks.

IP-based Routing Policy

  • IP-based routing (launched June 2022) allows fine-tuning DNS routing based on the source IP address of the DNS query, using user-IP-to-endpoint mappings.
  • IP-based routing gives granular control to optimize performance or reduce network costs by uploading data to Route 53 in the form of client IP to location mappings.
  • IP-based routing use cases include:
    • Routing end users from certain ISPs to specific endpoints to optimize network transit costs or performance.
    • Adding overrides to existing Route 53 routing types, such as geolocation routing, based on knowledge of clients’ physical locations.
  • IP ranges are managed using CIDR collections and CIDR locations:
    • CIDR block – An IP range in CIDR notation, e.g., 192.0.2.0/24 or 2001:DB8::/32
    • CIDR location – A named list of CIDR blocks, e.g., example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22]
    • CIDR collection – A named collection of locations that can be reused across records
  • For IPv4, CIDR blocks between 1 and 24 bits are supported. For IPv6, CIDR blocks between 1 and 48 bits are supported.
  • For DNS queries with a CIDR longer than the one specified in the collection, Route 53 matches it to the shorter CIDR.
  • A default (“*”) location can be used to handle queries that don’t match any specified CIDR block.
  • IP-based routing cannot be used for records in a private hosted zone.
  • IP-based routing supports health checks.

Multivalue Routing Policy

  • Multivalue routing helps return multiple values, e.g. IP addresses for the web servers, in response to DNS queries.
  • Multivalue routing also helps check the health of each resource, so only the values for healthy resources are returned.
  • Route 53 responds to DNS queries with up to eight healthy records and gives different answers to different DNS resolvers.
  • Multivalue answer routing is not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing.
  • To route traffic approximately randomly to multiple resources, such as web servers, one multivalue answer record can be created for each resource and, optionally, associate a Route 53 health check with each record. If a web server becomes unavailable after the resolver caches a response, client software can try another IP address in the response.
  • Multivalue answer routing can be used to create records in a private hosted zone.

Route 53 Traffic Flow

  • Route 53 Traffic Flow helps easily manage traffic globally through a variety of routing types combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures.
  • Traffic Flow provides a visual editor to easily manage how the end-users are routed to the application’s endpoints – whether in a single AWS region or distributed around the globe.
  • Traffic Flow introduced a new enhanced visual editor (March 2025) with a clearer sidebar-based configuration, undo/redo functionality, and a built-in JSON text editor for directly editing traffic policy documents in the browser.
  • Traffic Flow routes traffic based on multiple criteria, such as endpoint health, geographic location, and latency.
  • Traffic Flow’s versioning feature maintains a history of changes to the traffic policies to allow easy rollback to the previous version.
  • Traffic Flow supports geoproximity routing for AWS Local Zones.

Route 53 Routing Policies in Private Hosted Zones

  • Route 53 supports the following routing policies in private hosted zones:
    • Simple routing
    • Failover routing
    • Multivalue answer routing
    • Weighted routing
    • Latency-based routing (supported since March 2022)
    • Geolocation routing (supported since March 2022; routes based on the AWS Region of the VPC the query originates from)
    • Geoproximity routing (supported since January 2024)
  • IP-based routing is not supported in private hosted zones.

Route 53 Complex Routing Policies

Route 53 Complex Routing Policies

  • Route 53 can be used to define more complex and nested routing policies
  • A combination of alias records (such as weighted alias and failover alias) and non-alias records can be used to build a decision tree that gives you greater control over how Route 53 responds to requests.
  • Resources would be created from the bottom of the tree

Route 53 Application Recovery Controller (ARC)

  • Route 53 Application Recovery Controller (ARC) helps prepare for and quickly mitigate impairments for applications on AWS.
  • ARC provides routing controls – simple on/off switches hosted on a highly available cluster – that can be used to control routing of client traffic in and out of application cells (regions or availability zones).
  • Routing controls support failover across any AWS service that has a DNS endpoint.
  • ARC supports:
    • Zonal Shift – Temporarily move traffic away from an impaired Availability Zone
    • Zonal Autoshift – Automatically shift traffic away from AZs with detected impairments
    • Routing Control – Manually control traffic routing across regions with extreme reliability
  • Safety rules can be configured to prevent simultaneous disabling of all routing controls, ensuring at least one region remains active.
  • ARC routing control health checks integrate with Route 53 failover records to enable instant DNS-based failover.

Route 53 Accelerated Recovery

  • Route 53 Accelerated Recovery (launched November 2025) provides a 60-minute recovery time objective (RTO) for regaining the ability to make DNS changes to public hosted zone records if AWS services in US East (N. Virginia) become unavailable.
  • When enabled, Route 53 achieves built-in failover of the control plane to the Oregon Region (us-west-2).
  • DNS resolution for existing records continues to function normally during any disruption; accelerated recovery specifically addresses the ability to make changes to DNS records.
  • Accelerated recovery must be explicitly enabled per public hosted zone.

Route 53 Global Resolver

  • Route 53 Global Resolver (GA March 2026) provides managed anycast DNS resolution for clients outside AWS VPCs, including on-premises data centers, branch offices, and remote locations.
  • Global Resolver uses anycast IP addresses that automatically route DNS queries to the nearest AWS Region for optimal latency and availability.
  • Key capabilities include:
    • Resolution of public internet domains and private domains associated with Route 53 private hosted zones from any location
    • DNS traffic filtering to prevent DNS-based data exfiltration
    • Encrypted queries via DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT)
    • Centralized logging for compliance and security monitoring
    • Multi-region deployment with automatic failover
  • Available across 30+ AWS Regions with support for both IPv4 and IPv6 DNS query traffic.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have deployed a web application targeting a global audience across multiple AWS Regions under the domain name example.com. You decide to use Route 53 Latency-Based Routing to serve web requests to users from the region closest to the user. To provide business continuity in the event of server downtime you configure weighted record sets associated with two web servers in separate Availability Zones per region. During a DR test you notice that when you disable all web servers in one of the regions Route 53 does not automatically direct all users to the other region. What could be happening? (Choose 2 answers)
    1. Latency resource record sets cannot be used in combination with weighted resource record sets.
    2. You did not setup an http health check for one or more of the weighted resource record sets associated with the disabled web servers
    3. The value of the weight associated with the latency alias resource record set in the region with the disabled servers is higher than the weight for the other region.
    4. One of the two working web servers in the other region did not pass its HTTP health check
    5. You did not set “Evaluate Target Health” to “Yes” on the latency alias resource record set associated with example.com in the region where you disabled the servers.
  2. The compliance department within your multi-national organization requires that all data for your customers that reside in the European Union (EU) must not leave the EU and also data for customers that reside in the US must not leave the US without explicit authorization. What must you do to comply with this requirement for a web based profile management application running on EC2?
    1. Run EC2 instances in multiple AWS Availability Zones in single Region and leverage an Elastic Load Balancer with session stickiness to route traffic to the appropriate zone to create their profile (should be in 2 different regions – US and Europe)
    2. Run EC2 instances in multiple Regions and leverage Route 53’s Latency Based Routing capabilities to route traffic to the appropriate region to create their profile (Latency based routing policy would not guarantee the compliance requirement)
    3. Run EC2 instances in multiple Regions and leverage a third party data provider to determine if a user needs to be redirect to the appropriate region to create their profile
    4. Run EC2 instances in multiple AWS Availability Zones in a single Region and leverage a third party data provider to determine if a user needs to be redirect to the appropriate zone to create their profile(should be in 2 different regions – US and Europe)
  3. A US-based company is expanding their web presence into Europe. The company wants to extend their AWS infrastructure from Northern Virginia (us-east-1) into the Dublin (eu-west-1) region. Which of the following options would enable an equivalent experience for users on both continents?
    1. Use a public-facing load balancer per region to load-balance web traffic, and enable HTTP health checks.
    2. Use a public-facing load balancer per region to load-balance web traffic, and enable sticky sessions.
    3. Use Amazon Route 53, and apply a geolocation routing policy to distribute traffic across both regions
    4. Use Amazon Route 53, and apply a weighted routing policy to distribute traffic across both regions.
  4. You have been asked to propose a multi-region deployment of a web-facing application where a controlled portion of your traffic is being processed by an alternate region. Which configuration would achieve that goal?
    1. Route 53 record sets with weighted routing policy
    2. Route 53 record sets with latency based routing policy
    3. Auto Scaling with scheduled scaling actions set
    4. Elastic Load Balancing with health checks enabled
  5. Your company is moving towards tracking web page users with a small tracking image loaded on each page. Currently you are serving this image out of us-east, but are starting to get concerned about the time it takes to load the image for users on the west coast. What are the two best ways to speed up serving this image? Choose 2 answers
    1. Use Route 53’s Latency Based Routing and serve the image out of us-west-2 as well as us-east-1
    2. Serve the image out through CloudFront
    3. Serve the image out of S3 so that it isn’t being served of your web application tier
    4. Use EBS PIOPs to serve the image faster out of your EC2 instances
  6. Your API requires the ability to stay online during AWS regional failures. Your API does not store any state, it only aggregates data from other sources – you do not have a database. What is a simple but effective way to achieve this uptime goal?
    1. Use a CloudFront distribution to serve up your API. Even if the region your API is in goes down, the edge locations CloudFront uses will be fine.
    2. Use an ELB and a cross-zone ELB deployment to create redundancy across datacenters. Even if a region fails, the other AZ will stay online.
    3. Create a Route53 Weighted Round Robin record, and if one region goes down, have that region redirect to the other region.
    4. Create a Route53 Latency Based Routing Record with Failover and point it to two identical deployments of your stateless API in two different regions. Make sure both regions use Auto Scaling Groups behind ELBs. (Refer link)
  7. A company needs to route DNS traffic for their application based on the IP addresses of their clients. They want to optimize costs by routing traffic from a specific ISP to a particular endpoint. Which Route 53 routing policy should they use?
    1. Geolocation routing policy
    2. Latency-based routing policy
    3. IP-based routing policy
    4. Weighted routing policy
  8. A company uses Route 53 to manage DNS for their multi-region application. They want to ensure that during a regional AWS outage, they can still make DNS changes to their public hosted zone within 60 minutes. Which Route 53 feature should they enable?
    1. Route 53 Application Recovery Controller
    2. Route 53 Failover routing policy
    3. Route 53 Accelerated Recovery for public hosted zones
    4. Route 53 Global Resolver
  9. A company wants to route traffic to the geographically nearest resource and also wants to shift more traffic to a newly launched region by expanding its geographic catchment area. Which Route 53 routing policy should they use?
    1. Geolocation routing policy with a default record
    2. Latency-based routing policy
    3. Weighted routing policy with regional endpoints
    4. Geoproximity routing policy with a positive bias for the new region
  10. An organization with branch offices needs secure DNS resolution for both public domains and Route 53 private hosted zones from their on-premises locations. They require encrypted DNS queries and centralized logging. Which Route 53 feature best meets these requirements?
    1. Route 53 Resolver inbound endpoints with VPN
    2. Route 53 Profiles shared via AWS RAM
    3. Route 53 Global Resolver with DoH/DoT
    4. Route 53 Traffic Flow with failover

References

AWS Route 53 Resolver – Hybrid DNS

~ Last updated on : ~ jayendrapatil

AWS Route 53 Resolver – Hybrid DNS

  • Route 53 Resolver (also known as VPC Resolver) provides automatic DNS resolution within the VPC. It can help resolve DNS queries between VPCs and on-premises networks.
  • By default, Resolver answers DNS queries for VPC domain names such as domain names for EC2 instances or ELB load balancers.
  • Route 53 Resolver performs recursive lookups against public name servers for all other domain names.
  • However, on-premises instances cannot resolve Route 53 DNS entries and Route 53 cannot resolve on-premises DNS entries.
  • DNS resolution between VPC and on-premises network can be configured over a Direct Connect or VPN connection.
  • Route 53 Resolver is regional.
  • To use inbound or outbound forwarding, create a Resolver endpoint in the VPC.
  • As part of the definition of an endpoint, specify the IP addresses to forward inbound DNS queries to or the IP addresses that outbound queries originate from. For each IP address specified, Resolver automatically creates a VPC elastic network interface.
  • Resolver endpoints support DNS over UDP (Do53) and DNS-over-HTTPS (DoH) protocols for encrypted DNS queries.
  • Resolver endpoints support Server Name Indication (SNI) validation for DoH connections, enabling verification of the server’s identity.
  • Resolver rules and DNS Firewall rule groups can be shared across accounts using AWS Resource Access Manager (RAM).

Inbound Endpoint – Forward DNS queries from resolvers on your network to AWS

Route 53 Resolver Inbound Endpoint
  • DNS resolvers on the on-premises networks can forward DNS queries to Resolver in a specified VPC.
  • This enables DNS resolvers to easily resolve domain names for AWS resources such as EC2 instances or records in a Route 53 private hosted zone.
  • Inbound endpoints support Do53 and DoH protocols.
  • Inbound endpoints can be used for DNS delegation, allowing subdomain authority to be delegated between on-premises and cloud infrastructure.

Outbound Endpoint – Conditionally forward queries from a VPC to resolvers on your network

Route 53 Resolver Outbound Endpoint
  • Route 53 Resolver can be configured to forward queries that it receives from EC2 instances in the VPCs to DNS resolvers on the on-premises networks.
  • To forward selected queries, Resolver rules can be created that specify the domain names for the DNS queries that you want to forward (such as example.com), and the IP addresses of the DNS resolvers on the on-premises network that you want to forward the queries to.
  • If a query matches multiple rules (example.com, acme.example.com), Resolver chooses the rule with the most specific match (acme.example.com) and forwards the query to the IP addresses that you specified in that rule.
  • Outbound endpoints support Do53 and DoH protocols for encrypting forwarded DNS traffic.

Resolver Rules

  • Resolver rules control which DNS queries are forwarded to on-premises resolvers and which are resolved locally.
  • Forward rules – Forward DNS queries for a specified domain name to the IP addresses of on-premises DNS resolvers.
  • System rules – Selectively override the behavior defined in a forward rule. A system rule causes Resolver to resolve the query locally (within the VPC).
  • Auto-defined system rules – Automatically created rules for AWS-specific domain names and reverse DNS queries.
  • If a “.” (dot) or “com” forward rule is created, it is recommended to also create a system rule for amazonaws.com to ensure AWS service resolution works correctly.
  • Resolver rules can be shared across AWS accounts using AWS RAM, enabling centralized DNS forwarding management.

Resolver Query Logging

  • Resolver query logging allows logging of all DNS queries made by resources within VPCs.
  • Logs can be sent to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose.
  • Query logs include information such as the domain name queried, source IP, response code, and the Route 53 Resolver endpoint or firewall rule that processed the query.
  • Query logging configurations can be shared across AWS accounts.
  • Only unique queries are logged; queries answered from the Resolver cache are not logged.

DNSSEC Validation

  • Route 53 Resolver supports DNSSEC validation, which verifies that DNS responses have not been tampered with in transit.
  • When DNSSEC validation is enabled, Resolver validates the authenticity and integrity of DNS responses from public nameservers for DNSSEC-signed domains.
  • DNSSEC validation provides protection against DNS spoofing and cache poisoning attacks.
  • DNSSEC validation can be enabled per VPC.

Resolver Endpoint Metrics

  • Route 53 Resolver provides detailed CloudWatch metrics for monitoring endpoint health and performance.
  • Capacity Utilization metric – Helps monitor whether the endpoint is approaching query capacity limits. (Launched June 2025)
  • Detailed metrics – Include P90 response latency, SERVFAIL/NXDOMAIN/REFUSED/FORMERR response tracking, and target name server availability for outbound endpoints. (Launched December 2025)
  • Metrics are available at the Resolver Network Interface and Target Name Server levels.

Route 53 Resolver DNS Firewall

  • Route 53 Resolver DNS Firewall lets you control access to sites and block DNS-level threats for DNS queries going out from your VPC through the Route 53 VPC Resolver.
  • DNS Firewall allows you to define domain name filtering rules in rule groups that you associate with your VPCs.
  • You can specify lists of domain names to allow or block, and customize responses for blocked queries (NXDOMAIN, NODATA, or specific DNS responses).
  • DNS Firewall only filters on the domain name; it does not resolve that name to an IP address to be blocked.
  • DNS Firewall filters DNS traffic only; it does not filter other application layer protocols (HTTPS, SSH, TLS, FTP, etc.).
  • DNS Firewall is a feature of Route 53 VPC Resolver and doesn’t require any additional Resolver setup.
  • DNS Firewall rule groups can be shared across accounts using AWS RAM, managed centrally with AWS Firewall Manager, and applied via Route 53 Profiles.

AWS Managed Domain Lists

  • AWS provides managed domain lists for known threats, including malware, botnet command and control, and newly registered domains.
  • Threat categories – malware, phishing, spam, botnets, spyware, command and control.
  • Content categories – adult/mature content, gambling, social media, gaming, and other web content types. (Added May 2026)

DNS Firewall Advanced

  • DNS Firewall Advanced provides intelligent, real-time protection against sophisticated DNS-based threats beyond static domain lists. (Launched November 2024)
  • DNS Tunneling Detection – Identifies and blocks attempts to use DNS as a covert channel for data exfiltration or command-and-control communication.
  • Domain Generation Algorithm (DGA) Detection – Identifies and blocks queries to domains created by DGAs commonly used by malware.
  • Dictionary-based DGA Detection – Detects sophisticated DGA variants that use dictionary words to create more legitimate-looking domains. (Added November 2025)
  • DNS Firewall Advanced works by inspecting DNS payload characteristics including timestamps, request frequency, query strings, and query length/type/size.
  • Palo Alto Networks Advanced DNS Security integration (Preview) – Enables enforcement of third-party threat intelligence categories including fast-flux protection, DNS tunneling, DNS rebinding, and DGA detection directly within DNS Firewall rules. (June 2026)

Route 53 Profiles

  • Route 53 Profiles allow you to define a standard DNS configuration and apply it to multiple VPCs in the same AWS Region. (Launched April 2024)
  • A Profile can include Route 53 private hosted zone (PHZ) associations, Resolver forwarding rules, and DNS Firewall rule groups.
  • When you update a Profile, its settings are propagated to all associated VPCs automatically.
  • Profiles can be shared across AWS accounts using AWS RAM for centralized DNS management.
  • Profiles simplify multi-account DNS management by eliminating the need to manage individual resource associations per VPC.
  • Route 53 Profiles is a regional service.

Route 53 Global Resolver

  • Route 53 Global Resolver is a managed anycast DNS resolver accessible from anywhere over the internet. (Preview November 2025, GA March 2026)
  • Provides DNS resolution for both public internet domains and Route 53 private hosted zones from on-premises, branch offices, and remote clients.
  • Uses globally distributed anycast IP addresses that route queries to the nearest available AWS Region.
  • Supports multiple DNS protocols: DNS over UDP (Do53), DNS-over-HTTPS (DoH), and DNS-over-TLS (DoT).
  • Requires client authentication via token-based authentication (DoH/DoT) or ACL-based IP/CIDR allowlisting (Do53/DoT/DoH).
  • Includes built-in DNS traffic filtering using the same DNS Firewall rule capabilities (managed domain lists, custom lists, and advanced protections).
  • Provides centralized query logging to CloudWatch, S3, or Data Firehose.
  • Supports DNSSEC validation for public domains.
  • Must be deployed in a minimum of two AWS Regions for high availability with automatic failover.
  • Allows adding and removing AWS Regions dynamically for flexible geographic coverage. (May 2026)
  • Available across 30 AWS Regions with IPv4 and IPv6 support.
  • Protected against DDoS threats using AWS Shield.

Global Resolver vs VPC Resolver

  • Global Resolver – Internet-reachable via anycast IPs, designed for on-premises/remote clients, supports Do53/DoH/DoT, requires client authentication.
  • VPC Resolver – Default VPC recursive resolver, accessible by VPC-hosted clients or via VPN/Direct Connect through Resolver endpoints, DNS encryption available only for hybrid queries over endpoints.

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 install a new private intranet service using Amazon EC2 instances inside a Virtual Private Cloud (VPC). The VPC is connected to the company’s on-premises network using an AWS Site-to-Site VPN. The new service must communicate with the on-premises services already in place. On-premises services are accessed using company-owned hostnames. for instance, a DNS zone. This DNS zone is entirely on-premises and accessible only via the company’s private network. To connect the new service with current services, a solutions architect must guarantee that the new service can resolve hostnames on the company’s example domain. Which solution satisfies these criteria?
    1. Create an empty private zone in Route 53 for company.example. Add an additional NS record to the company’s on-premises company.example zone that points to the authoritative name servers for the new private zone in Route 53.
    2. Turn on DNS hostnames for the VPC. Configure a new outbound endpoint with Route 53 Resolver. Create a Resolver rule to forward requests for company.example to the on-premises name servers.
    3. Turn on DNS hostnames for the VPC. Configure a new inbound resolver endpoint with Route 53 Resolver. Configure the on-premises DNS server to forward requests for company.example to the new resolver.
    4. Use AWS Systems Manager to configure a run document that will install a hosts file that contains any required hostnames. Use an Amazon EventBridge rule to run the document when an instance is entering the running state.
  2. A company operates in a hybrid environment with multiple VPCs and on-premises data centers. The security team requires all DNS traffic from VPCs to be inspected for data exfiltration attempts and queries to known malicious domains must be blocked. Which solution provides the most comprehensive protection?
    1. Create Network ACLs to block DNS traffic to known malicious IP addresses.
    2. Configure security groups to restrict DNS traffic to specific DNS resolvers only.
    3. Configure Route 53 Resolver DNS Firewall with AWS managed domain lists for known threats and DNS Firewall Advanced rules for DNS tunneling and DGA detection, then associate the rule groups with all VPCs.
    4. Deploy third-party DNS security appliances in each VPC and route all DNS traffic through them.
  3. A multinational organization needs to provide secure DNS resolution for remote employees and branch offices accessing both public internet domains and internal applications hosted in AWS. The solution must encrypt DNS traffic and support centralized security policies. Which approach is most appropriate?
    1. Deploy Route 53 Resolver inbound endpoints in every AWS Region and configure on-premises DNS forwarders to send queries over VPN tunnels.
    2. Configure Route 53 Global Resolver with token-based authentication for remote clients and DNS Firewall rules to filter queries, using DoH or DoT for encryption.
    3. Set up a fleet of EC2 instances running BIND DNS servers with custom filtering and forward all client traffic through a VPN.
    4. Use Route 53 VPC Resolver with outbound endpoints and share Resolver rules across accounts using RAM.
  4. A company has 50 AWS accounts within an AWS Organization. They want to apply consistent DNS configurations—including private hosted zone associations, Resolver forwarding rules, and DNS Firewall rule groups—to all VPCs across accounts in the same Region. What is the most operationally efficient solution?
    1. Manually associate each private hosted zone, Resolver rule, and DNS Firewall rule group to each VPC individually.
    2. Use AWS RAM to share all DNS resources to each account and write automation scripts to associate them.
    3. Create a Route 53 Profile containing the DNS configuration, share it across accounts using AWS RAM, and associate it with all VPCs.
    4. Deploy CloudFormation StackSets to create identical DNS configurations in each account.
  5. A solutions architect wants to monitor the health and performance of Route 53 Resolver outbound endpoints that forward DNS queries to on-premises servers. They need to detect when target name servers become unavailable and when response latency increases. Which approach provides the required visibility?
    1. Enable VPC Flow Logs and filter for DNS traffic on port 53.
    2. Configure Resolver query logging and parse logs for timeout patterns.
    3. Enable detailed CloudWatch metrics for the Resolver endpoints to monitor P90 response latency, error responses (SERVFAIL, REFUSED), and target name server availability.
    4. Create a Lambda function that periodically sends test DNS queries and measures response times.

References

AWS Route 53 Alias vs CNAME

Route 53 CNAME vs Alias Records
~ Last updated on : ~ jayendrapatil

AWS Route 53 Alias vs CNAME

📅 Last Updated: June 2026 | Added: OpenSearch Service, AWS AppSync, VPC Lattice, App Runner alias targets; clarified record type support for alias-to-alias records.
  • Route 53 Alias records are similar to CNAME records, but there are some important differences.
  • Supported Resources
    • Alias records support selected AWS resources
      • Elastic Load Balancers (Application, Network, and Classic Load Balancers)
      • CloudFront distributions
      • Amazon API Gateway (custom regional and edge-optimized APIs)
      • Elastic Beanstalk environments
      • S3 Website (bucket configured as static website)
      • AWS Global Accelerator
      • VPC Interface Endpoints
      • Amazon OpenSearch Service custom domain endpoints (Added 2024)
      • AWS AppSync domain names
      • AWS App Runner services (Note: App Runner is no longer accepting new customers as of April 30, 2026)
      • Amazon VPC Lattice service domain endpoints (Added June 2025)
      • Route 53 record in the same hosted zone
    • Alias records do not support
      • EC2 DNS endpoint
      • RDS DNS endpoint
      • Non-AWS DNS endpoints
    • CNAME record can redirect DNS queries to any DNS record (AWS or non-AWS)
  • Zone Apex or Root domain like example.com
    • Alias record supports mapping Zone Apex records
    • CNAME record does not support Zone Apex records (per DNS RFC standards)
  • Charges
    • Route 53 doesn’t charge for alias queries to AWS resources
    • Route 53 charges for CNAME queries
    • Note: A CNAME record pointing to another Route 53 record incurs charges for both queries
  • Record Type
    • For AWS resource targets (ELB, CloudFront, S3, etc.), alias records support A (IPv4) or AAAA (IPv6) record types
    • For alias records pointing to another record in the same hosted zone, all record types are supported except NS and SOA
    • CNAME record redirects DNS queries for a record name regardless of the record type specified in the DNS query, such as A or AAAA
  • TTL (Time to Live)
    • When an alias record points to an AWS resource, you cannot set the TTL; Route 53 uses the default TTL for the resource
    • When an alias record points to another record in the same hosted zone, Route 53 uses the TTL of the target record
    • CNAME records allow custom TTL configuration
  • Health Checking
    • Alias records support “Evaluate Target Health” which integrates with the target resource’s health
    • For ELB and Elastic Beanstalk, Evaluate Target Health provides routing away from unhealthy resources
    • For highly available services (S3, API Gateway, Global Accelerator, OpenSearch, VPC Lattice), use Route 53 health checks instead

Route 53 Alias vs CNAME Comparison

Route 53 CNAME vs Alias Records

Key Considerations for Alias Records

  • Automatic IP Resolution – Route 53 automatically recognizes changes in the resource’s IP addresses (e.g., when an ELB’s IP changes)
  • No Extra Hop – Unlike CNAME which requires an additional DNS lookup, alias records resolve directly to IP addresses
  • IPv6 Support – For CloudFront, ELB, and OpenSearch Service, create separate A (IPv4) and AAAA (IPv6) alias records
  • Cross-Account Support – Alias records can point to resources in different AWS accounts (e.g., a CloudFront distribution in another account)

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 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.
  2. 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
  3. A company hosts its website using Amazon S3 static website hosting. They want to use their domain’s zone apex (example.com) to point to the S3 bucket. Which record type should they use?
    1. CNAME record pointing to the S3 website endpoint
    2. Alias record of type A pointing to the S3 website endpoint
    3. A record with the IP address of the S3 bucket
    4. MX record pointing to the S3 bucket
  4. Which of the following AWS resources can be targets for a Route 53 Alias record? (Choose 3)
    1. Application Load Balancer
    2. RDS database instance
    3. CloudFront distribution
    4. EC2 instance public DNS
    5. Amazon OpenSearch Service custom domain
  5. What is the primary advantage of using a Route 53 Alias record instead of a CNAME record when routing traffic to an AWS Elastic Load Balancer?
    1. Alias records support more record types than CNAME
    2. Alias records can point to non-AWS resources
    3. Alias records can be used at the zone apex and don’t incur query charges for AWS resources
    4. Alias records allow custom TTL values

References

AWS Networking & Content Delivery Services Cheat Sheet

AWS Networking & Content Delivery Services
~ Last updated on : ~ jayendrapatil ~ 27 Comments

AWS Networking & Content Delivery Services Cheat Sheet

AWS Networking & Content Delivery Services

Virtual Private Cloud – VPC

  • helps define a logically isolated dedicated virtual network within the AWS
  • provides control of IP addressing using CIDR block from a minimum of /28 to a maximum of /16 block size
  • supports IPv4 and IPv6 addressing
  • cannot be extended once created
  • can be extended by associating secondary IPv4 CIDR blocks to VPC
  • Components
    • Internet gateway (IGW) provides access to the Internet
    • Virtual gateway (VGW) provides access to the on-premises data center through VPN and Direct Connect connections
    • VPC can have only one IGW and VGW
    • Route tables determine network traffic routing from the subnet
    • Ability to create a subnet with VPC CIDR block
    • A Network Address Translation (NAT) server provides outbound Internet access for EC2 instances in private subnets
    • Elastic IP addresses are static, persistent public IP addresses
    • Instances launched in the VPC will have a Private IP address and can have a Public or an Elastic IP address associated with it
    • Security Groups and NACLs help define security
    • Flow logs – Capture information about the IP traffic going to and from network interfaces in your VPC
  • Tenancy option for instances
    • shared, by default, allows instances to be launched on shared tenancy
    • dedicated allows instances to be launched on a dedicated hardware
  • Route Tables
    • defines rules, termed as routes, which determine where network traffic from the subnet would be routed
    • Each VPC has a Main Route table and can have multiple custom route tables created
    • Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
    • Route priority is decided by matching the most specific route in the route table that matches the traffic
  • Subnets
    • map to AZs and do not span across AZs
    • have a CIDR range that is a portion of the whole VPC.
    • CIDR ranges cannot overlap between subnets within the VPC.
    • AWS reserves 5 IP addresses in each subnet – first 4 and last one
    • Each subnet is associated with a route table which define its behavior
      • Public subnets – inbound/outbound Internet connectivity via IGW
      • Private subnets – outbound Internet connectivity via an NAT or VGW
      • Protected subnets – no outbound connectivity and used for regulated workloads
  • Elastic Network Interface (ENI)
    • a default ENI, eth0, is attached to an instance which cannot be detached with one or more secondary detachable ENIs (eth1-ethn)
    • has primary private, one or more secondary private, public, Elastic IP address, security groups, MAC address and source/destination check flag attributes associated
    • AN ENI in one subnet can be attached to an instance in the same or another subnet, in the same AZ and the same VPC
    • Security group membership of an ENI can be changed
    • with pre-allocated Mac Address can be used for applications with special licensing requirements
  • Security Groups vs NACLs – Network Access Control Lists
    • Stateful vs Stateless
    • At instance level vs At subnet level
    • Only allows Allow rule vs Allows both Allow and Deny rules
    • Evaluated as a Whole vs Evaluated in defined Order
  • Elastic IP
    • is a static IP address designed for dynamic cloud computing.
    • is associated with an AWS account, and not a particular instance
    • can be remapped from one instance to another instance
    • is charged for non-usage, if not linked for any instance or instance associated is in a stopped state
  • NAT
    • allows internet access to instances in the private subnets.
    • performs the function of both address translation and port address translation (PAT)
    • needs source/destination check flag to be disabled as it is not the actual destination of the traffic for NAT Instance.
    • NAT gateway is an AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort
    • are not supported for IPv6 traffic
    • NAT Gateway supports private NAT with fixed private IPs.
    • Regional NAT Gateway (announced Nov 2025) automatically expands across Availability Zones based on workload footprint, providing simplified setup, enhanced security, and automatic high availability without manual multi-AZ configuration.
  • Egress-Only Internet Gateways
    • outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances
    • supports IPv6 traffic only
  • Shared VPCs
    • allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs
  • VPC Encryption Controls (announced Nov 2025)
    • allows enforcing encryption in transit for network traffic within the VPC
    • provides centralized encryption policy enforcement and monitoring capabilities
    • supports monitor and enforce modes to audit and enforce encryption compliance
    • transitioned to paid feature starting March 2026

VPC Peering

  • allows routing of traffic between the peer VPCs using private IP addresses with no IGW or VGW required.
  • No single point of failure and bandwidth bottlenecks
  • supports inter-region VPC peering
  • Limitations
    • IP space or CIDR blocks cannot overlap
    • cannot be transitive
    • supports a one-to-one relationship between two VPCs and has to be explicitly peered.
    • does not support edge-to-edge routing.
    • supports only one connection between any two VPCs
  • Private DNS values cannot be resolved
  • Security groups from peered VPC can now be referred to, however, the VPC should be in the same region.

VPC Endpoints

  • enables private connectivity from VPC to supported AWS services and VPC endpoint services powered by PrivateLink
  • does not require a public IP address, access over the Internet, NAT device, a VPN connection, or Direct Connect
  • traffic between VPC & AWS service does not leave the Amazon network
  • are virtual devices.
  • are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and services without imposing availability risks or bandwidth constraints on the network traffic.
  • Gateway Endpoints
    • is a gateway that is a target for a specified route in the route table, used for traffic destined to a supported AWS service.
    • only S3 and DynamoDB are currently supported
  • Interface Endpoints OR Private Links
    • is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service
    • supports services include AWS services, services hosted by other AWS customers and partners in their own VPCs (referred to as endpoint services), and supported AWS Marketplace partner services.
    • Private Links
      • provide fine-grained access control
      • provides a point-to-point integration.
      • supports overlapping CIDR blocks.
      • supports transitive routing
    • Access to VPC Resources over PrivateLink (announced Dec 2024) – allows sharing any VPC resource using AWS RAM and accessing them privately using VPC endpoints, without requiring the resource to sit behind a NLB.

CloudFront

  • provides low latency and high data transfer speeds for the distribution of static, dynamic web, or streaming content to web users.
  • delivers the content through a worldwide network of data centers called Edge Locations or Point of Presence (PoPs)
  • keeps persistent connections with the origin servers so that the files can be fetched from the origin servers as quickly as possible.
  • dramatically reduces the number of network hops that users’ requests must pass through
  • supports multiple origin server options, like AWS hosted service for e.g. S3, EC2, ELB, or an on-premise server, which stores the original, definitive version of the objects
  • single distribution can have multiple origins and Path pattern in a cache behavior determines which requests are routed to the origin
  • Web distribution supports static, dynamic web content, on-demand using progressive download & HLS, and live streaming video content
  • RTMP distributions were deprecated and removed on December 31, 2020. Use Web distributions with HTTP-based streaming protocols (HLS, DASH) instead.
  • supports HTTPS using either
    • dedicated IP address, which is expensive as a dedicated IP address is assigned to each CloudFront edge location
    • Server Name Indication (SNI), which is free but supported by modern browsers only with the domain name available in the request header
  • For E2E HTTPS connection,
    • Viewers -> CloudFront needs either a certificate issued by CA or ACM
    • CloudFront -> Origin needs a certificate issued by ACM for ELB and by CA for other origins
  • Security
    • Origin Access Control (OAC) is the recommended method to restrict content from S3 origin to be accessible from CloudFront only. OAC supports SSE-KMS, all HTTP methods, and all AWS Regions.
      • Origin Access Identity (OAI) is the legacy method. OAI creation was deprecated in 2024 and new distributions (as of March 2026) can only use OAC. Existing OAI configurations continue to work but migration to OAC is recommended.
    • supports Geo restriction (Geo-Blocking) to whitelist or blacklist countries that can access the content
    • Signed URLs
      • to restrict access to individual files, for e.g., an installation download for your application.
      • users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
    • Signed Cookies
      • provide access to multiple restricted files, for e.g., video part files in HLS format or all of the files in the subscribers’ area of a website.
      • don’t want to change the current URLs
    • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configured based on IP addresses, HTTP headers, and custom URI strings
  • supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get object & object headers, add, update, and delete objects
    • only caches responses to GET and HEAD requests and, optionally, OPTIONS requests
    • does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are proxied back to the origin
  • object removal from the cache
    • would be removed upon expiry (TTL) from the cache, by default 24 hrs
    • can be invalidated explicitly, but has a cost associated, however, might continue to see the old version until it expires from those caches
    • objects can be invalidated only for Web distribution
    • use versioning or change object name, to serve a different version
    • Tag-based cache invalidation (announced May 2026) – allows tagging cached objects via origin response headers or S3 metadata and invalidating them by tag directly through the CloudFront API.
  • supports adding or modifying custom headers before the request is sent to origin which can be used to
    • validate if a user is accessing the content from CDN
    • identifying CDN from which the request was forwarded, in case of multiple CloudFront distributions
    • for viewers not supporting CORS to return the Access-Control-Allow-Origin header for every request
  • supports Partial GET requests using range header to download objects in smaller units improving the efficiency of partial downloads and recovery from partially failed transfers
  • supports compression to compress and serve compressed files when viewer requests include Accept-Encoding: gzip in the request header
  • supports different price classes to include all regions, or only the least expensive regions and other regions without the most expensive regions
  • supports access logs which contain detailed information about every user request for both web distribution
  • Edge Compute
    • CloudFront Functions – lightweight JavaScript functions for simple request/response transformations (URL rewrites, header manipulation, redirects) executed at viewer request/response events with sub-millisecond latency
    • Lambda@Edge – more powerful compute for complex processing at origin request/response and viewer request/response events
    • CloudFront KeyValueStore (launched 2023) – a globally distributed, low-latency data store that CloudFront Functions can read at runtime for dynamic routing, A/B testing, feature flags, and geo-routing without redeploying function code
  • CloudFront Flat-Rate Pricing Plans – combine CDN, AWS WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch Logs ingestion, serverless edge compute, and S3 storage credits into a single monthly price

AWS VPN

  • AWS Site-to-Site VPN provides secure IPSec connections from on-premise computers or services to AWS over the Internet
  • is cheap, and quick to set up however it depends on the Internet speed
  • delivers high availability by using two tunnels across multiple Availability Zones within the AWS global network
  • VPN requires a Virtual Gateway – VGW and Customer Gateway – CGW for communication
  • VPN connection is terminated on VGW on AWS
  • Only one VGW can be attached to a VPC at a time
  • VGW supports both static and dynamic routing using Border Gateway Protocol (BGP)
  • VGW supports AWS-256 and SHA-2 for data encryption and integrity
  • AWS Client VPN is a managed client-based VPN service that enables secure access to AWS resources and resources in the on-premises network.
  • AWS VPN does not allow accessing the Internet through IGW or NAT Gateway, peered VPC resources, or VPC Gateway Endpoints from on-premises.
  • AWS VPN allows access accessing the Internet through NAT Instance and VPC Interface Endpoints from on-premises.

Direct Connect

  • is a network service that uses a private dedicated network connection to connect to AWS services.
  • helps reduce costs (long term), increases bandwidth, and provides a more consistent network experience than internet-based connections.
  • supports Dedicated and Hosted connections
    • Dedicated connection is made through a 1 Gbps, 10 Gbps, or 100 Gbps Ethernet port dedicated to a single customer.
    • Hosted connections are sourced from an AWS Direct Connect Partner that has a network link between themselves and AWS.
  • provides Virtual Interfaces
    • Private VIF to access instances within a VPC via VGW
    • Public VIF to access non VPC services
    • Transit VIF to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways, enabling connectivity to multiple VPCs through a single VIF
  • requires time to setup probably months, and should not be considered as an option if the turnaround time is less
  • does not provide redundancy, use either second direct connection or IPSec VPN connection
  • Virtual Private Gateway is on the AWS side and Customer Gateway is on the Customer side
  • route propagation is enabled on VGW and not on CGW
  • A link aggregation group (LAG) is a logical interface that uses the link aggregation control protocol (LACP) to aggregate multiple dedicated connections at a single AWS Direct Connect endpoint and treat them as a single, managed connection
  • VIF Rate Limiters (announced June 2026) on dedicated connections help prevent network congestion caused by unexpected traffic spikes on a VIF that could consume all available bandwidth impacting other VIFs on the same connection.
  • Direct Connect vs VPN IPSec
    • Expensive to Setup and Takes time vs Cheap & Immediate
    • Dedicated private connections vs Internet
    • Reduced data transfer rate vs Internet data transfer cost
    • Consistent performance vs Internet inherent variability
    • Do not provide Redundancy vs Provides Redundancy

Route 53

  • provides highly available and scalable DNS, Domain Registration Service, and health-checking web services
  • Reliable and cost-effective way to route end users to Internet applications
  • Supports multi-region and backup architectures for High availability. ELB is limited to region and does not support multi-region HA architecture.
  • supports private Intranet facing DNS service
  • internal resource record sets only work for requests originating from within the VPC and currently cannot extend to on-premise
  • Global propagation of any changes made to the DN records within ~ 1min
  • supports Alias resource record set is a Route 53 extension to DNS.
    • It’s similar to a CNAME resource record set, but supports both for root domain – zone apex e.g. example.com, and for subdomains for e.g. www.example.com.
    • supports ELB load balancers, CloudFront distributions, Elastic Beanstalk environments, API Gateways, VPC interface endpoints, and S3 buckets that are configured as websites.
  • CNAME resource record sets can be created only for subdomains and cannot be mapped to the zone apex record
  • supports Private DNS to provide an authoritative DNS within the VPCs without exposing the DNS records (including the name of the resource and its IP address(es) to the Internet.
  • Split-view (Split-horizon) DNS enables mapping the same domain publicly and privately. Requests are routed as per the origin.
  • Routing policy
    • Simple routing – simple round-robin policy
    • Weighted routing – assign weights to resource records sets to specify the proportion for e.g. 80%:20%
    • Latency based routing – helps improve global applications as requests are sent to the server from the location with minimal latency, is based on the latency and cannot guarantee users from the same geography will be served from the same location for any compliance reasons
    • Geolocation routing – Specify geographic locations by continent, country, the state limited to the US, is based on IP accuracy
    • Geoproximity routing policy – Use to route traffic based on the location of the resources and, optionally, shift traffic from resources in one location to resources in another.
    • Multivalue answer routing policy – Use to respond to DNS queries with up to eight healthy records selected at random.
    • Failover routing – failover to a backup site if the primary site fails and becomes unreachable
    • IP-based routing – route traffic based on the IP address of the client making the DNS query
  • Weighted, Latency and Geolocation can be used for Active-Active while Failover routing can be used for Active-Passive multi-region architecture
  • Traffic Flow is an easy-to-use and cost-effective global traffic management service. Traffic Flow supports versioning and helps create policies that route traffic based on the constraints they care most about, including latency, endpoint health, load, geoproximity, and geography.
  • Route 53 Resolver is a regional DNS service that helps with hybrid DNS
    • Inbound Endpoints are used to resolve DNS queries from an on-premises network to AWS
    • Outbound Endpoints are used to resolve DNS queries from AWS to an on-premises network
    • Resolver endpoints now support DNS delegation for private hosted zones (June 2025)
  • Route 53 Profiles – enables sharing DNS configurations (private hosted zone associations, Resolver rules, and Resolver DNS Firewall rule group associations) across VPCs and accounts using AWS RAM
  • Accelerated Recovery (announced Nov 2025) – provides a 60-minute recovery time objective (RTO) for regaining the ability to make DNS changes to public hosted zones during regional disruptions in US East (N. Virginia)
  • PrivateLink Support (announced Nov 2025) – allows making changes to DNS infrastructure (hosted zones, records, health checks) without using the public internet

AWS Global Accelerator

  • is a networking service that helps you improve the availability and performance of the applications to global users.
  • utilizes the Amazon global backbone network, improving the performance of the applications by lowering first-byte latency, and jitter, and increasing throughput as compared to the public internet.
  • provides two static IP addresses serviced by independent network zones that provide a fixed entry point to the applications and eliminate the complexity of managing specific IP addresses for different AWS Regions and AZs.
  • always routes user traffic to the optimal endpoint based on performance, reacting instantly to changes in application health, the user’s location, and configured policies
  • 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.
  • is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover.
  • integrates with AWS Shield for DDoS protection
  • uses a global network of 130+ Points of Presence in 95+ cities across 53+ countries
  • supports dual-stack Network Load Balancers as endpoints
  • supports endpoints in 33 AWS Regions (as of 2025)
  • integrates with AWS Load Balancer Controller for Kubernetes (announced 2025)

Transit Gateway – TGW

  • is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
  • acts as a Regional virtual router and is a network transit hub that can be used to interconnect VPCs and on-premises networks.
  • traffic always stays on the global AWS backbone, data is automatically encrypted, and never traverses the public internet, thereby reducing threat vectors, such as common exploits and DDoS attacks.
  • is a Regional resource and can connect VPCs within the same AWS Region.
  • TGWs across the same or different regions can peer with each other.
  • provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
  • scales elastically based on the volume of network traffic.
  • supports security group referencing (announced Sept 2024) – allows creating inbound security rules that reference security groups defined in other VPCs attached to the same Transit Gateway within the same Region.
  • supports per-AZ metrics delivered to CloudWatch and Path MTU Discovery (PMTUD) for both IPv4 and IPv6 (announced Nov 2024).
  • supports Transit Gateway Flow Logs for monitoring and logging network traffic between transit gateways.
  • supports Flexible Cost Allocation (announced Nov 2025) – provides versatile cost allocation options through a central metering policy beyond the default sender-pay model.

Amazon VPC Lattice

  • is a fully managed application networking service that connects, monitors, and secures communications between services and resources across VPCs and accounts.
  • simplifies service-to-service connectivity without requiring VPC peering, Transit Gateway, or PrivateLink NLBs.
  • automatically manages network connectivity and application-layer routing between services across different VPCs and AWS accounts.
  • supports connectivity to TCP resources, such as databases, domain names, and IP addresses across VPCs and accounts.
  • integrates with AWS IAM for service-to-service authentication and authorization using Auth policies.
  • removes the NLB requirement that PrivateLink imposes on providers and supports cross-VPC/cross-account connectivity without CIDR coordination.
  • terminates TLS at the data plane so callers do not need to manage certificates.
  • provides built-in observability with access logs, connection logs, and traffic metrics.
  • Key concepts:
    • Service Network – a logical boundary for a collection of services that can communicate with each other
    • Service – represents an application unit that is independently deployable
    • Target Groups – collection of resources (instances, IPs, Lambda, ALB) for routing
    • Resource Configurations – define TCP resources (databases, IPs, domain names) accessible through VPC Lattice
  • Use cases:
    • Microservices connectivity across multiple VPCs/accounts
    • Secure service-to-service communication with zero trust
    • Alternative to VPC Peering and Transit Gateway for application-layer connectivity
    • Replacement for AWS App Mesh (which reached EOL on September 30, 2026)

Amazon VPC IP Address Manager (IPAM)

  • is a VPC feature that allows you to plan, track, and monitor IP addresses for AWS workloads.
  • organizes IP addresses by routing and security requirements while automating allocation to VPCs, replacing manual spreadsheet-based tracking.
  • tracks AWS accounts and VPCs, eliminating IP bookkeeping overhead.
  • supports management at both VPC and subnet CIDR levels.
  • integrates with AWS Organizations for cross-account IP address management.
  • supports provisioning Amazon-provided contiguous IPv4 blocks into publicly scoped regional pools for use with EIPs, NLBs, and NAT Gateways.
  • Public IP Insights – free feature that simplifies monitoring, analysis, and auditing of public IPv4 addresses.
  • IPAM Policies – define public IPv4 allocation strategies and automate prefix lists.
  • integrates with ALB for predictable IP address blocks for internet-facing ALBs (March 2025).
  • IPAM Advanced Tier – includes Infoblox integration (Nov 2025) for managing AWS IP addresses through existing Infoblox workflows.

AWS Network Firewall

  • is a managed, stateful network firewall and intrusion detection and prevention service for all Amazon VPCs.
  • scales automatically with network traffic, requiring no infrastructure management.
  • provides Layer 7 firewall capabilities with deep packet inspection.
  • supports flexible rules engine for fine-grained control of VPC network traffic.
  • provides active threat defense using AWS managed rules to block evasive C2 channels, malicious URLs, and other threat vectors.
  • supports Suricata-compatible IPS rules for known bad signatures and traffic patterns.
  • includes Network Firewall Proxy for granular security controls to inspect and filter VPC outbound connections, preventing data exfiltration and malware intrusion.
  • integrates with AWS Firewall Manager for centralized policy management across accounts.
  • can be combined with VPC Lattice for comprehensive security (VPC Lattice for HTTP/S with identity-based controls, Network Firewall for other traffic types).

AWS Cloud WAN

  • is a managed WAN service that provides a central dashboard to connect and manage branch offices, data centers, VPN connections, SD-WAN, VPCs, and Transit Gateways.
  • uses network policies to create a global network spanning multiple locations and networks, removing the need for different technologies.
  • provides a single console and set of APIs to manage networks across AWS Regions.
  • supports direct Direct Connect gateway attachments without requiring an intermediate Transit Gateway (announced Nov 2024).
  • supports Routing Policy for advanced traffic control (announced Nov 2025) – enables controlled routing environments, minimizing route reachability blast radius.
  • supports Service Insertion for inspection and security appliance integration.
  • supports PMTUD for both IPv4 and IPv6 (announced Nov 2024).
  • supports AWS PrivateLink and IPv6 for management endpoint connectivity (announced March 2025).
  • available in AWS GovCloud (US) Regions.

AWS Verified Access

  • provides secure access to corporate applications and resources without requiring a VPN.
  • implements zero trust principles by evaluating each access request based on user identity and device security posture rather than network location.
  • uses the Cedar policy language for defining fine-grained access policies.
  • supports secure access to resources over non-HTTP(S) protocols (announced Feb 2025) – enables VPN-less access to TCP-based resources like SSH, RDP, and databases.
  • continuously monitors active connections and terminates connections when security requirements aren’t met.
  • integrates with third-party identity providers and device management solutions.
  • can be used with PrivateLink-backed services to provide authorized internet-based access while maintaining security boundaries.