Why We Rely on AWS

Hosting is the most boring decision in a web project — until it goes wrong. Then it becomes the most expensive. Over the past two years we have deliberately reduced the convenience decisions and consolidated on Amazon Web Services, and in this post I describe why.

Why not Hetzner or bare metal?

The honest answer first: per CPU hour, Hetzner and comparable providers are almost always cheaper than AWS. If your only metric is the cost of power and bandwidth, you do not end up on AWS. We calculate the full lifecycle of a setup: auto-healing after a node failure, backups with a defined restore time, encryption at storage and network level, automatic patching of the database, audit logs that hold up in a later penetration test.

All of that is doable on Hetzner — but costs engineering time we would rather invest in our clients' applications. On AWS it is built in, tested, documented. For a mid-market TYPO3 setup, this difference is often half of the total cost of ownership, and it only becomes visible when something breaks.

Scalability as a property, not a promise

Scalability reads similarly on every vendor's slide. In practice it is a property of the concrete services. For TYPO3 and Symfony applications we typically use one of two compute topologies — EC2 instances in an Auto Scaling Group for clients with a classical hosting mindset, or Amazon EKS for clients with in-house Kubernetes competence. In both cases Amazon RDS for MySQL sits behind as the managed database, and CloudFront in front of the static assets and HTTP caching. Both topologies scale in both directions without nightly interventions: when a marketing campaign goes live, the Auto Scaling Group brings up new instances or the Horizontal Pod Autoscaler adds pods; when the peak is over, they go away again.

More important to us than the maximum is the lower bound. We configure the Auto Scaling Group or the Horizontal Pod Autoscaler so it scales down overnight and on weekends to a minimal configuration that still absorbs the morning burst. On the database side, we size the RDS instance for the regular daily peak, not for the worst case — the rare outliers are absorbed by the application via CloudFront caching.

Security as a delivered foundation

On the security topic, many teams underestimate how much a cloud provider brings out of the box today — and how much they would have to build themselves on a classical root server. AWS delivers encryption at rest via KMS, encryption in transit via ACM-managed certificates, granular permissions via IAM and continuous conformity checks via AWS Config. Anyone wanting to run an ISO 27001-conform platform has the bulk of the technical measures met from day one.

Concretely, we run all workloads in the Frankfurt region (eu-central-1), sign the data-processing agreement directly with AWS Europe SARL, and log every access via CloudTrail. For our clients, this means a GDPR audit does not end in an audit marathon but in readable documentation.

A footnote at the end: security on AWS is not autopilot. Misconfigured IAM policies are a real risk class. We review permissions at least every six months, disable unused accounts, and consistently work with roles rather than long-lived keys. That is discipline, not a feature.

Cost efficiency, if you do the maths

AWS has a reputation for being expensive. That is true for the list price, and not true for the effective price if you use the available levers. Three levers pull the largest effect.

Graviton instances. Graviton is AWS's own ARM64 processor family. In our load tests it delivers roughly 20 percent more performance at about 20 percent lower price than comparable Intel and AMD instances on x86_64. For PHP workloads, the switch is typically a new AMI or container image build, in the vast majority of cases without code changes. We use Graviton by default, except where a third-party tool forces us onto x86.

Reserved Instances and Savings Plans. Anyone running predictable production workloads for one or three years gets 30 to 50 percent off. We decouple the reservation from the concrete instance shape via Compute Savings Plans — that keeps the architecture changeable without losing the discount.

EC2 Spot Instances for background jobs. Cron jobs, image conversions, reports — anything that may be interrupted and restarted runs on EC2 Spot Instances at around 30 percent of the regular on-demand price. The precondition is clean job idempotency, which is good engineering hygiene anyway.

We build a dedicated cost dashboard and a cost-anomaly alert for every client. A test EC2 instance left running in a sandbox region or a runaway loop surfaces within hours, not on next month's invoice.

What a typical TYPO3 stack looks like with us

So this does not stay abstract, here is the architecture we currently roll out for mid-market TYPO3 11 LTS platforms (and the first pilot setups on the upcoming v12):

• A dedicated VPC per client, with private subnets for application and database, public subnets only for the load balancers.
• For the PHP workers, one of two variants depending on the client setup: either EC2 instances in an Auto Scaling Group behind an Application Load Balancer with AMIs built and versioned via Packer in CI, or Amazon EKS with the PHP workers as a Deployment behind the AWS Load Balancer Controller. Both scale on CPU and request metrics.
• Amazon RDS for MySQL as the managed database, Multi-AZ, automated snapshots with 35 days retention plus daily logical backups into a separate S3 bucket.
• S3 for file uploads and backup archival, lifecycle policies into S3 Glacier Deep Archive after three months.
• CloudFront in front of all static delivery plus the TYPO3 frontend; HTTP caching with a defined Vary header, signed URLs for protected downloads.
• Route 53 for DNS with health checks, so that a partial regional disruption does not lead to complete unavailability.
• Secrets Manager for database credentials and external API keys, automatic rotation where possible.

The infrastructure of this stack lives as a Terraform module in the client repository and rolls out via GitLab CI. A new environment — staging, demo, integration — is a matter of minutes, not weeks.

What we have learned in operations

Three observations from the day-to-day that are on no vendor's slide.

Multi-AZ does not pay off in disaster, it pays off at patch time. RDS Multi-AZ is not primarily protection against a failed data centre — that rarely happens in Frankfurt — but it lets us run minor and major database upgrades through a failover window of a few seconds. We simply do not have this property on a classical root server.

IAM discipline is an investment with delayed payoff. The first three months in which you consistently work with roles, tightly scoped policies and permission boundaries feel like overhead. By the third incident in which a colleague did not copy long-lived keys into the wrong Slack channel, the payoff is visible.

Cost surprises come from data egress, not from compute. The biggest unexpected items on an AWS bill are usually not compute, but data transfer out of AWS. Anyone putting CloudFront correctly in front of the frontend keeps the expensive egress small. We check that actively on every new project.

Conclusion

AWS is not the right choice if the only lever is the hourly price of a small virtual machine. Anyone wanting to run a TYPO3 platform with productive load, serious backup requirements and a defensible GDPR position gets structurally further today with AWS than with classical web hosting. These are exactly the clients we support — from the architecture decision to running operations.