The short answer
AWS support means someone else runs your Amazon Web Services environment: instances, storage, networking, backups, patching and the bill. We're AWS Certified, we work from Brisbane, and we respond in 1 to 3 hours. Most accounts we inherit pay for capacity nobody uses.
What we look after
- Account and environment audit, in read only, before we change anything
- Instance right sizing, patching and operating system updates
- Backups and snapshot retention that actually has a retention rule
- Security groups, access keys and identity permissions reviewed
- Monitoring, alerting and capacity trends through managed support
- Cost review and tagging so the bill can be read by project
- Deployment for applications our team builds. See apps and software
- Multi cloud work where it's warranted, including Azure integrations
Where AWS bills leak
AWS doesn't overcharge. It charges precisely, for everything, including the things you forgot you switched on.
Instances sized for a launch that never came.
Someone picked an instance before go live based on a guess about traffic, and nobody went back when the guess turned out wrong. Two years later it sits at 4% processor use and you pay for the other 96%. The same account is usually running an older instance generation as well, when the current one is faster and cheaper for the same work.
Snapshots nobody deletes.
Automated snapshots are the right call until you notice the policy has no expiry, so four years of daily copies are still billed. Then there are volumes left behind when instances are terminated, sitting unattached and charged monthly, plus old machine images holding snapshots of servers that no longer exist.
Data transfer between availability zones.
Traffic crossing zones inside the same region is charged, in both directions. An application server in one zone chatting constantly to a database in another can cost more in transfer than the database costs to run, and nothing in the console makes that obvious.
Idle load balancers.
One with no healthy targets bills by the hour exactly like a busy one. Static IP addresses attached to nothing are charged too.
Regions nobody looks at.
The console shows one region at a time, so a test environment a contractor spun up in Virginia is invisible from the Sydney view and has been running ever since.
How to audit it.
Open Cost Explorer, group by service, then by usage type, across three months rather than one, because a single month hides anything spiky. Turn on cost allocation tags so spend traces back to a project. Run the built in right sizing reports, then check every region individually. Do the right sizing before committing to any reserved capacity, because committing to the wrong size locks the waste in for a year.
What you'll actually save.
It depends on how long the account has gone unmanaged. One nobody has reviewed since launch usually has obvious waste. One that's already tagged and right sized may have very little, and we'll say so. Anyone quoting a percentage before looking is guessing.
We'll audit the account in read only and tell you what we'd change before you commit to anything.
Why the Sydney region matters
Every request between an Australian visitor and a server in North America crosses the Pacific and back. One round trip is a fraction of a second. A page making dozens of them, plus the database calls behind each, turns that into something people feel on mobile.
Running in the Sydney region removes the distance. It also answers the question you'll eventually get from a government, health or finance client: where is our data physically stored? Onshore storage is a contract requirement in more tenders every year, and "somewhere in the cloud" isn't an acceptable answer.
How we take over an account
Read only audit
We look before we touch. Running resources, every region, security posture and three months of spend.
You get the findings
What's wasteful, what's risky, and what's fine. Including the parts we'd leave alone.
We tidy and harden
Right sizing, retention rules, permissions and alerting, in an agreed order.
We run it
Patching, backups, capacity, and 1 to 3 hours when something needs a person.
Who this suits, and who it doesn't
It suits businesses running an application on AWS with no in house infrastructure person, teams whose developer has moved on, and anyone whose bill has grown without an explanation.
It's a poor fit if you're a static brochure site. You'd be paying for complexity you don't need, and a VPS would do the job for less.
Why clients hand AWS to us
AWS Certified, and we build as well as host.
The people running your infrastructure write software, so they read the application before resizing the server under it.
We respond in 1 to 3 hours.
A published number, not a promise about fast support.
No lock in contracts.
Month to month. The account stays in your name and your billing details.
"Isn't AWS more expensive than normal hosting?"
Per gigabyte, usually, and that's the wrong comparison. AWS earns its price when you need to scale or meet a compliance requirement, and it's poor value when you don't. We've moved clients off AWS when that was the honest answer.