Amazon Web Services (AWS)

AWS Architect Certification (Associate & Professsional)

Associate Certification

Resource Collection

Topic Resources White Papers Technical Terms Qwiklabs
  • EC2
    • Security
ELB: Documentation   Introduction to EC2 Spot Instances: 20 minutes
ELB     sticky session Working with Elastic Load Balancing: 20 minutes
Networking: VPC


VPC landing page

Getting Started Guide(html)

User Guide

Amazon VPC Connectivity Options

End point, gateway, public subnet, subnet, peering, routing, AZ   
Networking: Direct Connect FAQs  

VLAN,  1000BASE-LX, 10GBASE-LR, singlemode fiber, Bidirectional Forwarding Detection, IPsec VPN, Border Gateway Protocol (BGP), Autonomous System Number (ASN)

Storage: EBS EC2 FAQs      
Storage: S3, CloudFront



  Bucket, Origin Access Identity, trusted signer, Cloud Front signed URL  
Storage: Glacier  FAQs   vault lock policy  
Storage: Storage Gateway  FAQs Youtube Introduction video Gateway-VTL, Gateway-Cached Volumes, Gateway-Stored Volumes  
SQS  FAQ (one question)   hidden (after having fetched it), standard queue, FIFO queue, batch, send receive, delete, DeadLetterSourceQueues, Lifecycle, long polls, retention  




Overview of Security Processes

Introduction to AWS Security (High level introduction)

Security Best Practices

AWS Best Practices for DDoS Resiliency

 IDS (Re-Invent pres.), DDos, WAF sandwich Auditing Your Security with AWS Trusted Advisor: 35 minutes
Auditing Changes to Amazon EC2 Security Groups: 37 minutes

Example setup (youtube 11min)


    Maintaining High Availability with Auto Scaling: 50 minutes
Launching Amazon EC2 Spot Instances with Auto Scaling and Amazon CloudWatch: 45 minutes
Database: RDS FAQs    know the DB specific replication technologies RDS is using Administering Amazon RDS for Microsoft SQL Server: 90 minutes
Database: DynamoDB FAQs  

partition key, item, attribute, key-value, composite primary keys, Global Secondary Index, Local Secondary Index (LSI), Projection, Fine-Grained Access Control (FGAC), provisioneds through put, cross-region replication, streams

Working with Amazon DynamoDB:: 25 minutes
Database: Redshift


Cluster Management Guide

 Getting Started Guide (Video, hands on lab etc.) Cluster, Node, Cluster Type, Cluster Parameter Group, WLM (Workload management Configuration)  Working with Redshift: 55 minutes
CloudWatch  FAQs      


