AWS Account Anatomy: Root, IAM and Service Limits

In AWS the account itself is the primary boundary. Not a project, not a subscription, not a folder. Resources belong to an account, permissions are written inside it, and the bill is drawn against it. Most AWS design advice is really advice about where to draw account boundaries.

The root user

Every AWS account has a root user tied to the email address used at signup. Root can do anything, including things no policy can restrict, such as closing the account or changing the payment method.

The near-universal recommendation is to secure root and then stop using it. Give it a strong unique password and a hardware or application second factor, remove any access keys attached to it, and do daily work through IAM identities instead.

When an account changes hands this is the single most important item. Until the root credentials and the root email are under your control, control of the account is not really yours.

IAM: users, roles and policies

IAM is where day-to-day permissions live. Three pieces matter:

• Users are long-lived identities with passwords or access keys.
• Roles are identities that are assumed temporarily, by a person or by a service.
• Policies are JSON documents attached to either, describing what is allowed.

Roles are preferable to users wherever possible, because the credentials are short-lived. An application running on an instance should assume a role rather than carry a stored key.

On an inherited account, IAM is the first place to audit. List every user, every access key and every role, and remove anything you cannot account for. The approach is described in auditing an unfamiliar cloud account.

Regions and service limits

AWS resources live in regions, and most limits apply per region. Running capacity in one region says nothing about another, and a new region generally starts from conservative defaults.

The limit people meet first is the vCPU quota for on-demand instances, which is expressed per instance family. It is the reason a launch can fail on a funded account with no configuration error.

Current catalogue options

These configurations come straight from the current catalogue.

Reading the configuration names

The AWS listings describe several different dimensions, which is why they are worth reading carefully rather than by price alone:

• vCPU figures describe compute headroom, which relates to quota rather than to a specific machine.
• Credit figures describe a promotional balance on the billing side.
• Service readiness, such as Bedrock-enabled configurations, describes whether a managed service has been activated on the account.
• Request-rate figures such as RPM relate to how much throughput a managed service will accept.

A high vCPU figure and a large credit balance solve different problems. Decide which constraint you actually have before comparing prices. Capacity is discussed further in what vCPU counts mean, and AI service readiness in cloud infrastructure for AI workloads.

Billing shape

AWS bills per account with a granular line for each service, region and usage type. Cost Explorer makes this readable, but only if resources carry tags. Tagging from the first resource is far easier than retrofitting it later, as described in tagging resources for cost allocation.

A sensible first hour

1. Take control of root: password, second factor, recovery email, no access keys.
2. Create an IAM identity for yourself and use it from then on.
3. List IAM users, roles and keys, and remove anything unexplained.
4. Enable CloudTrail in all regions and send logs somewhere durable.
5. Check every region for running resources, not just the one you plan to use.
6. Set budget alerts below expected spend.

AWS terms of service continue to govern the account and its use throughout.