AWS

What renting infrastructure changes

Before cloud platforms, capacity was a purchase. Servers were specified, ordered, delivered, installed and configured, on a timescale of weeks or months.

The consequence was that capacity had to be predicted in advance, and predictions were made generously because running out was worse than over provisioning. Organisations owned hardware sized for a peak that arrived rarely.

Cloud platforms change this to a request. Capacity is created when needed and released when not.

That is the fundamental shift, and everything else about these platforms follows from it.

Breadth, and what it means

AWS offers a very large number of services, covering computing, storage, databases, networking, analytics, machine learning and much more.

The breadth is genuinely useful. Most requirements have a service, so infrastructure that would have to be built and operated is instead consumed.

It is also the platform's most confusing characteristic. Several services frequently address overlapping needs, differing in ways that matter for particular cases and are not obvious from the names.

The practical approach is to start from the requirement rather than the catalogue. Deciding what the application actually needs, then finding which service fits, works better than surveying what is available.

Regions and zones

Services run in regions, geographic locations around the world.

Each region contains multiple availability zones, which are separate locations with independent power and networking, close enough for fast connections between them.

The distinction matters for two reasons.

Resilience. An architecture spanning zones survives the loss of one. This is the standard arrangement for anything that must stay available, and it is a design decision rather than something provided automatically.

Location requirements. Where data may be held is a constraint for many organisations, and choosing a region is how it is satisfied.

Access control

Policies govern what each identity may do, attached to users, roles and resources.

This is one of the more intricate parts of the platform and one of the most consequential.

Policies that are too restrictive break applications in ways that are confusing to diagnose. Policies that are too permissive create exposure, and the exposure is invisible until something goes wrong.

The principle worth applying is granting what is actually needed rather than what is convenient. Broad permissions granted to get something working, and never narrowed afterwards, are a recurring pattern that deserves resisting.

AWS publishes guidance on this, and it is worth reading properly rather than learning by trial.

Cost

Charging follows use, and each service has its own model covering compute time, storage, requests and data transfer.

Two things surprise people consistently.

Costs accumulate from many small sources. No single item is large, and the total is larger than expected because there are many items.

Data transfer is frequently underestimated. Moving data between regions, or out of the platform, is charged, and architectures that move a great deal of data can find this a significant proportion of the bill.

Cost management deserves setting up deliberately: tagging resources so spending can be attributed, alerts on unexpected increases, and periodic review of what is running. Doing this early is far easier than reducing spend afterwards.

The commitment question

How committed an organisation becomes depends on what it uses.

Virtual machines running standard software are relatively portable. The same software runs elsewhere.

Services specific to the platform provide more capability and less portability. Building on them means moving would be substantial work.

Neither position is wrong. Using managed services rather than building equivalents is frequently the right decision, and it should be made knowingly rather than discovered later.

Who uses it

AWS is used by platform engineers, infrastructure teams, developers and data teams. It is used by organisations of every size, from those running a single application to those operating their entire estate on it.

Points to consider

AWS is a commercial platform and the official documentation is the reference for services, pricing and limits, all of which change frequently.

Access control deserves proper study. It is where the most consequential mistakes are made.

Cost requires active management rather than periodic surprise. Controls and visibility should be in place before usage grows.

Service breadth means choosing well matters. Understanding the differences between similar services prevents building on one that does not quite fit.

Getting started

The official documentation covers every service along with guidance on architecture and security. Starting from a specific requirement, identifying the service that meets it, and reading that service's documentation properly is more effective than attempting to survey the platform.