AWS gives you every part a system could need, and you pay for choosing them.
AWS is a catalogue, not a product. Servers, databases, queues, file storage, email, identity and monitoring all sit under one account, and a small company can rent any of them within minutes. Most business systems need about six, so the skill lies in leaving the rest alone.
That range is the appeal. It is also the trap. A company that rents a database today can end up with forty services nobody remembers creating. Each one quietly adds another line to the bill every month, and finding the cause later takes real effort.
AWS is a set of rented computing parts that Amazon runs in data centres around the world. You hire servers, storage and databases by the hour instead of buying machines. Everything is controlled through a web console or code. You pay for what is switched on. Forgotten resources keep costing money.
Where it earns its place.
What it is genuinely good at
- Storing files cheaply and durably in S3, from invoices to customer uploads
- Managed databases with automatic backups, through RDS or Aurora
- Queues and scheduled jobs, so slow work leaves the screen alone
- Growing from one small server to many without moving provider
- Fine-grained permissions, so each service touches only what it needs
Where it turns against you
The catalogue is wide and the billing is detailed. Both can hurt a team that has never run cloud infrastructure before, because nobody warns you which choices are hard to undo.
- A bill built from dozens of small meters, hard to predict in advance
- Data leaving AWS is charged, which makes moving away expensive
- Permission settings that are easy to make too open by accident
- Dozens of overlapping services for the same job, with unclear differences
- A console that rewards experts and confuses the first-time owner
None of this is hidden. It simply means someone must own the account, watch the bill and set alerts on the first day.
The parts of AWS we reach for
- EC2 or a container service for the application itself
- RDS for PostgreSQL or MySQL, with backups switched on and tested
- S3 for files, with private access by default
- SQS and EventBridge for queues and timed jobs
- CloudWatch for logs and alerts, and SES for transactional email
The upkeep and the cost nobody quotes
Renting infrastructure does not remove the work. Amazon looks after the buildings and the hardware, and everything above that line stays with you.
- Budget alerts and a monthly look at what is actually running
- Security patches on any server you manage yourself
- Old snapshots, unused disks and idle addresses that keep billing
- Restore tests, because a backup nobody has restored is a hope
- Someone who knows the account well enough to explain the invoice
How AWS fits with the rest of a system
AWS rarely stands alone. It hosts the application, while the code, the deployment pipeline and the domain name usually live with other providers and need to be wired together.
- Code and deployment pipelines often run from GitHub Actions
- Infrastructure described in Terraform, so the setup can be rebuilt
- DNS and edge protection sometimes sit with Cloudflare
- Identity can come from Cognito or from your existing company directory
- Monitoring tools outside AWS can read the same logs
When this is the right choice.
- You expect traffic or data to grow and want room without a migration later
- The system needs several managed parts, such as a database, a queue and file storage
- Your customers or compliance rules ask for hosting in a specific region
- Someone on your side, or ours, will watch the account every month
- You already use AWS for other work and want everything under one roof
When it is not.
- A brochure site or small internal tool, where a plain virtual server is cheaper to understand
- A team with nobody to own the bill, the permissions and the updates
- A system with steady, predictable load, where a fixed-price host may cost less
- A company that needs one flat monthly price, because AWS bills by usage
- Anyone who simply wants the lowest effort, since a managed platform hides most of this
Questions we are asked about it.
Is AWS too big for a small business?
Not always, but it is more than most need. A handful of its services cover nearly every business application, and the rest can be ignored. If you only need a website and a database, a simpler host is easier to run.
How do we avoid a surprise bill?
Set budget alerts the day the account opens. Tag everything by project, then review the bill once a month for services nobody recognises. Most surprises come from forgotten test resources and data leaving the platform.
Can we move off AWS later?
Yes, with some planning. Standard databases, containers and files move without much trouble. Services that exist only on AWS, such as its queues or serverless functions, need rewriting, so we use them with care.
Who owns the AWS account?
You do, always. We work inside it with limited permissions, and we hand over a written map of what runs where. The account is never held in our name.
Do we need Kubernetes on AWS?
Almost never for a business system. A few containers on a managed service do the job with far less to maintain. Kubernetes earns its place only when many teams ship many separate services.
AWS or Azure for our company?
It depends on what you already use. If your people live in Microsoft 365 and run .NET or SQL Server, Azure often fits more naturally. For most other web systems either works, and the deciding factor is usually who on your side already knows it.
Services that use it.
What it sits with.
Not sure Amazon Web Services is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements