Implement AWS Cold Start

This document describes every step of the cold-start process required to initialize a net-new AWS Organization utilizing DevOps Accelerator's 1xOps approach. The cold-start process is the first and most intense step of setting up a new AWS Organization. The process involves a number of manual steps and adjustments to bootstrap all the tooling and configurations before we can start any meaningful work.

note

Please take the time to read through the entire process before starting, and reach out if you have any questions!

Problem

AWS provides poor documentation for all the steps required for setting up a new AWS Organization. Once the Organization is set up, there’s a lot of manual steps and remediations required to bootstrap all the tooling and configurations before we can start to do anything meaningful.

Solution

The purpose of the cold-start process is to provision the initial set of AWS accounts and IAM roles so that users can log in to AWS with existing credentials and build the rest of the infrastructure. Many of the same steps need to be repeated in order to later add a new AWS account or organizational unit, so these documents also implicitly provide guidance for that task.

A cold start is when you go from zero to a full deployment, typically occurring on day zero in the life cycle of your resources.

Layout

• Detailed Cold Start Implementation
• How to Set Up AWS Email Notifications
• How to Register Pristine AWS Root Account
• How to Create super-admin-user user
• Deprecated Cold Start Components

Conventions

There are a few things that are required but that change from project to project. To avoid excessive use of generic placeholders in the text, we use the following values as placeholders, and you should change them as needed:

• acme is the placeholder for the project's namespace. Each project needs to have a project namespace, preferably 3 or 4 letters, that is unique in the DevOps Accelerator architecture. It is part of every identifier and is what makes it possible to generate globally unique names for things like S3 buckets.

• uw2 is the placeholder for the chosen abbreviation style of the default AWS Region. If you are using the “tenant” feature, you need to replace uw2 with <tenant>-<environment> where <tenant> is the tenant abbreviation for the tenant holding the root AWS organization and <environment> is the abbreviated default AWS region.

• "1Password" is the placeholder for the application or system used to store and share secrets like AWS credentials.

Prerequisites

This document assumes as a baseline that DevOps and developer personnel who need AWS access have a working computing environment that:

• Docker installed
• Has bash, git, and Taskfile installed
• Has a host file system that containers can access (when properly configured)
• Can install and run GUI applications (e.g. AWX | RunDeck | Semaphore UI )

Typically our recommendation is Docker Desktop running on a local, dedicated (to the user) MacOS or Windows computer. If the user cannot install new applications due to administrative restrictions, then all of the above components, plus nnthanh101/terraform, should be pre-installed for them.

nnthanh101/terraform Docker-Image

The nnthanh101/terraform:latest Docker image is a secure, lightweight, and production-ready environment tailored for modern CloudOps and DevOps workflows. Built on Chainguard's Wolfi Linux, this image incorporates best practices for multi-cloud, Infrastructure-as-Code (IaC), and Kubernetes ecosystem management.

docker run -it --rm nnthanh101/terraform:latest bash

docker run -it --rm nnthanh101/terraform:latest sh -c start.sh

Tag	Description
latest	Core DevOps tools (e.g., Terraform, Git, AWS CLI, Azure CLI, and linters like TFLint/Tfsec).
devops	Includes latest + Kubernetes ecosystem tools (kubectl, helm, kustomize, k9s) and Go.

Deactivate super-admin-user user

info

super-admin-user is no longer deactivated with the addition of the aws-teams components. super-admin-user is required to make changes to root components, since the ...root-terraform role no longer has permission to make changes to the the root account

After all the cold-start components have been provisioned, we have SSO and all IAM roles configured, and users will be able to login to AWS accounts using GSuite by assuming the IAM roles.

We can deactivate super-admin-user user now.

Login to AWS IAM console using the root credentials, select the super-admin-user user, go to the "Security credentials" tab, and click "Make inactive" for any keys listed under "Access keys". This will prevent them from being used until you need them again, and at the same time will enable you to use them without having to reconfigure Leapp. Alternately (and somewhat more securely), you can delete the keys, and when you need to use them again create new ones and add them to Leapp as you did with the first keys.