AWS — Frequently Asked Questions
Practical answers on running workloads in AWS — account structure, IAM without long-lived keys, what actually drives the bill, when serverless fits, and how to avoid the mistakes that are expensive to undo.
Accounts and structure#
How many AWS accounts should we have?#
More than one. At minimum, separate production from everything else.
The account is the strongest isolation boundary AWS provides: a policy mistake in one cannot reach into another, blast radius is contained, and costs are attributable without any tagging discipline. A common structure is one account per environment per workload, under an organisation with centralised billing and guardrails.
The objection is always administrative overhead, and it is real — but it is a one-time setup cost against a permanent boundary. Merging accounts later is easy; splitting a shared account after two years of resources have grown into each other is not.
What should live in the management account?#
As little as possible. Organisations, billing, and guardrails — no workloads. It is the account with the most power and it should be the account with the least activity.
Identity#
Should we still create IAM users?#
Rarely. Prefer identity-centre/SSO for humans and roles for workloads, so credentials are short-lived and centrally revocable.
Static access keys are the credential that leaks. They end up in commits, CI configuration, screenshots and laptops, and they do not expire. If you must have one, give it an owner, an expiry and a rotation date, and record it somewhere a human reviews.
How permissive should the first policy be?#
Start restrictive and widen on evidence. The opposite order — start broad, tighten later — never gets a second half, because nothing breaks to remind you.
Read the access logs to see what was actually used, then write the policy from that. Note the trap: a permission only shows up in the logs if someone exercised it, so a monthly job's needs will not appear in a week of data.
What about the root user?#
Secure it and stop using it. MFA on, no access keys, credentials stored where two people can reach them in an emergency and nobody reaches them otherwise. There are only a handful of tasks that genuinely require it.
Cost#
Why is the bill higher than expected?#
In most accounts, in this order: compute left running that nobody owns; data transfer, particularly across availability zones and out to the internet; storage that accumulates because no lifecycle rule was ever set; over-provisioned databases; and forgotten non-production environments running at production size.
Almost none of that is a pricing surprise — it is an ownership problem. Tag everything with an owner and an environment from the first resource, and the anomalies become obvious rather than archaeological.
Are savings plans and reserved capacity worth it?#
Once your baseline is stable and understood, yes — the discount is substantial for load you were going to run anyway. Before that, no: committing to a baseline you have not measured turns a variable cost into a fixed one at the wrong level.
Measure for a quarter, commit to the floor rather than the average, and keep the peak on demand.
Is serverless cheaper?#
For spiky, low-baseline workloads, usually. For steady high-throughput workloads, frequently not — per-request pricing that is excellent at 10,000 requests a day can be poor at 10 million.
The cost that matters is rarely the line item. Serverless removes patching, capacity planning and some classes of failure; it adds cold starts, execution limits, and a harder local development story. Decide on the whole picture and record the reasoning.
Building#
Managed service or run it ourselves?#
Take the managed service unless you have a specific requirement it cannot meet. What you are buying is not the software — it is the patching, the backups, the failover and the on-call rotation you no longer staff.
Run it yourself when you need a version or extension the service does not support, when the cost difference is large and demonstrated, or when portability is a stated requirement with a real reason behind it.
How do we handle secrets?#
In a secrets manager or parameter store, referenced by role, never in environment variables committed to a repository and never in an image. Rotate them, and make sure the application picks up the rotation without a deploy — otherwise rotation is theoretical.
What does multi-region actually require?#
More than duplicated infrastructure. It requires deciding what happens to data written on both sides, how failover is triggered and by whom, how DNS moves, and how you fail back. Most organisations that say they want multi-region want a tested recovery process in one region, which is far cheaper and addresses the outage they are actually likely to have.
Be honest about which you are buying, because the difference is an order of magnitude in cost and complexity.
Operations#
What should we monitor first?#
Whatever tells you a customer is affected — error rates and latency at the entry point — then saturation of the resource most likely to run out. Alarms should page a person only when a person must act; everything else belongs on a dashboard.
An alarm that fires regularly and is routinely ignored is worse than no alarm, because it trains the team to ignore the class.
How do we know our backups work?#
By restoring them, on a schedule, and recording how long it took. Backup success metrics measure that a job ran, not that the data is usable — the two diverge quietly.
Keep backups in a separate account. A backup that an attacker with account access can delete is not protecting you against the scenario you bought it for.
What is the most expensive mistake to undo later?#
Account structure, followed by tagging and identity. All three are cheap on day one and become a migration project after a year of growth. If you are early, spend the day on them now.