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

FAQs

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

FAQs

Documentation

  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  
Security

 IAM FAQ

Cloud HSM FAQ

WAF FAQs

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
 
Autoscaling

Example setup (youtube 11min)

Documentation

    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

FAQs

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      
CloudFormation

FAQs
Documentation

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

FAQs 

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

Architecture

 

Well-Architected Framework (Great appendix)

Security Best Practices

AWS Best Practices for DDoS Resiliency

Disaster Recovery Whitepaper

NAT

Security, Reliability, Performance, Cost optimization  

IAM

 

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  

Kinesis

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

Qwiklabs 

 

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:

MYPROFILE=default
INSTANCE=i-1234567890
REG=us-east-1
echo " I am in locale:" export LC_ALL=en_US.UTF-8
locale
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
locale
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 http://169.254.169.254. 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 169.254.169.254 | 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 = "http://169.254.169.254"
$request = [System.Net.WebRequest]::Create($url)
$request.Method = "HEAD"
$request.Proxy = $null
$response = $request.GetResponse()
$response.Headers.Get("Server")

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 http://169.254.169.254:/latest/dynamic/instance-identity/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
ec296900-a260-8001-9a78-a0c7d06d1f58

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
SerialNumber
ec2f1d85-08d6-62f2-4382f5e8dbdb

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

 

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

 

IP Adress Failover for highly available AWS Services

Abstract

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.

Introduction

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.

/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=`ec2-describe-network-interfaces $INTERFACE | \
awk /ATTACHMENT/'{print $3 }'` INTERFACESTATUS=`ec2-describe-network-interfaces $INTERFACE | \
awk -F"\t" /NETWORKINTERFACE/'{print $10 }'`
echo "$DETACH to be detached. Current interface status is $INTERFACESTATUS"
ec2-detach-network-interface $DETACH --f
echo "Command to detach Interface $INTERFACE submitted"
while [ "$INTERFACESTATUS" = 'in-use' ]
do
 echo "Will sleep 1 second"
 sleep 1
 INTERFACESTATUS=`ec2-describe-network-interfaces $INTERFACE | \
 awk -F"\t" /NETWORKINTERFACE/'{print $10 }'`
Done
echo "Will attach interface $INTERFACE to $TONODE "
ec2-attach-network-interface $INTERFACE -i $TONODE -d

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

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": [
"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": "Stmt1424860166260",
"Action": [
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:DescribeRouteTables",
"ec2:ReplaceRoute"
],
"Effect": "Allow",
"Resource": "*"
}
]
}

 

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

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.

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

 

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.

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

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.