2015: Where It All Began

I had been an AWS user since 2011/2012, but my first contact with the AWS Community started just one month before in June 2015 when I attended my first AWS User Group Meetup. This one was hosted at Jimdo and moderated by Sandra Liermann and Mark Bate from Amazon Web Services (AWS), it was a very memorable evening. What really stuck with me was how Sandra and Mark emphasized that a User Group should be driven by the Community, for the Community. This had been my personal main driver for almost everything I did as part of the AWS Community since that day. So when they mentioned they were looking for someone to take over the User Group, I volunteered that very evening.

Fast forward one month, I was hosting my first AWS User Group Meetup as User Group Leader. Since then, I've been deeply involved with the AWS User Group in Hamburg, organizing over 60 meetups, including 5 re:Invent re:Caps, and helping grow the group to over 2,700 members - making it the third-largest AWS User Group in Germany.

A big Thank You goes to Björn Böttcher who started the group back in 2011, and also to all my co-organizer who joined me over the years: Ramona Junge, Martin Schütte, Enrico Boldt and Sönke Ruempler. And I’m super thankfully for Vanessa Giese who is taking over the torch since I moved out of Hamburg.

In 2015, I had also the chance to attend AWS re:Invent for the first time. It was mind-blowing, huge, and an incredible experience. I attended as many sessions I could squeeze into the week, including a special and cozy gathering of about 20 User Group Leaders from around the world meeting the incredible Jeff Barr for a cosy evening.

2016-2017: Growing Community Involvement

In 2016, I contributed to the AWS Advent, writing a blog post as part of a series running from December 1st until Christmas, finalizing my submission during my second visit to re:Invent.

2017 marked another milestone when the first AWS Community Day in Germany was born at the AWS Summit in Berlin. Around a dozen User Group leaders from Germany met at the evening before the summit, organized by Marin Mamic from the German ISV Team. From the start, I was involved in organizing it, running the Kubernetes Track including a Call for Papers, selecting the talks, and moderating the talks during the event. It was a great first Community Day, including having Ross Barich as our special guest. Since then, I've been involved in all subsequent AWS Community Days, which have taken place in Frankfurt, Hamburg, Dresden, and two times in Munich (plus two virtual editions in between).

2019-2021: Expanding Horizons

In 2019, I organized our first AWS Community GameDay, hosted at my then-employer Smaato (Now part of Verve)'s office, on the Day after the AWS Community Day in Hamburg. Special Thanks to ☁ Jens Gehring ☁, Stefan Christoph, Robert Hanuschke, Thorsten Höger, Madlin Collins, and the many others who made it possible.

While COVID-19 presented challenges for community activities, 2020 brought also new opportunities. I was selected to join the first official cohort of AWS Community Builders, a program which really helped me expand my horizons and connect with AWS Community enthusiast from around the world. I'm proud to still be part of it today. Special thanks to Jason Dunn for what he has created here.

During 2020, I also launched the AWS Community DACH Slack space, which has grown to almost 1,000 members and serves AWS Communities across Germany, Austria, and Switzerland as place to connect. Along special channels for organizing our various AWS community events, also many User Groups have their dedicated channel there.

2020 was also the first re:Invent during COVID-19, which was complete remote. Together with Markus Ostertag, Thorsten Höger and Dennis Traub I joined a live re:Cap of Andy Jassys keynote on Youtube.

2021 saw us also adapting to the virtual world with our first virtual AWS Community GameDay, complete with unicorn costumes, alongside Linda Mohamed, Kristine Howard, and Dennis Traub.

2022-2025: New Milestones

In 2022, I became a founding member of the Förderverein AWS Community DACH. I’m part of the board since the start and served as second chairman and financial auditor. The Fördervereins mission is to facilitate engagement, knowledge-sharing, and networking opportunities across the AWS Community within the DACH region. Our Members are all either AWS Heros, AWS User Group Leads or AWS Community Builder. The Verein acts also as legal framework for our growing community activities, especially when it’s about handling finances, contracts, sponsors, insurances, etc. for the AWS Community Day DACH.

2022 was also the first time we all met again for the AWS Summit in Berlin. This time that the AWS Community got the chance to have their own dedicated stage and together with some Members of the Förderverein I joined organizing the Call for Papers, moderated the Sessions and had a booth where we presented the different AWS Community Programs.

