Amazon Web Services (AWS)

Amazon Web Services (AWS)
Stefan Schneider Thu, 04/03/2014 - 12:19

AWS Architect Certification (Associate & Professsional)

AWS Architect Certification (Associate & Professsional)

Associate Certification

Resource Collection

Topic Resources White Papers Technical Terms Qwiklabs


  • Security
    Introduction to EC2 Spot Instances: 20 minutes
ELB ELB: Documentation sticky session, ELB, ALB, NLB, code 504, TCP/IP Level 7, TCP/IP level 4, intelligent routing, Cross Zone Load Balancing, Path Patterns 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


Annoying Facts

S3 Path Styles


1. Virtual hosted-style

Format: name (Reference)

2.  Path-style

support ends September 30, 2020


3. C-Name Method


The  C.Name is an alias for (Reference)

4. s3-Region


some regions only

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



Stefan Schneider Tue, 10/13/2015 - 09:37

AWS CloudFormation (Resource Collection)

AWS CloudFormation (Resource Collection) Stefan Schneider Wed, 02/20/2019 - 10:08

Get AMI Ids for all world wide AWS regions

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
# 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
# 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 ${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" ]
echo "\"${i}\" : {\"HVM64\": \"${AMI}\" },"

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


Stefan Schneider Wed, 02/20/2019 - 10:28

AWS Command Line Interface (CLI): Best Practises

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.

Stefan Schneider Mon, 08/21/2017 - 12:58

AWS Platform Identification

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!


Stefan Schneider Thu, 04/16/2015 - 10:14

AWS Region End Points (including China Region)

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.

Stefan Schneider Wed, 01/27/2016 - 09:42

AWS Simple Icons to draw Architecture Diagrams

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.

Stefan Schneider Tue, 06/17/2014 - 14:42

AWS Specific Drivers

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.

Stefan Schneider Wed, 05/31/2017 - 12:18

AWS Tidbits

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


Stefan Schneider Mon, 06/23/2014 - 08:40

AWS Well Architected Framework

AWS Well Architected Framework Stefan Schneider Fri, 07/05/2019 - 11:15

Getting started with AWS

Getting started with AWS

This is a collection of things which should be done before a first POC (Probe of Concept) or a first deployment can happen. These hints are not sufficient to setup a production and final development environment. Be ready to abandon the entire account to recreate a production account by using the AWS Landing Zone concept.

The goal of this page is to help you to build a save environment which is using a minimum set of AWS features.

Stefan Schneider Thu, 03/26/2020 - 13:45

Machine Monitoring

Machine Monitoring

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


Machine Monitoring demo architecture

See as well: The AWS Manufacturing Reference Architecture

Other resources

holodoctor Thu, 11/17/2022 - 15:32

AWS services used in this demonstration

AWS services used in this demonstration
  • AWS IoT Greengrass V2: Management of the edge software
  • AWS IoT Core: The AWS services to manage the IoT messages
  • AWS IoT Sitewise: Collect, organize, and analyze data from industrial equipment at scale
  • Amazon SNS: Fully managed Pub/Sub service for A2A and A2P messaging
  • AWS Lambda: Run code without thinking about servers or clusters (used to generate a custom SMS and email text)
  • Amazon Managed Grafana: Scalable and secure data visualization for your operational metrics, logs, and traces
  • AWS IoT TwinMaker: Optimize operations by easily creating digital twins of real-world systems
  • Amazon Lookout for Vision: Spot product defects using computer vision to automate quality inspection
  • AWS Systems Manager: Gain operational insights into AWS and on-premises resources (used to managed the Raspberry)
  • Amazon QuickSight A serverless BI service
  • AWS IAM Identity Center (Successor to AWS Single Sign-On): Centrally manage workforce access to multiple AWS accounts and applications
Stefan Schneider Fri, 11/18/2022 - 09:41

About us

About us

We are Partner Solution architects working for AWS.
We work with AWS partners.
This demonstration will be shown at the Re:Invent Builders fair 2022 in Las Vegas. All implementations follow the AWS Manufacturing Reference Architecture. Every service published on this page is however not officially endorsed by AWS. Please contact us, if you plan to go into production with certain components, we work with hardware partners, system integrators and consulting partners which are happy to turn this demonstration into a professional solution.

Stefan Schneider Fri, 11/18/2022 - 17:19

Building this Demonstration

Building this Demonstration

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

Stefan Schneider Tue, 01/17/2023 - 17:13

BOM: Bill of Material (Hardware)

BOM: Bill of Material (Hardware)

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

All measurements in metric units!

Id Number Item Comment
1 4 Plywood 250x350mm (Bottom, Middle board, Upper board, cover of case, 6mm thick beech is very robust. The upper board has to carry quite some load
2 1 Plywood 70x40mm,6mm thick, raiser for the burners Use the leftover from the cut out of the middle board
3 8 wood screws, 3mm x 15mm to fasten the three boards
4 2 Plywood 238mmx110mmx6mm the sides of the cover box
5 2 Plywood 350mmx110mmx6mm the other sides of the cover box
6 1 HB12: Big Powerstation the Stirling engine. Pick self assembly. The two cylinder model is more robust against wind from the side. The flame may not generate enough heat for the HB10 or HB11 in windy trade show halls.
7 1 Raspberry 4 Model B 8GB starte kit The
8 1 Case for DIN rail mount GeekPi sells an enclosure for rail mounting
9 1 Rail for case  (DIN TS35) The rail will need to be shortened
10 1 TRCT500 IR sensor Pack of 3.
11 7 Round head M4 screws 10 or 12mm
  • 2 Raspberry Rail
  • 2 IO Cover
  • 2 HB 12
  • 1 IR sensor enclosure 
12 5 M4 screw nuts
  • 2 Raspberry Rail
  • 2 IO Cover
  • 1 IR sensor enclosure 
13 1 Kit of jumper cables Female-Female ones are required. Lengths required vary in between 10cm and 30cm
14 1 kit, flat band cables to reach the physical location of the Raspberry optical camera
15 1 Raspberry Camera Module 3 Wide wide angle is important here. The autofocus is very helpful. An earlier camera will work as well. They have however a fixed focus which needs to be broken to just for the focus at ~12cm
16 1 MLX90640 Infrared camera, 55 degrees, with sockets to plugs. Soldering required for models without a plug...
17 1 plug fo MLX90640 This plug allows to connect the infrared camera to regular breadboard cables

Disclaimer: This list looks very concise. This is the third revision of the demonstration. The components are known to work. Most components can be replaced by different ones. There are lots of degrees of freedom...

Stefan Schneider Tue, 01/17/2023 - 17:15

Mechanical Design and Layout

Mechanical Design and Layout

The mechanical layout follows a number of requirements:

  • robustness: The demonstration will be taken to customers and trade shows. It needs to be robust
    • It has to fit into hand luaggage
    • No part should be damaged
    • Cable connection have to be robust and protected against accidental damage
  • It has to look a kind of professional, viewers shouldn't be distracted by non relevant parts
  • has to meet the skills of the builder
    • basic wood processing
    • soldering
    • 3D printing
    • plastic processing (grinding, drilling, cutting)

The layout looks as follows:

Overview layout

Stefan Schneider Wed, 01/25/2023 - 13:34

IR Sensor TCRT5000 (RPM Counting)

IR Sensor TCRT5000 (RPM Counting)

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

Wiring plan.

Sensor seen from the back. Electrical pins at the downside. Pins from left to right. The cable colors are arbitrary, pick them as you like. 30cm long female-female cables work out well. The cables get connected directly with the Raspberry pins, no resistors are required.

Pin Meaning Color Comment
1 A0   Not being used
2 D0 Red  
3 GND Brown  
4 VCC Orange  

Placing and Tuning

The sensor has to be placed at about 5mm distance from the flywheel. The flywheel needs a black mark to make the IR sensor to trigger an event.

The TCRT5000 has a potentiometer at the rear side. It allows to calibrate the sensitivity. Turning this potentiometer up to a half turn to the left or right should trigger the events. The TCRT5000 sensor has a LED at the rear side. This sensor will blick with every event when if it is adjusted correctly.

Stefan Schneider Mon, 01/30/2023 - 18:19

Infrared Camera (MLX90640)

Infrared Camera (MLX90640)

We use an infrared camera of the type MLX90460 with a 50mm lens for three purposes:

  • temperature cool cylinder
  • temperature warm cylinder
  • the flame burning

It'll take four components to build this sensor

A Housing for the Sensor (the Rocket)

The camera has to be placed 7 to 10 cm from the flame.

The camera has to have a fixed position in relation to the Stirling engine. The software will have to pick two rectangles out of the image. This is a static software configuration.

The Sensor

The MX90460 with a 50 mm lens It has a 32x24 pixel array. I got it from here.

The connector 3.0V does not get used. The camera gets powered with the VON cable.

Connector to the Camera and extension Cable

The wires to the camera can be directly soldered on. I decided to buy a small plug (4 Pin Dupont female). This cable is 150mm long. This is not long enough to connect it to the Raspberry. I had to put a 300mm long male-female 4 wire extension cable in between. This allows me to change the camera without having to solder. I have to switch colors in the wiring plan to connect to the Raspberry.

The information flow starts from 4 contacts from the camera. I pick it up with with 4Pin Dupont plug. I extend it with a male-female cable. This cable gets connected with the GPIO pins of the Raspberry.

The Wiring Schema

MLX90460 Connector Cable Color (arbitrary) Cable Color (arbitrary) Raspberry Pin GPIO
VIN Red Red 1 3.3V
SDA Blue Orange 3 GPIO 2
SCL Yellow Yellow 5 GPIO 3
GND Black Brown 14 GND
3.0V - - - -


Enable the Operating System

The sensor is using the I2C protocol. It needs to be enabled. Use the interactive "Raspberry Pi Configuration" tool and enable it in the "Interfaces" section. Reboot the Raspberry.

An alternative is to update /boot/config.txt with the following two parameters


The first parameter will do the same as the interactive tool. The second parameter is a safety precaution to avoid bottlenecks on the bus.

Testing the Sensor

The took i2cdetect needs to be installed upfront:

pi@raspberrypi:~ $ sudo apt-get install -y python3-smbus
pi@raspberrypi:~ $ sudo apt-get install -y i2c-tools

Then use the command

pi@raspberrypi:~ $i2cdetect -y 1

It should list a table. The table has to have an entry "33" somewhere. The is the identifier of an MLX90640 sensor on the bus.

Enabling Greengrass V2 to access the Sensor

The Python scripts run as user ggc_user in Greengrass. Use the following command to allow ggc_user to access i2c:

sudo usermod -a -G i2c ggc_user

Enabling the Calibration of the Camera

The camera will be in different positions depending on the physical setup. The Greengrass component will install a a calibration program as well. This calibration will have to be run as root. The calibration program is written in Python3 and it will need a number of Python libraries. Install them with the command:

At this point, the MLX90640 is ready to be read by the Raspberry Pi. However, since the Adafruit library is being used, a few other libraries need to be installed:

pi@raspberrypi:~ $ sudo pip3 install RPI.GPIO adafruit-blinka
pi@raspberrypi:~ $ sudo pip3 install adafruit-circuitpython-mlx90640
pi@raspberrypi:~ $ sudo pip3 install matplotlib


Stefan Schneider Wed, 02/22/2023 - 16:25

Optical Camera (Module 3)

Optical Camera (Module 3)

Cabling is straight forward. The module 3 camera gets connected with a flatland cable. Pass through holes have to be significant larger.

It'll take one change to allow the Greengrass component to access the hardware component.

Execute the following command:

$ sudo usermod -a -G video ggc_user
Stefan Schneider Wed, 04/12/2023 - 09:17

The Base Board

The Base Board

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

Use four boards 350mm x 250mm x 6 mm beech plywood boards. The material is very sturdy, it won't bend quickly.

  • The lower board is the simplest one. It only needs 8 holes for srews to get tied with the two upper boards
  • The middle board has a large cut out which is 20mm smaller than it's size. This empty space will hide all the cables
    • Keep a small board at the middle level. The two burners shouldn't sit lower than 6 mm. Make it large enough to fit underneath the two holes for the burner. You can glue it to be in the right position. You can leave it at the right place. The upper and the lower board will keep it in place through friction.
  • The upper board is the most complex one. It'll have the holes to fix all the objects and it'll need holes for the cables to go through.
    • All components will leave 20mm distance from any boarder. The cover will sit on the upper board. The cover will consist of 10mm walls.
  • The cover:
    • I used birch plywood boards with the sizes
      • 2 boards 350mm x 110mm x 10mm
      • 2 boards 330mm x 110mm x 10mm
    • The 10mm birch plywood panels allow to use 6mm wooden dowels to connect all 4 boards
    • The top cover is the 4th beech plywood board. I nailed it the the side boards
    • The cover board isn't shown at the image below

WIP: The position of the holes will get published at a later point of time. More and more holes are required for the objects which will be documented in future.

Base board

Stefan Schneider Wed, 01/25/2023 - 14:17

The Raspberry

The Raspberry

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

Stefan Schneider Wed, 01/25/2023 - 14:45

Raspberry IO Wiring

Raspberry IO Wiring

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting it, while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

The cable colors are arbitrary. Pick which ever color you want to pick!

Pin GPIO Id Cable Color Connected device Comment
1 3.3V Red 30cm MLX90460 Power Power
2 +5V Orange 30cm TCRT5000 Power Power
3 SDA Blue 30cm MLX90460  
4 +5V Red Raspberry fan Raspberry Cooling
5 SCL Yellow 30cm MLX90460  
6 GND Black Raspberry fan Raspberry Cooling
7 4 Red 30cm TCRT5000 Binary
8 24      
9 GND Brown 30cm TCRT5000 Ground
14 GND Broen 30cm MLX90460 Ground


Stefan Schneider Tue, 01/24/2023 - 13:47

Software Configuration

Software Configuration

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

Stefan Schneider Wed, 02/01/2023 - 17:29

Raspberry Configuration

Raspberry Configuration

WIP: Work in progress: I'm rebuilding the demo setup. I'm documenting while I'm rebuilding. Revisit this page by the end of March 2023 for a complete document

OS Configuration

Use the default OS from from and configure it on a 32GB SD card. Use a version with the desktop software. The Raspberry may need to connect to a new Wifi. It's simpler to do this on the fly with a monitor and a key board.

I'm using:

pi@raspberrypi:~ $ more /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION="11 (bullseye)"

I created a user pi for backward compatibility reasons.

Upgrade to the latest packages

$ sudo apt update
$ sudo apt dist-upgrade
$ sudo apt clean
$ sudo reboot

Prepare GreenGrass V2 installation

Install GGV2 accoring to this installation page.

Allow Greengrass user to access GPIO

Execute the following command to make the ggc_user to be part of the gpis group:

$ sudo adduser ggc_user gpio
Stefan Schneider Wed, 02/01/2023 - 17:31

FAQ: Frequently asked Questions

FAQ: Frequently asked Questions

How do I implement this architecture?

All AWS services are public available. The demonstration has been build using public available tutorials. Everything in the AWS cloud can be generated by scripts or configured through the AWS console

I am a AWS customer or partner and I'm interested in the demos and the services. How can I adopt them?

Get in touch with us. We will help you depending on your business case.

Is this architecture ready for industrial production use?

Yes and no...

Yes: all AWS services all highly available. They are scalable. Security is at a production level. The Greengrass V2 container manages the software on the Raspberry at a production level.

No: The Raspberry, the sensors and the wiring is not a professional level. We recommend to work with AWS partners who have verified Greengrass V2 hardware and carrier grade sensors. This project had no funding. This was the cheapest solution.
The quality of the Python scripts which run on the Raspberry are not at a quality level to use it at production. There is very limited error checking; there is very limited checking for incorrect data; the software has no life cycle. The gathering and filtering of data at the edge device would be different with professional hardware and professional sensors

Can we get access to the Python scripts running in Greengrass V2?

Not as of today (November 2022). The scripts have been derived vom AWS tutorials and Raspberry websites. The sensor libraries are open source raspberry libraries.

AWS does not release the scripts as of today since they did not yet pass the reviews to allow AWS to publish them as Open Source. Such a review would require significant resources in AWS. Please talk to us, we want to share the scripts with the community...

Where can I get such a Stirling machine?

Search for Stirling machines at!
We bought our machines from Böhm. Böhm ships self assembly and assembled Stirling engines world wide. We picked the engines since they are robust enough for heavy usage. The oldest machine which we use has more than 20h of operation. Böhm ships as well spare parts.
... and yes, they are a kind of affordable. Get one as a Christmas present. The eight year old in yourself deservers it.

holodoctor Fri, 11/18/2022 - 09:11

Media transfers to EC instances

Media transfers to EC instances

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:
   "Statement":[ { 
         "Action":[ "s3:ListAllMyBuckets" ],
       { "Effect":"Allow",
         "Action":[ "s3:ListBucket", "s3:GetBucketLocation" ],
       { "Effect":"Allow", 
         "Action":[ "s3:PutObject",

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 from the bucket examplebucket your media with a command like

$ aws s3 cp s3://examplebucket/

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

Stefan Schneider Thu, 03/26/2020 - 14:28

IP Adress Failover for highly available AWS Services

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:

  • AWS Elastic Load Balancers (ELB) in conjunction with AWS Autoscaling allows rerouting traffic to other service providers when needed. AWS Elastic Load Balancers support many other protocols beyond http and https. They may however not work with some proprietary and legacy protocols.
  • Domain Name Service (DNS) failover with AWS Route 53 : This approach allows redirecting network consumers which lookup services by name to get redirected to a different network service provider. This concept works well with software solutions, which use name resolution to reach their service provider. Some legacy applications rely however on a communication through IP addresses only.

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.

Stefan Schneider Wed, 02/17/2016 - 11:04

IP Failover through Reassigning Network Interfaces

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


Stefan Schneider Wed, 02/17/2016 - 11:14

Anonymous (not verified)

Wed, 07/26/2017 - 15:55

Thanks for providing such a great resource of knowledge! I'd like to understand - what is the difference between IP Address failover by the method of attaching/re-attaching an ENI (eth1) versus following the private-IP-reassignment approach in the article here: AWS article: Leveraging Multiple IP Addresses for Virtual IP Address Fail-over in 6 Simple Steps

It seems that using private-IP-address-reassignment would not require changes to the Linux instance network config scripts and be a simpler solution? But are there advantages/limitations to consider between the 2 approaches where a=ENI re-assignment, and b=secondary IP address reassignment?

Many thanks for your input!

Keep in mind that the AWS networking infrastructure needs to know that it will send traffic to a given IP address. I personally prefer "ENI reattach" since the IP address is only once in the routing system. Updating secondary IP addresses may theoretically lead to duplicate IP addresses. I guess it won't matter...

IP Failover with Overlay IP Addresses

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
Stefan Schneider Wed, 02/17/2016 - 11:50

Anonymous (not verified)

Thu, 09/15/2016 - 03:32


First I'd like to say, you blog is fantastic. We've implemented SAPHANASR configuration out lined, and the Overlay IP seems to work fine only when working within AWS. (subnet to subnet)

However, we're having issues directing traffic from our main site over a site to site VPN which leverages the AWS VPN Gateway. Was this part successfully implemented? Anything special had to be done on the main site other that implementing a route to the Overlay IP?

I'm asking to know if this is an issue on our side?



overlay IP addresses can be reached from inside the VPN only.
You will want to run your users like application servers inside the VPN.
You will need a proxy like an ELB/ALB or a SAP GUI router if you want to reach the Overlay IP address from outside of the VPC.

Hi Stefan,

Thanks for a wonderful explanation.However i am not still able to understand how ELN/ALB will help n forwarding the traffic to the Overlay IP address.Since ELB has no understanding of the OverlayIP address which is plumbed inside the instance and no where mapped in the (just in the route tables).
So how will ELB/ALB will forward traffic to the Overlay IP address.


this page is based on my daily work.

ELBs are great to load balance http and https protocols.
ELBs are great for web facing applications.

I'm working with legacy ERP applications which use lasting TCP connections and my users want to use everything in a VPC and intranet setup.
My GUI users may be idle for more than an hour (see:…).

Anonymous (not verified)

Mon, 07/29/2019 - 17:39

In reply to by Stefan Schneider

Hi Stefan

Was there any response for the question asked above?

I'm pasting the question again here -

Thanks for a wonderful explanation.However i am not still able to understand how ELN/ALB will help in forwarding the traffic to the Overlay IP address.Since ELB has no understanding of the OverlayIP address which is plumbed inside the instance and no where mapped in the (just in the route tables).
So how will ELB/ALB will forward traffic to the Overlay IP address.

An ELB and an Overlay IP address means applying two solutions for one problem. You can use an ELB exclusively. The ELB may end an IP connection after an hour.You will have to make sure that only one target is getting configured at a time. Please touch base with your SAP savy architect from AWS to discuss this problem. There's a lot of innovation at AWS.

Anonymous (not verified)

Fri, 05/25/2018 - 00:47


Have a question, how a subnet CIRD could be when VPC is (lower number of IPs)

Stefan Schneider

Thu, 05/31/2018 - 20:07

In reply to by Anonymous (not verified)

Correct observation. This is a typo in the diagram. I'll fix it.

vinoth (not verified)

Thu, 08/18/2022 - 12:25

In reply to by Stefan Schneider

Hi Stefan

could please let me know on overlayip address creation i am struck with it.
to create overlayip do i need to create a seperate vpc or in existing vpc can i create an seperate subnet.

Stefan Schneider

Fri, 08/26/2022 - 14:10

In reply to by vinoth (not verified)

This solution has been created for routers. An EC2 system which acts as a router get packets to an IP range which is out of the VPC routing. It would normally route these packages to a "remote" location.

  • You don't need a subnet
  • You can narrow down the network mask to one IP only
  • The EC2 system is not a router it processes the request.
  • The VPC backend knows how to reach the EC2 system, no matter in which AZ

Stalin (not verified)

Sat, 11/07/2020 - 02:42

Great documentation!!

I just had one real quick question, will this Overlay IP get relased upon a reboot? Just in case we want to applying monthly paches on these cluster nodes. If yes, what is best way to manage it.


jayanth (not verified)

Thu, 11/12/2020 - 18:14

How will i communicate overlay ip, if the overlay ip is from different VPC

Stefan Schneider

Thu, 11/26/2020 - 10:16

In reply to by jayanth (not verified)

Any IP address within the VPC will be routed to the EC2 instance behind. This happens because they (hopefully) use the same routing table. You may have to maintain multiple routing tables if needed. An overlay IP address can't be reached from outside the VPC. The routing won't work :-( .

Starting Greengrass V1 automatically on a Raspberry Pi

Starting Greengrass V1 automatically on a Raspberry Pi

Greengrass core on a Raspberry Pi needs to be started manually.

The following script will create a system-D control file and use it to start the service.

The service will then restart automatically at any reboot. Non disclaimer.


  • This script with Greengrass V1 only. Greengrass V2 doesn't need it anymore.
  • The script has been tested on a Raspberry Pi 4B with Debian. The script will most likely work on all distributions using system-D
  • Have Greengrass V1 installed.

Non Disclaimer

  • The scripts needs to be executed with elevate super privileges. This is mandatory. It may however created harm to your system. Check the script upfront. There is no warranty.
  • The script will delete any old versions of the system-D service file /etc/systemd/system/aws-ggc.service
  • The script will need a bash shell and the following commands installed (very likely to be preinstalled):
    • echo, systemctl, if

The Installation Script

Create a file with the name

#!/usr/bin/env bash
# version 1.1
# March, 2021
if [[ -e ${SERVICEFILE} ]];then
   echo "AWS Greengrass Service is already installed as SYSTEMD, trying to stop
the service."
   echo "*****";
   systemctl stop aws-ggc.service
echo "[Unit]" >  ${SERVICEFILE};
echo "Description=AWS Greengrass Service" >>  ${SERVICEFILE};
echo "" >>  ${SERVICEFILE};
echo " " >>  ${SERVICEFILE};
echo "[Service]" >>  ${SERVICEFILE};
echo "Type=forking" >>  ${SERVICEFILE};
echo "User=root" >>  ${SERVICEFILE};
echo "WorkingDirectory=/greengrass/ggc/core" >>  ${SERVICEFILE};
echo "ExecStart=/greengrass/ggc/core/greengrassd start" >>  ${SERVICEFILE};
echo "ExecStop=/greengrass/ggc/core/greengrassd stop" >>  ${SERVICEFILE};
echo "Restart=always" >>  ${SERVICEFILE};
echo "RestartSec=60" >>  ${SERVICEFILE};
echo " " >>  ${SERVICEFILE};
echo "[Install]" >>  ${SERVICEFILE};
echo "" >>  ${SERVICEFILE};
systemctl daemon-reload
systemctl enable aws-ggc.service
systemctl start aws-ggc.service
echo "Done installing prerequisites (SYSTEMD)"

Installation of the Service

Make the file executable:

$ chmod u+x

Execute the file with super user privileges:

$ sudo ./

Check for Success

This command checks whether the service started. It doesn't check whether Greengrass Core is working!
Execute the following command:

pi@raspberrypi:~ $ systemctl status aws-ggc.service
● aws-ggc.service
   Loaded: loaded (/etc/systemd/system/aws-ggc.service; enabled; vendor preset:
   Active: active (running) since Mon 2020-11-23 11:53:08 CET; 30min ago
  Process: 396 ExecStart=/greengrass/ggc/core/greengrassd start (code=exited, st
 Main PID: 452 (5)
    Tasks: 132 (limit: 4915)
   Memory: 236.8M
   CGroup: /system.slice/aws-ggc.service
           ├─ 452 /greengrass/ggc/packages/1.11.0/bin/daemon -core-dir /greengra
           ├─ 634 /lambda/greengrassSystemComponents -runAs=tes
           ├─ 639 /lambda/greengrassSystemComponents -runAs=shadow
           ├─ 647 /lambda/greengrassSystemComponents -runAs=cloudSpooler
           ├─ 665 /lambda/greengrassSystemComponents -runAs=connectionManager
           ├─ 679 /lambda/greengrassSystemComponents -runAs=deviceCertificateMan
           ├─ 692 /lambda/greengrassSystemComponents -runAs=shadowSync
           ├─ 694 /lambda/greengrassSystemComponents -runAs=secretManager
           ├─ 772 /lambda/ipdetector
           ├─ 773 java -cp /lambda/stream_manager/AWSGreengrassStreamManager.jar
           └─1209 python3.7 -u /runtime/python/ --handler=green

Nov 23 11:52:54 raspberrypi systemd[1]: Starting aws-ggc.service...
Nov 23 11:52:54 raspberrypi greengrassd[396]: Setting up greengrass daemon
Nov 23 11:52:54 raspberrypi greengrassd[396]: Validating hardlink/softlink prote
Nov 23 11:52:54 raspberrypi greengrassd[396]: Waiting for up to 1m10s for Daemon
Nov 23 11:53:08 raspberrypi greengrassd[396]: Greengrass successfully started wi
Nov 23 11:53:08 raspberrypi systemd[1]: Started aws-ggc.service.

Abort with <ctrl> c

Stopping the Service

$ sudo systemctl stop aws-ggc.service
Stefan Schneider Mon, 11/23/2020 - 11:55

DNS Name Failover for Highly Available AWS Services

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:

  • Consumers of a highly available service connect through the services through name exclusively.
  • Consumers of such a service have a comain name service configured which uses the AWS Route52 information
    • They use a public AWS IP address with a publicly registered domain
    • They have an on premises intranet which uses AWS Route53 as a secondary domain name server.
  • End consumers are able to reconnect a network session in a case of failure

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.

Stefan Schneider Fri, 08/12/2016 - 12:35

Creation of a Route53 Service in a private VPC

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

Stefan Schneider Fri, 08/19/2016 - 14:49

Changing the IP Address for a Host Name Entry in Route53

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.


Stefan Schneider Fri, 08/19/2016 - 14:55

Propagating the Name Change back to the On-Premises Intranet

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.



Stefan Schneider Fri, 08/19/2016 - 15:09

Use the Name Services in the Intranet

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.

Stefan Schneider Fri, 08/19/2016 - 15:53