AWS in Practice: What to Learn First and What the Bill Will Say

AWS has over two hundred services. You will use about eight.

The difficulty with AWS is not technical depth — it is that the surface area is enormous, the naming is unhelpful, and there are usually four ways to do the same thing with very different bills. Everything below is aimed at the person who needs to make sensible choices without spending six months becoming a specialist.

The services that cover most needs#

Master those and you can build almost anything. The rest of the catalogue is for specific problems you will recognise when you have them.

The cost mechanics that surprise people#

AWS bills are rarely surprising because of the obvious line — the servers. They are surprising because of these.

Data transfer out. Moving data into AWS is generally free. Moving it out to the internet is charged per gigabyte, and it accumulates quietly. Transfer between availability zones is also charged. A chatty architecture spread across zones can cost more in transfer than in compute.

Anything idle but running. A stopped EC2 instance still bills for its attached storage. An unattached IP address bills. A load balancer with no traffic bills. Development environments left running overnight and at weekends are, in our experience, the most common single source of waste — roughly two-thirds of the hours in a week are outside working time.

NAT Gateway. A managed component many architectures include by default. It has an hourly charge and a per-gigabyte charge, and it frequently appears in the top five line items of bills where nobody remembers choosing it.

Storage that is never deleted. Snapshots, old backups, log data with no retention policy. Each is small; together they compound indefinitely.

Cross-region traffic. Usually the result of an architecture decision nobody revisited.

The practical defence is unglamorous: turn on cost allocation tags, set a budget alert on day one, and look at the bill monthly with someone who can explain each line. Most organisations find 20–30% of spend is on things nobody intended.

Decisions that are painful to change later#

Some choices are easy to revise. These are not — get them right at the start.

Account structure. Use separate accounts for production and non-production, under an organisation. This gives you a hard blast radius: a mistake in development cannot touch production, and costs are separated without any tagging discipline. Retrofitting this after everything is in one account is a migration project.

Region. Data residency, latency and pricing all vary. Moving later means moving data, and data has gravity.

IAM from the start. No long-lived access keys for humans — use identity federation. Roles, not users, for applications. Least privilege from day one, because widening permissions is easy and narrowing them after everything depends on them is not.

Tagging. Owner, environment, cost centre, on every resource. Enforce it. Without tags you cannot answer "what is this and can we delete it?", and untagged resources are never deleted because nobody dares.

Infrastructure as code. Console-created resources are invisible, unreviewable and unreproducible. The moment you have more than a handful, describe them in code.

Availability without over-engineering#

Multi-region active-active architectures get talked about far more than they get justified. A realistic ladder:

1. Single AZ — cheapest. Acceptable for development and for workloads that tolerate downtime.
2. Multi-AZ within a region — the sensible default for production. Survives a data-centre failure, costs modestly more, and is largely a configuration choice on managed services.
3. Multi-region — survives a regional failure. Substantially more complex and expensive; data consistency becomes a real engineering problem.

Most organisations should sit firmly at level 2 and put the money they saved into tested backups instead. A tested restore protects against far more likely failures — deletion, corruption, ransomware — than a second region does.

Security defaults worth setting immediately#

• MFA on the root account, then lock it away and never use it for daily work
• CloudTrail on, logging to a bucket in a separate account if possible
• Block public access on S3 at the account level, then grant exceptions deliberately
• Encryption at rest on by default — it is effectively free and hard to retrofit
• Security groups scoped to specific sources, not 0.0.0.0/0
• A billing alarm, which is as much a security control as a financial one — unexpected spend is often the first sign of compromised credentials

Where people get stuck#

Choosing between EC2, ECS, Lambda and everything else. A reasonable heuristic: Lambda for event-driven work with variable load; Fargate for containers where you do not want to manage servers; EC2 when you need control or have licensing constraints. You can be wrong and change later — this is the reversible decision people agonise over while getting the irreversible ones by default.

Networking. VPCs, subnets, route tables and gateways are the single biggest source of "why can this not reach that". Learn the basics properly; it repays the time.

Assuming managed means maintenance-free. RDS still needs version upgrades, parameter tuning and someone watching for storage filling up.

FAQ#

Is AWS cheaper than running our own servers?#

Not automatically. It is cheaper for variable load, for avoiding capital expenditure, and for capabilities you would not build yourself. It is often more expensive for steady, predictable workloads left running continuously. The saving comes from turning things off, which requires someone to look.

Do we need a solutions architect?#

For a straightforward application, no. For anything touching networking, compliance or significant spend, a few days of experienced review early is cheap relative to what it prevents — particularly around account structure and IAM, which are the expensive things to fix later.

AWS, Azure or Google Cloud?#

For most workloads the technical differences matter less than existing commitments, the skills you have, and where your data must live. If you are already heavily Microsoft, Azure has genuine integration advantages. Otherwise, pick one and go deep — spreading across providers to "avoid lock-in" usually produces the complexity of all three and the discounts of none.

How do we control costs?#

Budget alerts on day one, mandatory tags, turn off non-production outside working hours, set retention on logs and snapshots, and review the top ten line items monthly. Reserved capacity and savings plans matter once your baseline is stable — commit to what you provably use, not to what you hope to use.

Is our data safe on AWS?#

The infrastructure is almost certainly more secure than what you would run yourself. The shared responsibility model means AWS secures the platform and you secure your configuration — and essentially all publicised "AWS breaches" have been customer misconfiguration, most often a publicly readable storage bucket.

What about vendor lock-in?#

Real, and worth managing rather than fearing. Containers, standard databases and infrastructure as code keep you reasonably portable. Deep use of proprietary managed services buys real productivity at the cost of portability — that is a legitimate trade, as long as it is made deliberately.

How long to get productive?#

An engineer can deploy something real in days. Being confident about networking, IAM and cost takes months. The fastest route is a small production workload with a real budget attached — nothing teaches AWS cost mechanics like owning a bill.

What else is coming for AWS