2023 brought another exciting chapter as I co-founded a new AWS User Group from scratch in Bonn with Johannes Oehmen. Despite Bonn's smaller size compared to Hamburg, we've grown to almost 200 members, organized 12 Meetups (including one re:Invent re:Cap) at 6 different locations so far, and established a strong collaboration with our neighbors form the AWS User Group Cologne.

For re:Invent 2024, I joined a group of AWS Community Builders and organized a special "re:Invent at Home" event for the rest of AWS Community Builders program, featuring talks, keynote viewing parties, and knowledge sharing sessions. I also shared my experiences from previous re:Invents to help others navigate the event. Big thank you goes to Annem Sabah Shah, Endah Bongo-Awah, Emmanuel Mingle, Katoria H., Oluwasegun Adeniyi Adedigba and Jason Dunn.

2025 is already proving to be another landmark year, highlighted by an excellent AWS Summit in Hamburg. As every years since 2022 I helped to organize and run the Community stage. This one was our largest yet, with 350 seats.

Only one week later I was back at the local AWS User Group Meetup in Bonn, where I also gave a talk about AWS SES and was accompanied by my former Colleague johan beisser who spoke about Local Lambda development.

Just last month we closed already the Call for Papers for this years AWS Community Day DACH. Going through over 120 great submission took a while but I’m super happy and proud that we where able to create an awesome lineup again and just opened the registration a few days ago. Looking forward seeing you there :-)

Looking Ahead

As I reflect on these 10 years, I'm grateful for the connections made, knowledge shared, and communities built. The AWS Community has become more than just a professional network - it's a second family. I look forward to many more years of innovation, collaboration, and community building in the AWS ecosystem.

It’s impossible for me to name everybody I’m super thankful for being part of that journey, here a just a few which haven't been mention already in no particular order: Mathias Leppich, Matthias Schmidt, Philipp Garbe, Johannes Koch, Tom Lorenz, Christian Bonzelet, Davide de Paolis, Dmytro Hlotenko, Vadym Kazulkin 🇺🇦, Timur Galeev, Markus Kaiser, Michael Hanisch, Nora Schöner, Frank Prechtel, Gustavo Tavares, Aaron Walker, Julian Michel, Sana Shah, Stefan Bauer, Steffen Mazanek, Dr. Sven Seiler, Martin Raabe, Andreas Wittig, Michael Wittig, Chris Derby, David Heidt María Encinar, Thembile Martis, Susan Lopez, and many many more.

This week I retook the exam. One of the reason is obviously that the certified status had expired already years ago. With this blog post, I would like to share my experiences doing this exam for the second time and provide insights into what has changed over time.

The format

Let's start with taking a look at what are some of the formal changes.

The current version of this certification is called: AWS Certified Solutions Architect – Associate (SAA-C02). This version of the exam was released in March 2020 and is already the second iteration after the one I did. SAA-C01 was released beginning of 2018. You can find the official Exam Guide for the SAA-C02 here.

Most of it is very similar to how it looked in 2015. You get a total of 65 questions; these will be a mix of simple multiple-choice and multiple response questions. The latter also states how many correct answers you should pick. You get 130 minutes for this and need a score of 720 out of 1000 to pass based on a scaled scoring model.

Exam Content

The actual content has changed quite a lot. The current version still has questions out of 4 domains, but the subjects and the weighting have changed.

AWS-ASA (2015)

• 60% – Designing highly available, cost efficient, fault tolerant, scalable systems
• 10% – Implementation/Deployment
• 20% – Data Security
• 10% – Troubleshooting

SAA-C02 (2021)

• 30% – Design Resilient Architectures
• 28% – Design High-Performing Architectures
• 25% – Design Secure Applications and Architectures
• 18% – Design Cost-Optimized Architectures

AWS moves very fast, and therefore it's no surprise that the current version includes a lot of topics for features and services which did not exist in 2015.

For example, S3 grew a lot and got many new features and a few new storage classes. The AWS Snow family didn't exist at all, and the same goes for Athena or Macie. EC2 Spot is now way more complex than it used to be. On the Network side, we got things like VPC Gateway Endpoints, Private Link, or Transit Gateway. Back then, ELB was the name of the only available load balancer in AWS before he got renamed to classic ELB at the birth of its siblings ALB and NLB. Parameter Store, Systems Manager, or ECS were not yet released, and as far as I remember, even Lambda wasn't part of the exam in 2015.

