# Alias record

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/alias-record

## Quick definition

An Alias record is a special DNS record used in AWS Route 53 that lets you point your domain name to an AWS resource, such as a load balancer or S3 bucket. It works like a CNAME record but can be used for the root domain (e.g., example.com). When someone visits your site, the Alias record automatically directs them to the correct AWS endpoint without extra cost or delay.

## Simple meaning

Think of an Alias record like a mail forwarding service for letters. When you move to a new house, you set up mail forwarding at the post office. Any letters addressed to your old address get automatically sent to your new address. The Alias record does something similar for internet traffic: it takes visitors who type your domain name (like example.com) and forwards them to the actual AWS service you are using (like a load balancer). Unlike regular mail forwarding, Alias records work for both the root domain (example.com) and subdomains (like blog.example.com). This is important because with a standard CNAME record you cannot point the root domain to another name. Alias records are free in Route 53, meaning you don't pay for the DNS queries they resolve. They also work closely with AWS health checks, so if your primary resource becomes unavailable, the Alias record can automatically route traffic to a healthy resource. In everyday terms, an Alias record is like a smart signpost that changes directions based on where the road is clear, ensuring your users always reach the right destination without getting lost.

## Technical definition

An Alias record is a proprietary DNS record type specific to Amazon Route 53, which provides a way to map a DNS name to an AWS resource endpoint. Unlike a standard CNAME record, which is restricted to subdomains and incurs additional DNS query costs, an Alias record can be created for the zone apex (root domain) and is resolved at no extra charge. When a DNS query is made for an Alias record, Route 53 responds directly with the IP address(es) of the target AWS resource, such as an Application Load Balancer (ALB), Classic Load Balancer (CLB), Network Load Balancer (NLB), CloudFront distribution, Elastic Beanstalk environment, API Gateway, VPC endpoint, or S3 bucket configured for static website hosting. The resolution happens at the Route 53 edge location, using internal mappings that eliminate the need for a separate DNS lookup chain. Technically, the Alias record target must be a DNS name that belongs to the AWS resource, and Route 53 performs a health check on that target before returning IP addresses. If the target is unhealthy, Route 53 can fail over to another Alias record in a routing policy like weighted or failover. Alias records support all standard routing policies, including simple, weighted, latency based, geolocation, geoproximity, and failover. They also support both IPv4 and IPv6 address responses via A and AAAA record types. The key limitation is that Alias records can only point to AWS resources within the same account and region, except for CloudFront and S3 buckets which can be cross-account. The TTL (time to live) for an Alias record is set by the AWS resource and cannot be manually overridden, ensuring optimal caching and quick failover. This design allows Alias records to provide high availability and low latency by using the AWS global infrastructure. In practice, when you migrate a website to AWS, you replace your A or CNAME records with Alias records pointing to your load balancer, thus simplifying DNS management and reducing latency for end users.

## Real-life example

Imagine you own a food truck that moves to different locations each day. Your customers know your brand name, like "The Rolling Kitchen." Instead of giving them a specific street address that changes daily, you set up a central phone number that automatically tells callers where you are parked today. When someone calls that number, they hear the current location and directions. This central phone number is like an Alias record: it always points to your current location (the AWS resource) without the caller needing to know the exact address. If you move to a different park tomorrow, you just update the phone system, and all callers get the new location. Similarly, if your food truck has a backup driver, you can have the phone system direct callers to the backup if you are unavailable. This Alias record style approach saves your customers from remembering changing addresses and ensures they always find you. In the same way, an Alias record lets you change your website's underlying infrastructure (like switching from one load balancer to another) without changing the domain name your visitors type. It provides flexibility, reliability, and simplicity, just like that central phone number for your roaming food truck.

## Why it matters

