How an AWS Account Is Structured: Root, IAM, Organizations and Billing

AWS makes one architectural decision that explains almost everything else about it: the account is the isolation boundary. Not a project, not a subscription, not a folder. Resources in one account cannot see resources in another unless you deliberately connect them.

That is why AWS customers end up with many accounts, why Organizations exists, and why account-level details matter so much when you take one over.

The root user is not an administrator

Every AWS account has exactly one root user, identified by the email address the account was created with. It cannot be deleted and cannot have its permissions reduced. It can close the account, change the payment method, and recover access when IAM is misconfigured.

It is also the single most important thing to control in any hand-over. An account where you hold an IAM administrator login but someone else holds root is not an account you control.

A correct hand-over means the root email is changed to an address you own, the root password is reset, root MFA is re-enrolled on a device you hold, and any root access keys are deleted outright. Root access keys should not exist at all.

IAM: users, roles and policies

Below root, IAM governs everything:

• Users are long-lived identities with passwords and optional access keys.
• Roles are assumable identities with no permanent credentials — the preferred pattern for applications, EC2 instances and cross-account access.
• Policies are JSON documents attached to users, groups or roles.

The detail that catches people out is the trust policy on a role. A role can be written so that a principal in a completely different AWS account may assume it. Rotating passwords does nothing to that. Every role's trust relationships need reading during an audit, not just its permissions.

Service quotas are the real capacity limit

An AWS account does not give unlimited capacity. Service Quotas (formerly limits) cap vCPUs per instance family per region, Elastic IPs, VPCs, EBS volume totals, Lambda concurrency and much else. New accounts start conservative.

This is why vCPU capacity appears so often in how environments are described. An account already approved for a high On-Demand vCPU limit in a specific family and region is meaningfully more useful than a fresh one, because the approval process takes time and is granted per region.

When you evaluate any AWS account, ask for the quota figures in the region and instance family you actually intend to use. A 256 vCPU limit in a region you will never deploy to is not capacity.

Bedrock, inference quotas and what "enabled" means

Amazon Bedrock adds a second dimension of limits. Access is granted per model, and throughput is governed by requests per minute and tokens per minute, per region. An account with model access already granted and higher RPM limits removes a waiting period that can otherwise block a project.

These are ordinary service quotas, not a separate product. They are worth verifying explicitly — model access, the specific models, the region, and the actual RPM figure — because "Bedrock enabled" on its own does not describe throughput.

EC2 sizing in practice

EC2 instance families follow a readable pattern once you know it. The letter is the family, the number is the generation, and the suffix describes the processor or capability:

• T-series — burstable, with CPU credits. Cheap, and unsuitable for sustained load.
• M-series — balanced general purpose.
• C-series — compute-optimised.
• R-series and X-series — memory-optimised.
• G, P and Inf/Trn — GPU and purpose-built accelerators.

Burstable instances deserve particular care. A t3.medium looks inexpensive until a sustained workload exhausts its credit balance and performance falls off a cliff. If the load is steady, choose a non-burstable family, a decision explored further in the guide to sizing vCPU and memory.

Billing, Organizations and consolidated invoices

An account can be standalone or a member of an AWS Organization. Membership matters:

• A member account's charges roll up to the management account's invoice.
• Service Control Policies set at the organisation level can deny actions regardless of local IAM permissions.
• Leaving an organisation requires the member account to have its own valid payment method and complete contact details.

If an environment is described as an AWS account and turns out to be an Organization member, you inherit whatever the management account permits. That is a material difference, and worth confirming directly.

A realistic post-transfer sequence

1. Change the root email address, reset the root password, re-enrol root MFA.
2. Delete any root access keys.
3. List all IAM users, keys and roles. Deactivate unknown keys before deleting them, so you can see what breaks.
4. Read every role trust policy for external account principals.
5. Check whether the account belongs to an Organization.
6. Enable CloudTrail in all regions and confirm it is writing somewhere you control.
7. Set a billing budget with an alert threshold before deploying anything.
8. Review every region — not just your own — for running resources.

Point eight matters more than it sounds. Resources can be running in regions nobody has looked at, and they bill just the same. Budget alerts are the cheapest insurance available here.

Frequently asked questions

Is an IAM administrator the same as the account owner? No. Root retains capabilities IAM cannot be granted, including closing the account and changing payment details.

Do quotas transfer with the account? Yes — quotas belong to the account and region, so an account with approved increases keeps them. They do not follow you to a different account.

What is the fastest way to find forgotten resources? The Billing console's cost breakdown by service and region will surface anything that costs money, which is the practical definition of what matters.

Does deleting an IAM user revoke its access keys? Yes, but deactivate first and watch for breakage before deleting, so you understand what was depending on it.

If you are weighing this platform against the alternatives, the AWS and Google Cloud comparison covers where each one is genuinely stronger, and the Buy AWS Account listing shows which configurations are currently available.