AWS CloudFormation is a technology which allows automated software installation in all AWS regions.

AWS CloudFormation requires a unique AMI identifier to pick the appropriate AMI. AWS is using however different AMI identifiers for the same content in all regions. A developer who wants the script to work in all regions world wide has to lookup all AMI identifiers for all regions.

The script below automates this task. It takes the AMI name as a parameter. It'll then print the output in a json format of a CloudFormation mapping.

Example

Excute the script as: 

$ ./getAMIs.sh suse-sles-12-sp3-byos-v20180104-hvm-ssd-x86_64

The result will be:

Will search for AMIs with name: suse-sles-12-sp3-byos-v20180104-hvm-ssd-x86_64
---------------------------------------
"eu-north-1"	: {"HVM64": "NOT_SUPPORTED" },
"ap-south-1"	: {"HVM64": "ami-0f227660" },
"eu-west-3"	: {"HVM64": "ami-5212a52f" },
"eu-west-2"	: {"HVM64": "ami-c5ccd4a1" },
"eu-west-1"	: {"HVM64": "ami-2aae3953" },
"ap-northeast-3"	: {"HVM64": "ami-4c040a31" },
"ap-northeast-2"	: {"HVM64": "ami-15ff5f7b" },
"ap-northeast-1"	: {"HVM64": "ami-caf26eac" },
"sa-east-1"	: {"HVM64": "ami-aea7e4c2" },
"ca-central-1"	: {"HVM64": "ami-4ed85d2a" },
"ap-southeast-1"	: {"HVM64": "ami-eb6f1997" },
"ap-southeast-2"	: {"HVM64": "ami-b7ec1ed5" },
"eu-central-1"	: {"HVM64": "ami-c40696ab" },
"us-east-1"	: {"HVM64": "ami-be2b7ac4" },
"us-east-2"	: {"HVM64": "ami-8fefc4ea" },
"us-west-1"	: {"HVM64": "ami-a34747c3" },
"us-west-2"	: {"HVM64": "ami-36aa004e" },

Use this output to create a CloudFormation mapping like:

"AWSRegionArch2AMI" : {
    "eu-north-1"     : {"HVM64": "NOT_SUPPORTED"},
    "ap-south-1"     : {"HVM64": "ami-0f227660" },
    "eu-west-3"      : {"HVM64": "ami-5212a52f" },
    "eu-west-2"      : {"HVM64": "ami-c5ccd4a1" },
    "eu-west-1"      : {"HVM64": "ami-2aae3953" },
    "ap-northeast-3" : {"HVM64": "ami-4c040a31" },
    "ap-northeast-2" : {"HVM64": "ami-15ff5f7b" },
    "ap-northeast-1" : {"HVM64": "ami-caf26eac" },
    "sa-east-1"      : {"HVM64": "ami-aea7e4c2" },
    "ca-central-1"   : {"HVM64": "ami-4ed85d2a" },
    "ap-southeast-1" : {"HVM64": "ami-eb6f1997" },
    "ap-southeast-2" : {"HVM64": "ami-b7ec1ed5" },
    "eu-central-1"   : {"HVM64": "ami-c40696ab" },
    "us-east-1"      : {"HVM64": "ami-be2b7ac4" },
    "us-east-2"      : {"HVM64": "ami-8fefc4ea" },
    "us-west-1"      : {"HVM64": "ami-a34747c3" },
    "us-west-2"      : {"HVM64": "ami-36aa004e" }
    }

Important: remove the colon at the last printed line. A short coming of the current script...

The Script

Create a file with a name (like getAMIs.sh):

#!/bin/bash
# This script takes a a parameter which needs to be a name of an AWS AMI
# The string will have to identify the AMI uniquely in all regions.
# The script will then identify the AMI identifier in all common regions (but China)
# The script will generate an output which can be copied into json files of AWS CloudFormation
#
# The script has been tested on Mac OS only
# The script uses the AWS command line tools.
# The AWS command line tools have to have a default profile with the permission to
# describe a region and to describe an image

# The script can be run with normal OS user privileges.
# The script is not supposed to modify anything.
# There is no warranty. Please check the script upfront. You will use it on your own risk
# String to be used when no AMI is available in region
NOAMI="NOT_SUPPORTED"
# Change your aws prfile if needed here:
PROFILE=" --profile default"
# Check whether AWS CLI is installed and in search path
if ! aws_loc="$(type -p "aws")" || [ -z "$aws_loc" ]; then
echo "Error: Script requeres AWS CLI . Install it and retry"
exit 1
fi
# Check whether parameter has been provided
if [ -z "$1" ]
then
NAME=suse-sles-12-sp3-byos-v20180104-hvm-ssd-x86_64
echo "No parameter provided."
else
NAME=$1
fi
echo "Will search for AMIs with name: ${NAME}"
echo "---------------------------------------"
##NAME=suse-sles-12-sp3-byos-v20180104-hvm-ssd-x86_64
R=$(aws ec2 describe-regions --query "Regions[].{Name:RegionName}" --output text ${PROFILE})
for i in $R; do
AMI=`aws ec2 describe-images --output text --region $i --filters "Name=name,Values=${NAME}" ${PROFILE} | awk -F"\t" '{ print $7;}'i`
if [ -z "$AMI" ]
then
AMI=$NOAMI
fi
echo "\"${i}\" : {\"HVM64\": \"${AMI}\" },"
done

The script uses a variable PROFILE which is set to default. Change this variable setting if you need to use a different AWS configuration

The script isn't perfect. Please help improving it. Please post updates as comments to this page if you enhanced it.

Context needed...

This script assumes

• that the AWS CLI is installed on the system.
• that the AWS CLI is configured with a default profile on the system. The user of the default profile will have to have the rights to execute the describe statements.
• that the AMI name provided is an exact match of the name. It will print "NOT_SUPPORTED" entries otherwise
• that it can reach the Internet...

Disclaimer: This page and this website are not owned or controlled by Amazon or AWS!

Architecture

See as well: The AWS Manufacturing Reference Architecture

Other resources

• Check out the German language blog about this demonstration!

Most users will have to transfer installation media to the targeted EC systems. Copying data to a Bastian host or a jum start server is the straight forward approach. AWS acually allows to simplify this transfer with the help of S3. The idea is

• Copy installation media to a (private) S3 bucket
• Download media to the target systems for the installations

S3 will store the installation media savely for a future use. S3 costs are relatively low. Delete the S3 files after you don't need them anymore. This will help to keep costs at a minimum.

The AWS IAM (Identity and access management) will help you to keep your data private. This requires a few extra steps.

1. Create a S3 Bucket to store your Installation Media

S3 buckets are world wide uniformly accessible. Make sure that you store your media files in the region you work. This saves costs and it expedites the data transfer.

1. Become a user with administration rights in your AWS console
2. Go to the S3 screen
   1. Select "Services" (upper left corner)
   2. Look or search for "S3" and click on this button
3. Pick "Buckets" in the left column (most likely already being shown)
4. Pick "Create bucket"
   1. Choose a name (This name will be unique, world wide across AWS!)
   2. Pick the region in which you work (a remote region will create a bit of costs, increase access latency and it may put your data under a different legislation)
   3. Do not pick any other option. The default setting will create a user private bucket. The costs will be OK. Access speed will be OK as well. All options, but the region can be changed later on.
   4. Consider to create some subfolders in your bucket. It's straight forward...

Test the entire setup. The AWS console allows you to up and download files as well

• Use the console to upload a file to a bucket.
• Try accessing the file through it''s URL. This shouldn't work.
• Use the download option to download it again

Background information: You have the authority of the user with whom you logged into the console to perform these operations.

2. Uploading your Media Files

There are a number of options:

• The AWS console. See above
• There are S3 tools out there. Search for them. You will have to provide these tools with a public and a secret user key in order to authenticate the AWS users.
• Use the AWS CLI (Command Line Interface). You will have to provide these tools with a public and a secret user key in order to authenticate the AWS users.
  • The AWS CLI needs to be installed on on-premises systems manually.
  • Most Linux and Windows AMIs have it preinstalled. Check your EC2 system and install it manually if needed.

3. Downloading the Media Files to the EC2 Systems

Downloads within a region are very fast. We will use the AWS CLI which is preinstalled on most AMIs. Download it here if it is not installed. The EC system will need access to an S3 end point. This is given as long as the system has Internet and DNS access (very common). A in VPC S3 end point is an alternative (unlikely in a new setup).

The AWS CLI allows for save and secure resource access in AWS. The work we will have to do is:

• Create an access policy which allows to work with one given S3 bucket.
• Attach the policy to a role
• Attach the role to the instance.

This will allow any user on the EC2 instance to access the S3 bucket without any extra authenticaten. No IAM user will have to leave the individual credentials on the machine. User on the machine can allow perform a well defined scope of actions.

3.1 Creation of a Bucket Access Policy

Perform the following steps on the AWS console

1. Select Services (upper left corner in window)
2. Search for "IAM", select it.
3. Pick "Policies" from the left column
4. Push "Create Policy" button
5. Select tabulator "JSON"
6. Replace content with the following content:

{ 
   "Version":"2012-10-17",
   "Statement":[ { 
         "Effect":"Allow",
         "Action":[ "s3:ListAllMyBuckets" ],
         "Resource":"arn:aws:s3:::*"
       }, 
       { "Effect":"Allow",
         "Action":[ "s3:ListBucket", "s3:GetBucketLocation" ],
         "Resource":"arn:aws:s3:::examplebucket"
       }, 
       { "Effect":"Allow", 
         "Action":[ "s3:PutObject",
                    "s3:PutObjectAcl",
                    "s3:GetObject",
                    "s3:GetObjectAcl",
                    "s3:DeleteObject" 
                 ], 
                 "Resource":"arn:aws:s3:::examplebucket/*" 
      } 
    ] 
 }

Replace the string examplebucket with your individual bucket name. Give it a name. For example "mediaaccess". Save everything.

3.2 Create a Role for EC2 Systems

It'll take a role which we associate with the EC2 systems which need to access the bucket with the installation media.

1. Use the console. Use "Services" in the upper left corner
2. Search for "IAM" and select it
3. Select "Roles" in the left column
4. Push "Create Role"
5. "AWS service" with EC2 is high lighted
6. Click on "Nect: Permissions" in the lower right corner
7. Enter the name of your policy ("mediaaccess") in the search field.
8. Mark the policy and click on "Nect: Tags"
9. Optional: Add a tag
10. Click on "Next: Review"in the lower right corner
11. Provide a Role name and a description
12. Click on "Create Role" in the lower right corner

3.3 Associate the Role with all relevant Instances

The EC2 inszances need to be enabled to act with this role

1. Use the console. "Use "Services" in the upper left corner
2. Search for "EC2" and select it
3. View all instances
4. Pick your instance
5. Select "Actions" -> "Instance Settings" -> "Attach/Replace IAM Role"
6. Select your role in "IAM role"
7. Click on "Apply"

There may be two different situations:

• You create a new instance: Consider to assign the IAM role when you create the instance
• Your instance already has a role: Consider to add the policy to the existing role.

4. Downloading media on your Instance

Your instance now has the right to access this bucket without having to add a local user!

Do not add user credentials with "aws configure"!

Run "aws configure" and add the region to be used only. This may have to be done for every Linux user who wants to download media.

You can now download a file install.zip from the bucket examplebucket your media with a command like

$ aws s3 cp s3://examplebucket/install.zip install.zip

The aws s3 sync command is very useful as well. It acts similary to the Linux rsync command.

This concept is based on the fact that multiple EC2 instances are reachable through their standard network interface (eth0) and an additional IP address that is used to provide the high available service. The high available service IP address has to belong to a different subnet. This IP address gets modeled with an AWS Elastic Network Interface (ENI). The ENI gets detached from an EC2 instance when the instance fails, it gets then attached to the EC2 instance which is supposed to take a service over.

The Elastic Network Interface with the name eni-x is currently attached to instance i-a and it can be attached on demand to instance i-b. The highly available service is provided through subnet A. The two service providing instances i-a and i-b can be reached through subnet B with their standard network interfaces (eth0). This architecture requires at least two subnets: A service provider subnet (here A) A subnet which allows access to the normal (eth0) interfaces of the two instances (here B) It takes the following steps to make such a failover scenario work Create and configure an ENI Enable the Linux instances to accept traffic and to send traffic back through the dynamically attached ENI Create policies for the two instances to allow them pull over the dynamic IP address Execute the appropriate AWS commands to detach and reattach the ENI

Create and configure an Elastic Network Interface (ENI)

Prerequisites to create an Elastic Network Interface are to have the following information:

• Name of the AWS subnet in which the IP address fits
• IP addresses which matches the CIDR of the AWS subnet
• A security group for the ENI, which allows the required service, protocols to pass. The allowed protocols to pass are typically a subset of the protocols one would use for the primary interface in a non-high-available configuration.