Alias records matter because they solve a fundamental limitation of DNS that affects every website hosted on AWS. Without Alias records, you cannot point the root domain of your website (example.com) to a load balancer or CloudFront distribution using a CNAME record, because DNS standards forbid CNAME records at the zone apex. This forces many administrators to use a static A record pointing to an IP address, which breaks when the underlying resource changes or scales. Alias records eliminate this constraint, allowing you to use a clean, user-friendly root domain with dynamic AWS resources. This is crucial for professional web applications, e-commerce sites, and corporate portals where the root domain is the primary entry point. Alias records improve performance by resolving DNS queries at Route 53's edge locations, reducing latency. They also enable advanced routing policies like latency-based routing, which directs users to the region with the fastest response time. In a disaster recovery scenario, you can combine Alias records with failover routing to automatically redirect traffic to a backup region if the primary region becomes unavailable. This makes your application resilient without manual intervention. For IT professionals managing AWS environments, Alias records simplify DNS configuration because you do not need to maintain separate A records for each IP address. Instead, you point to the resource DNS name, which remains constant even as the underlying infrastructure scales or updates. Ultimately, Alias records are a core component of a well-architected AWS infrastructure, directly impacting availability, scalability, and user experience.

## Why it matters in exams

For the AWS Certified Solutions Architect Associate (SAA-C03) exam, Alias records are a high-yield topic because they appear in many domain-focused questions, particularly those covering networking, content delivery, and high availability. The exam objectives explicitly include DNS resolution, Route 53 routing policies, and integration with other AWS services. You can expect scenario-based questions that require you to choose between Alias records and CNAME records for a given architecture. For example, a question might describe a company that wants to serve its website from an S3 bucket configured for static website hosting, and ask which DNS record type allows using the root domain. The correct answer is an Alias record. Similarly, questions about multi-region active-passive architectures often involve Alias records with failover routing. The exam also tests your understanding of the limitations: Alias records can only point to AWS resources, and they support specific targets (ALB, CloudFront, S3, etc.). You might see a question where the wrong answer suggests using a CNAME for the root domain, which is invalid. Another common pattern is troubleshooting: a candidate configures an Alias record but traffic is not reaching the target-the cause might be a missing health check or incorrect target selection. The exam also covers cost implications: Alias record queries are free, whereas CNAME queries incur standard DNS charges. Remembering that Alias records are always free in Route 53 can help you eliminate answer choices that suggest using CNAMEs to save cost. The exam may combine Alias records with weighted routing policies to distribute traffic between multiple resources, or with geolocation routing to serve regional content. To succeed, you should be comfortable mapping these scenarios to the correct record type and understanding the underlying mechanics of how Route 53 resolves Alias records at the edge.

## How it appears in exam questions

In the AWS SAA exam, Alias record questions typically fall into three categories: design scenarios, configuration choices, and troubleshooting. A typical design question might present a company that wants to host a web application on AWS using an Application Load Balancer across multiple Availability Zones, and the domain name must be example.com (root domain). The question will list several DNS record options: A record pointing to the ALB's IP, CNAME record pointing to the ALB's DNS name, Alias record pointing to the ALB, or a combination. The correct answer is the Alias record because CNAME cannot be used at the zone apex, and A records are static and cannot track ALB IP changes. Another common pattern involves content delivery: a company wants to use CloudFront with a custom domain like www.example.com and also wants example.com to redirect to www.example.com. The question might ask what record type to create for example.com. The answer is an Alias record pointing to the CloudFront distribution. Configuration choice questions might ask which targets are valid for an Alias record: the correct list includes ALB, CloudFront, S3 website endpoint, Elastic Beanstalk, and API Gateway, but not an EC2 instance directly or an RDS endpoint. Troubleshooting questions often describe a scenario where Alias record configuration works locally but fails for external clients, and the cause is that the Alias record target is in a different AWS account or region without proper permissions. These questions test your understanding of the limitations and prerequisites. Another frequent question involves health checks: if an Alias record is associated with a failover routing policy and the primary target becomes unhealthy, will traffic automatically shift to the secondary? The answer is yes, but only if the health check is attached to the primary record. Questions may also combine Alias records with latency routing, asking you to select the correct configuration to direct users to the fastest region. The exam expects you to know that Alias records can be combined with any routing policy. Finally, there are compare-and-contrast questions between Alias and A/AAAA records, where the nuance is that Alias records can return multiple IP addresses if the target resource has multiple IPs (like a load balancer), and the routing is handled automatically by Route 53.

## Example scenario

