AWS
Your quote says AWS. Here's the small part of it that matters.
The short answer
AWS is Amazon's computing rental business: hundreds of separate services, metered by the second, the gigabyte and the request. Almost every build uses the same handful. Somewhere to run code, somewhere to keep files, a managed database, and the networking that puts one address in front of it all. The rest of the catalogue is somebody else's problem.
Somebody put AWS in a proposal, and the word arrives carrying a reputation without carrying any meaning. Here's what kind of thing it is, the small part of it a normal build actually touches, and where choosing it costs you more than it gives you.
A rental catalogue, and you'll use four things from it
AWS is Amazon Web Services, the part of Amazon that rents out computing. Not a server with your name on it. Capacity, sold as separate metered products: processing time, storage space, database instances, network traffic. Each has its own name, its own console and its own line on the bill.
The catalogue is enormous. AWS advertises more than two hundred services, and the list grows every year. That number causes most of the intimidation and almost none of the relevance: a normal product uses a handful and ignores the rest.
For a web or mobile product the handful is predictable. Somewhere for the code to run. Somewhere to put the files people upload. A database that gets patched and backed up without anyone remembering to. And the networking that puts it all behind one address with a certificate on it. Everything else is a convenience sitting on those four, or an answer to a problem you don't have.
The way in
Per hour, plus traffic
One address, a certificate, and something spreading requests across whatever is running behind it.
Where the code runs
Per second
Rented machines, containers or functions. Billed while they're running, visitors or not.
Where the records live
Per hour
A managed database. AWS handles the patching, the backups and the failover, and you use it.
Where the files sit
Per gigabyte
Uploads, images, documents and backups, in storage that is cheap to fill and charged again to read.
Pay for what you use, in both directions
What AWS replaced was buying whole machines before you had any traffic. You sized for your busiest day, paid for that on your quietest, and guessing low cost you weeks and a purchase order.
Amazon started selling storage and computing capacity by the unit in 2006, and that one change explains nearly everything about how AWS behaves. Capacity arrives in minutes and leaves in minutes, and you're billed for what ran.
The direction people forget is the other one. Metered means metered whether or not anybody shows up. Plenty of ordinary components charge by the hour simply for existing: an address reserved, a load balancer with no traffic on it, a database instance nobody is querying. Nothing turns itself off, and the bill arrives after the month it describes.
That isn't a trap. It's what per-use pricing means, and it surprises everyone arriving from a flat monthly plan checked once a year.
What it's genuinely good at
Three things, and then one that isn't technical.
Load that changes shape rather than just size. A system quiet for eleven months and swamped for one grows and shrinks on the day instead of being sized for its worst hour forever.
Geography you can point at. AWS divides the world into regions, each built from several separate data centre clusters, so one building's bad day doesn't take the rest with it. You choose the region your records sit in, and two of them are Canadian.
Breadth, for the unusual requirement. Video processing, message queues, a data warehouse, machine learning. If a product needs one specific hard thing, there's usually a managed service to rent instead of building it. It's also how a design quietly acquires a dependency list nobody wrote down.
The one that isn't technical is people. AWS has held the largest share of this market for years, and the labour pool matches. You can hire for it, get three quotes on the same work, and hand it on when a relationship ends.
Where it stops being the right answer
For a marketing site, AWS is significant overhead for no gain. You can run one on it. You'll also acquire accounts, permissions, networking and a deployment process to look after, for a site a managed platform would have hosted without any of it. The one good reason to do it anyway is that everything else already lives there.
The second is a straightforward product with steady load and nobody to operate infrastructure. AWS hands you control over things you were never going to change, and the work of running them. A managed platform takes that work away, charges more per unit while you're small, and eventually meets a limit. Hitting it in year three beats staffing for it in month one.
The third is a team that has never operated anything. AWS assumes an operator. It won't mention the database filling up or the certificate nobody renewed, and it will let you build something wide open without complaint. Its shared responsibility model says so: security of the cloud is Amazon's, security in the cloud is yours.
AWS directly
A managed platform
- Getting the first version live
AWS directly: Accounts, permissions and networking before any code runs.
A managed platform: Live sooner, on defaults you don't get to argue with.
- What the bill does
AWS directly: Metered per service, and low only while somebody watches it.
A managed platform: Predictable, and higher per unit for as long as you stay small.
- When the load changes
AWS directly: Handles almost anything, once somebody configures how.
A managed platform: Handles more of the same. An odd shape meets a wall you can't move.
- Who has to be available
AWS directly: Someone who knows the platform, reachable when it breaks on a Sunday.
A managed platform: The vendor, until their limits become your problem instead.
- Leaving later
AWS directly: Data exports cleanly. Everything wired around it gets rebuilt.
A managed platform: Less to rebuild, because less of it was ever yours to take.
The real cost is a person, not the invoice
The bill is the visible number and it's usually the smaller one. The expensive part of AWS is that running it well is a specialist skill, priced as one, needed in small amounts at unpredictable moments.
So settle who that person is before you settle the platform. There are four honest answers: somebody on your staff, a written arrangement with whoever builds it, a firm on retainer, or a platform that removes the question. The fifth answer, that the developer who set it up will probably still be around, shows up as an outage two years later.
That question is the same on any cloud. What's specific to AWS is how much it assumes you'll operate yourself.
Worth knowing before you start
Ask which AWS account the system will live in, and whose email the root login sits on. If it's your builder's, you're renting the account as well as the servers.
Set a spending alert before launch, not after the first surprising month. AWS Budgets can notify you on forecast spend as well as actual, and billing data lags real usage, so treat any alert as an early warning.
Ask for the AWS services the design depends on as a written list on one page. For a first version, a dozen is a lot. The ones nobody can explain are what makes leaving expensive.
Price it yourself before anybody quotes an operating cost. The AWS Pricing Calculator is free and needs no account. You won't get the number right. You only need to know whether it's small and boring or large enough to change the design.
Put multi-factor authentication on the root login and then stop using it. AWS's own guidance is to lock that account away and give people their own identities, because ordinary permission rules don't constrain root the way they constrain everyone else.
Common questions
It depends on what you run and how closely anybody watches it. Per unit it isn't the cheapest place for a small, steady workload, and it keeps charging while nobody is using the thing. What it's good at is not paying for capacity you don't need yet, which is worth little if your load is small and flat.
Almost certainly not. A brochure site, a content site with a few forms, a store on a hosted commerce platform: none gain anything, and all pick up a maintenance job by moving. The exception is a business already running everything else there.
Not in a way that decides it for you. All three cover the same ground, and the differences that matter are rarely technical: what your team already knows, what your other systems sit beside, and who you can hire locally. Choose on those, and the shortlist usually picks itself.
The three names you'll see most. EC2 is a rented virtual computer, billed for the time it runs, with its attached disk charged whether it runs or not. S3 is file storage, billed per gigabyte per month plus what it costs to read the files back. RDS is a managed database, where AWS does the patching and the backups.
Not unless somebody chooses that. You pick which region a system runs in, and two of them are Canadian. Whether your business is required to use one is a legal question rather than a technical one, so ask your own counsel before the architecture is settled.
The data moves and the wiring doesn't. Files and databases export in ordinary formats. What gets rebuilt is everything that leaned on an AWS-specific service, which is why that list is worth asking for while it can still be shortened.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.