If you're running Drupal on AWS, you've probably had a Drupal agency promise you speed, scale, and "best practice" architecture. Maybe they even threw in a DevOps package or performance layer. And at first, everything looks great. The site loads fast. Deployments are clean. AWS is humming in the background.
Then the monthly bills start creeping up. The EC2 footprint grows. Your RDS usage spikes during routine traffic. Backups, logs, assets—they all start adding weight. Before you know it, you're spending 2x what you budgeted. And the agency? Silent.
This is the part they don’t tell you. Most Drupal agencies know how to build on AWS. Very few know how to optimize for it. And the difference between those two skills? That’s where your money goes.
Why Agencies Build for Function, Not Efficiency
To be clear, most Drupal agencies aren’t acting in bad faith. They’re simply focused on what they’ve always been paid to do- launch the site, make it work, and walk away.
The typical agency dev team builds a scalable architecture because it's safe. They choose EC2 over ECS because it's familiar. They duplicate staging environments because it's faster than scripting teardown logic. They suggest RDS with provisioned IOPS because no client wants to hear “it might be slow at launch.”
But here’s the thing: none of those choices are wrong on Day 1. They just become expensive on Day 30, 90, or 180. And by then, your budget is bleeding slowly and quietly.
Agencies Rarely Audit What They Build
Ask yourself: When was the last time your agency re-evaluated your AWS setup after go-live?
Most don't. Once the site is up, the attention moves to support tickets, small feature releases, or redesign cycles. The AWS layer becomes invisible. But AWS doesn't forget. It bills for everything- even unused environments, underutilized volumes, and redundant snapshots from a site feature no one uses anymore.
An optimized AWS setup is not a “set and forget” job. It’s an evolving puzzle. And the best cost-saving opportunities appear after launch, when real-world usage shows what parts of your infrastructure are overkill.
Agencies don’t want to admit that. Because optimization requires revisiting the choices they made. It requires telling clients: “We could have done this differently.” And that’s not a conversation most vendors are built to have.
The Real Cost Isn't in the Code. It’s in the Assumptions.
Here’s what rarely makes it into agency proposals:
- That 95% of Drupal traffic could be cached, making many EC2 requests unnecessary
- That S3 needs lifecycle policies from day one, or it silently becomes a junk drawer
- That RDS performance doesn’t come from IOPS- it comes from efficient Views and smart cron jobs
- That static assets from Drupal media could live entirely outside of your origin server
What agencies deliver is a working Drupal site on AWS.
What they assume is that you’ll figure out the rest.
Who Actually Pays the Price? The CIO.
The agency walks away with a successful delivery. But it’s the CIO, or the Head of Infra, who’s left explaining why infrastructure costs are 40% higher than projected. Why there's no room for innovation in the budget. Why speed improvements stall because the platform has become fragile from too much scale and not enough strategy.
This is why more enterprises are separating build partners from optimization partners. One builds the house. The other makes it efficient, breathable, and future-ready.
At Valuebound, we’ve seen this pattern across global enterprises. The build is fine. The setup works. But the cost-to-performance ratio? Broken.
A New Kind of Partnership Is Emerging
CIOs are now looking for Drupal partners who go beyond “launch-ready.” They want partners who understand AWS billing, who can draw a direct line from a Drupal module to a compute charge. They want to know which part of the site is burning cycles and why. They don’t just want DevOps. They want CostOps.
And most agencies? They’re not built for this shift. They’re still billing for tickets and modules. They’re still pitching new features when what the client really needs is fewer moving parts and lower bills.
Final Thought: Building Smart is the New Building Fast
This isn’t about blaming agencies. It’s about evolving expectations. The old model was “get it live.” The new model is “make it last, and make it lean.”
So, if you’re running Drupal on AWS, ask yourself:
- Do you know which service costs the most?
- Are your staging environments scaling for no reason?
- Are your modules optimized for real usage or theoretical scale?
- Is your infrastructure aligned with your traffic, not just your ambition?
If the answer is “we’re not sure,” then maybe it’s time to stop asking for new features and start asking for answers.
