How To Create A Brand New AWS Cloud Environment For A Development Team

You have a development team, they deploy solutions in the cloud, they need the right tooling and a good foundation to work with, this is a short general story on how to accomplish that based on a multi AWS account strategy.

Form a site reliability engineering team (SRE)

To do it quickly and full focus, form a new team with only cloud-engineers that way you can remove the pressure from the development teams. The SRE team's main goal should be: focus on the development of a new AWS infrastructure, which should be solid, reliable, and future-proof. Following AWS best practices and Guidelines. Site Reliability Engineering is a concept brought into the world by the Google engineering team, the credits go to Ben Treynor Sloss. If you want more information, search for SRE teams on Google.

Implement a solution

Working together with the same end goal in mind. It’s actually the best way to learn from your teammates and see what they are capable of.

We came up with a Multi AWS account strategy based on services, with 100% infrastructure as code using the AWS CDK and CI/CD pipelines. A team is responsible for an application or service, and they get their own AWS environment for which they are responsible. This environment consists of three AWS accounts and one centrally managed account for deploying centralised solutions, like for instance logging and monitoring.

The hierarchy looks like this: A build account which contains the pipeline to build your application and push it to other environments, cross-account deployment. A development account / acceptance account: do everything you want here before deploying to production, also, acceptance testing takes place here. A production account: completely isolated from all other accounts, decoupled.

And as extra, like mentioned before, a centrally managed account for centralised solutions and managed by the SRE team. The whole concept is actually based on a solution Snyk suggested a while ago in one of their blogs, and of course the multi account strategy is also something AWS recommends. The whole concept looks like this:

Example Environment with build account, development account, and production account with full Snyk Integration. credits: Snyk.

Infrastructure as Code (IaC)

infrastructure as code should be mandatory within the AWS structure. Creating resources through the console is a no-go. For our infrastructure as code we embraced AWS CDK. Why? Because it is awesome! For anyone interested, take the official AWS workshops from the docs (only 20 minutes to set up a fargate cluster), and you are convinced. It is a revolutionary cloud development kit, which is open source with a fast and frequent release cycle.

Communications

To get maximum output from everybody involved, follow the scrum methodology and organise short time-boxed sessions to immediately clear uncertainties, communicate impediments, and make decisions on the spot. By doing so, you eliminated the need for other meetings and keep the (agile) development flow going at a steady pace.

Have a continuous open Google Meet conference and use a dedicated Slack channel. That way, no time will be lost if someone has a question or wants to organise a quick meeting. And because everybody realises we’re entering a new cloud phase, you can see the full potential of aligned autonomy, mature self organised teams, implementing their own solutions.

Guidelines and Strategies to stay Future-Proof

Completely isolate your production environment.
Security shifting left, use Snyk.
Infrastructure as code should be mandatory, it can be in any language of your preference.
Tagging must be 100% - which is quite easy to accomplish with CDK.
Manage your costs efficiently, because tagging is 100%, you can now pinpoint exactly where to save costs.
Aligned autonomy, work with mature teams, give them the trust to work on and implement their ideas.
We all know security is shifting left, find and fix your vulnerabilities before deployment.
Use AWS backup and AWS backup vault for creating and storing backups.