A small business called "Beans & Bytes" wants to launch an e-commerce website. They register the domain beansandbytes.com and decide to host their site on AWS using an Application Load Balancer (ALB) behind EC2 instances. Their developer creates an ALB with DNS name internal-alb-123456.us-east-1.elb.amazonaws.com. To make the site accessible at beansandbytes.com, they need to set up DNS. The developer knows that a CNAME record cannot be used for the root domain, so they cannot simply point beansandbytes.com to the ALB's DNS name. They consider an A record, but that would require them to hardcode an IP address that might change if the ALB is recreated or scaled. The correct solution is to create an Alias record in Route 53 with name beansandbytes.com, type A, and target the Application Load Balancer. Once the Alias record is created, any user who types beansandbytes.com into their browser will be directed to the ALB, which then forwards the request to a healthy EC2 instance. The site loads quickly because Route 53 resolves the Alias record at its edge location, returning the IP address of the ALB. The business later decides to add CloudFront for content delivery. They create a CloudFront distribution with domain name d123.cloudfront.net and configure it with beansandbytes.com as an alternate domain. They then update the Alias record to point to the CloudFront distribution instead of the ALB. This change is seamless; no users experience downtime because the domain name remains the same. The Alias record automatically resolves to CloudFront's edge IPs. This scenario illustrates how Alias records simplify DNS management and provide flexibility to change infrastructure without changing the user-facing domain name.

## Common mistakes

- **Mistake:** Using a CNAME record for the root domain (e.g., example.com) instead of an Alias record.
  - Why it is wrong: DNS standards forbid CNAME records at the zone apex because the root domain must have other record types (like SOA and NS) that CNAME would conflict with. This would break DNS resolution for the entire domain.
  - Fix: Always use an Alias record of type A or AAAA when you need to point the root domain to an AWS resource. An Alias record does not have the same restrictions as a CNAME.
- **Mistake:** Assuming Alias records can point to any DNS name, including external non-AWS endpoints.
  - Why it is wrong: Alias records are a Route 53 proprietary feature and can only target specific AWS resource DNS names (e.g., ALB, CloudFront, S3 website endpoint). They cannot point to external servers or other DNS providers.
  - Fix: Verify that the target DNS name belongs to a supported AWS resource. If you need to point to an external service, use a CNAME record on a subdomain instead.
- **Mistake:** Forgetting to set a health check on an Alias record used with failover routing, assuming Route 53 will automatically detect failures.
  - Why it is wrong: Alias records themselves do not perform health checks. The health check must be explicitly configured and associated with the record. Without it, failover will not occur even if the target is unhealthy.
  - Fix: Always create and associate a Route 53 health check with the target resource when using failover routing with Alias records. Monitor the health check status to ensure it reflects the resource availability.
- **Mistake:** Believing that Alias records incur the same cost as standard Route 53 queries.
  - Why it is wrong: Alias record queries are free of charge in Route 53, while standard DNS queries (including CNAME lookups) are billed. This can lead to incorrect cost calculations and suboptimal architectural decisions.
  - Fix: When designing cost-effective architectures, prefer Alias records over CNAME records when targeting AWS resources. This reduces DNS query costs, especially for high-traffic domains.
- **Mistake:** Configuring an Alias record with a type that does not match the target resource's IP version.
  - Why it is wrong: If the Alias record is set to type A (IPv4) but the target resource only supports IPv6 (AAAA), or vice versa, the DNS resolution may fail for clients that request the other address family.
  - Fix: Check the DNS type supported by the target AWS resource. Typically, ALBs and CloudFront support both A and AAAA. Create separate Alias records for each type you need, or use A type if you only need IPv4.

## Exam trap

{"trap":"The exam question states: 'You want to use a DNS record to point your website's root domain (example.com) to an Elastic Load Balancer. Which record type should you choose? Options include: A, CNAME, Alias, and SRV.' A common trap answer is A record pointing to the load balancer's IP.","why_learners_choose_it":"Learners often choose A record because they know A records can exist at the zone apex, and they think using the IP address is straightforward. They may not realize that load balancers can change IP addresses over time, making a static A record unreliable.","how_to_avoid_it":"Remember that AWS load balancers are assigned a DNS name that does not change, but the underlying IP address can change. The correct answer is Alias record pointing to the load balancer's DNS name. This ensures that Route 53 always returns the current IP addresses of the load balancer, even if they change. Always consider long-term maintainability when answering DNS questions."}

