“GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD.”
To separate different workloads, environments, playgrounds, lab areas, from each other the preferred way is to use separate AWS accounts. AWS Organizations offers a nice way to handle all of your AWS accounts from a single locations. Creating and managing the accounts in a manual way can be a time consuming work. I needed a way to be able to manage the accounts and to setup resources in the accounts at the time of creation in an automatic way.
I started to write this post almost a year ago but for some reason I never finished it.
I have been using the small tooling, easy-aws-credentials (EAC), since I started the post.
Now finally I decided that it was time to clean up the tool, release it, and finish the post.
A couple of weeks ago I decided to give the AWS CDK (Cloud Development Kit) a go. It had just become general available and the support for Python was in place.
This is not the bastion host you are looking for!
A common way to get ssh access to EC2 instances in a VPC would be to go through a hardened bastion host. Does it sound familiar? Most people use this pattern, it has been around for like forever.
About a year ago I started to look at LEX, you know the thing that powers ALEXa. I started to build a simple chat bot that could respond to simple queries. One thing led to another and I also created a very basic Alexa Skill. After my initial development I put it on hold, there was more things to look at that felt more attractive.
After Re:Invent 2018 I watch a couple of Alexa talks on YouTube and suddenly the interest to build voice enabled applications was reborn.
There was a new SDK and development kit and everything felt refreshed. I started to build a simple Guess the number skill to test the development kit and pick up where I left off. In this blog I will walk you through the creation of this skill and things to think about.
During Re:Invent 2018 a new concept was introduced to AWS Lambda, Dr. Werner Vogels introduced Layers. This is a way to create shared libraries that can be used across many functions without the need to duplicate code.
No more pulling in libraries or shared code when deploying your function.
No more confusion what version of the shared code each function uses.
No more risk of creating a monolith.
Layers are versioned and the function references an exact version and each function can update to new versions in its own pace.
In this post I will describe how I created this blog. What technologies I have used, how the site is hosted, why I decided to go with Jekyll, and more.
When I decided that I wanted to start writing on a cloud related blog I started to search for different solutions. Naturally my first choice was Wordpress. Being one of the most, if not the most, used blog engine in the world this just felt natural. I started to deploy everything and within a couple of hours I had everything running. I used an image from AWS marketplace, supplied by Bitnami.
After this setup I had a VPC with public subnets and one EC2 host with Wordpress on it running. This just didn’t feel right. One server, with everything on that? That’s not good. What if the server dies?
A couple of weeks ago AWS released a new feature to CloudFormation. Macros, a way to transform your template. This is the same technology that power the Serverless Application Model (SAM).
This release is a real game changer and this will make my life so much easier.
Why is this such a game changer then?
During the years that I have been using CloudFormation to create and handle my infrastructure I have written so many rows of boiler plate code. Adding the same sections to resources over and over again. Tags is one example, I always add a Name, Cost Allocation and Application Tag. Writing this over and over again is so annoying. With a special macro I would only need to add something like this: