Chykalophia Docs

How AWS account access works — the root user, IAM users and roles, access keys, and the practices that prevent an expensive mistake.

Amazon Web Services underpins a lot of custom applications — file storage, encryption, email, compute. Its access model is more powerful than most platforms', and correspondingly easier to get wrong. Three things cause most of the trouble: the root user, a leaked access key, or an over-permissive policy.

Quick summary

The root user is the email address the account was created with. Lock it away: strong password, hardware or app-based MFA, no access keys, and never used for daily work. Everyone else gets an IAM user or, better, signs in through IAM Identity Center with a role granting only what they need.

The root user

The root user has complete access to every service and resource in the account — it can close the account, change billing, and restore an administrator who has locked themselves out. Ordinary IAM permissions don't limit it.

Register it to a shared, monitored address, not an individual's inbox. AWS recommends a business-managed address that forwards to a group, so a message from AWS isn't sitting unread while someone is on holiday.

Enable MFA on it immediately, ideally a hardware key or passkey. AWS now requires MFA on the root user of every account, and gives you 35 days from the first console sign-in attempt to register it.

Don't create root access keys, and delete any that already exist. AWS's own advice is not to create them at all; sign in to the console for the few tasks that need root.

Store the credentials in a password manager with restricted access, and make sure more than one trusted person can reach them.

Use it only for the handful of tasks that require it — changing the account's email address or root password, closing the account, restoring an administrator's permissions, and a few billing tasks.

IAM: users, roles, and policies

Users are long-lived identities for people or applications.
Roles are temporary identities that anything can assume for a short period. Preferred, because the credentials expire.
Policies are JSON documents attached to users or roles saying what is allowed.

Modern practice is to avoid creating IAM users for people at all. IAM Identity Center lets staff sign in with a central identity and assume a role with a defined permission set — access that expires, is centrally revoked, and works cleanly across multiple AWS accounts.

Access keys are the usual leak

A long-lived access key pair is a standing credential, in plain text, carrying whatever permissions its IAM user has — and it doesn't expire on its own. Automated scanners hunt for exposed keys in public code, and abuse can run up large charges fast. Prefer roles. Where a key is unavoidable, scope it tightly, rotate it on a schedule, and never commit it. See environment variables & secrets.

Least privilege in practice

Start from nothing and add what's needed. In particular:

Avoid AdministratorAccess for anything that isn't a break-glass role.
Avoid wildcards on both action and resource ("Action": "*" with "Resource": "*").
Scope policies to specific buckets, keys, and regions.
Separate environments — staging credentials should not reach production data.

AWS gives you two ways to trim an over-broad policy after the fact: IAM's "last accessed" information shows which permissions an identity actually used, and IAM Access Analyzer can generate a fine-grained policy from the activity CloudTrail has logged.

Billing protection

AWS bills by consumption, and nothing caps your spend by default. That's the mechanism behind the horror stories.

Set a budget with alerts so unexpected spend is noticed early rather than at month end. A budget can also trigger an action — for example applying an IAM policy that stops new resources being created. Note that AWS warns of a delay between a charge being incurred and the alert arriving, so a budget is a warning, not a brake.

Point billing alerts at a monitored address, not a personal one.

Restrict who can create expensive resources through IAM policy.

Review the bill monthly. A sudden jump is often the first sign of compromise.

Common questions

Who should own the AWS account?

You. It holds your data, your encryption keys, and your bill. We work inside it under a scoped IAM role or Identity Center assignment that you can revoke at any time, without affecting the running infrastructure.

How do we give an agency or contractor access?

Cleanest is a dedicated IAM role they assume, scoped to the services they need, with MFA required. That way there is no shared password, access is logged, and removing it is a one-line change. Never share root.

How do we know what someone did?

AWS CloudTrail records API activity, and you already have some of it: CloudTrail is on by default, and every account can look back over the past 90 days of management events in a Region from the CloudTrail console at no extra charge. The limits matter, though. That event history covers 90 days only, one account and one Region at a time, and management events only. For a longer record, or one that spans your whole organisation, create a trail or an event data store — and do it before you need it, because neither can reach back past the day you set it up.

We think a key has leaked. What now?

Deactivate the key immediately, then delete it. Review CloudTrail for unexpected activity, check every region for resources you didn't create (compute in an unused region is the classic sign), and contact AWS support about any fraudulent charges. Rotate anything the key could have reached.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

Learn more

AWS — IAM security best practices

AWS accounts & IAM access