A safe AWS account starts with a protected root user, named human identities, temporary credentials, billing alerts, and an audit trail.
The root user owns account-level powers that ordinary administrators do not need. Store its credentials securely, enable phishing-resistant MFA when possible, and use it only for documented root-only tasks.
For everyday access, prefer IAM Identity Center or role assumption. Configure separate CLI profiles so personal, lab, and production credentials are not mixed.
Use a unique email address and password, enable MFA, remove root access keys, and make recovery details available to more than one trusted owner. Root access should be exceptional and reviewed after use.
Set up IAM Identity Center for workforce access or create a tightly controlled bootstrap administrator role. Assign permissions to groups, require MFA, and issue short sessions instead of sharing one IAM user.
Create an AWS Budget before launching resources, enable Cost Explorer, and confirm CloudTrail event history is available. A multi-account setup should also define organization controls and a dedicated log archive strategy.
Use a named profile with an explicit default Region and output format. Verify the profile with STS, then test that an allowed read succeeds and an intentionally unauthorized action is denied.
The root user is created with the account and has authority that cannot be fully constrained by ordinary IAM policies. Treat it as an account-recovery identity, not as the first administrator for daily work. Use a company-controlled email address, a unique password stored in an approved vault, and more than one MFA device where the account configuration and organizational policy permit it.
Recovery is part of security. Keep the email inbox, telephone details, payment method, and security challenge information under organizational control rather than tied to one employee. Separate who can retrieve the root password from who can approve a root sign-in when the organization requires two-person control. Document the few tasks that genuinely require root and record every use.
For member accounts in AWS Organizations, evaluate centralized root-access management. AWS can remove long-term root credentials from member accounts and provide controlled privileged access for supported root tasks. The management account remains exceptionally sensitive and should have a smaller administrator group, stronger monitoring, and no application workloads.
A production landing zone normally uses multiple accounts because the account is a strong boundary for resources, quotas, permissions, and billing. Start with management, security tooling, log archive, shared services, and workload accounts only when the organization can operate them. A small learner lab can remain one sandbox account, but it should not be confused with a production topology.
Group accounts into organizational units by control need, not merely by the current reporting chart. Service control policies set maximum available permissions for affected accounts; they do not grant access. Test a policy on a sandbox organizational unit before broad attachment, preserve an emergency path, and remember that a mistaken explicit deny can interrupt administration across many accounts.
Define account names, alternate contacts, approved Regions, baseline logging, security services, and cost tags through an account-vending process. The goal is a repeatable account with known controls, not a manually configured snowflake. Keep application deployments out of the Organizations management account so a workload incident has a smaller blast radius.
Use IAM Identity Center or federation with an external identity provider for workforce access. Assign permission sets to groups and accounts so a developer, auditor, billing analyst, and administrator receive different role sessions. A short-lived session reduces the value of stolen credentials and gives audit events an attributable principal.
Configure the AWS CLI with the SSO workflow and a named profile. The profile records the start URL or issuer, SSO Region, account, role, and default workload Region without storing a permanent access key. Authenticate interactively, then run `aws sts get-caller-identity --profile NAME` before any create or delete command. The returned account and ARN are the authoritative context for that session.
Separate profiles for sandbox and production and make production changes flow through reviewed automation wherever possible. Environment variables can override profile settings, so troubleshooting must inspect the complete credential provider chain rather than assuming the named profile won. Never paste cached SSO tokens or temporary credentials into tickets, repositories, or screenshots.
Choose initial Regions from latency, legal requirements, service availability, recovery strategy, and cost. Set a default Region in tools, but continue to pass or verify Region explicitly for high-impact work. A resource that appears missing is often in another account or Region rather than deleted.
Restrict unused Regions only after identifying global services and the Regions required for identity, logging, support, and recovery. Organization policies can deny actions outside an approved set, but exceptions must be designed carefully. Record why each Region is allowed and test the policy against deployment and incident-response roles.
Review service quotas before a load test or launch. Quotas are often regional and account-specific, and a new account may have lower practical capacity than an established environment. Request increases early, monitor usage, and keep a fallback when a quota request is not approved by the required date.
A budget is an alerting rule, not a hard spending cap. Create actual and forecast thresholds, route them to a monitored owner, and test the notification path. Enable Cost Explorer and decide which account, application, environment, and owner dimensions must appear in reports. Cost allocation tags need consistent spelling and activation before they become useful billing dimensions.
CloudTrail event history provides recent management-event visibility in each Region, but durable auditing needs a trail or event data store designed for retention and analysis. In a multi-account organization, centralize protected logs in a log archive account, encrypt them, restrict deletion, and monitor delivery. Decide separately whether high-volume data events are required for resources such as S3 objects or Lambda functions.
Turn on the security and configuration services selected by the organization, then prove their destinations and owners. A green console page is not enough: retrieve an event for a known read operation, locate one test budget notification, and confirm that an unauthorized principal cannot alter the audit destination.
Before launching a workload, perform a short readiness drill. Sign in through the normal workforce path, verify the account and role with STS, list one harmless regional resource, and confirm a denied administrative action from a read-only role. Then locate the corresponding audit event. This proves identity, authorization, Region context, and evidence collection together.
Simulate an ownership problem without changing production credentials: ask who receives a security notification, who can approve emergency access, and how a lost MFA device is handled. Confirm that the answer survives an employee absence. Review the budget recipient and perform the cleanup checklist for any account-setup resources created during the lab.
Record failures as baseline defects. A missing contact, broad permission set, unsearchable trail, or unowned alert should block promotion of the account to production use. Account setup is complete only when the team can enter safely, observe actions, control cost, recover access, and explain the boundaries.
Named profiles keep lab credentials isolated and make it easier to switch between sandbox and shared accounts safely.
aws configure set region us-east-1 --profile lab
aws configure set output json --profile lab
aws sts get-caller-identity --profile labA new production account needs daily federated administration while the root identity remains recoverable.
Constraints: Root credentials stay offline; administrators use short sessions; billing and CloudTrail alerts must reach an owned channel.
Decision: Enroll two hardware-backed root MFA factors, create an Identity Center permission set for daily work, and document an emergency access test.
Verification: A named administrator obtains a short-lived session, the root inbox receives the expected alert, and the recovery owner signs the runbook.
Failure test: Expire the daily session and confirm recovery does not depend on that administrator or laptop.Expected evidence: A named administrator obtains a short-lived session, the root inbox receives the expected alert, and the recovery owner signs the runbook.Explore 500+ free tutorials across 20+ languages and frameworks.