SOP — Create and Manage an AWS Cloud Account

Goal: stand up AWS for MPT Work the right way from day one — a secure management account, a multi-account organization with guardrails, federated single sign-on, and addressing that fits the enterprise IPAM plan. Don't run workloads in the management account.

0. Plan the account structure

Use a multi-account organization (isolation, blast-radius control, clean billing) rather than one big account. A recommended landing-zone layout:

Root (management account: aws-management@mptwork.com)
├── Security OU
│     ├── Log Archive account      (aws-logarchive@mptwork.com)
│     └── Audit / Security Tooling (aws-security@mptwork.com)
├── Infrastructure OU
│     └── Network / Shared Services (aws-network@mptwork.com)
├── Workloads OU
│     ├── Prod OU      → prod accounts (aws-prod@mptwork.com)
│     └── Non-Prod OU  → dev/test     (aws-dev@mptwork.com)
├── Sandbox OU
└── Suspended OU

• Every AWS account needs a unique root email — use team-owned distribution lists / shared mailboxes (e.g., aws-<purpose>@mptwork.com), never a personal address.
• For the multi-subsidiary design (US/JP/UK), you can nest per-subsidiary OUs under Workloads and align accounts to the IPAM subsidiary blocks.

Part 1 — Create the management (root) account

1. Go to https://aws.amazon.com → Create an AWS Account using aws-management@mptwork.com.
2. Provide the legal business name, address, and a company phone; choose a Business account; enter payment details.
3. Complete identity verification and select a support plan (at least Business support for production).
4. Sign in to the console, open Billing → Account, set an account alias, and verify contact/alternate-contact details.

Part 2 — Secure the root user (do this immediately)

1. Enable MFA on the root user — this is required (register within 35 days of first sign-in or you'll be forced to before further console access). Prefer a passkey or FIDO2 security key (phishing-resistant); a virtual TOTP app is an interim option. You can register up to 8 MFA devices.
2. Set a strong, unique root password stored in the team password manager.
3. Ensure there are no root access keys (delete any). Use root only for the few tasks that require it.
4. Set alternate contacts (Billing, Operations, Security) to team distribution lists.
5. Configure a CloudWatch/EventBridge alert on root sign-in so any root use is flagged.

Part 3 — Enable AWS Organizations and build the structure

1. In the management account → AWS Organizations → ensure all features are enabled.
2. Create the OUs from the layout in section 0.
3. Create member accounts (Organizations → Add account), each with a unique aws-<purpose>@mptwork.com root email, and place them in the right OUs. New member accounts join consolidated billing automatically.

Part 4 — (Recommended) Deploy an AWS Control Tower landing zone

1. From the management account, set up AWS Control Tower to get a governed, secure-by-default landing zone.
2. Control Tower provisions the Log Archive and Audit accounts, applies baseline guardrails (controls), and gives Account Factory for standardized account vending.
3. Use Account Factory to create future accounts so they inherit the baseline automatically.

Part 5 — Centralize root access for member accounts

1. In IAM → Organization root access (management/delegated admin), enable centralized root access management.
2. Remove root credentials from member accounts — they then operate without root user credentials (no password, no MFA, no recovery), a secure-by-default state; new accounts start this way.
3. Perform any rare privileged root task centrally from the management/delegated-admin account, or temporarily enable password recovery for a specific member account when truly needed.

Part 6 — Set up IAM Identity Center and federate to Entra / Google

1. Enable IAM Identity Center (in the management account or a delegated admin). Note the AWS access portal URL (e.g., https://d-xxxxxxxxxx.awsapps.com/start).
2. Set the identity source to an external IdP:
   • Microsoft Entra: add the AWS IAM Identity Center gallery app in Entra; exchange SAML metadata both ways; enable SCIM provisioning so Entra groups/users sync into Identity Center.
   • Google (if used for a population): configure Google as a SAML IdP similarly.
3. Create permission sets (e.g., AdministratorAccess, PowerUser, ReadOnly, plus least-privilege custom sets).
4. Assign IdP groups to accounts with permission sets (e.g., group AWS-Prod-Admins → Prod accounts → AdministratorAccess). Users then sign in once at the access portal and assume roles via SSO — no IAM users, no long-lived keys.

This mirrors the federation pattern from the Entra/Google SOPs: AWS becomes another SSO app behind @mptwork.com, with joiner/mover/leaver driven by the IdP.

Part 7 — Guardrails and governance

1. Service Control Policies (SCPs): restrict member accounts (e.g., deny disabling CloudTrail/GuardDuty, deny leaving the org, restrict regions, restrict root actions).
2. Organization CloudTrail: an org-wide trail logging all accounts to the Log Archive account's S3 bucket.
3. AWS Config: org-wide configuration recording and conformance packs.
4. Amazon GuardDuty + Security Hub: enable org-wide (delegated admin = Audit account) for threat detection and posture.
5. IAM Access Analyzer: detect external/unintended access.

Part 8 — Billing and cost management

1. Consolidated billing is automatic in Organizations (one bill, shared volume pricing).
2. Set AWS Budgets with alerts, enable Cost Anomaly Detection, and use Cost Explorer.
3. Define a tagging policy (e.g., CostCenter, Environment, Owner, Subsidiary) and enforce tag policies; activate cost allocation tags.

Part 9 — Networking baseline (align to the IPAM plan)

1. Allocate VPC CIDRs from the enterprise IPAM plan — AWS blocks are US 10.0.0.0/14, Japan 10.16.0.0/14, UK 10.32.0.0/14 — and carve region/environment/VPC ranges per that scheme.
2. Use AWS IPAM to manage and enforce allocations across accounts/regions.
3. Build connectivity per the network reference architecture (Transit Gateway hub, site-to-site VPN to offices, no overlapping CIDRs) in the Network/Shared Services account.

Part 10 — Ongoing operations

Appendix — Notes and caveats

• Root MFA is mandatory on every account type (management/standalone/member) — register within 35 days; prefer passkeys/security keys. Where possible, use centralized root access to remove member-account root credentials entirely.
• Never run workloads in the management account; keep it for org/billing/governance only.
• No IAM users for humans — use IAM Identity Center federation; reserve IAM roles for workloads/services (prefer IAM Roles Anywhere / OIDC over static keys).
• Unique root email per account via team distribution lists; protect the management-account root credentials above all.
• Verify current steps in AWS documentation — console layout, Control Tower, and Identity Center features change frequently.