Skip to main content

The Rhythmic Blog

AWS Service Catalog – Building Platforms and Managing Infrastructure with CloudFormation

February 23, 2022       Steven Black       ,         Comments  0

With the endless flood of new products, features and changes from AWS and its surrounding ecosystem, it can be easy to miss an update. Our monthly round-up highlights major AWS news, announcements, product updates, and behind-the-scenes changes we think are most relevant.

Kubernetes: The Documentary [watch it]

I’ll be honest, this isn’t primarily about AWS, BUT this series does start and end with AWS!

It starts with the birth of Kubernetes, and one of the essential ingredients for the genesis of Kubernetes was Google’s envy of AWS’s cloud success. Back in 2013, Google was the big computing company, and AWS did retail. Then AWS invented the cloud, leaving Google totally in the dust. Google needed a way to compete that would let them strut their superior compute and came up with Kubernetes.

It ends (the series, not the saga of container orchestration) with Kubernetes claiming victory in the “container wars.” Between the origins of the project and now, Kubernetes has had to compete with a bunch of other container orchestrators. There was (and still is) Docker Swarm, ECS (Elastic Container Service), and Tupperware (now twine). It was not clear who’d or if Kubernetes would even stick around until AWS released their Kubernetes offering. If there’s any signal to show the world that you’ve made it, it’s AWS co-opting your IP.

CloudFormation Allthethings

This post on AWS Service Catalog is fantastic for many reasons. First, if the dates on all supporting materials are correct, it was written back in 2020 but has languished somewhere internal to AWS for almost two years.

Second, it demonstrates the platform-building capabilities of the AWS Service Catalog. Typically, we think of AWS as the platform developers build their services, but that’s rarely the case. There’s usually a team of engineers in the middle who build out the Kubernetes clusters or EC2 fleets where the developers land their code. The AWS Service Catalog lets you configure these AWS primitives (EKS or EC2 in this example) so developers can service themselves. Instead of spinning up an EKS cluster for the developers, you point them to the catalog and let them click their way to glory.

Third, this post demonstrates how AWS has layered cloud formation with code into a nightmare lasagna. If you check out the GitHub repository that goes with this blog post, it’s written in AWS CDK, which is code that generates CloudFormation. Then each of these internal “products” gets launched with a CloudFormation stack. This includes a Helm Chart for WordPress, which uses a helm resource provider for AWS CloudFormation. That means you have code to generate CloudFormation that uses code to launch more CloudFormation to run your code. Which of these is the meat and which is the noodle in our lasagna is up to your imagination.

Up until the present, terraform has been my favorite Infrastructure As Code tool because it’s relatively easy to work with. AWS is making it clear that all roads run through CloudFormation. If that’s the case, when in Rome do as the Romans do, or when in AWS define everything in YAML structured to resemble their API. Resource link here.

Enforce Compliance with Custom CloudFormation Errors

This edition will be CloudFormation heavy, but that’s ok because we got two big CloudFormation announcements this month! The tl;dr of this one is this: you can have CloudFormation trigger lambdas that can stop the actions of said CloudFormation stack. The kicker is you can define this to be triggered when any CloudFormation stack tries to create a specific resource across the entire account.

This means that any time someone wants to deploy a CloudFormation stack (and let’s not forget resources like Serverless that compile to CloudFormation), their CloudFormation is subject to the approval of your lambda function. Want to make sure every S3 bucket is named after a Simpson character? You can fail CloudFormation stacks that don’t. Think your organization will never need to update an instance size larger than t3.micro? With only a few lines of python, you can make that a reality. Maybe you want to pass a warning to any developer trying to delete a CloudFormation stack? Warnings are a supported FailureMode for CloudFormation hooks, and you can trigger them before deletion.

I’m sure there are a lot of great use-cases for these hooks. Being able to enforce security or cost-consciousness in a large organization where lots of people make changes with little oversight is absolutely an asset. But humans don’t generally like to be told what to do, so when you come across an engineer becoming particularly pigheaded because of these hooks, remember to post your situation to r/MaliciousCompliance so we can all share in the fun.

Miscellaneous News

Leave a Reply