From credit card to a safe, organized AWS

Create the account, lock away root, build the organization, sign in safely, pick a Region and turn on the audit trail.

Text version of this diagram.

What sits where:

AWS Organization · Todo.io: A group of AWS accounts with one owner (the management account) and one combined bill. contains:
- Management account · 111111111111: The account that owns the organization and pays the bill. Keep apps out of it. The 12-digit number is its account ID. contains:
  - Root user (owner@todo.io): The email address that created the AWS account. It can do absolutely anything, so you lock it with MFA and almost never use it.
  - IAM Identity Center (everyday sign-in): Where people sign in to AWS every day: one login with MFA, then you pick an account and get a role in it.
  - AWS Organizations (accounts + SCPs): Groups many AWS accounts under one owner and one bill. SCPs (service control policies) are rules that cap what those accounts are allowed to do.
  - CloudTrail (organization trail): AWS's activity log: who did what, when and from where. An organization trail records every account in one place.
  - CloudWatch (alarm on root sign-in): AWS's monitoring service. It watches numbers and logs, and raises an alarm (here, an email) when something crosses a line.
  - S3 bucket (todoio-org-trail): A named container for files in Amazon S3, AWS's file storage. This one holds the audit trail's log files.
- Prod account · 222222222222: Production: the AWS account where the real Todo.io runs for real users. The 12-digit number is its account ID. contains:
  - us-east-1 · N. Virginia: A Region is a part of the world where AWS has data centers. Most things you build live in one Region. us-east-1 is in northern Virginia. contains:
    - Todo.io stack (VPC, app, database (tab 2)): Everything that runs Todo.io: its private network (VPC), the app and the database. The Design Todo.io tab walks through it.
  - Admin role (AdministratorAccess): A role is a set of permissions you step into for a while, with temporary keys. AdministratorAccess is AWS's ready-made policy that allows everything.
- Dev account · 333333333333: Development: a separate AWS account for experiments, so a mistake there can't touch Prod. contains:
  - Same setup (for trying things safely): Dev gets the same pieces as Prod, so you can try changes without risking the real app.
You (Ryan) (laptop + browser)

Steps, in order:

Create the AWS account. Path: You (Ryan) → Root user. You sign up with an email address, a card and a phone number. That email becomes the root user: the all-powerful owner of a brand new AWS account.
Lock the root user away. Path: Root user. Turn on MFA for root, create no access keys for it, and stop using it. Root can't be limited by IAM policies, so it only comes out for the few jobs that need it. Checks: setting: MFA on the root user → allow; setting: No root access keys → allow.
Create an organization. Path: Root user → AWS Organizations. You turn on AWS Organizations. This account becomes the management account, which pays one combined bill for every account in the organization.
Create Prod and Dev. Path: AWS Organizations. Organizations creates two member accounts: Prod for the real Todo.io and Dev for experiments. A mistake in Dev can't touch Prod.
Create your everyday login. Path: Root user → IAM Identity Center. You turn on IAM Identity Center and create user ryan, assigned the AdministratorAccess permission set in Prod and Dev. Root can go back in the safe.
Sign in the everyday way. Path: You (Ryan) → IAM Identity Center → Admin role. From now on you sign in at the access portal with MFA, pick Prod, and get a role with temporary credentials in it.
Pick one Region. Path: Todo.io stack. In the console's Region menu you choose us-east-1. Everything Todo.io builds goes there. IAM, Organizations and billing are global, so the menu doesn't change them.
Add a guardrail. Path: AWS Organizations. A service control policy on Prod and Dev denies any request outside us-east-1. Global services such as IAM and Organizations aren't exempt on their own: the policy lists them under NotAction, or it would block them too.
Turn on the audit trail. Path: CloudTrail → S3 bucket. In the management account you create an organization trail in CloudTrail. Every management API call (creating, changing, deleting or listing resources) in every account and every Region gets written to one S3 bucket.
Alarm on root sign-in. Path: CloudTrail → CloudWatch. The trail also streams to CloudWatch Logs. A metric filter and alarm email you if anyone ever signs in as root.

Step 1 of 10

You sign up with an email address, a card and a phone number. That email becomes the root user: the all-powerful owner of a brand new AWS account.
Show me the real thing
What you get
```
Account ID:  111111111111
Root user:   owner@todo.io
```
Exam tipAn AWS account is a container for resources and a boundary for security and billing. Nothing crosses it unless you allow it.
Turn on MFA for root, create no access keys for it, and stop using it. Root can't be limited by IAM policies, so it only comes out for the few jobs that need it.
- ⚙Setting MFA on the root userAllowed
- ⚙Setting No root access keysAllowed
Exam tipJobs that need root include closing the account, changing the account email and restoring lost admin access.
You turn on AWS Organizations. This account becomes the management account, which pays one combined bill for every account in the organization.
Exam tipSCPs never apply to the management account. That's why nothing runs in it except account management, billing and the audit trail.
Organizations creates two member accounts: Prod for the real Todo.io and Dev for experiments. A mistake in Dev can't touch Prod.
Exam tipEach new member account gets a role called OrganizationAccountAccessRole that the management account can assume.
You turn on IAM Identity Center and create user ryan, assigned the AdministratorAccess permission set in Prod and Dev. Root can go back in the safe.
Exam tipIdentity Center is the recommended way for people to sign in. The older way, an IAM user per person in each account, comes up in Level 1.
From now on you sign in at the access portal with MFA, pick Prod, and get a role with temporary credentials in it.
In the console's Region menu you choose us-east-1. Everything Todo.io builds goes there. IAM, Organizations and billing are global, so the menu doesn't change them.
Exam tipMost services are regional: a database made in us-east-1 does not exist in eu-west-1. Always check the Region menu before you build or go looking.
A service control policy on Prod and Dev denies any request outside us-east-1. Global services such as IAM and Organizations aren't exempt on their own: the policy lists them under NotAction, or it would block them too.
Show me the real thing
The SCP (trimmed: AWS's full example lists a few more global services)
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OnlyUsEast1",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "sts:*",
        "sso:*",
        "route53:*",
        "cloudfront:*",
        "budgets:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}
```
Exam tipSCPs never grant anything. They set the most an account can do; IAM policies inside the account still have to allow it. They even limit root in member accounts.
In the management account you create an organization trail in CloudTrail. Every management API call (creating, changing, deleting or listing resources) in every account and every Region gets written to one S3 bucket.
Show me the real thing
Trail settings
```
{
  "Name": "todoio-org-trail",
  "IsOrganizationTrail": true,
  "IsMultiRegionTrail": true,
  "S3BucketName": "todoio-org-trail",
  "LogFileValidationEnabled": true
}
```
Exam tipWithout a trail, CloudTrail still keeps 90 days of management events in Event history, per account and Region. Member accounts can't turn off an organization trail.
The trail also streams to CloudWatch Logs. A metric filter and alarm email you if anyone ever signs in as root.
Show me the real thing
Metric filter pattern
```
{ $.userIdentity.type = "Root" && $.eventType = "AwsConsoleSignIn" }
```
Exam tipCloudTrail records who did what. CloudWatch watches numbers and logs and raises alarms. Together they answer "tell me when something bad happens".

What to notice

Root is the one identity no IAM policy can limit, so it gets MFA and goes in the safe.
Separate accounts are the strongest wall AWS has. Prod and Dev cannot touch each other by default.
The management account only manages: accounts, billing, sign-in and the audit trail. No workloads.
People sign in through Identity Center and borrow roles. Nobody has long-lived keys.
One SCP keeps every member account in us-east-1, and one organization trail records everything.