Abstract:
AWS is a powerful platform, but it often feels like one where every default setting can cost you, and understanding why takes more time than most small teams can spare. Our recent experiences with two separate billing issues highlight how difficult it can be to navigate AWS’s complexity, even when you are acting in good faith.
Case 1: The Long Road to Billing Relief
Our first issue began with an unexpected spike in AppSync and CloudWatch charges. A small configuration change in Amplify caused excessive polling and logging, generating far more usage than our development setup would ever justify. You can read more about that here: How a Single Browser Tab Exploded Our AWS Spend – QuantumVision AI
We had not realized how AppSync’s default logging level could amplify costs so dramatically. What followed was a lesson in how difficult it is for customers to get meaningful support or clarity when something like this happens.
To request relief, we had to acknowledge multiple layers of AWS documentation including the Service Agreement, Shared Responsibility Model, IAM best practices, and pricing structures for the services in question. Each link was several pages long and filled with caveats. We spent hours trying to justify what had happened and outline what we were doing to prevent it in the future.
AWS eventually provided some relief, but as a startup, the process left us feeling that the burden was entirely on us to mine the poorly organized and complex pricing structures. The pricing structures vary across every service, so even reading all the terms in advance would not have prevented the situation. The defaults simply are not optimized for cost awareness, and the documentation does not prepare you for the hidden costs that can emerge when one service interacts with another.
Adding to the challenge, the AWS pricing calculator provides only a static snapshot. It does not adapt automatically when architectural changes occur, which makes it useful only if you already understand the full cost model of every component. Combined with the tone of the support exchanges, it sometimes felt as though we were presumed guilty until we could prove our innocence.
Case 2: The Ghost of Bedrock Past
A few weeks later, another mysterious charge appeared, this time for Amazon OpenSearch Serverless, a service we do not even use in that account. After a long search, the explanation finally surfaced.
The charge had been quietly accruing for months. Earlier in the year, we had created Bedrock Knowledge Bases for a proof of concept. Unknown to us, AWS automatically created OpenSearch Serverless collections behind the scenes. When we deleted the knowledge bases, those collections remained active, quietly incurring daily charges.
Without AWS support’s help, we never would have found them. There was no notification, dependency warning, or reminder that something else might remain running in the background. For a company that prides itself on automation, this felt like a serious oversight that contradicts AWS’s “pay for what you use” message.
Reflections: Complexity Is Not a Good Default
Both cases shared a common theme. We did not fail to read the fine print; the fine print simply was not enough. AWS pricing and inter-service dependencies are vast, inconsistent, and often unintuitive.
For large enterprises, that complexity might be manageable. For small, fast-moving teams, the learning curve and financial risk are steep. AWS could do far more to surface cost-impacting defaults, automatically clean up dependent resources, and make its pricing tool dynamic enough to reflect real usage changes.
Closing Thoughts
We still believe in the promise of AWS and continue to build with it daily. But these experiences have taught us that “pay as you go” does not mean “safe by default.” Until AWS makes cost awareness part of its design philosophy, every new feature risks becoming a hidden cost waiting to happen.
Matt Pitts, Sr Architect
No responses yet