AWS Deployment Services
AWS will do anything you ask, which is the problem. The useful work is choosing the smallest set of services that meets your requirement and that your team can still operate once we have gone.
Discuss your projectChoosing compute
The decision that most affects both your bill and your operational burden.
| Best for | Watch out for | |
|---|---|---|
| ECS on Fargate | Standard web applications in containers. Our usual default | Costs more per unit than EC2; worth it for not managing servers |
| Lambda | Event-driven work, scheduled jobs, spiky and low-volume traffic | Cold starts, execution time limits, and cost at sustained high volume |
| EC2 | Workloads needing specific instances, GPUs, or long-running processes | You own patching, scaling and availability |
| App Runner or Elastic Beanstalk | Small teams wanting the least AWS to think about | Less control; can become limiting as requirements grow |
| EKS (Kubernetes) | Many services, a platform team, genuine need for orchestration | Substantial ongoing burden. Rarely right for a small team |
For most applications we would propose ECS on Fargate with RDS behind it. It is unglamorous, well understood, and a team of three can operate it. If your requirements genuinely warrant Kubernetes we will say so, and we will say when they do not.
What we set up
Infrastructure as code
Terraform, or CDK where your team prefers it. Environments reproducible from the repository, and changes reviewed in a pull request rather than typed into the console at speed.
Networking that is not the default
A VPC with private subnets for the database and application, public only where it must be, and security groups scoped to what actually needs to talk to what.
Database
RDS PostgreSQL with automated backups, point-in-time recovery, and multi-AZ where your availability requirement justifies the cost. Never on a public subnet.
Secrets
Secrets Manager or Parameter Store, injected at runtime, separate per environment. Not in environment files, and not in the repository.
IAM on least privilege
Roles scoped to the specific actions and resources needed. The step most often skipped, and the one that determines how bad a compromise would be.
Delivery and caching
CloudFront in front of static assets and the application, with S3 for user uploads and signed URLs rather than public buckets.
Monitoring
CloudWatch alarms on the handful of signals worth waking someone for, plus error tracking. We keep the alert list short on purpose.
Backups you have restored
Backups configured and a restore actually performed during the engagement. An untested backup is a belief.
Cost control, as part of the build
AWS bills grow quietly. These are the findings that recur, roughly in order of how often we see them.
- Instances and tasks sized for a load that never arrived, often several times larger than the traffic justifies.
- Non-production environments running at full size overnight and at weekends, when nobody is using them.
- Unattached EBS volumes and years of old snapshots nobody has reviewed.
- NAT Gateway charges, which are frequently a surprisingly large line and sometimes avoidable with different networking.
- Data transfer out, which nobody models in advance and which can dominate a bill for media-heavy applications.
- CloudWatch log retention set to never expire, accumulating cost indefinitely for logs no one will read.
- Savings Plans or Reserved Instances unused on genuinely steady workloads, which is money left on the table.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch