Scalable, secure infrastructure with a bill you can explain, defined as code in your repository so leaving us is a permissions change.
The danger with AWS isn't capability, it's accidental complexity and an unexplainable invoice.
Everything defined in your repository, so it can be reviewed, rebuilt and audited instead of clicked together.
Right-sized instances, tagged resources and alerts on spend, so surprises arrive as a warning rather than an invoice.
Narrow roles, private networking and encrypted storage set up at the start, when it's still cheap to do.
Automated backups plus a rehearsed restore with a measured time, because untested backups are decoration.
We build and deploy into infrastructure you own. The bill comes to you, the access is yours, and leaving us is a permissions change rather than a migration.
Everything defined in files in your repository, so the environment can be rebuilt from nothing and nobody has to remember what was clicked.
The usual first step: containers, a managed database, backups that are tested, and a deploy that's not a person copying files.
Right-sizing, storage tiers and switching off what nothing uses. Most bills we inherit have a straightforward third to remove.
A backup nobody has restored is a hope. We rehearse the restore and write down how long it takes.
Written for someone deciding, not for someone who already knows. Skip it if you do.
Amazon's rented computing: servers, databases, storage, networking and a few hundred more specialised services, charged by use. It's the largest provider and the one with the most of everything, including the most ways to spend money by accident.
Elasticity and other people's operations. You're not buying hardware; you're buying the ability to have ten machines on Friday and one on Sunday, and the ability to use a managed database rather than employing someone to patch one at midnight.
Almost always three places: machines that idle at full price, storage nobody deleted, and data leaving the network. None is complicated; all of them require someone to look. A bill that has never been reviewed is usually a third larger than it needs to be.
Use plain containers, a normal database and object storage and you can leave in weeks. Build on the proprietary services and you can't, at any price. We default to the portable option and tell you explicitly when a proprietary one is worth the trade.
Almost always fixable, and the first review is worth more than any architecture change.
Both a security and a continuity problem. Fixing it's a day of work and it's the day best spent.
Then you don't know that you have one. This is the cheapest test in infrastructure and the one most often skipped.
It's expensive when it's oversized and untagged. Sized to actual load, with a monthly look at the bill, it's usually competitive and always flexible.
Almost certainly not at the start. Most applications run happily on simpler container services, and adopting Kubernetes early buys complexity you then have to staff.
That's why we keep the application in containers and the infrastructure in code. Moving is work, but it's not a rebuild.
Yes, and we prefer it. You own the account, we get the access we need, and ending the relationship doesn't mean moving anything.
Per unit, yes. In total it depends on what you would otherwise pay someone to do. For a steady, small workload a plain server can be cheaper, and we'll say so.
A few lines are enough to start. You get a reply within two working days.
