What we use AWS for
AWS comes into play when the requirement justifies it. A shop with audiences in several countries benefits from delivery close to the user. A campaign that generates its load over hours rather than months needs capacity that disappears again afterwards. Some corporate clients specify the platform — then we build there. And sometimes it is a single managed service that tips the decision, a database with automatic failover, for example.
The usual building blocks in our projects: EC2 or ECS for the application, RDS for MariaDB or PostgreSQL, S3 for media and backups, CloudFront for delivery, Route 53 for DNS. Add ElastiCache where Valkey or Redis should run as a managed service, and SES for transactional mail. All in European regions, usually Frankfurt. Often AWS is only one part of the picture: the application with us, individual services there — or the other way round.
How we build and look after AWS environments
We describe infrastructure as code, with Terraform or CloudFormation, instead of clicking it together in the console. That is not for its own sake: nobody can retrace an environment that was clicked into place, and nobody can rebuild it quickly when it matters. Rights are granted through IAM on the principle of least privilege, split across separate accounts for test and production. Networking, security groups and certificates belong to the build, not to the clean-up afterwards.
Looking after an environment includes the bill. We set up budgets and alarms, review regularly which resources are actually needed, and switch off whatever is only still running out of habit. Data protection is settled in advance: European regions, a data processing agreement under the GDPR, encryption at rest and in transit. For your data protection officer we supply the technical details needed for the record of processing activities. Support runs under individually agreed service level agreements.
Limits and alternatives
The house standard is our own Proxmox infrastructure, on servers in Germany. For predictable load it is usually more economical and entirely under our own control. Elasticity costs money even when nobody draws on it — and most mid-sized projects have a load curve that has barely changed in years. Run a steady baseline in an environment sized for a multiple of it, and you are paying for readiness rather than for work done.
Then there is lock-in. The deeper an application grows into managed services, the more work a later move becomes. That can be the right call — it should be a decision, though, not something you drift into. We recommend the route that fits the project, not the one that produces more line items on an invoice. If AWS is the better answer, we build there. If it is not, we say so before the quote and not after the first bill.