org-formation-cli VS serverless

And these guardrails are usually owned by platform teams. One downside to doing all these with AWS Organizations is that it involves a lot of clickops… This is where I would turn to org-formation, an open-source tool that gives you infrastructure-as-code for AWS Organizations. It’s a really powerful tool and I strongly recommend that you check it out if you haven’t already.

If you don’t like control tower, try org formation. https://github.com/org-formation/org-formation-cli

I found myself bootstrapping a new AWS Organization. I am using org-formation to define the basic account structure, an OIDC IdP for Github Actions and the essential roles for Terraform to do its job.

an AWS account is free, so if you're planning basically reselling AWS, an account per tenant is a nobrainer. There are a few ways to create loads of accounts, org-formation is my favorite

We use https://github.com/org-formation/org-formation-cli for most of our work, though just vanilla Terraform can work reasonably well for most of the things.

By the way, if you like the "deploy this stack to multiple accounts"-feature of Stacksets, you're going to lovveee org-formation.

This led me to two problems. The first was the perennial issue I've had with Terraform from day one: "How do I manage state?". The second issue was how do I leverage some form of CI/CD tooling to allow me to leverage one of Terraform's biggest strengths - the terraform plan capability. Since Fooli is an AWS product, I figured that I should be able to use AWS native tools for this. I've used CodePipeline in the past to preview change-sets with aws-org-formation, so I thought it would be easy to find a well-worn pattern from AWS on doing it.

You can now manage your AWS Organization through CloudFormation, including creating accounts, organizational units, and policies. It's one of those things you are surprised were not already possible. However, I will stick to the OrgFormation for my own accounts, as it offers additional features like deploying stacks and performing custom logic across the organization.

I don't know any tutorials that cover all of these, but check out: https://cdkpatterns.com/ for 1) https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html for 2) 3) and 5) https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-cdk-testing.html for 4)

I would like to see re-useable design patterns advocated similar to the terraform/terragrunt modules concepts. Encouraging pulumi.ComponentResource definitions multi environment structure, best practices. The cdk guys have something similar https://cdkpatterns.com/.

While writing this post, the four stacks combined are 129 lines of source code. With the help of the CDK Constructs that are being used this translates to over 1k lines of code in CloudFormation. We are only using L2 constructs here – there is way more constructs available that you can use in the Constructs Hub and also a lot of guidance regarding the usage of CDK over at CDKPatterns.

I use the "Lambda-lith" pattern, primarily because I am using Rust and deploying via CI/CD (codepipeline).

Here is a read of common lambda design pattern https://github.com/cdk-patterns/serverless/blob/main/the-lambda-trilogy/README.md

Level 3 constructs are opinionated units of reusable code which often deliver a service. Open source level 3 constructs are available from AWS Solutions Constructs - an extension to the CDK, CDK Patterns - a library of well-architected patterns, Construct Hub - a library of open-source constructs and some even come out of the box with the CDK - these are appended with 'patterns' to make them identifiable. Two examples are shown below: