Current package is deprecated and will not be maintained anymore. AWS Bootstrap Kit implementation has been moved to leverage the new AWS Landing Zone Accelerator solution (github).
- AWS Bootstrap Kit Examples Overview
- Who is this for?
- What you will get with it?
- What you will get with it? (the AWS infrastructure)
- Getting started
- Tenets
- What you will find in this repository
- What you won't find in this repository
- Do I need to be familiar with the AWS Services used under the hood?
- Concept
- Security
- Costs
- Cleaning up accounts
- Known limitations
- Getting Help
- Next
This repository contains examples of using the AWS Bootstrap Kit to set your development and deployment environment on AWS. The AWS Bootstrap Kit is a strongly opinionated CDK set of constructs built for companies looking to follow AWS best practices on Day 1.
Let's start small but with potential for future growth without adding tech debt.
Here is the list of the personas targeted by this solution:
- Operators
- Developers
- Oncall developers (aka Ops)
A structured set of environments to develop and operate your software on AWS for your different team roles:
- An isolated set of secure environments enabling you to ensure the reliability of your system by limiting blast radius of issues (being security, code change, manual operations ...)
- A Web Portal enabling to log in to your different environment (dev, staging, prod, CI/CD ...)
- A central billing system enabling you to control your spend accross your environments
- A central activity view enabling to control what is done across your environments
- A central users and permissions management service enabling you to control what your team members can do or not in your different environments
- An isolated DNS management zone to securely control your main DNS domains
Most of it as Infrastructure as Code artifact.
DNS hierarchy:
- An environment with wide permissions to experiment, test and develop
- A Web Portal enabling to log in to your different environment (dev, staging, prod, CI/CD ...)
- A simple way to add multi stages CI/CD pipeline to deploy securely your code to production
- A simple way to add public DNS records to expose your app or service
- A Web Portal enabling to log in to the different environment you are in charge to monitor
Basically the same as above but:
- Environments = AWS Accounts (not a user account but actually a isolated environment tied to an email (& password) and unique id)
- Set of Environments = Set of AWS Accounts under a main one = AWS Organizations
- Users and Permissions management solution = AWS IAM Identity Center
- Login Web Portal = AWS access portal URL
- Central Activity logs = Centralized AWS Cloudtrail
- Central Bills = AWS Consolidated Billing
- CI/CD Pipeline = AWS CodePipeline
- Infrastructure as code Artifact = AWS CDK construct/App
- Security monitoring rule = AWS Config rule
- DNS Zone = Route53 Public HostedZone
Here is a diagram showing the different services involved and how they are interconnected.
Let's deploy your Software Development Life Cycle Organization.
For a full learning path check the Activate workshop leveraging the aws-bootstrap-kit.
What this setup fight for:
-
Bootstrapping an organization on AWS should be easy: whatever the size of an organization, bootstrapping it on AWS should be as simple as running a command line
-
AWS best practices is for everyone: whatever the size of an organization, their end customers deserve a secure, reliable and cost efficient solution so we don't compromise on AWS best practices for simplicity
-
Everything is code (when possible): infrastructure management is a lot easier and more reliable when everything is managed by code.
-
CI/CD everywhere: Human is flawed, let's automate any deployment at any stage
-
Think of the future: what's created by the resources available here aims to limit future tech debt and ease future growth by being easily migratable to large enterprise solutions such as AWS Control Tower.
-
Keep it simple: keeping things simple is the best way to avoid technical debt
-
Keep it open: our code is open source so that you can contribute or adapt it to fit your needs
In this respository, you will find:
- the source code of the examples used in the documentation
- the SDLC Organization CDK app that creates several accounts for you through AWS Organizations and sets up the appropriate centralized audit logs.
- the Landing Page CDK app that demonstrates how to deploy a static web site in the Dev account.
- the Landing Page with Pipeline CDK app that demonstrates how to deploy a static web site accross your Staging and Prod environment thanks to a CI/CD pipeline.
If you are looking for the source code of the AWS Bootstrap Kit, go there: https://www.github.com/awslabs/aws-bootstrap-kit.
No, to set up your multi-account strategy with the AWS Bootstrap Kit, you don't need to be familiar with the AWS services used under the hood. The intent of the AWS Bootstrap Kit is helping you to start quickly, knowing that you are following AWS best practices and can grow further. Of course, over the time, you may need to learn about these services to fine tune your deployment but you don't need to start there.
The AWS Bootstrap Kit is based on AWS CDK, the AWS Cloud Development Kit, which is a software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation.
With AWS CDK, you define your cloud resources in a familiar programming language. You don't need to learn the syntax of CloudFormation templates. The AWS CDK supports TypeScript, JavaScript, Python, Java, and C#/.Net. If you want to know more about CDK, please visit AWS CDK documentation.
AWS CDK is based on the concept of construct. A construct represents an AWS resource or a set of AWS resources. A low-level construct directly maps to a CloudFormation resource while higher level of construct can represent a set of resources that represents a pattern.
In addition, AWS CDK uses the concept of stack. It is the unit of deployment. All AWS resources defined within the scope of a stack, either directly or indirectly, are provisioned as a single unit.
Forcing any deployment to go through CI/CD will enforce repeatability through automation and ensure a high control over production release.
Having multiple stages enable to catch errors and issues early in order to prevent them to reach production.
See how amazon code deployment automation and continuous delivery increased velocity.
Isolating the different environments involved in software development brings many advantages around least priviledge principle (it will be easy to segregate access to prod environment for instance) or reliability by reducing the blast radius of an issue.
See official best practices documentation and our official prescriptive guidance for more details.
Your DNS root domain (yourdomain.com for instance) is a resource to particularly protect, however the use of it to expose service to the internet should not be blocked. That is the reason why this solution propose to set it up in an environment only accessible by administrators and set a chain of subzones enabling developers to stay agile.
All changes to your organization and services will go through CI/CD based on code change. Therefore access to those code repository needs to be properly secured.
You will see that manual approvals are added by default in CI/CD pipelines giving you a second layer of protection for prod deployments with the need of proper AWS permissions to approve in addition to git push permission.
Going with AWS IAM Identity Center will enforce temporary credentials usage while simplifying developers environment setup.
In this solution, we included what we think are a minimal set of security best practices:
- Centralized activity log (AWS Cloudtrail accounts' trails centralized to main account) is a must. It enables you to easily control what is done in each account.
- Check on Multi factor authentication for root user (AWS Config rule)
- Creation of a dedicated administrator user to replace root user (IAM user)
By default, this solution occurs less than 1$ / month bill (price may slightly vary by region) by focusing more on structure of your accounts and using serverless technology.
AWS Bootstrap Kit creates accounts (e.g CICD, Staging, etc.) through AWS Organization. Behind the scene, it uses CloudFormation Custom Resource and AWS Lambda to call CreateAccount API.
However, there is no API to delete or remove accounts. Thus, the created accounts (aka. member accounts) cannot be cleaned up automatically via Custom Resources. You need to delete these accounts manually. The steps below explain how to clean up those accounts. You have to repeat these steps for each account one by one.
- Ensure that you have access to the email address of the member account Without access to email address, you cannot recover root user to close the account. If that is the case, you have to manually delete all created resources. After that, you should create a Service Control Policy (SCP) with deny * on all resources and apply it to all accounts to disable all future access.
- Recover root user access in the member account Follow section "Accessing a member account as the root user" in this documentation.
- Remove the member account from AWS Organization Follow the instruction on this documentation. In essence, you need to fill required information (e.g. billing) to detach the member account from an existing Organization.
- Delete each account Sign-in with root credential and go to Account Setting page. Scroll down to "Close Account" section. Read and ensure that you understand the information on check box before closing the account.
If you want to delete the master account (aka. management account). You need to manually delete AWS Organization in the account after you have removed all member accounts. You can find the details on this documentation.
- Rollback of the SDLC Organization is tricky since AWS Accounts can't be easily deleted
- Change of the organization structure is not supported (especially accounts' name needs to stay as is).
- No check will be done on email given the configuration and can't be changed afterwards
- Deployment won't work if:
- You already have an AWS Organizations setup
- You already have a AWS Config recorder (created automatically if you used AWS Config before)
- Auto CDK bootstrap is only done in the original deployment region
The best way to interact with our team is through GitHub. You can open an issue and choose from one of our templates for bug reports, feature requests, documentation issues, or guidance.
Let's deploy your Software Development Life Cycle Organization.