Overview of Deployment Options on AWS (Covers as well OpsWork and CodeDeploy Stack, Template, create- cancel- delete- rollback-stack, UserData, AWS:CloudFormation:init, stack updates Creating an Amazon Virtual Private Cloud (VPC) with CloudFormation: 27 minutes
Launching and Managing a Web Application with AWS CloudFormation: 27 minutes
Elastic Beanstalk  FAQs
  ebextensino, leader_only  
Architecure, Availability     RTO, RPO, AZ  
SNS   SNS Mobile Push topic, subscribe, publish  
SWF: Simple Workflow Service Developer Guide    asynchronous, distributed, workflow, activities, domain, activity workers, activity tasks, deciders  
Route 53


Route 53 Developer Guide

  DNS, A (address) record, CNAME (canonical name record), AAAA (IPv6 addres record), Alias record, hosted zone, TTL, WWR (Weighted Round Robin), LBR (Latency Based Routing), Geo DNS, private DNS, health check Introduction to Amazon Route 53: 55 minutes


Professional Certification

AWS landing page: AWS Certified Solutions Architect – Professional

170 minutes: Multiple choice and multiple answer questions

Exam Guide

Sample questions

Recommended trainings

General advice

Resource Collection (for specific Professional Certification Topics)

Topic Resources White Papers Technical Terms Qwiklabs



Well-Architected Framework (Great appendix)

Security Best Practices

AWS Best Practices for DDoS Resiliency

Disaster Recovery Whitepaper


Security, Reliability, Performance, Cost optimization  



Temporary Security Credentials

Cross Account Access Roles 

Cognito, STS, Identity Federation, SSO  

Deployment: CodeDeploy

FAQs   configuration, application, revision, group, Appspec file, lifecycle events, agent Introduction to CodeDeploy: 40 minutes

Deployment: CodePipeline

FAQs   pipeline, revision, stage, artifact, transition, action  

Architecture: CloudFront

FAQs  Developer's Guide edge location, CNAME alias, invalidation requests, price class, geo restriction, RTMP delivery, signed request  

Data Pipeline

FAQs   Documentation activity, precondition, on-premises task runner  


FAQs   Documentation
  • streams,
    • shards
    • data records
    • retention period
    • partition keys
  • firehose,
    • Firehose delivery stream
    • records
    • data producers
  • analytics
    • time-series analytics
    • real-time dashboards
    • real-time metrics
Introduction to Amazon Kinesis Firehose: 30 minutes

Building Real-Time Dashboards with Amazon Kinesis Dynamic Aggregators: 55 minutes



AWS CloudFormation (Resource Collection)

Get AMI Ids for all world wide AWS regions

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.


Excute the script as: 

$ ./ 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

# 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
# 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
# Check whether parameter has been provided
if [ -z "$1" ]
echo "No parameter provided."
echo "Will search for AMIs with name: ${NAME}"
echo "---------------------------------------"
R=$(aws ec2 describe-regions --query "Regions[].{Name:RegionName}" --output text)
for i in $R; do
AMI=`aws ec2 describe-images --output text --region $i --filters "Name=name,Values=${NAME}" | awk -F"\t" '{ print $7;}'i`
if [ -z "$AMI" ]
echo "\"${i}\" : {\"HVM64\": \"${AMI}\" },"

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...


AWS Command Line Interface (CLI): Best Practises

Use an UTF locale when using AWS CLI on Unix/Linux

There are AWS strings which can be coded in Unicode. These are at least EC2 tags and volume tags.

Unix/Linux scripts which will run as super user will most likely run in the C locale.

The C locale is an ASCII 7 bit locale which doesn't support Unicode characters. The Python run time which gets used by the AWS CLI will throw an error message because it can't convert Unicode characters.

The simplest way to avoid this error is to start any script using AWS CLI with a set locale like:

export LC_ALL=en_US.UTF-8

Here is an example on how to reproduce the error:

echo " I am in locale:" export LC_ALL=en_US.UTF-8
echo "*******"
aws ec2 create-tags --profile $MYPROFILE --region $REG --resources $INSTANCE --tags Key=Unicodetest,Value=SchöneScheiße
aws --profile $MYPROFILE ec2 describe-instances --region $REG --instance-ids $INSTANCE
echo "*******" echo " I am in locale:"
export LC_ALL=C
echo "*******"
aws ec2 create-tags --profile $MYPROFILE --region $REG --resources $INSTANCE --tags Key=Unicodetest,Value=SchöneScheiße
aws --profile $MYPROFILE ec2 describe-instances --region $REG --instance-ids $INSTANCE
echo "*******"

The error message looks like:

ascii' codec can't decode byte 0xc3 in position 25: ordinal not in range(128)

This error is annoying since administrators may add Unicode strings in their browser at any point of time. Commands like describe-instance which dump all information about an instance are going to fail.

AWS Platform Identification

Applications may want to know whether they run on the AWS platform or not. There are a number of ways to identify whether your application runs on AWS or not. AWS documents a numbre of them as well.

Disclaimer: The stability of the AWS APIs discussed below varies. Please use the references to the AWS documentation to verify whether the stability of the API is sufficient for your use case. 

EC2 Instance Metadata Service

The hypervisor of any EC instance is providing a range of information which is available to a given EC instance only. The information is provided through a number of web pages which are accessible through The AWS page "Instance MetaData and User Data" provides more details about the information offered through this service. This service is available independent of the AMIs operating system.

This information can be gathered by any process on any platform without increased (means root) privileges.

AWS Specific HTTP Header Fields of the Instance Meta Service

Each http request against a page of this service is answered with a AWS specific signature in the http response header field. The Server field contains the string EC2ws.

This field is platform independent.

Check this Field on a Linux Platform

One way to verify this field is the Linux curl command:

ec2-user@ip-w-x-y-z:~> curl -I | grep Server
Server: EC2ws

This information can be gathered by any process on any platform without increased (means root) privileges.

Check this Field on the Windows Platform

Open a Power Shell Window with adminstrator rights and enter the following command sequence:

$url = ""
$request = [System.Net.WebRequest]::Create($url)
$request.Method = "HEAD"
$request.Proxy = $null
$response = $request.GetResponse()

The last command will display the string EC2ws.

Signed AWS Dynamic Data

Every EC2 instance hosts dynamic instance specific data which got signed by AWS (see AWS Instance MetaData and User Data, section: Dynamic Data Categories).

The document hosts a JSON document which looks similar to this one:

"instanceId" : "i-c495bb93",
"billingProducts" : [ "bp-xxx" ],
"accountId" : "xxx",
"imageId" : "ami-e80xxxx",
"instanceType" : "c3.xlarge",
"kernelId" : "aki-825ea7eb",
"ramdiskId" : null,
"pendingTime" : "2015-02-24T14:38:43Z",
"architecture" : "x86_64",
"region" : "us-east-1",
"version" : "2010-08-31",
"availabilityZone" : "us-east-1c",
"privateIp" : "w.x.y.z",
"devpayProductCodes" : null

The authenticity of this document can be verified through the two documents hosted under

This verification method is operating system independent and it doesn't require a process to have increased access privileges (beyond http access).

AWS BIOS Serial Number

EC2 instances have serial numbers which start with the string ec2

One way to gather this information on a Linux system is the dmidecode command:

ip-w-x-y-z:/home/ec2-user # dmidecode -s system-serial-number

The execution of the dmidecode command requires root privileges for security reasons.

Windows users can gather this information without administrator privileges through the command wmic:

PS C:\> wmic bios get serialnumber

The BIOS UUID field features the same information in upper case letters.

AWS bare Metal and KVM virtualized Instances

AWS fills certain BIOS fields in bare metal and KVM virtualized Instances. These are typically instances which have been released after Oct. 2017.

Linux allows to check the settings with the dmidecode command:

Base Board Information
Manufacturer: Amazon EC2
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: i-0123456789abcdef0
Board is a hosting board
Board is replaceable
Location In Chassis: empty
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 25 bytes
Chassis Information
Manufacturer: Amazon EC2
Type: Rack Mount Chassis
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Amazon EC2
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 1
SKU Number: To be filled by O.E.M


The asset tag in the Base Board Information contains the instance id. It can be read without super user privileges!

The asset tag in the Chassis Information contains Amazon EC2 with identifies the system to be an AWS instance. It can be read without super user privileges!


AWS Region End Points (including China Region)

Various AWS services require end points which differ by region.

The AWS documentation (AWS Regions and Endpoints) describes the end points for all general regions.

AWS documents the end points for the China region in a separate document.

AWS Simple Icons to draw Architecture Diagrams

 AWS simple icons to draw architecture diagrams are available through

Disclaimer: Please verify whether the copyright of the individual templates matches your needs before you publish the diagrams.

AWS Specific Drivers

 Newer AWS instances use specific drivers to boost their network performance.

These drivers are Open-Source. They can be found in github.

Red Hat Bugzilla entry.

AWS Tidbits

Disclaimer: The commands on this page typically require administrator rights and they have the potential to damage your system. Do not use them if you don't understand them!

Prewarming of EBS Volumes

AWS Documentation: Pre-Warming of EBS Volumes

Windows Server 2012R2

C:\>dd if=\\.\drive_letter: of=/dev/null bs=1M --progress

This commands reads all bits from the volume drive_letter. It should be non destructive.

Formatting the drive is another option. It deletes the old content.

C:\>format drive_letter: /p:1”

Link Collection


AWS Well Architected Framework

IP Adress Failover for highly available AWS Services


This documents describes the implementation of high available failover services for applications, which rely on IP address based communication only.
It shows how to configure IP addresses in a Virtual Private Network (VPC), which will route network traffic to a node A or an alternate node B as needed. The document describes how to change the setup of a VPC in case of a failure of node A. The document shows step by step how to automatically assign a service IP address to a standby node B when needed.
The document outlines two different technologies to achieve the same purpose. This allows the implementer to pick the technology that is most suitable for a given infrastructure and the switch over requirements.


High available failover architectures are based on a concept where consumers reach a service provider A through a network connection. The core idea is to reroute the consumer traffic to a standby service B when the initial service A fails to provide a given service.
Amazon Web Services provides many building blocks to achieve the purpose to failover network consumers to a new network service. The following solutions are commonly used, they are however not subject of this document:

This paper focuses on network consumers which need to reach a service through a given, fixed IP address.

The two solutions work for any protocol. Both solutions require that a given network consumer can reconnect to the same IP address if the original service hangs and times out.

Amazon Web Services (AWS) offers two solutions to failover IP addresses, which should be chosen, based on the network and high availability requirements.

The first solution is based on the fact that AWS manages IP addresses as separate build blocks with the name “Elastic Network Interface” (ENI). Such an ENI hosts an IP address and it can be attached and detached on the fly from an EC2 instance. This allows redirecting the traffic to such an IP address by detaching and re-attaching ENIs to EC2 instances. The limitation of this concept is that it is limited to a single availability zone (AZ).

An IP address has to be part of a subnet. And a subnet has to be assigned to a given AZ. Attaching the same ENI to instances in two different AZs isn’t possible since a given IP address can belong to one subnet only.

This limitation may not be important for some high availability solutions. There may be however the need to leverage the key features of availability zones by running failover instances in two different availability zones.

The second solution is overcoming this limitation with Overlay IP addresses. AWS allows creating routing tables in a VPC which route any traffic for an IP address to an instance no matter where it is in the VPC. These IP addresses are called Overlay IP addresses.

The Overlay IP address can route traffic to instances in different availability zones. This comes with the challenge that the Overlay IP address has to be an IP address that isn’t part of the VPC. The general routing rules wouldn’t work otherwise.

On premises network consumers like desktops who try to access such an IP address have to be routed to the AWS VPC knowing that the Overlay IP address is not part of the regular subnet of the VPC. This leads to the extra effort to have to route on premises consumers to the AWS VPC with an additional subnet which isn’t part of the VPC itself.

IP Failover through Reassigning Network Interfaces

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.

ENI address reassignment 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

  1. Create and configure an ENI
  2. Enable the Linux instances to accept traffic and to send traffic back through the dynamically attached ENI
  3. Create policies for the two instances to allow them pull over the dynamic IP address
  4. 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.
Create ENI Interface

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.


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 according to the network diagram above
  • DEFAULT-ROUTER: The default router for the default subnet. This would be for the network diagram from above:
if [ "$1" = 'eth1' ]
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

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


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

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

if [ "$1" = 'eth1' ]
        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": [
         "Effect": "Allow",
         "Resource": [ 

Scripts to detach and reattach an ENI

The script 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
# 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` 
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' ]
 echo "Will sleep 1 second"
 sleep 1
 INTERFACESTATUS=`aws ec2 describe-network-interfaces --network-interface-ids $INTERFACE | \
 awk -F"\t" /NETWORKINTERFACE/'{print $10 }'`
echo "Will attach interface $INTERFACE to $TONODE "
aws ec2 attach-network-interface --instance-id $TONODE --network-interface-id $INTERFACE

 More Resources


IP Failover with Overlay IP Addresses

 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.

diagrams with overlay IP address

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 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

AWS console, change source destination check

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": [

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": [
"Resource": "*"
"Sid": "Stmt1424860166260",
"Action": [
"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

DNS Name Failover for Highly Available AWS Services

Highly available AWS services are supposed to be build covering multiple Availability Zones (AZ). Highly available AWS services with single point of failures (example: traditional, non parallel database) need to implement their single point of failure in each Availability and assure that the state of the services stays syncronized.

The second task is to assure that the backup services becomes available to end consumers in the case of a failure of the primary service.

One way to solve this problem is to reassign a given IP adress to the standby server. AWS currently offers two ways to accomplish this failover. The IP Failover scenarios are described here.

This document focuses on a name based failover in a private VPC with access to an on premises intranet.

Targeted architecures for Route53 Failover

This document describes how to switch the IP address for a given name entry in the AWS specific Domain Naming service Route53. This approach will work for the following architectures:

The solution presented on the following pages will resonate more with DNS users. A similar solution using Active Directory and the Actice Directory Connector is being presented here.

Creation of a Route53 Service in a private VPC

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
Enable DNS Resolution.

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"

Edit DNS Resolutions 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
 Edit DNS Hostnames The next step happens as well through the AWS VPC console. Hover the mouse above your VPC. Make a mouse right click. Select ""
Edit DNS Hostnames 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:

 create hosted zone

We assume that you will want to use this domain name server for intrenet case only. Fill the fields with the following values:

  • Domain Name: Consider to pick a subdomain from your intranet domain. Your intranet domain name server will have to use this server for name resolution for your VPC only
  • Comment: A comment :-)
  • Type: Select Private Hosted Zone for Amazon VPC
  • VPC ID: Enter the VPC-ID from the VPC you plan to associate the hosted zone with

Save everything through using the Create button.

Changing the IP Address for a Host Name Entry in Route53

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 
  • domain name: for example
  • Time to life (TTL): for example 10s 


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": "",
"Type": "A",
"TTL": 10,
"ResourceRecords": [
"Value": ""

Replace the string with the host name and the domain which matches your requirements.

Replace 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.


Propagating the Name Change back to the On-Premises Intranet

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.

AWS now provides the service Route 53 Resolvers for Hybrid Clouds which solves this problem.

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:

Architecture for redundant bind forwarders

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:
  • Intranet domain: mycompany.corp
  • AWS VPC IP range:
  • AWS VPC domainname: awslab.mycompany.corp
    • IP address bind forwarder 1:
    • IP address bind forwarder 2:
    • Route53 IP address:
    • 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
    • DNS(UDP), port 53 open to
    • DNS(TCP), port 53 open to
  • 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 {;

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

   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{
   category client{

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

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

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.



Use the Name Services in the Intranet

 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.