## Commonly confused with

- **Alias record vs CNAME record:** A CNAME record maps one DNS name to another but cannot be used at the zone apex (root domain). An Alias record is like a CNAME for the root domain, but it only works for AWS resources. CNAME records incur standard DNS query costs, while Alias record queries are free. (Example: If you own example.com and want to point www.example.com to a load balancer, you could use a CNAME. But for example.com itself, you must use an Alias record.)
- **Alias record vs A record:** An A record maps a domain name directly to an IPv4 address. It is static, meaning if the underlying resource's IP changes, you must manually update the record. An Alias record maps to an AWS resource's DNS name, and Route 53 automatically resolves the current IP addresses, making it more flexible and reliable. (Example: An A record for example.com would point to IP 203.0.113.5. If the server moves, you must update the record. An Alias record for example.com points to the ALB's DNS name, and Route 53 handles IP changes automatically.)
- **Alias record vs AAAA record:** A AAA record maps a domain name to an IPv6 address. Like an A record, it is static and requires manual updates if the IP changes. An Alias record can be configured as type AAAA to point to AWS resources supporting IPv6, but it remains dynamic because it uses the resource's DNS name. (Example: If your load balancer supports IPv6, you could use a AAA record pointing to a static IPv6 address, but it could break if the address changes. Better to use an Alias record of type AAA pointing to the load balancer's DNS name.)

## Step-by-step breakdown

1. **Create a Route 53 hosted zone for your domain** — Before you can create an Alias record, you must have a hosted zone in Route 53 for your domain (e.g., example.com). This zone is the container for all DNS records for that domain, including the Alias record. You can create a public hosted zone via the Route 53 console, CLI, or SDK.
2. **Identify the AWS resource you want to point to** — You need to know the exact DNS name of the AWS resource that will serve your traffic. For example, an Application Load Balancer has a DNS name like internal-alb-123456789.us-east-1.elb.amazonaws.com. You can find this in the EC2 console or via the AWS CLI. The resource must be in the same AWS account (with some exceptions like CloudFront).
3. **Choose the Alias record type (A or AAAA)** — Decide whether you need IPv4 (A record) or IPv6 (AAAA) resolution. Most resources support both. If you are unsure, create an A record for IPv4, as it covers the majority of internet traffic. You can create separate Alias records for each type if needed.
4. **Add the Alias record in Route 53 with the resource target** — In the Route 53 console, select your hosted zone and click 'Create record'. Choose Alias toggle to 'Yes'. In the 'Route traffic to' dropdown, select the type of AWS resource (e.g., Alias to Application Load Balancer). Then choose the specific resource from the list or enter its DNS name manually. Save the record.
5. **(Optional) Attach a health check and configure routing policy** — For advanced scenarios with failover, weighted, or latency-based routing, you need to attach a health check to the Alias record. Create a health check that monitors the resource (e.g., ping the ALB on port 80). Then, when creating the Alias record, select the desired routing policy and associate the health check.
6. **Verify propagation and test the Alias record** — After saving the record, it may take a few minutes for DNS changes to propagate globally. Use tools like 'dig' or 'nslookup' to query your domain and verify that it resolves to the correct IP addresses. Also test the actual website access to ensure the Alias record is routing traffic successfully.

## Practical mini-lesson

An Alias record is more than just a DNS trick; it is a fundamental tool for building resilient and scalable AWS architectures. In practice, when you configure an Alias record, you are telling Route 53 to internally resolve the AWS resource's DNS name and return the corresponding IP addresses to the client. This internal resolution is key to its value: if the underlying resource scales up or down, or if its IP addresses change for any reason, the Alias record automatically updates without any action from you. This is particularly important for load balancers, which can have their IP addresses change during auto scaling events or when the load balancer is replaced. For production environments, professionals often combine Alias records with multiple routing policies. For example, you might use weighted routing with two Alias records pointing to different regional ALBs, distributing traffic 80% to us-east-1 and 20% to eu-west-1. If one region becomes unhealthy, the Alias record in that region fails over to zero weight automatically if a health check is attached. This is a powerful pattern for blue/green deployments and canary releases. When configuring Alias records for CloudFront, you must also add the domain name as an alternate domain name in the CloudFront distribution settings, and upload an SSL certificate for HTTPS. This is a common oversight that leads to configuration errors. Another practical consideration is that Alias records cannot point to an EC2 instance directly because the instance's DNS name is not an AWS resource endpoint in the same sense. To route traffic to an EC2 instance, you would point the Alias record to an ALB or use an Elastic IP with a standard A record. Understanding these nuances helps avoid misconfiguration. Also, remember that Alias records support both public and private hosted zones, but the target must be accessible from the clients. For internal services, you can create Alias records in private hosted zones pointing to internal load balancers. This is common for microservices architectures where internal DNS routes traffic within a VPC. Finally, cost management is a practical advantage: since Alias record queries are free, you can use them liberally even for high-traffic domains, whereas using CNAME records could generate significant costs. Professionals should document all Alias records and their targets to simplify troubleshooting and auditing.

## Commands

```
aws route53 change-resource-record-sets --hosted-zone-id Z3A1234567890 --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{"Name":"example.com.","Type":"A","AliasTarget":{"HostedZoneId":"Z2FDTNDATAQYW2","DNSName":"d123.cloudfront.net.","EvaluateTargetHealth":false}}}]}'
```


## Troubleshooting clues

- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined

## Memory tip

Remember 'Alias for Apex': Alias records are the only way to point the root domain (apex) to an AWS resource like a load balancer or CloudFront.

## FAQ

**Can an Alias record point to an EC2 instance's private IP?**

No, Alias records cannot point directly to an EC2 instance. They point to AWS resource DNS names, such as load balancers or CloudFront. To route traffic to an EC2 instance, use an A record with its Elastic IP or an Alias record pointing to a load balancer that forwards traffic to the instance.

**Is there a limit on how many Alias records I can create in Route 53?**

You can create up to 10,000 records per hosted zone by default, but this limit can be increased by requesting a quota increase. Alias records count toward that total. There is no separate limit specifically for Alias records.

**Do Alias records support IPv6?**

Yes, Alias records can be configured as type AAAA to return IPv6 addresses. You need to ensure the target AWS resource supports IPv6. Most modern resources like ALB and CloudFront do support both IPv4 and IPv6.

**What happens if the target resource of an Alias record is deleted?**

If the target resource is deleted, the Alias record will still exist but will not resolve correctly. Route 53 will return a SERVFAIL or similar error because the target DNS name no longer resolves. You must manually delete or update the Alias record to point to a valid target.

**Can I use an Alias record with a private hosted zone?**

Yes, you can create Alias records in private hosted zones to point to internal AWS resources, such as internal load balancers or VPC endpoints. This is useful for routing traffic within a VPC.

**Is there any cost difference between using Alias records and CNAME records?**

Yes, Alias record queries are free of charge in Route 53. Standard CNAME record queries incur the standard Route 53 query charges. For high-traffic domains, using Alias records can significantly reduce DNS costs.

## Summary

The Alias record is a powerful AWS-specific DNS record type that allows you to map your domain name directly to AWS resources like load balancers, CloudFront distributions, and S3 website endpoints. It overcomes a critical limitation of standard DNS by supporting both root domains (zone apex) and subdomains, which CNAME records cannot do for root domains. Alias records work by instructing Route 53 to internally resolve the DNS name of the target AWS resource and return the current IP addresses to clients, ensuring automatic updates when the resource's IP addresses change. This makes them ideal for dynamic environments where infrastructure scales or recovers from failures. From an exam perspective, especially for AWS SAA, understanding when to use Alias records versus CNAME or A records is essential. Key points to remember: Alias records are free, support various routing policies, and can only target specific AWS services. Common exam traps include trying to use a CNAME for the root domain or assuming Alias records work with non-AWS targets. In real-world practice, Alias records simplify DNS management, improve resilience through health checks and failover, and reduce costs. By mastering Alias records, you not only prepare for certification success but also gain a practical tool for building robust, scalable cloud architectures on AWS.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/alias-record