Use CloudFormation to build a Route53 Geolocation routing policy environment

TOC

Use CloudFormation to build a Route53 Geolocation routing policy environment

One of the routing policies provided by Route 53 is Geolocation routing.

Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from.
Geolocation routing

This page introduces a configuration using Geolocation routing for multiple ALBs.

Environment

Prepare identical configurations in the two regions. Specifically, associate an Auto Scaling group with the ALB and create an EC2 instance in that group.

The domain used in this configuration is the one obtained from Route 53 (awstut.net). So we will not configure the HostedZone of the domain.

In this configuration, the ALB will be located in the following two regions.

ap-northeast-1
us-east-1

CloudFormation template files

The above configuration is built with CloudFormation. The CloudFormation templates are placed at the following URL

https://github.com/awstut-an-r/awstut-saa/tree/main/01/007

Explanation of key points of template files

Route 53

Resources:
  RecordSetGroup:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      HostedZoneName: !Sub "${DomainName}."
      RecordSets:
        - AliasTarget:
            DNSName: !Sub "{{resolve:ssm:${SSMParameterALBDNSName1}}}"
            HostedZoneId: !Ref ALBHostedZoneId1
          GeoLocation:
            ContinentCode: AS
          Name: !Ref DomainName
          SetIdentifier: !Ref Region1
          Type: A
        - AliasTarget:
            DNSName: !Sub "{{resolve:ssm:${SSMParameterALBDNSName2}}}"
            HostedZoneId: !Ref ALBHostedZoneId2
          GeoLocation:
            ContinentCode: NA
          Name: !Ref DomainName
          SetIdentifier: !Ref Region2
          Type: A
Code language: YAML (yaml)

Add two records to one domain. Therefore, set the RecordSetGroup for two records.

The following pages summarize the key points in setting up Geolocation routing.

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-geo.html

Particularly key settings will be covered.

The GeoLocation property sets the geographic information. There are three patterns of geographic information.

continental code
country code
U.S. State Code

In this case we will use continental code. Set the first record with “AS” for traffic from Asia. Specify “NA” for the second record, for traffic from North America.

Specify the domain name for the Name property. Specify “awstut.net” for both records.

The SetIdentifier property assigns a unique ID to the record. In this case, specify the name of the region where each VPC was created.

(Reference) Using CloudFormation Stacksets to build ALB and Auto Scaling configurations in 2 regions

To validate Geolocation routing, we will build ALB and EC2 Auto Scaling configurations in two regions. The configuration itself is exactly the same in both regions. This time we will build this configuration with CloudFormation Stacksets.

For basic information about Stacksets, please see the following pages.

The structure of this time is exactly the same as the following page.

The above page shows a configuration to validate Route53 latency-based routing. The configuration within each region’s VPC is exactly the same, although different from this routing policy.

Architecting

Use CloudFormation to build this environment and check its actual behavior.

Create CloudFormation stacks and check the resources in the stacks

Create CloudFormation stacks. For information on how to create stacks and check each stack, please see the following page.

Note that in this configuration, we will create an IAM role with a name. So we will create a stack with the following command.

$ aws cloudformation create-stack \
--stack-name [stack-name] \
--template-url https://[template-path]/soa-01-007.yaml \
--capabilities CAPABILITY_NAMED_IAM
Code language: Bash (bash)

After reviewing the resources in each stack, information on the main resources created in this case is as follows

ALBのDNS名1：saa-01-007-ALB-2006865402.ap-northeast-1.elb.amazonaws.com
ALBのDNS名2：saa-01-007-ALB-1792436665.us-east-1.elb.amazonaws.com
SSM Parameter Storeパラメータ1：saa-01-007-alb-dns-name-ap-northeast-1
SSM Parameter Storeパラメータ2：saa-01-007-alb-dns-name-us-east-1

Check the created resource from the AWS Management Console.

Check the two ALBs.

One ALB has been created in each of the two regions. This means that CloudFormation StackSets has created a uniform and identical configuration in the two regions.

Check SSM Parameter Store.

The DNS name of the ALB is stored in the two parameter stores. If we look at the updated user, it is a Lambda function. This means that these parameters were updated by the Lambda function associated with the CloudFormation custom resource.

Check Route 53.

There are several records set up for the domain “awstut.net”. If we look at the Routing Policy column, we see two lines for “Geolocation”. If we look at where the traffic is routed to, we see that it is the DNS name of the ALB. The first line is a record for access from Asia and the second line is for access from North America.

Operation Check

Now that we are ready, we can actually check the behavior.

First, access the DNS name of each ALB.

$ curl http://saa-01-007-ALB-2006865402.ap-northeast-1.elb.amazonaws.com
instance-id: i-026833c9117843b43

$ curl http://saa-01-007-ALB-1792436665.us-east-1.elb.amazonaws.com
instance-id: i-0e377907b1bf24e15
Code language: Bash (bash)

The IDs of the EC2 instances under each ALB are returned. Both ALBs are working properly.

Access by domain name from CloudShell in the ap-northeast-1 region.

You can see that you are accessing the ALB on the ap-northeast-1 side. This means that it was routed to the ap-northeast-1 side, not us-east-1, using the geographic information from the source.

Next, access it by domain name from CloudShell in the us-east-1 region.

We can see that we are accessing the ALB on the us-east-1 side. Similar to the previous example, this means that the source geographic information was used to route to the us-east-1 side.

Finally, access it by domain name from CloudShell in the eu-central-1 region.

Access failed.

This is due to the location information routing specification.

You can create a default record that handles both queries from IP addresses that aren’t mapped to any location and queries that come from locations that you haven’t created geolocation records for. If you don’t create a default record, Route 53 returns a “no answer” response for queries from those locations.
Geolocation routing

For your information, here is how to create a default resource record.

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. When you configure the default location, set the country code to an asterisk “*”.
Values specific for geolocation records

Summary

Route53 location-based routing was introduced.