The creation can be done manually using the AWS console. You have to choose the EC2 console. Select the entry “Network Interfaces” in the left column. Click on “Create Network Interface” and you’ll see a dialog that looks like the one to the left.

Enter the required information. The ENI will be created. It’ll have a unique AWS-identifier in the form eni-XYZ,

The alternative is to use the command line with the AWS-CLI tools . The equivalent AWS-CLI command is:

create-network-interface --subnet-id <value>[--description <value>] [--private-ip-address <value>]

Network Configuration for the Linux Instances

Linux instances have to learn that they have to return the network traffic through the new network interface (eth1) once it is attached. It takes a number of instance specific routing changes once the interface gets attached. It’s important to undo these routing changes after the secondary network interface (eth1) gets detached.

The scripts below work for SLES 11 SP3 instances other Linux distributions will need the routing entries to be performed in different network configuration scripts.

/etc/sysconfig/network/scripts/ifup.local.eth1

The script below needs to be adopted by replacing the two following variables, which are printed in bold letters

• DEFAULT-SUBNET-CIDR: This would be 10.1.0.0/8 according to the network diagram above
• DEFAULT-ROUTER: The default router for the default subnet. This would be 10.1.0.1 for the network diagram from above:

#!/bin/bash
if [ "$1" = 'eth1' ]
then
ip route flush table MYHA
ip rule add from DEFAULT-SUBNET-CIDR table MYHA priority 100
ip route add default via DEFAULT-ROUTER dev eth1 table MYHA
fi

This script needs to be executable. A root user will have to perform this command to achieve this:

chmod +x /etc/sysconfig/network/scripts/ifup.local.eth1

/etc/sysconfig/network/scripts/ifdown.local.eth1

The script below needs to be adopted a replacing the variable shown in bold letters

• DEFAULT-SUBNET-CIDR: This would be 10.1.0.0/8 according to the network diagram above

#!/bin/bash
if [ "$1" = 'eth1' ]
        then
        ip route flush table MYHA
        ip rule del from DEFAULT-SUBNET-CIDR table MYHA priority 100 fi

This script needs to be executable. A root user will have to perform this command to achieve this:

chmod +x /etc/sysconfig/network/scripts/ifdown.local.eth1

Linking the Scripts to the right Directories

The scripts above need to be found by the help of soft links which have to be created by a root user the following way:

cd /etc/sysconfig/network/if-down.d
ln –s ../scripts/ifdown.local.eth1 ifdown.local.eth1
cd /etc/sysconfig/network/if-up.d
ln –s ../scripts/ifup.local.eth1 ifup.local.eth1

Adding an additional Routing Table

The scripts from this section will need an additional routing table. This table can be declared with the following command getting executed by a root user:

echo "100 MYHA" >> /etc/iproute2/rt_tables

Policies needed to Detach and Attach ENIs to EC2 Instances

It’s common that two highly available nodes monitor the other one and take action when the monitored node fails. It takes the following policy to enable a node to perform the required AWS configuration change. Attach this policy to all nodes which are supposed to change the network configuration:

{ 
  "Statement": [
      {
       "Sid": "Stmt1346888659253", 
       "Action": [
           "ec2:AttachNetworkInterface",
           "ec2:DescribeInstances",
           "ec2:DescribeInstanceStatus",
           "ec2:DescribeNetworkInterfaces",
           "ec2:DetachNetworkInterface",
           "ec2:DescribeNetworkInterfaceAttribute",
         ], 
         "Effect": "Allow",
         "Resource": [ 
             "*" 
         ] 
      } 
    ] 
}

Scripts to detach and reattach an ENI

The script getInterface.sh below is an example of how the AWS-CLI can be used to dynamically attach an Elastic Network Interface. It requires the dynamic IP to be entered as first command line parameter. The second command line parameter is the primary IP address of the system, which will then host the dynamic address.

The script

1. Identifies the name of the ENI by using it’s IP address
2. it determines the EC2 instance from which the ENI needs to be detached
3. it detaches the ENI
4. it waits until the operation has completed
5. it attaches the ENI to the second system once it’s available

#!/bin/bash
# This scripts detaches as secondary interface from an instance.
# It then attaches the interface to the instance where it has been executed
# 
# Command line parameter
#=======================
# First parameter: IP address which needs to be detached and moved to a
# different instance 
echo "Move IP adress: $1 to system with primary IP address $2" 
INTERFACE=`ec2-describe-network-interfaces | grep $1 | \
awk /NETWORKINTERFACE/'{print $2 }'` 
TONODE=`curl -silent http://169.254.169.254/latest/meta-data/instance-id` 
echo "move eni: $INTERFACE to instance id: $TONODE " 
DETACH=`aws ec2 describe-network-interfaces --network-interface-ids $INTERFACE | \
awk /ATTACHMENT/'{print $3 }'` INTERFACESTATUS=`aws ec2 describe-network-interfaces --network-interface-ids $INTERFACE | \
awk -F"\t" /NETWORKINTERFACE/'{print $10 }'`
echo "$DETACH to be detached. Current interface status is $INTERFACESTATUS"
aws ec2 detach-network-interface --attachment-id $DETACH --force
echo "Command to detach Interface $INTERFACE submitted"
while [ "$INTERFACESTATUS" = 'in-use' ]
do
 echo "Will sleep 1 second"
 sleep 1
 INTERFACESTATUS=`aws ec2 describe-network-interfaces --network-interface-ids $INTERFACE | \
 awk -F"\t" /NETWORKINTERFACE/'{print $10 }'`
Done
echo "Will attach interface $INTERFACE to $TONODE "
aws ec2 attach-network-interface --instance-id $TONODE --network-interface-id $INTERFACE

 More Resources

• AWS article: Leveraging Multiple IP Addresses for Virtual IP Address Fail-over in 6 Simple Steps

 AWS networking allows creating routing entries for routing tables, which direct all traffic for an IP address to an EC2 instance. This concept allows directing the traffic to any instance in a Virtual Private Network (VPC) no matter which subnet it is in and no matter which availability zone (AZ) it is in. Changing this routing entry for the subnets in a given VPC allows redirecting traffic when needed. This concept is known as “IP Overlay” routing in AWS. It is normally being used in a static way for routers and Network Address Translation (NAT) instances. Overlay IP routing can however be used in a dynamic fashion.

The diagram in Figure X shows a network topology in which this concept can get used. Two instances named node1 (EC2 instance i-a) and node2 (EC2 instance i-b) are connected to two different subnets. The two subnets are assigned to the same VPC in two different Availability Zones (AZ). It is not mandatory that both nodes are located in different availalibility zones and subnets, it’s however desirable in many cases. Failover nodes in high availability architectures should be independent of common failure root causes. Both nodes are part of the same Virtual Private Network (VPC). Both subnets share the same routing table named rtb_A.

The idea is to route traffic from on premises consumers or consumers from within the VPC to the IP address 10.2.0.1 in this case. It’s important that the IP address is outside of the Classless Inter-Domain Routing (CIDR) block of the VPC.

It takes 4 steps to route traffic through an Overlay IP address to EC2 node1 or node2

1. Create a routing entry in the routing table which sends the traffic to the EC2 instance in question
2.  Disable the source/destination check for the network traffic to the two instances in the EC2 network management. The AWS network doesn’t by default send network packets to instances which don’t match the normal routing entries
3. Enable the operating system of the EC2 instances to accept these packets
4. The two EC2 instances are likely to monitor each other. They are likely to initiate the routing change when needed. The EC2 instances require policies in the IAM roles which authorize them make these changes in the routing table

Creating and managing the routing Entries

The AWS command line interface (AWS-CLI) allows creating such a route with the command:

aws ec2 create-route --route-table-id ROUTE_TABLE --destination-cidr-block CIDR --instance-id INSTANCE

Where as ROUTE_TABLE is the identifier of the routing table which needs to me modified. CIDR is an IP address with the filter. INSTANCE is the node to which the traffic gets directed.

Once the route exists it can be changed whenever traffic is supposed to be routed to a different node with the command:

aws ec2 replace-route --route-table-id ROUTE_TABLE --destination-cidr-block CIDR --instance-id INSTANCE

There are chances if there is a need to delete such a route entry. This happens with the command:

aws ec2 delete-route --route-table-id ROUTE_TABLE --destination-cidr-block CIDR 

It may be as well important to check for the current status of the routing table. A routing table can be checked with this command:

aws ec2 describe-route-tables --route-table-ids ROUTE_TABLE

The output will list all routing entries. The user will have to filter out the line with the CIDR in question.

Disable the Source/Destination Check for the Failover Instances