How I prepared for each of them

I started using AWS as part of my day-to-day job somewhere around 2012/2013, giving me the recommended hands-on experience for my first exam in 2015. This was a huge help and provided a solid level of ground knowledge. To fill the gaps I used the online learning platform Linux Academy for preparation and study. They offer a digital course dedicated to the certification which covered all needed topics and a bit more. In addition to the video material and some references, I remember two features that also helped me a lot preparing:

1. Practice exams that simulated a real exam, including a random mix of questions and actual time pressure. This gave an excellent impression of how the exam will feel. How questions and answers are structured, and how to approach such a set of questions with the given time limit.
2. The possibility to define your own learning schedule. A small tool where you would specify how many hours you will put in on each day of the week. Based on that data a detailed plan gets created showing you which session you should take when. It also shows when you would be done with the entire content so that you can schedule your exam accordingly.

At the end of 2019, A Cloud Guru announced Linux Academy's acquisition. Both companies are in the same market and provide online learning for cloud and related technologies. However, both used to have a slightly different approach.

I was curious about which would be the better choice for my new preparation. So I took a look at the course for this certification on both platforms. As it turns out, both programs provide the same content nowadays and with exactly the same videos and materials for this specific course. This time, I picked A Cloud Guru to see if there are any other differences and get a feeling for the learning experience with them.

The only thing I missed was that tool to plan out my learning schedule. You only get an indication by looking at each video's length and the sum for each chapter. I believe it was ok for this time, as most of the content wasn't entirely new. But I assume that if I'd do another certification, one where I would have to put in more effort, I would appreciate that structure of scheduled learning for myself.

I started my preparation beginning of December 2020. With all the distractions of re:invent, Christmas, and the holidays I used effectively 4-5 weeks to watch 98% of all the videos, took the quizzes, and did the practice exam five times.

The exam

I took the AWS-ASA exam on an early Monday morning at re:invent 2015. It was a regular exam like you have it at any onsite AWS event or one of the many certification test centers worldwide. It's in a room full of tables arranged in rows and desktop PCs presenting you the exam questions in a web application.

This time was a lot different due to the current pandemic. Since the end of March 2020, AWS offers doing the exam virtually and from home together with their testing vendor Pearson VUE. I had used this approach for the AWS Cloud Practitioner in June 2020, so I was already familiar with the procedure.

In short: you need to download a particular application from Pearson VUE, which is available for Windows and MacOS. And on the day of your exam, you login ~30 minutes before it starts and follow the online proctoring instructions. You need a quiet room where you won't be interrupted by somebody, a clean desk, and a stable internet connection. During the onboarding, you use your laptop's webcam to show your ID, the room you are in, and that your desk is completely empty. You cannot have an external screen, use pen or paper, or any food and drinks during the exam. Your webcam will also record you for the entire time. That felt a bit wired initially, but it faded away as soon I started concentrating on the questions.

In both cases, I get a simple pass immediately after doing the exam and a more detailed overview of my score a few days later via email.

Conclusion

In the end, I'm pleased that I got certified again. Going through the preparation got me (again) looking at some features or details of AWS that I haven't encountered before. This is especially true for services I don't touch regularly as part of my day job.

It was definitely worth the effort, and I would like to encourage everybody who works with AWS to get certified as well.

Amazon machine images (AMIs) are the basis of every EC2 instance launched. They contain the root volume and thereby define what operating system or application will run on the instance.

There are two types of AMIs:

• public AMIs are provided by vendors, communities or individuals. They are available on the AWS Marketplace and can be paid or free.
• private AMIs belong to a specific AWS account. They can be shared with other AWS accounts by granting launch permissions. Usually they are either a copy of a public AMI or created by the account owner.

There are several reasons to create your own AMI:

• predefine a template of the software, which runs on your instances. This provides a major advantage for autoscaling environments. Since most, if not all, of the system configuration has already been done, there is no need to run extensive provisioning steps on boot. This drastically reduces the amount of time from instance start to service ready.
• provide a base AMI for further usage by others. This can be used to ensure a specific baseline across your entire organization.

