

# Values that you specify when you create or edit Amazon Route 53 records
<a name="resource-record-sets-values"></a>

When you create records using the Amazon Route 53 console, the values that you specify depend on the routing policy that you want to use and on whether you're creating alias records, which route traffic to AWS resources.

Alias records that route traffic to certain AWS resources for which you specify the target resource (for example, Elastic Load Balancing, CloudFront distribution, Amazon S3 bucket). You can also optionally associate health checks and configure target health evaluation. The following topics provide detailed information on the values required for each routing policy and record type, helping you configure your Route 53 records effectively.

**Topics**
+ [

# Values that are common for all routing policies
](resource-record-sets-values-shared.md)
+ [

# Values that are common for alias records for all routing policies
](resource-record-sets-values-alias-common.md)
+ [

# Values specific for simple records
](resource-record-sets-values-basic.md)
+ [

# Values specific for simple alias records
](resource-record-sets-values-alias.md)
+ [

# Values specific for failover records
](resource-record-sets-values-failover.md)
+ [

# Values specific for failover alias records
](resource-record-sets-values-failover-alias.md)
+ [

# Values specific for geolocation records
](resource-record-sets-values-geo.md)
+ [

# Values specific for geolocation alias records
](resource-record-sets-values-geo-alias.md)
+ [

# Values specific for geoproximity records
](resource-record-sets-values-geoprox.md)
+ [

# Values specific for geoproximity alias records
](resource-record-sets-values-geoprox-alias.md)
+ [

# Values specific for latency records
](resource-record-sets-values-latency.md)
+ [

# Values specific for latency alias records
](resource-record-sets-values-latency-alias.md)
+ [

# Values specific for IP-based records
](resource-record-sets-values-ipbased.md)
+ [

# Values specific for IP-based alias records
](resource-record-sets-values-ipbased-alias.md)
+ [

# Values specific for multivalue answer records
](resource-record-sets-values-multivalue.md)
+ [

# Values specific for weighted records
](resource-record-sets-values-weighted.md)
+ [

# Values specific for weighted alias records
](resource-record-sets-values-weighted-alias.md)

# Values that are common for all routing policies
<a name="resource-record-sets-values-shared"></a>

These are the common values that you can specify when you create or edit Amazon Route 53 records. These values are used by all routing policies.



