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

Form a Site Reliability Engineering team (SRE)

To Create A Brand New AWS Cloud Environment For A Development Team quickly and with 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: to 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. If you want more information, search for SRE teams on the Internet.

Implement a solution
Go for a multi-AWS account strategy based on services, and aim at 100% Infrastructure as Code (IaC) by using, for instance, the AWS CDK and CI/CD pipelines (see IaC). It’s built around the concept that a team is responsible for an application or service and the team gets its own AWS environment. This environment consists of three AWS accounts and one centrally managed account for deploying centralized solutions, like logging and monitoring.

The hierarchy looks like this: a build account that contains the pipeline to build your application and push it to other environments; it’s called cross-account deployment. Next, a development account/acceptance account: do everything you want here before deploying to production. Also, acceptance testing takes place here. Finally, a production account: completely isolated from all other accounts. By decoupling it, you can, for instance, implement security solutions relatively easily. And last but not least, as mentioned before, a centrally managed account for centralized solutions - managed by the SRE team.

The whole concept is based on a solution Snyk suggested a while ago in one of their blogs here: Snyk and Trek10 AWS Secure Serverless CI/CD Deployments. And, of course, the multi-account strategy is also something AWS recommends: Organizing Your AWS Environment Using Multiple Accounts.

Visualized in a diagram, the concept looks like this

Example Environment with build, development, and production accounts 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 IaC, you could embrace AWS CDK. Why? Because it is awesome! For anyone interested, take this official AWS workshop from the docs Creating an AWS Fargate service using the AWS CDK (only 20 minutes to set up this fargate cluster), and you are convinced. It is a revolutionary cloud development kit that is open source with a fast and frequent release cycle.

Communications

To get maximum output from everybody involved, follow the scrum methodology and organize short time-boxed sessions to immediately clear uncertainties, communicate impediments, and make decisions on the spot. Doing so eliminates the need for other meetings and keeps the (agile) development flow steady.

Have a continuous open Google Meet (or similar tool) conference and use a dedicated Slack channel. That way, no time will be lost if someone has a question or wants to organize a quick meeting.

Guidelines and Strategies to Stay Future-Proof

• Completely isolate your production environment.

• Adopt security shifting left, use Snyk and find and fix your vulnerabilities before deployment.

• Infrastructure as code should be mandatory; it can be in any language of your preference, I would suggest the AWS CDK.

• Tagging must be 100% which is quite easy to accomplish with CDK.

• Manage your costs efficiently. Because your tagging is 100%, you can now pinpoint exactly where to save costs. Adopt Graviton for your workloads.

• Aligned autonomy, work with mature teams, and give them the trust to work on and implement their ideas.

• Use AWS backup and AWS backup vault for creating and storing backups.