What is Packer

Packer is software from the HashiCorp universe, like Vagrant, Terraform or Consul. From a single source, you can create machine and container images for multiple platforms.

For that Packer has the concept of builder and provisioner.

Builders exist for major cloud providers (like Amazon EC2, Azure or Google), for container environments (like Docker) or classical visualization environments (like QEMU, VirtualBox or VMware). They manage the build environment and perform the actual image creation.

Provisioners on the other hand are responsible for installing and configuring all components, that will be part of the final image. They can be simple shell commands or fully featured configuration management systems like Puppet, Chef or Ansible.

How to use Packer for building AWS EC2 AMIs

The heart of every Packer build is the template, a JSON file which defines the various steps of each Packer run. Let’s have a look at a very simple Packer template:

There is just one builder and one simple provisioner. On line 4, we specify the amazon-ebs builder which means Packer will create an EBS-backed AMI by:

• launching the source AMI
• running the provisioner
• stopping the instance
• creating a snapshot
• converting the snapshot into a new AMI
• terminating the instance

As this all occurs under your AWS account, you need to specify your access_key and secret_key. Lines 7-9 specify the region, source AMI and instance type that will be used during the build. ssh_username specifies which user Packer will use to ssh into the build instance. This is specific to the source AMI. Ubuntu based AMIs use ubuntu which AWS Linux based AMIs use ec2-user.

Packer will create temporary keypairs and security groups to connect the local system to the build instance to run the provisioner. If you are running packer prior to 0.12.0 watch out for GitHub issue #4057.

The last line defines the name of the resulting AMI. We use the {{timestamp}} function of the Packer template engine which generates the current timestamp as part of the final AMI name.

The provisioner section defines one provisioner of the type shell. The local script “setup_things.sh” will be transferred to the build instance and executed. This is the easiest and most basic way to provision an instance.

A more extensive example

The requirements for a real world scenario usually needs something more than just executing a simple shell script during provisioning. Lets add some more advanced features to the simple template.

Optional sections

The first thing somebody could add is a description and a variables section to the top of our template, like:

{
    "description": "Demo Packer template",
    "variables": {
        "aws_access_key": "",
        "aws_secret_key": "",
        "base_ami": "ami-b520c0d8",
        "base_docker_image": "ubuntu:16.04",
        "instance_type": "t2.medium",
        "vpc_id": "vpc-12345678",
        "subnet_id": "subnet-87654321"
    },
    [...]
}

The first one is just a simple and optional description of the template. While the second adds some useful functionality. It defines variables, which can later be used in the template. Some of them have a default value, others are optional and can be set during the Packer call. Using packer inspect shows that:

$ packer inspect advanced_template.json
Description:

Demo Packer template

Optional variables and their defaults:

aws_access_key =
aws_secret_key =
base_ami = ami-b520c0d8
base_docker_image = ubuntu:16.04
instance_type = t2.medium
subnet_id = subnet-87654321
vpc_id = vpc-12345678
[...]

Overriding can be done like this:

$ packer build \
        -var 'aws_access_key=foo' \
        -var 'aws_secret_key=bar' \
        advanced_template.json

Multiple builders

The next extension could be to define multiple builders:

{
[...]
  "builders": [
    {
      "type": "amazon-ebs",
      "access_key": "{{user `aws_access_key`}}",
      "secret_key": "{{user `aws_secret_key`}}",
      "region": "us-east-1",
      "source_ami": "{{user `base_ami`}}",
      "instance_type": "{{user `instance_type`}}",
      "vpc_id": "{{user `vpc_id`}}",
      "subnet_id": "{{user `subnet_id`}}",
      "associate_public_ip_address": true,
      "ssh_username": "ubuntu",
      "ami_name": "Packer-build DEMO {{timestamp}}",
      "ami_description": "Build at {{isotime \"Mon, 02 Jan 2006 15:04:05 MST\"}} based on {{user `base_ami`}}"
    },
    {
      "type": "docker",
      "image": "{{user `base_docker_image`}}",
      "pull": true,
      "commit": true,
      "run_command": ["-d", "-i", "--net=host", "-t", "{{.Image}}", "/bin/bash"]
    }
  ]
[...]
}

The amazon-ebs builder was extended by using some of the previously introduced variables. It got a bit more specific about the build environment which will be used on AWS side by defining a VPC, a subnet and attaching a public IP address to the build instance, and also added how the description of the resulting AMI will look.

The second builder defines a build with docker. This is quite useful for testing the provisioning part of the template. Creating an EC2 instance and an AMI afterwards takes some time and resources while building in a local docker environment is faster.

The pull option ensures that the base docker image is pulled if it isn’t already in the local repository. While the commit option is set so that the container will be committed to an image in the local repository after provisioning instead of exported.

Per default, packer will execute all builders which have been defined. This can be useful if you want to build the same image in a different Cloud Provider or in different AWS regions at the same time. In our example we have a special test builder and the actual AWS builder. The following command tells packer to use only a specific builder:

$ sudo packer build -only=docker advanced_template.json

Provisioner

Provisioners are executed sequentially during the build phase. Using the only option you can restrict the provisioner to be called only by the corresponding builder.

{
  "provisioners": [
    {
      "type": "shell",
      "script": "bootstrap.sh",
      "execute_command": "{{ .Vars }} sudo -E sh '{{ .Path }}'",
      "only": ["amazon-ebs"]
    },
    {
      "type": "shell",
      "script": "bootstrap.sh",
      "only": ["docker"]
    },
    {
      "type": "ansible-local",
      "playbook_file": "site.yml"
    },
    {
      "type": "shell",
      "script": "cleanup.sh"
    }
  ]
}

This is useful if you need different provisioners or different options for a provisioner. In this example both call the same script to do some general bootstrap actions. One is for the amazon-ebs builder, where we call the script with sudo, and the other is for the docker builder where we don’t need to call sudo, as being root is the default inside a docker container.

The script itself is about upgrading all installed packages and installing Ansible to prepare the next provisioner:

#!/bin/bash

export DEBIAN_FRONTEND=noninteractive

apt-get update
apt-get -y upgrade
apt-get -y install sudo ansible

Now a provisioner of the type ansible-local can be used. Packer will copy the defined Ansible Playbook from the local system into the instance and then execute it locally.

The last one is another simple shell provisioner to do some cleanup:

#!/bin/bash

# Remove Ansible
sudo bash -c "apt-get purge -y ansible"

# Remove temporary stuff
sudo bash -c "apt-get autoremove -y"
sudo bash -c "apt-get clean"
sudo bash -c "rm -rf /tmp/_"
sudo bash -c "rm -rf /home/ubuntu/.ansible"
sudo bash -c "rm -rf /root/.ssh/authorized*keys"
sudo bash -c "rm -rf /usr/sbin/policy-rc.d/"
sudo bash -c "rm -rf /etc/ssh/ssh_host*_"
sudo bash -c "cat /dev/null > /var/log/wtmp"
sudo bash -c "cat /dev/null > /var/log/syslog"

Post-Processors

Post-processors are run right after the image is built. For example to tag the docker image in the local docker repository:

{
  "post-processors": [
    [
      {
        "type": "docker-tag",
        "only": ["docker"],
        "repository": "demo/awsadvent",
        "tag": "{{timestamp}}"
      }
    ]
  ]
}

Or to trigger the next step of a CI/CD pipeline.

Pitfalls

While building AMIs with packer is quite easy in general, there are some pitfalls to be aware of.

The most common is differences between the build system and the instance which will be created based on the AMI. It could be anything from simple things like different instance type to running in a different VPC. This means thinking about what can already be done at build time and what is specific to the environment where an EC2 instance is created based on the build AMI. Other examples, an Apache worker threads configuration based on the amount of available CPU cores, or a VPC specific endpoint the application communicates with, for example, an S3 VPC endpoint or the CloudWatch endpoint where custom metrics are sent.

This can be addressed by running a script or any real configuration management system at first boot time.

Wrapping up

As we have seen, building an AMI with a pre-installed configuration is not that hard. Packer is an easy to use and powerful tool to do that. We have discussed the basic building blocks of a packer template and some of the more advanced options. Go ahead and check out the great Packer documentation which explains this and much more in detail.

All code examples can be found at https://github.com/aruetten/aws-advent-2016-building-amis