**Topics**
+ [

## Record name
](#rrsets-values-common-name)
+ [

## Value/Route traffic to
](#rrsets-values-common-value)
+ [

## TTL (seconds)
](#rrsets-values-common-ttl)

## Record name
<a name="rrsets-values-common-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Special characters**  
For information about how to specify characters other than a-z, 0-9, and - (hyphen) and how to specify internationalized domain names, see [DNS domain name format](DomainNameFormat.md).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).  
You can't use the \$1 wildcard for resource records sets that have a type of **NS**.

## Value/Route traffic to
<a name="rrsets-values-common-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

**A — IPv4 address**  
An IP address in IPv4 format, for example, **192.0.2.235**.

**AAAA — IPv6 address**  
An IP address in IPv6 format, for example, **2001:0db8:85a3:0:0:8a2e:0370:7334**.

**CAA — Certificate Authority Authorization**  
Three space-separated values that control which certificate authorities are allowed to issue certificates or wildcard certificates for the domain or subdomain that is specified by **Record name**. You can use CAA records to specify the following:  
+ Which certificate authorities (CAs) can issue SSL/TLS certificates, if any
+ The email address or URL to contact when a CA issues a certificate for the domain or subdomain

**CNAME — Canonical name**  
The fully qualified domain name (for example, *www.example.com*) that you want Route 53 to return in response to DNS queries for this record. A trailing dot is optional; Route 53 assumes that the domain name is fully qualified. This means that Route 53 treats *www.example.com* (without a trailing dot) and *www.example.com.* (with a trailing dot) as identical.

**MX — Mail exchange**  
A priority and a domain name that specifies a mail server, for example, **10 mailserver.example.com**. The trailing dot is treated as optional.

**NAPTR — Name Authority Pointer**  
Six space-separated settings that are used by Dynamic Delegation Discovery System (DDDS) applications to convert one value to another or to replace one value with another. For more information, see [NAPTR record type](ResourceRecordTypes.md#NAPTRFormat).

**PTR — Pointer**  
The domain name that you want Route 53 to return.

**NS — Name server**  
The domain name of a name server, for example, **ns1.example.com**.  
You can specify an NS record with only simple routing policy.

**SPF — Sender Policy Framework**  
An SPF record enclosed in quotation marks, for example, **"v=spf1 ip4:192.168.0.1/16-all"**. SPF records are not recommended. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

**SRV — Service locator**  
An SRV record. SRV records are used for accessing services, such as a service for email or communications. For information about SRV record format, refer to the documentation for the service that you want to connect to. Trailing dot is treated as optional.  
The format of an SRV record is:  
**[priority] [weight] [port] [server host name]**  
For example:  
**1 10 5269 xmpp-server.example.com.**

**TXT — Text**  
A text record. Enclose text in quotation marks, for example, **"Sample text entry"**. 

## TTL (seconds)
<a name="rrsets-values-common-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

# Values that are common for alias records for all routing policies
<a name="resource-record-sets-values-alias-common"></a>

These are the common alias values that you can specify when you create or edit Amazon Route 53 records. These values are used by all routing policies.

**Topics**
+ [

## Record name
](#rrsets-values-common-alias-name)
+ [

## Value/route traffic to
](#rrsets-values-alias-common-target)

## Record name
<a name="rrsets-values-common-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Type**, the name of the record can't be the same as the name of the hosted zone.

**Aliases to CloudFront distributions and Amazon S3 buckets**  
The value that you specify depends in part on the AWS resource that you're routing traffic to:  
+ **CloudFront distribution** – Your distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*. 
+ **Amazon S3 bucket** – The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.

  In addition, you must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*. 

**Special characters**  
For information about how to specify characters other than a-z, 0-9, and - (hyphen) and how to specify internationalized domain names, see [DNS domain name format](DomainNameFormat.md).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Value/route traffic to
<a name="rrsets-values-alias-common-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

**Important**  
If you used the same AWS account to create your hosted zone and the resource that you're routing traffic to, and if your resource doesn't appear in the **Endpoint** list, check the following:  
Confirm that you chose a supported value for **Record type**. Supported values are specific to the resource that you're routing traffic to. For example, to route traffic to an S3 bucket, you must choose **A — IPv4 address** for **Record type**.
Confirm that the account has the IAM permissions that are required to list the applicable resources. For example, for CloudFront distributions to appear in the **Endpoint** list, the account must have permission to perform the following action: `cloudfront:ListDistributions`.  
For an example IAM policy, see [Permissions required to use the Amazon Route 53 console](access-control-managing-permissions.md#console-required-permissions).
If you used different AWS accounts to create the hosted zone and the resource, the **Endpoint** list doesn't display your resource. See the following documentation for your resource type to determine what value to type in **Endpoint**.

**API Gateway custom regional APIs and edge-optimized APIs**  
For API Gateway custom regional APIs and edge-optimized APIs, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your API** – Choose **Endpoint**, and then choose an API from the list. If you have a lot of APIs, you can enter the first few characters of the API endpoint to filter the list.
**Note**  
The name of this record must match a custom domain name for your API, such as **api.example.com**.
+ **If you used different accounts to create your Route 53 hosted zone and your API** – Enter the API endpoint for the API, such as **api.example.com**.

  If you used one AWS account to create the current hosted zone and a different account to create an API, the API won't appear in the **Endpoints** list under **API Gateway APIs**.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your APIs, the **Endpoints** list shows **No targets available** under **API Gateway APIs**. For more information, see [Routing traffic to an Amazon API Gateway API by using your domain name](routing-to-api-gateway.md).

**CloudFront distributions**  
For CloudFront distributions, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your CloudFront distribution** – Choose **Endpoint** and choose a distribution from the list. If you have a lot of distributions, you can enter the first few characters of the domain name for your distribution to filter the list.

  If your distribution doesn't appear in the list, note the following:
  + The name of this record must match an alternate domain name in your distribution.
  + If you just added an alternate domain name to your distribution, it may take 15 minutes for your changes to propagate to all CloudFront edge locations. Until changes have propagated, Route 53 can't know about the new alternate domain name.
+ **If you used different accounts to create your Route 53 hosted zone and your distribution** – Enter the CloudFront domain name for the distribution, such as **d111111abcdef8.cloudfront.net**.

  If you used one AWS account to create the current hosted zone and a different account to create a distribution, the distribution will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your distributions, the **Endpoints** list shows **No targets available** under **CloudFront distributions**.
Do not route queries to a CloudFront distribution that has not propagated to all edge locations, or your users won't be able to access the applicable content. 
Your CloudFront distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Record type**, and one with a value of **AAAA — IPv6 address**. For more information, see [Routing traffic to an Amazon CloudFront distribution by using your domain name](routing-to-cloudfront-distribution.md).

**App Runner service**  
For App Runner service, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your App Runner service** – choose the AWS Region, then choose the domain name of the environment that you want to route traffic to from the list.
+ **If you used different accounts to create your Route 53 hosted zone and your App Runner** – Enter the custom domain name. For more information, see [Managing custom domain names for App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html).

  If you used one AWS account to create the current hosted zone and a different account to create a App Runner, the App Runner will not appear in the **Endpoints** list.
For more information, see [Configuring Amazon Route 53 to route traffic to an App Runner service](routing-to-app-runner.md#routing-to-app-runner-configuring).

**Elastic Beanstalk environments that have regionalized subdomains**  
If the domain name for your Elastic Beanstalk environment includes the Region that you deployed the environment in, you can create an alias record that routes traffic to the environment. For example, the domain name `my-environment.us-west-2.elasticbeanstalk.com` is a regionalized domain name.  
For environments that were created before early 2016, the domain name doesn't include the Region. To route traffic to these environments, you must create a CNAME record instead of an alias record. Note that you can't create a CNAME record for the root domain name. For example, if your domain name is example.com, you can create a record that routes traffic for acme.example.com to your Elastic Beanstalk environment, but you can't create a record that routes traffic for example.com to your Elastic Beanstalk environment.
For Elastic Beanstalk environments that have regionalized subdomains, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your Elastic Beanstalk environment** – Choose **Endpoint**, and then choose an environment from the list. If you have a lot of environments, you can enter the first few characters of the CNAME attribute for the environment to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your Elastic Beanstalk environment** – Enter the CNAME attribute for the Elastic Beanstalk environment.
For more information, see [Routing traffic to an AWS Elastic Beanstalk environment](routing-to-beanstalk-environment.md).

**ELB Load Balancers**  
For ELB load balancers, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your load balancer** – Choose **Endpoint** and choose a load balancer from the list. If you have a lot of load balancers, you can enter the first few characters of the DNS name to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your load balancer** – Enter the value that you got in the procedure [Getting the DNS name for an Elastic Load Balancing load balancer](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure).

  If you used one AWS account to create the current hosted zone and a different account to create a load balancer, the load balancer will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your load balancers, the **Endpoints** list shows **No targets available** under **Elastic Load Balancers**.
The console prepends **dualstack.** for Application and Classic Load Balancer from a different account. When a client, such as a web browser, requests the IP address for your domain name (example.com) or subdomain name (www.example.com), the client can request an IPv4 address (an A record), an IPv6 address (a AAAA record), or both IPv4 and IPv6 addresses (in separate requests). The **dualstack.** designation allows Route 53 to respond with the appropriate IP address for your load balancer based on which IP address format the client requested.  
For more information, see [Routing traffic to an ELB load balancer](routing-to-elb-load-balancer.md).

**AWS Global Accelerator accelerators**  
For AWS Global Accelerator accelerators, enter the DNS name for the accelerator. You can enter the DNS name of an accelerator that you created using the current AWS account or using a different AWS account. 

**Amazon S3 Buckets**  
For Amazon S3 buckets that are configured as website endpoints, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your Amazon S3 bucket** – Choose **Endpoint** and choose a bucket from the list. If you have a lot of buckets, you can enter the first few characters of the DNS name to filter the list.

  The value of **Endpoint** changes to the Amazon S3 website endpoint for your bucket.
+ **If you used different accounts to create your Route 53 hosted zone and your Amazon S3 bucket** – Enter the name of the Region that you created your S3 bucket in. Use the value that appears in the **Website endpoint** column in the table [Amazon S3 website endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) in the *Amazon Web Services General Reference*.

  If you used AWS accounts other than the current account to create your Amazon S3 buckets, the bucket won't appear in the **Endpoints** list.
You must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*.  
The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your Amazon S3 bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.  
In a group of weighted alias, latency alias, failover alias, or geolocation alias records, you can create only one record that routes queries to an Amazon S3 bucket because the name of the record must match the name of the bucket and bucket names must be globally unique.

**Amazon OpenSearch Service**  
For OpenSearch Service, do one of the following:  
+ **OpenSearch Service custom domain**: The name of the record must match the custom domain. For example, if the name of your custom domain is test.example.com, the name of this record must also be test.example.com.
+ **If you used the same account to create your Route 53 hosted zone and your OpenSearch Service domain** – choose the AWS Region, then choose the domain name.
+ **If you used different accounts to create your Route 53 hosted zone and your OpenSearch Service domain** – Enter the custom domain name. For more information, see [Create a custom endpoint](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).

  If you used one AWS account to create the current hosted zone and a different account to create a OpenSearch Service domain, the domain will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your OpenSearch Service domains, the **Endpoints** list shows **No targets available** under **OpenSearch Service**.
For more information, see [Configuring Amazon Route 53 to route traffic to an Amazon OpenSearch Service domain endpoint](routing-to-open-search-service.md#routing-to-open-search-service-configuring).

**Amazon VPC interface endpoints**  
For Amazon VPC interface endpoints, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your interface endpoint** – Choose **Endpoint**, and then choose an interface endpoint from the list. If you have a lot of interface endpoints, you can enter the first few characters of the DNS hostname to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your interface endpoint** – Enter the DNS hostname for the interface endpoint, such as **vpce-123456789abcdef01-example-us-east-1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**.

  If you used one AWS account to create the current hosted zone and a different account to create an interface endpoint, the interface endpoint won't appear in the **Endpoint** list under **VPC endpoints**.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your interface endpoints, the **Endpoint** list shows **No targets available** under **VPC endpoints**.

  For more information, see [Routing traffic to an Amazon Virtual Private Cloud interface endpoint by using your domain name](routing-to-vpc-interface-endpoint.md).

**Records in this Hosted Zone**  
For records in this hosted zone, choose **Endpoint** and choose the applicable record. If you have a lot of records, you can enter the first few characters of the name to filter the list.  
If the hosted zone contains only the default NS and SOA records, the **Endpoints** list shows **No targets available**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't choose a record for which the value of **Record type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

# Values specific for simple records
<a name="resource-record-sets-values-basic"></a>

When you create simple records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-basic-routing-policy)
+ [

## Record name
](#rrsets-values-basic-name)
+ [

## Value/Route traffic to
](#rrsets-values-basic-value)
+ [

## Record type
](#rrsets-values-basic-type)
+ [

## TTL (seconds)
](#rrsets-values-basic-ttl)

## Routing policy
<a name="rrsets-values-basic-routing-policy"></a>

Choose **Simple routing**.

## Record name
<a name="rrsets-values-basic-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Value/Route traffic to
<a name="rrsets-values-basic-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **NS — Name server**

  The domain name of a name server, for example, **ns1.example.com**.
**Note**  
You can specify an NS record with only simple routing policy.
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Record type
<a name="rrsets-values-basic-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Record type** based on how you want Route 53 to respond to DNS queries. 

## TTL (seconds)
<a name="rrsets-values-basic-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

# Values specific for simple alias records
<a name="resource-record-sets-values-alias"></a>

When you create alias records, you specify the following values. For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Note**  
If you are using Route 53 in the AWS GovCloud (US) Region, this feature has some restrictions. For more information, see the [Amazon Route 53 page](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) in the *AWS GovCloud (US) User Guide*.

**Topics**
+ [

## Routing policy
](#rrsets-values-alias-routing-policy)
+ [

## Record name
](#rrsets-values-alias-name)
+ [

## Value/route traffic to
](#rrsets-values-alias-alias-target)
+ [

## Record type
](#rrsets-values-alias-type)
+ [

## Evaluate target health
](#rrsets-values-alias-evaluate-target-health)

## Routing policy
<a name="rrsets-values-alias-routing-policy"></a>

Choose **Simple routing**.

## Record name
<a name="rrsets-values-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Value/route traffic to
<a name="rrsets-values-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Record type
<a name="rrsets-values-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Evaluate target health
<a name="rrsets-values-alias-evaluate-target-health"></a>

When the value of **Routing policy** is **Simple**, you can choose either **No** or the default **Yes** because **Evaluate target health** has no effect for **Simple** routing. If you have only one record that has a given name and type, Route 53 responds to DNS queries by using the values in that record regardless of whether the resource is healthy.

For other routing policies, **Evaluate target health** determines whether Route 53 checks the health of the resource that the alias record refers to:
+ **Services where Evaluate target health provides operational benefit**: For load balancers (ELB) and AWS Elastic Beanstalk environments with load balancers, setting **Evaluate target health** to **Yes** allows Route 53 to route traffic away from unhealthy resources.
+ **Highly available services**: For services like Amazon S3 buckets, VPC interface endpoints, Amazon API Gateway, AWS Global Accelerator, Amazon OpenSearch Service, and Amazon VPC Lattice, **Evaluate target health** provides no operational benefit because these services are designed for high availability. For failover scenarios with these services, use [Route 53 health checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html) instead.

For detailed information about how **Evaluate target health** works with different AWS services, see the [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth) documentation in the API reference.

# Values specific for failover records
<a name="resource-record-sets-values-failover"></a>

When you create failover records, you specify the following values.

**Note**  
For information about creating failover records in a private hosted zone, see [Configuring failover in a private hosted zone](dns-failover-private-hosted-zones.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-failover-routing-policy)
+ [

## Record name
](#rrsets-values-failover-name)
+ [

## Record type
](#rrsets-values-failover-type)
+ [

## TTL (seconds)
](#rrsets-values-failover-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-failover-value)
+ [

## Failover record type
](#rrsets-values-failover-record-type)
+ [

## Health check
](#rrsets-values-failover-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-failover-set-id)

## Routing policy
<a name="rrsets-values-failover-routing-policy"></a>

Choose **Failover**. 

## Record name
<a name="rrsets-values-failover-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for both of the records in the group of failover records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-failover-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for both the primary and secondary failover records.

## TTL (seconds)
<a name="rrsets-values-failover-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-failover-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Failover record type
<a name="rrsets-values-failover-record-type"></a>

Choose the applicable value for this record. For failover to function correctly, you must create one primary and one secondary failover record.

You can't create non-failover records that have the same values for **Record name** and **Record type** as failover records.

## Health check
<a name="rrsets-values-failover-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-failover-set-id"></a>

Enter a value that uniquely identifies the primary and secondary records. 

# Values specific for failover alias records
<a name="resource-record-sets-values-failover-alias"></a>

When you create failover alias records, you specify the following values.

For information, see the following topics:
+ For information about creating failover records in a private hosted zone, see [Configuring failover in a private hosted zone](dns-failover-private-hosted-zones.md).
+ For information about alias records, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-failover-alias-routing-policy)
+ [

## Record name
](#rrsets-values-failover-alias-name)
+ [

## Record type
](#rrsets-values-failover-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-failover-alias-alias-target)
+ [

## Failover record type
](#rrsets-values-failover-alias-failover-record-type)
+ [

## Health check
](#rrsets-values-failover-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-failover-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-failover-alias-set-id)

## Routing policy
<a name="rrsets-values-failover-alias-routing-policy"></a>

Choose **Failover**. 

## Record name
<a name="rrsets-values-failover-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for both of the records in the group of failover records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-failover-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for both the primary and secondary failover records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-failover-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

**Note**  
When you create primary and secondary failover records, you can optionally create one failover and one failover *alias* record that have the same values for **Name** and **Record type**. If you mix failover and failover alias records, either one can be the primary record. 

## Failover record type
<a name="rrsets-values-failover-alias-failover-record-type"></a>

Choose the applicable value for this record. For failover to function correctly, you must create one primary and one secondary failover record.

You can't create non-failover records that have the same values for **Record name** and **Record type** as failover records.

## Health check
<a name="rrsets-values-failover-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-failover-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic load balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate Target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, a target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-failover-alias-set-id"></a>

Enter a value that uniquely identifies the primary and secondary records. 

# Values specific for geolocation records
<a name="resource-record-sets-values-geo"></a>

When you create geolocation records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-geo-routing-policy)
+ [

## Record name
](#rrsets-values-geo-name)
+ [

## Record type
](#rrsets-values-geo-type)
+ [

## TTL (seconds)
](#rrsets-values-geo-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-geo-value)
+ [

## Location
](#rrsets-values-geo-location)
+ [

## U.S. states
](#rrsets-values-geo-sublocation)
+ [

## Health check
](#rrsets-values-geo-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-geo-set-id)

## Routing policy
<a name="rrsets-values-geo-routing-policy"></a>

Choose **Geolocation**. 

## Record name
<a name="rrsets-values-geo-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of geolocation records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-geo-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of geolocation records.

## TTL (seconds)
<a name="rrsets-values-geo-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-geo-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Location
<a name="rrsets-values-geo-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the continent or country for which you want Route 53 to respond with the settings in this record. If you want Route 53 to respond to DNS queries for individual states in the United States, select **United States** from the **Location** list, and then select the state under the **Sublocation** group.

For a private hosted zone, select the continent, country, or sub-division closest to the AWS Region that your resource is in. For example, if your resource is in us-east-1, you can specify North America, United States, or Virginia.

**Important**  
We recommend that you create one geolocation record that has a value of **Default** for **Location**. This covers geographic locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-geolocation records that have the same values for **Record name** and **Record type** as geolocation records.

For more information, see [Geolocation routing](routing-policy-geo.md).

Here are the countries that Amazon Route 53 associates with each continent. The country codes are from ISO 3166. For more information, see the Wikipedia article [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):

**Africa (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctica (AN)**  
AQ, GS, TF

**Asia (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Some providers consider TR to be in Asia and the IP-addresses will reflect that.

**North America (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Oceania (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**South America (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 doesn't support creating geolocation records for the following countries: Bouvet Island (BV), Christmas Island (CX), Western Sahara (EH), and Heard Island and McDonald Islands (HM). No data is available about IP addresses for these countries.

## U.S. states
<a name="rrsets-values-geo-sublocation"></a>

When you configure Route 53 to respond to DNS queries based on the state of the United States that the queries originated from, select the state from the **U.S. states** list. United States territories (for example, Puerto Rico) are listed as countries in the **Location** list.

**Important**  
Some IP addresses are associated with the United States, but not with an individual state. If you create records for all of the states in the United States, we recommend that you also create a record for the United States to route queries for these unassociated IP addresses. If you don't create a record for the United States, Route 53 responds to DNS queries from unassociated United States IP addresses with settings from the default geolocation record (if you created one) or with a "no answer" response. 

## Health check
<a name="rrsets-values-geo-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geolocation records, if an endpoint is unhealthy, Route 53 looks for a record for the larger, associated geographic Region. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Record ID
<a name="rrsets-values-geo-set-id"></a>

Enter a value that uniquely identifies this record in the group of geolocation records.

# Values specific for geolocation alias records
<a name="resource-record-sets-values-geo-alias"></a>

When you create geolocation alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-geo-alias-routing-policy)
+ [

## Record name
](#rrsets-values-geo-alias-name)
+ [

## Record type
](#rrsets-values-geo-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-geo-alias-alias-target)
+ [

## Location
](#rrsets-values-geo-alias-location)
+ [

## U.S. states
](#rrsets-values-geo-alias-sublocation)
+ [

## Health check
](#rrsets-values-geo-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-geo-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-geo-alias-set-id)

## Routing policy
<a name="rrsets-values-geo-alias-routing-policy"></a>

Choose **Geolocation**. 

## Record name
<a name="rrsets-values-geo-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of geolocation records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-geo-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of geolocation records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-geo-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [Value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-geo-alias-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the continent or country for which you want Route 53 to respond with the settings in this record. If you want Route 53 to respond to DNS queries for individual states in the United States, select **United States** from the **Location** list, and then select the state from the **U.S. states** list.

For a private hosted zone, select the continent, country, or sub-division closest to the AWS Region that your resource is in. For example, if your resource is in us-east-1, you can specify North America, United States, or Virginia.

**Important**  
We recommend that you create one geolocation record that has a value of **Default** for **Location**. This covers geographic locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-geolocation records that have the same values for **Record name** and **Record type** as geolocation records.

For more information, see [Geolocation routing](routing-policy-geo.md).

Here are the countries that Amazon Route 53 associates with each continent. The country codes are from ISO 3166. For more information, see the Wikipedia article [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):

**Africa (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctica (AN)**  
AQ, GS, TF

**Asia (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Some providers consider TR to be in Asia and the IP-addresses will reflect that.

**North America (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Oceania (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**South America (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 doesn't support creating geolocation records for the following countries: Bouvet Island (BV), Christmas Island (CX), Western Sahara (EH), and Heard Island and McDonald Islands (HM). No data is available about IP addresses for these countries.

## U.S. states
<a name="rrsets-values-geo-alias-sublocation"></a>

When you configure Route 53 to respond to DNS queries based on the state of the United States that the queries originated from, select the state from the **U.S. states** list. United States territories (for example, Puerto Rico) are listed as countries in the **Location** list.

**Important**  
Some IP addresses are associated with the United States, but not with an individual state. If you create records for all of the states in the United States, we recommend that you also create a record for the United States to route queries for these unassociated IP addresses. If you don't create a record for the United States, Route 53 responds to DNS queries from unassociated United States IP addresses with settings from the default geolocation record (if you created one) or with a "no answer" response. 

## Health check
<a name="rrsets-values-geo-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geolocation records, if an endpoint is unhealthy, Route 53 looks for a record for the larger, associated geographic Region. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Evaluate target health
<a name="rrsets-values-geo-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-geo-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of geolocation records.

# Values specific for geoproximity records
<a name="resource-record-sets-values-geoprox"></a>

When you create geoproximity records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-geoprox-routing-policy)
+ [

## Record name
](#rrsets-values-geoprox-name)
+ [

## Record type
](#rrsets-values-geoprox-type)
+ [

## TTL (seconds)
](#rrsets-values-geoprox-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-geoprox-value)
+ [

## Endpoint location
](#rrsets-values-geoprox-endpoint-location)
+ [

## Bias
](#rrsets-values-geoprox-bias)
+ [

## Health check
](#rrsets-values-geoprox-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-geoprox-set-id)

## Routing policy
<a name="rrsets-values-geoprox-routing-policy"></a>

Choose **Geoproximity**. 

## Record name
<a name="rrsets-values-geoprox-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of geoproximity records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-geoprox-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of geoproximity records.

## TTL (seconds)
<a name="rrsets-values-geoprox-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-geoprox-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Endpoint location
<a name="rrsets-values-geoprox-endpoint-location"></a>

You can specify the resource endpoint location by using one of the following: 

**Custom coordinates**  
Specify the longitude and lattitude for a geopgraphic area.

**AWS Region**  
Choose an available Region from the **Location** list.   
For more information about the Regions, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Local Zone Group**  
Choose an available Local Zone Group from the **Location** list.  
For more information about Local Zones, see [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) in the *AWS Local Zones User Guide*. A local Zone Group is usually the Local Zone without the ending character. For example, if the Local Zone is `us-east-1-bue-1a` the Local Zone Group is `us-east-1-bue-1`.

You can also identify the Local Zones Group for a specific Local Zone by using the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI command:

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

This command returns: `"GroupName": "us-west-2-den-1"`, specifying that the Local Zone `us-west-2-den-1a` belongs to the Local Zone Group `us-west-2-den-1`.

You can't create non-geoproximity records that have the same values for **Record name** and **Record type** as geoproximity records.

You also can't create two geoproximity resource record sets that specify the same location for the same record name and record type.

## Bias
<a name="rrsets-values-geoprox-bias"></a>

A bias either expands or shrinks a geographic area from which Route 53 routes traffic to a resource. A positive bias expands the area, and a negative bias shrinks it. For more information, see [How Amazon Route 53 uses bias to route traffic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Health check
<a name="rrsets-values-geoprox-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, geoproximity alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geoproximity records, if an endpoint is unhealthy, Route 53 looks for a closest endpoint that is still healthy. 

## Record ID
<a name="rrsets-values-geoprox-set-id"></a>

Enter a value that uniquely identifies this record in the group of geoproximity records.

# Values specific for geoproximity alias records
<a name="resource-record-sets-values-geoprox-alias"></a>

When you create geoproximity alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-geoprox-alias-routing-policy)
+ [

## Record name
](#rrsets-values-geoprox-alias-name)
+ [

## Record type
](#rrsets-values-geoprox-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-geoprox-alias-alias-target)
+ [

## Endpoint location
](#rrsets-values-geoprox-alias-endpoint-location)
+ [

## Bias
](#rrsets-values-geoprox-alias-bias)
+ [

## Health check
](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-geoprox-alias-set-id)

## Routing policy
<a name="rrsets-values-geoprox-alias-routing-policy"></a>

Choose **Geoproximity**. 

## Record name
<a name="rrsets-values-geoprox-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of geoproximity records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-geoprox-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of geoproximity records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-geoprox-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [Value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Endpoint location
<a name="rrsets-values-geoprox-alias-endpoint-location"></a>

You can specify the resource endpoint location by using one of the following: 

**Custom coordinates**  
Specify the longitude and lattitude for a geopgraphic area.

**AWS Region**  
Choose an available Region from the **Location** list.   
For more information about the Regions, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Local Zone Group**  
Choose an available Local Zone Region from the **Location** list.  
For more information about Local Zones, see [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) in the *AWS Local Zones User Guide*. A local Zone Group is usually the Local Zone without the ending character. For example, if the Local Zone is `us-east-1-bue-1a` the Local Zone Group is `us-east-1-bue-1`.

You can also identify the Local Zones Group for a specific Local Zone by using the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI command:

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

This command returns: `"GroupName": "us-west-2-den-1"`, specifying that the Local Zone `us-west-2-den-1a` belongs to the Local Zone Group `us-west-2-den-1`.

You can't create non-geoproximity records that have the same values for **Record name** and **Record type** as geoproximity records.

You also can't create two geoproximity resource record sets that specify the same location for the same record name and record type.

For more information, see available-local-zones.html

## Bias
<a name="rrsets-values-geoprox-alias-bias"></a>

A bias either expands or shrinks a geographic area from which Route 53 routes traffic to a resource. A positive bias expands the area, and a negative bias shrinks it. For more information, see [How Amazon Route 53 uses bias to route traffic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Health check
<a name="rrsets-values-geoprox-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, geoproximity alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geoproximity records, if an endpoint is unhealthy, Route 53 looks for a closest endpoint that is still healthy. 

## Evaluate target health
<a name="rrsets-values-geoprox-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-geoprox-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of geoproximity records.

# Values specific for latency records
<a name="resource-record-sets-values-latency"></a>

When you create latency records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-latency-routing-policy)
+ [

## Record name
](#rrsets-values-latency-name)
+ [

## Record type
](#rrsets-values-latency-type)
+ [

## TTL (seconds)
](#rrsets-values-latency-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-latency-value)
+ [

## Region
](#rrsets-values-latency-region)
+ [

## Health check
](#rrsets-values-latency-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-latency-set-id)

## Routing policy
<a name="rrsets-values-latency-routing-policy"></a>

Choose **Latency**. 

## Record name
<a name="rrsets-values-latency-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of latency records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-latency-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Type** based on how you want Route 53 to respond to DNS queries. 

Select the same value for all of the records in the group of latency records.

## TTL (seconds)
<a name="rrsets-values-latency-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-latency-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Region
<a name="rrsets-values-latency-region"></a>

The Amazon EC2 Region where the resource that you specified in this record resides. Route 53 recommends an Amazon EC2 Region based on other values that you've specified. This also applies to private hosted zones. We recommend that you not change this value.

Note the following:
+ You can only create one latency record for each Amazon EC2 Region.
+ You aren't required to create latency records for all Amazon EC2 Regions. Route 53 chooses the Region with the best latency from among the Regions that you create latency records for.
+ You can't create non-latency records that have the same values for **Record name** and **Record type** as latency records.
+ If you create a record tagged with the Region **cn-north-1**, Route 53 always responds to queries from within China using this record, regardless of the latency.

For more information about using latency records, see [Latency-based routing](routing-policy-latency.md). 

## Health check
<a name="rrsets-values-latency-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-latency-set-id"></a>

Enter a value that uniquely identifies this record in the group of latency records.

# Values specific for latency alias records
<a name="resource-record-sets-values-latency-alias"></a>

When you create latency alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-latency-alias-routing-policy)
+ [

## Record name
](#rrsets-values-latency-alias-name)
+ [

## Record type
](#rrsets-values-latency-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-latency-alias-alias-target)
+ [

## Region
](#rrsets-values-latency-alias-region)
+ [

## Health check
](#rrsets-values-latency-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-latency-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-latency-alias-set-id)

## Routing policy
<a name="rrsets-values-latency-alias-routing-policy"></a>

Choose **Latency**. 

## Record name
<a name="rrsets-values-latency-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of latency records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Record type
<a name="rrsets-values-latency-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

Select the same value for all of the records in the group of latency records.

## Value/Route traffic to
<a name="rrsets-values-latency-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Region
<a name="rrsets-values-latency-alias-region"></a>

The Amazon EC2 region where the resource that you specified in this record resides. Route 53 recommends an Amazon EC2 Region based on other values that you've specified. This also applies to private hosted zones. We recommend that you not change this value.

Note the following:
+ You can only create one latency record for each Amazon EC2 Region.
+ You aren't required to create latency records for all Amazon EC2 Regions. Route 53 chooses the Region with the best latency from among the Regions that you create latency records for.
+ You can't create non-latency records that have the same values for **Record name** and **Record type** as latency records.
+ If you create a record tagged with the Region **cn-north-1**, Route 53 always responds to queries from within China using this record, regardless of the latency.

For more information about using latency records, see [Latency-based routing](routing-policy-latency.md). 

## Health check
<a name="rrsets-values-latency-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-latency-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate Target Health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-latency-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of latency records.

# Values specific for IP-based records
<a name="resource-record-sets-values-ipbased"></a>

When you create IP-based records, you specify the following values.

**Note**  
Although creating IP-based records in a private hosted zone is allowed, it's not supported.

**Topics**
+ [

## Routing policy
](#rrsets-values-ipbased-routing-policy)
+ [

## Record name
](#rrsets-values-ibased-name)
+ [

## Record type
](#rrsets-values-ibased-type)
+ [

## TTL (seconds)
](#rrsets-values-ibased-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-ibased-value)
+ [

## Location
](#rrsets-values-ibased-location)
+ [

## Health check
](#rrsets-values-ibased-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-ipbased-set-id)

## Routing policy
<a name="rrsets-values-ipbased-routing-policy"></a>

Choose **IP-based**. 

## Record name
<a name="rrsets-values-ibased-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of IP-based records. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Special characters**  
For information about how to specify characters other than a-z, 0-9, and - (hyphen) and how to specify internationalized domain names, see [DNS domain name format](DomainNameFormat.md).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Record type
<a name="rrsets-values-ibased-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Type** based on how you want Route 53 to respond to DNS queries. 

Select the same value for all of the records in the group of IP-based records.

## TTL (seconds)
<a name="rrsets-values-ibased-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-ibased-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value) [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Location
<a name="rrsets-values-ibased-location"></a>

The name of the CIDR location where the resource that you specified in this record is specified by the CIDR block values within the CIDR location. 

For more information about using IP-based records, see [IP-based routing](routing-policy-ipbased.md). 

## Health check
<a name="rrsets-values-ibased-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, IP-based alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-ipbased-set-id"></a>

Enter a value that uniquely identifies this record in the group of IP-based records.

# Values specific for IP-based alias records
<a name="resource-record-sets-values-ipbased-alias"></a>

When you create IP-based alias records, you specify the following values.

**Note**  
Although creating IP-based alias records in a private hosted zone is allowed, it's not supported.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-ipbased-alias-routing-policy)
+ [

## Record name
](#rrsets-values-ipbased-alias-name)
+ [

## Record type
](#rrsets-values-ipbased-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-ipbased-alias-alias-target)
+ [

## Location
](#rrsets-values-ipbased-alias-location)
+ [

## Health check
](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-ipbased-alias-set-id)

## Routing policy
<a name="rrsets-values-ipbased-alias-routing-policy"></a>

Choose **IP-based**. 

**Note**  
Although creating IP-based alias records in a private hosted zone is allowed, it's not supported.

## Record name
<a name="rrsets-values-ipbased-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of IP-based records. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Aliases to CloudFront distributions and Amazon S3 buckets**  
The value that you specify depends in part on the AWS resource that you're routing traffic to:  
+ **CloudFront distribution** – Your distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*. 
+ **Amazon S3 bucket** – The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.

  In addition, you must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*. 

**Special characters**  
For information about how to specify characters other than a-z, 0-9, and - (hyphen) and how to specify internationalized domain names, see [DNS domain name format](DomainNameFormat.md).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Record type
<a name="rrsets-values-ipbased-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of IP-based records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-ipbased-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-ipbased-alias-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the CIDR location for which you want Route 53 to respond with the settings in this record.

**Important**  
We recommend that you create one IP-based record that has a value of **Default** for **Location**. This covers locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-IP-based records that have the same values for **Record name** and **Record type** as IP-based records.

For more information, see [IP-based routing](routing-policy-ipbased.md).

## Health check
<a name="rrsets-values-ipbased-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, IP-based routing alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For IP-based alias records, if an endpoint is unhealthy, Route 53 looks for a record within the larger, associated location. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Evaluate target health
<a name="rrsets-values-ipbased-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-ipbased-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of IP-based records.

# Values specific for multivalue answer records
<a name="resource-record-sets-values-multivalue"></a>

When you create multivalue answer records, you specify the following values.

**Note**  
Creating multivalue answer alias records is not supported.

**Topics**
+ [

## Routing policy
](#rrsets-values-multivalue-routing-policy)
+ [

## Record name
](#rrsets-values-multivalue-name)
+ [

## Record type
](#rrsets-values-multivalue-type)
+ [

## TTL (seconds)
](#rrsets-values-multivalue-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-multivalue-value)
+ [

## Health check
](#rrsets-values-multivalue-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-multivalue-set-identifier)

## Routing policy
<a name="rrsets-values-multivalue-routing-policy"></a>

Choose **Multivalue answer**.

## Record name
<a name="rrsets-values-multivalue-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of multivalue records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-multivalue-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select any value except **NS** or **CNAME**.

Select the same value for all of the records in the group of multivalue answer records.

## TTL (seconds)
<a name="rrsets-values-multivalue-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

**Note**  
If you create two or more multivalue answer records that have the same name and type, you are using the console, and you specify different values for **TTL**, Route 53 changes the value of **TTL** for all of the records to the last value that you specified.

## Value/Route traffic to
<a name="rrsets-values-multivalue-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. If you enter more than one value, enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Health check
<a name="rrsets-values-multivalue-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-multivalue-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of multivalue answer records. 

# Values specific for weighted records
<a name="resource-record-sets-values-weighted"></a>

When you create weighted records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-weighted-routing-policy)
+ [

## Record name
](#rrsets-values-weighted-name)
+ [

## Record type
](#rrsets-values-weighted-type)
+ [

## TTL (seconds)
](#rrsets-values-weighted-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-weighted-value)
+ [

## Weight
](#rrsets-values-weighted-weight)
+ [

## Health check
](#rrsets-values-weighted-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-weighted-set-identifier)

## Routing policy
<a name="rrsets-values-weighted-routing-policy"></a>

Select **Weighted**.

## Record name
<a name="rrsets-values-weighted-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of weighted records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-weighted-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of weighted records.

## TTL (seconds)
<a name="rrsets-values-weighted-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

You must specify the same value for **TTL** for all of the records in this group of weighted records.

**Note**  
If you create two or more weighted records that have the same name and type, and you specify different values for **TTL**, Route 53 changes the value of **TTL** for all of the records to the last value that you specified.

If a group of weighted records includes one or more weighted alias records that are routing traffic to an ELB load balancer, we recommend that you specify a TTL of 60 seconds for all of the non-alias weighted records that have the same name and type. Values other than 60 seconds (the TTL for load balancers) will change the effect of the values that you specify for **Weight**.

## Value/Route traffic to
<a name="rrsets-values-weighted-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Weight
<a name="rrsets-values-weighted-weight"></a>

A value that determines the proportion of DNS queries that Route 53 responds to using the current record. Route 53 calculates the sum of the weights for the records that have the same combination of DNS name and type. Route 53 then responds to queries based on the ratio of a resource's weight to the total. 

You can't create non-weighted records that have the same values for **Record name** and **Record type** as weighted records.

Enter an integer between 0 and 255. To disable routing to a resource, set **Weight** to 0. If you set **Weight** to 0 for all of the records in the group, traffic is routed to all resources with equal probability. This ensures that you don't accidentally disable routing for a group of weighted records.

The effect of setting **Weight** to 0 is different when you associate health checks with weighted records. For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).

## Health check
<a name="rrsets-values-weighted-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-weighted-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of weighted records.

# Values specific for weighted alias records
<a name="resource-record-sets-values-weighted-alias"></a>

When you create weighted alias records, you specify the following values. For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-weighted-alias-routing-policy)
+ [

## Record name
](#rrsets-values-weighted-alias-name)
+ [

## Record type
](#rrsets-values-weighted-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-weighted-alias-alias-target)
+ [

## Weight
](#rrsets-values-weighted-alias-weight)
+ [

## Health check
](#rrsets-values-weighted-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-weighted-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-weighted-alias-set-identifier)

## Routing policy
<a name="rrsets-values-weighted-alias-routing-policy"></a>

Choose **Weighted**.

## Record name
<a name="rrsets-values-weighted-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of weighted records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Record type
<a name="rrsets-values-weighted-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

Select the same value for all of the records in the group of weighted records.

## Value/Route traffic to
<a name="rrsets-values-weighted-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Weight
<a name="rrsets-values-weighted-alias-weight"></a>

A value that determines the proportion of DNS queries that Route 53 responds to using the current record. Route 53 calculates the sum of the weights for the records that have the same combination of DNS name and type. Route 53 then responds to queries based on the ratio of a resource's weight to the total. 

You can't create non-weighted records that have the same values for **Record name** and **Record type** as weighted records.

Enter an integer between 0 and 255. To disable routing to a resource, set **Weight** to 0. If you set **Weight** to 0 for all of the records in the group, traffic is routed to all resources with equal probability. This ensures that you don't accidentally disable routing for a group of weighted records.

The effect of setting **Weight** to 0 is different when you associate health checks with weighted records. For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).

## Health check
<a name="rrsets-values-weighted-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-weighted-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate Target Health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate Target Health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-weighted-alias-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of weighted records.