The source/destination check can be disabled through the EC2 console. It takes the execution of the following pull down menu in the console for both EC2 instances (see left). The same operation can be performed through scripts using the AWS command line interface (AWS-CLI). The following command needs to be executed one time for both instances, which are supposed to receive traffic from the Overlay IP address:

 ec2-modify-instance-attribute EC2-INSTANCE --source-dest-check false

The system on which this command gets executed needs temporarily a role with the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1424870324000",
      "Effect": "Allow",
      "Action": [ "ec2:ModifyInstanceAttribute"],
      "Resource": [
       "arn:aws:ec2:REGION:ACCOUNT-ID:instance/INSTANCE-A",
       "arn:aws:ec2:REGION:ACCOUNT-ID:instance/INSTANCE-B"
      ]
    }
  ]
}

Replace the individual parameters (bold letters) for the region, the account identifier and the two identifiers for the EC2 instances with the placeholders in bold letters.

Configure the Network Interfaces to receive the Network Traffic of the Overlay IP Address

Linux systems need the overlay IP addresses to be configured as secondary IP address on their standard interface eth0. This can be achieved by the command:

ip address add OVERLAY-IPD/CIDR dev eth0:1

The tools to make the secondary IP address permanent vary across the Linux distributions. Please use the individual documentation to lookup the commands.

Enable the Instances to change the Routes

Switching routes from node to node typically happens in failover cluster. Failover clusters with two nodes monitor each other and take action when the other node doesn’t seem to be alive anymore. The following policy has to be applied to the EC2 instances, which are supposed to monitor each other and be allowed to switch the route when needed:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1424870324000",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceAttribute",
                "ec2:DescribeTags"
             ],
            "Resource": "*"
        },
        {
            "Sid": "Stmt1424860166260",
            "Action": [
                "ec2:CreateRoute",
                "ec2:DeleteRoute",
                "ec2:DescribeRouteTables",
                "ec2:ReplaceRoute"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:ec2:region-name:account-id:route-table/rtb-XYZ"
       } 
     ]
}

Replace the following variables with the appropriate names:

• region-name : the name of the AWS region
• account-id : The name of the AWS account in which the policy is getting used
• rtb-XYZ : The identifier of the routing table which needs to be updated

Enable your VPC to work with Route53. Skip this step if you already use Route53.

The AWS Command Line Interface (CLI) allows to list all VPCs with the following command:

aws ec2 describe-vpcs

.

The following commands will make the instances in your VPC use the domain name entries from Route53. This is most likely required since some of the consumers may be part of the VPC. Use the AWS console. Move to the VPC screen. Make a right mouse click above the VPC which you plan to enable. Select "Edit DNS Resolution"

It will then show a modal dialog in which you will have to click on "Yes" and "Save"

The AWS Command Line Interface (CLI) allows to perform this operation though the following command:

aws ec2 modify-vpc-attribute --vpc-id <value> --enable-dns-support

The next step happens as well through the AWS VPC console. Hover the mouse above your VPC. Make a mouse right click. Select ""

It will show a modal dialog. Select "Yes" and Save your data entry.

The AWS CLI allows to perform this operation though the following command:

aws ec2 modify-vpc-attribute --vpc-id <value> --enable-dns-hostnames

Important: Note down the name of your VPC or tag it. The name will be needed later on.

Creation of the Route53 Hosted Zone (The Domain Name Server)

Use the AWS console. Move to the Route53 screen. Click on the Create Hosted Zone button. You will see a dialog like the following one:

The failover can be execute by changing the IP address for a given host name. This means a A record has to be introducted or modified.

This can be done through a CLI command. The information required is:

• Route53 hosted zone id: for example HOSTED-ZONE-ID
• name of entry: for example myservice
• IP address for entry: for example 10.79.252.13 
• domain name: for example myvpc.mycompany.com
• Time to life (TTL): for example 10s 

Prework

Find your hosted zone through using the AWS console or the AWS CLI command:

aws route53 list-hosted-zones

Create a file like change-resource-record-sets.json:

{
    "Comment": "Update record to reflect new IP address for a system ",
    "Changes": [
        {
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "myservice.myvpc.mycompany.com",
                "Type": "A",
                "TTL": 10,
                "ResourceRecords": [
                    {
                        "Value": "10.79.252.13"
                    }
                ]
            }
        }
    ]
}

Replace the string myservice.myvpc.mycompany.com with the host name and the domain which matches your requirements.

Replace 10.79.252.13 with the IP address where your service is being provided.

Changing the A record in Route53

Use the following AWS CLI command to implement the change:

aws route53 change-resource-record-sets --hosted-zone-id HOSTED-ZONE-ID --change-batch file:///mypath/change-resource-record-sets.json

Replace HOSTED-ZONE-ID with the identifier for your hosted zone. Pick the correct path to your json configuration file.

This command can be used to create an A record initially. It will work as well if the record already exists. It will then update the IP address and the TTL value.

The command will return a transaction Id which should be caught...

Checking Progess of the Update

The Route53 update takes as while (~20s). The successfull completion of the transaction can be checked with the following command:

aws route53 get-change --id <value>

The result will provide a status field which is PENDING or INSYNC.

We assume here that an on-premises intranet user wants to use a service in the AWS cloud. The service has been made highly available by two services. A high availability service will point to the active and available service by changing the IP address in the Route53 naming service.

This page explains what needs to be done to allow on-premises service consumers to get an IP address from am Route53 service. Customers who implemented Microsoft Active Directory will have to follow this blog post. The remainder of this page will deal with DNS implementations.

The problem is, that Route53 is serving only EC2 instances in a VPC. It not exposing it's service back over the VPN tunnel to the intranet.

The solution for this problem are DNS forwarders called "bind forwarders". This page explains how to create such a bind forwarder. Users will actually want to create two bind forwarders in two different availability zones to avoid a single point of failure.

The final architecture will look as follows:

We will create two bind forwarders in two AWS Availabilty Zones. Corporate clients will submit their queries to the corporate DNS server. The corporate DNS server will then relay the requests to the bind forwarders. The bind forwarders will query Route53 for the final resolution. We assume the the VPC will operate in a separate subdomain of the intranet. This will simply the routing for the corporate DNS server. The diagram to the left shows how two application servers register or deregister themselves in Route53 win step 1 and 2. Step 3 to 5 shows how the name resolution request will be pulled from Route53. This page describes how a bind forwarder can be configured. We assume that the we have the following network topology: Intranet IP range: 10.0.0.0/8 Intranet domain: mycompany.corp AWS VPC IP range: 10.78.0.0/16 AWS VPC domainname: awslab.mycompany.corp IP address bind forwarder 1: 10.79.7.17 IP address bind forwarder 2: 10.79.8.17 Route53 IP address: 10.79.0.2 AWS regions: us-east-1

Creation of EC2 Instances

Create two EC instances. The T2 instance type is likely to be sufficient:

• Pick the two IP addresses from above. It'll be important that the subnets are located in different Availability Zones
• Pick Amazon Linux
• Use Security Groups with the following inbound settings
  • ssh, tcp, port 22 open to 10.0.0.0/8
  • DNS(UDP), port 53 open to 10.0.0.0/8
  • DNS(TCP), port 53 open to 10.0.0.0/8
• Use a certificate
• Disk requirements minimal

Configuration of the named Service

The named service is providing the task we need.

Login a ec2-user to the instance and execute the following commands:

sudo yum install bind

Install the packages required for the named services.

Create the file /etc/named.conf. You may use the vi editor:

sudo vi /etc/named.conf

replace the content of this file with this content:

acl goodclients {
   10.0.0.0/8;
   localhost;
   localnets;
};

options {
   directory "/var/named";
   version "not currently available";
   allow-query { goodclients; };
   forwarders {10.79.0.2;};
   forward only;
};

logging{
   channel simple_log {
   file "/var/log/named/bind.log" versions 3 size 5m;
   severity warning;
   print-time yes;
   print-severity yes;
   print-category yes;
   };
   category default{
      simple_log;
   };
   category client{
      simple_log;
   };
};

zone "us-east-1.compute.internal" IN {
   type forward;
   forwarders {10.79.0.2;};
};

zone "awslab.mycompany.corp." IN {
   type forward;
   forwarders {10.79.0.2;};
};

Change all network specific values (bold) with the ones which match your configuration.

Create a log File for named Service

sudo mkdir /var/log/named
sudo touch /var/log/named/bind.log
sudo chmod ug+w bind.log

Start the Service

Execute the command:

sudo service named start

Make the service permanent and have it started after a reboot:

sudo chkconfig named on

Perform this setup for both of your EC2 instances.

 The final step is to make your name services in the intranet use the bind forwarders.

The intranet DNS servers will have to forward requests for the awslab subdomain to the two bind forwarders.

Individual clients may add the IP addresses of the bind forwarders to their /etc/resolv.conf file.