DEV Community: Rituraj Borah

Applying the AWS Well-Architected Framework to Growing AWS Bills

Rituraj Borah — Fri, 06 Mar 2026 07:43:32 +0000

As organizations scale on the cloud, a familiar pattern emerges: infrastructure grows quickly, teams move faster, and AWS bills start climbing faster than expected. For many companies, the challenge isn’t simply reducing cloud costs - it’s understanding WHY costs are increasing and how to manage them without slowing innovation.

This is where the AWS Well-Architected Review Framework (WAF) becomes highly relevant. While often associated with architecture best practices, the framework also provides a structured way to control cloud spending and align engineering decisions with financial efficiency.

By applying the principles of the Well-Architected Framework, especially the Cost Optimization pillar, organizations can transform rising AWS bills into an opportunity for smarter governance and long-term efficiency.

Why AWS Costs Increase as Environments Scale

Cloud costs rarely spike overnight. Instead, they grow gradually as infrastructure becomes more complex. New workloads are deployed, environments are replicated for testing, and teams experiment with different services.

Over time, this leads to patterns such as underutilized compute resources, idle storage volumes, duplicated environments, and inefficient scaling policies. Without continuous monitoring and optimization, these inefficiencies accumulate silently.

Many engineering teams initially rely on AWS-native dashboards to track spending. While these tools provide visibility into usage trends, they do not always provide actionable governance mechanisms that prevent inefficiencies from recurring.

Applying the AWS Well-Architected Framework introduces a systematic approach to managing these challenges.

The Cost Optimization Pillar in Practice

The Cost Optimization pillar focuses on ensuring that cloud resources deliver maximum value at the lowest possible cost. Rather than treating cost reduction as a reactive activity, the framework encourages teams to embed financial awareness directly into architectural decisions.

In practice, this begins with gaining clear visibility into how resources are used across accounts, services, and teams. Organizations must be able to identify which workloads drive the majority of their spending and whether those resources are being used efficiently.

For example, compute resources should be regularly evaluated for utilization patterns. Instances that remain underutilized for extended periods often indicate overprovisioning. Rightsizing these resources or shifting them to more appropriate instance types can significantly reduce waste without affecting performance.

Another common area of inefficiency is storage. Applying lifecycle policies to move infrequently accessed data to lower-cost storage classes can lead to substantial long-term cloud cost savings.

Designing for Elasticity

A fundamental cloud advantage is elasticity - the ability to scale resources dynamically based on demand. However, many environments fail to fully leverage this capability.

Workloads that run on fixed instance capacity often result in unnecessary costs during periods of low usage. The Well-Architected Framework recommends designing systems that automatically scale up or down depending on real-time demand.

This may include implementing autoscaling groups, serverless architectures, or container-based workloads that adjust capacity dynamically.

Leveraging Pricing Models Strategically

Another key recommendation within the Cost Optimization pillar is to take advantage of AWS pricing models that reward predictable usage patterns.

For stable workloads that run continuously, long-term commitment options such as Savings Plans or Reserved Instances can provide significant cost reductions compared to on-demand pricing.

However, these commitment strategies require careful planning. Overcommitting can lead to unused capacity, while undercommitting leaves potential savings unrealized.

Organizations therefore need ongoing analysis of usage patterns to ensure commitments align with actual workload demand. As environments evolve, commitment strategies should be revisited and adjusted accordingly.

Governance Through Visibility and Accountability

One of the most powerful aspects of the Well-Architected Framework is its emphasis on governance. Cloud cost optimization is not a one-time exercise - it must be embedded into daily operations.

This begins with clear cost allocation. Tagging resources by application, environment, and business unit allows organizations to attribute cloud spending accurately. When teams can see how their workloads affect overall cloud costs, they become more accountable for efficient resource usage.

Regular cost reviews are also essential. Engineering and finance teams should collaborate to analyze usage trends, identify anomalies, and prioritize optimization opportunities.

Moving From Monitoring to Intelligent Governance

Many organizations initially approach cloud cost management through monitoring alone. Dashboards provide visibility into usage trends and billing breakdowns, but visibility alone rarely drives sustained optimization.

The real value emerges when monitoring evolves into governance, where insights lead to concrete actions such as rightsizing resources, adjusting scaling policies, or refining commitment strategies.

Solutions like CloudKeeper Lens, for example, focus on turning cloud cost visibility into continuous optimization by identifying inefficiencies and helping teams implement improvements across their AWS environments. Rather than replacing native tools, platforms like these extend them with deeper analysis and actionable insights.

Embedding Cost Awareness Into Engineering Culture

Cloud cost efficiency improves when engineering teams begin to view cost as a design parameter alongside performance, reliability, and security. When developers understand the financial impact of architectural choices, they can build systems that are both scalable and economically efficient.
Turning Growing AWS Bills Into an Optimization Opportunity

Rising AWS bills are often a natural consequence of cloud adoption and business growth. The real challenge lies in ensuring that spending grows in proportion to the value delivered.

By applying the AWS Well-Architected Framework - particularly the Cost Optimization pillar, organizations gain a structured approach to identifying inefficiencies, improving resource utilization, and aligning cloud spending with business objectives.

Cloud Cost Visibility: From Monthly Reports to Real-Time Insight

Rituraj Borah — Mon, 16 Feb 2026 06:26:50 +0000

Cloud adoption has matured a lot. What started as an agility play is now core business infrastructure. Yet while cloud environments have become more advanced, financial oversight hasn’t evolved at the same pace.

Infrastructure now expands in seconds. Workloads autoscale, Containers spin up and disappear, AI models consume compute unpredictably. Yet many organizations still rely on monthly billing summaries to understand what happened weeks ago.

According to Gartner, worldwide public cloud end-user spending is projected to exceed $675 billion, reflecting continued double-digit growth. At that scale, even minor inefficiencies translate into significant financial impact.

Many organizations still rely on monthly billing summaries to understand what happened weeks ago. By the time reports are reviewed, overspending is already embedded in the cycle.

This is why cloud cost visibility must move from static monthly reports to continuous, real-time insights.

The Visibility Gap Driving Cloud Waste

The problem isn’t adoption, it’s control. When cost insight arrives weeks late, inefficiencies are already embedded. Idle resources persist, overprovisioning continues, and optimization becomes reactive.
Without real-time cloud cost visibility, organizations operate without financial precision. Control begins the moment visibility becomes immediate.

Why Monthly Reporting No Longer Works

Monthly reporting was built for predictable infrastructure. The cloud is anything but predictable. Workloads scale automatically, containers appear and disappear in minutes, development environments expand overnight, AI-driven processes spike without warning. In this environment, waiting 30 days to understand spending makes no operational sense.

By the time a billing summary is reviewed, the context behind the numbers is gone. The teams who triggered the usage have moved on. The architectural decisions that increased cost are already embedded in production. Optimization becomes damage control instead of prevention.

The real problem is latency.

When financial insight lags behind infrastructure activity, organizations lose control over cause and effect. Engineers make deployment decisions without cost context, Finance reviews outcomes without technical visibility and accountability fragments.

True cloud cost visibility eliminates that delay. It connects infrastructure behavior with financial impact instantly, allowing action at the moment it matters. In a real-time infrastructure model, cost oversight must operate in real time as well.

Why Real-Time Insight Has Become Essential

Cloud environments are expanding in scale and complexity. Multi-cloud architectures, Kubernetes clusters, and dynamic workloads create constant shifts in usage and cost. In this landscape, static dashboards updated once a month are no longer sufficient.

Enterprises require immediate anomaly detection, granular resource-level cost breakdowns, service-level financial transparency, and automated alerts that respond to usage spikes as they happen.

This is where advanced cloud monitoring tools redefine the model, moving organizations from delayed reporting to active governance powered by real-time cloud cost visibility

Cloud Monitoring Tools as Financial Control Systems

Traditional monitoring platforms focused on uptime and latency. Today’s cloud monitoring tools must integrate financial telemetry alongside performance metrics.

When financial data and infrastructure data exist in silos, decisions lag. When they converge, action accelerates.

With real-time cloud cost visibility powered by intelligent monitoring, enterprises can:

Detect unused compute resources instantly
Attribute spend by team, workload, or environment
Align DevOps decisions with financial targets
Enforce policy-based cost controls

This convergence turns cost management into an operational discipline.

Kubernetes and the New Cost Frontier

Containerized workloads add another layer of complexity.
As per the 2026 CNCF Annual Survey, Kubernetes now runs in 82% of production environments, yet cluster-level cost visibility gaps persist, driving the need for stronger observability and FinOps.
Without granular cloud cost visibility, ephemeral workloads and auto-scaling groups can inflate expenses unnoticed.
Modern cloud monitoring tools now provide:

Cost per namespace or cluster
Idle node identification
Rightsizing insights
Budget-based automation triggers

This level of detail prevents silent cost drift in highly dynamic environments.

From Visibility to Accountability

Cloud economics is no longer just a finance function.
Real-time cloud cost visibility creates shared ownership. Engineers understand the financial impact of architecture decisions. Product leaders evaluate margins before scaling and CFOs gain transparency without waiting for reconciliation cycles.

The result is not just reduced waste, but smarter investment.

Strategic Advantage in a Competitive Market

The conversation around cloud cost visibility is no longer about trimming budgets. It is about sustaining growth.

Enterprises that leverage advanced cloud monitoring tools can:

Improve forecasting accuracy
Optimize reserved capacity strategies
Identify cost-performance tradeoffs
Accelerate time-to-optimization

In fast-moving industries, the ability to act on financial signals instantly becomes a competitive differentiator.

The Shift Enterprises Cannot Ignore

Monthly cloud reports answer one question: What did we spend on?
Real-time cloud cost visibility answers more strategic ones:

Why did spending change today?
Which workload is driving growth?
Where can we improve efficiency immediately?
How does infrastructure investment map to revenue impact?

As cloud adoption deepens, delayed insight becomes operational risk.

Conclusion

Cloud infrastructure evolves by the second and Financial oversight must evolve with it.

Analyst data consistently shows that cloud spend management remains a top enterprise concern, as waste persists, allocation remains complex, and multi-cloud environments add further friction.

The solution is not more reports, it is radical visibility. When continuous cloud cost visibility, intelligent monitoring, and disciplined cloud cost optimization converge, organizations move from chasing spend to commanding it. They don’t just control costs, they convert them into strategic leverage. In a cloud-first economy, real-time cost intelligence isn’t a feature; it is the foundation of competitive dominance.

AWS Savings Plans: When They Make Sense, and When They Don’t

Rituraj Borah — Tue, 03 Feb 2026 10:35:25 +0000

As cloud adoption on Amazon Web Services continues to grow, controlling cloud spend has become a priority for engineering and finance teams alike. One of the most widely used commitment-based pricing models AWS offers is AWS Savings Plans. When used correctly, they can significantly reduce compute costs, but when applied without enough visibility, they can limit flexibility and deliver far less value than expected.

Understanding AWS Savings Plans, the different options available, and the scenarios where they work (or don’t) is critical before committing long term. This blog breaks down how AWS Savings Plans work, when they make sense, and how organizations can make smarter decisions using the right visibility and governance.

Understanding AWS Savings Plans and Commitment Options

AWS Savings Plans offer discounted pricing in exchange for committing to a consistent amount of compute usage over a one-year or three-year period. Instead of paying purely on-demand rates, organizations commit to a baseline level of spend and receive reduced pricing in return.

Unlike traditional Reserved Instances, AWS Savings Plans are designed to offer more flexibility. However, not all Savings Plans provide the same level of coverage or adaptability. Choosing the right option requires visibility into usage patterns and a clear understanding of workload behavior.

Types of AWS Savings Plans You Should Know

1. Compute Savings Plans

Compute Savings Plans are the most flexible option within AWS Savings Plans. They apply discounts automatically to eligible compute usage, regardless of instance family, region, operating system, or tenancy.

They cover:
Amazon EC2 usage
AWS Fargate compute
AWS Lambda compute

These plans are commonly used in environments where workloads evolve frequently, instance families change often, or container and serverless adoption is increasing. Because of their broad coverage, Compute Savings Plans are often used as a foundation for long-term commitment strategies.

2. EC2 Instance Savings Plans

EC2 Instance Savings Plans offer higher discounts than Compute Savings Plans but introduce more constraints. These plans apply only to a specific EC2 instance family within a selected region.

They are typically applied to:
Stable production workloads
Long-running EC2 applications
Environments with minimal architectural change

The reduced flexibility is offset by deeper savings, making them suitable for predictable workloads with consistent demand.

3. Reserved Instances and Their Role

While not technically part of AWS Savings Plans, Reserved Instances are often evaluated alongside them.

Standard Reserved Instances provide the highest discounts but are tightly locked to instance type, region, and operating system.

Convertible Reserved Instances offer moderate discounts with the ability to change instance families and operating systems over time.
For most modern cloud environments, AWS Savings Plans strike a better balance between flexibility and savings, but Reserved Instances may still be relevant for highly static workloads.

Where AWS Savings Plans Are Commonly Used?

1. Predictable Compute Workloads

AWS Savings Plans are most effective for workloads with steady, always-on usage. When baseline consumption is consistent, commitments can be planned with confidence.

Common examples include:
Core production systems
Backend services with stable traffic
Internal platforms with predictable demand In these scenarios, Savings Plans reduce costs without requiring architectural changes

2. Mature AWS Environments with Cost Visibility

Organizations with established AWS cost monitoring and reporting practices are better positioned to use AWS Savings Plans successfully. Historical usage data allows teams to base commitments on evidence rather than assumptions.

Savings Plans are more commonly adopted when:

Usage trends are well understood
Seasonal patterns are documented
Teams actively track compute utilization This aligns closely with FinOps best practices for AWS cost management.

3. Long-Term Workloads with Defined Roadmaps

Workloads with stable roadmaps and minimal re-architecture plans are strong candidates for AWS Savings Plans. Clear alignment between engineering and business planning reduces the risk of underutilized commitments.

These typically include enterprise platforms, business-critical applications, and systems with predictable growth patterns.

Situations That Reduce the Effectiveness of AWS Savings Plans

1.Variable or Spiky Usage Patterns

Applications with fluctuating demand often struggle to fully utilize committed spend under AWS Savings Plans. Event-driven workloads, seasonal applications, or short-term projects can lead to unused commitments that offset savings

2. Early-Stage or Rapidly Changing Environments

In fast-growing environments, infrastructure changes frequently. Committing to AWS Savings Plans too early can introduce rigidity and reduce flexibility when it is most needed.
Common challenges include overcommitting before usage stabilizes and paying for capacity that no longer aligns with current workloads.

3. Active Architecture Modernization

Modernization initiatives such as migrating to containers, serverless, or newer instance families can significantly alter usage patterns. During these transitions, AWS Savings Plans may be less effective than short-term optimization approaches.

How to Manage AWS Savings Plans More Effectively?

Organizations that succeed with AWS Savings Plans treat them as an ongoing strategy rather than a one-time purchase.
Common practices include:

Starting with conservative commitments
Reviewing utilization regularly
Adjusting future commitments based on actual usage

Combining AWS Savings Plans with continuous AWS cost visibility and governance ensures commitments continue to deliver value as environments evolve

Key Considerations Before Committing to AWS Savings Plans

Before committing, teams should evaluate:

Stability of baseline compute usage
Expected architectural changes
Accuracy of historical usage data
Ability to continuously monitor utilization These considerations help reduce risk and improve long-term outcomes.

Conclusion

AWS Savings Plans can be an effective tool for reducing AWS compute costs when aligned with real workload behavior and supported by strong visibility. They deliver the most value in mature environments with predictable usage and clear ownership.
For dynamic or rapidly evolving workloads, flexibility often outweighs long-term discounts. The key lies in understanding all available commitment options, applying them selectively, and revisiting decisions as cloud usage changes.
When managed thoughtfully, AWS Savings Plans help organizations optimize spend without compromising agility.

AWS Database Savings Plans: What They Actually Mean for Your Cloud Bill

Rituraj Borah — Fri, 19 Dec 2025 05:08:56 +0000

Databases don’t usually cause sudden AWS bill spikes.
They’re worse than that.
They just… sit there.
Running 24/7.
Quietly expensive.

For a long time, your only real option to reduce database costs was Reserved Instances. They worked, but they were rigid, hard to manage, and easy to get wrong.

AWS Database Savings Plans are an attempt to fix that.

And honestly?
They’re a step in the right direction.

What are AWS Database Savings Plans?

At AWS re:Invent this year, AWS announced Database Savings Plans - a new pricing model designed to make database spend cheaper and simpler across a range of services.

At a high level, Database Savings Plans are spend-based commitments.

You commit to spending a fixed dollar amount per hour for 1 year, and AWS gives you discounted pricing on eligible database usage in return.

The discount automatically applies to your usage - no instance-level locking, no region pinning, no guessing exact instance families upfront.

If you’ve used Compute Savings Plans before, the mental model is very similar - just scoped specifically to databases.

What databases are covered?

Database Savings Plans apply across a wide range of AWS database services, including:

Amazon RDS
Amazon Aurora (including Serverless v2)
DynamoDB
Amazon DocumentDB
Amazon Neptune
Amazon Keyspaces
Amazon Timestream
AWS DMS

That cross-service coverage is the big win here.
You’re not committing to how you run databases - just that you will.

How much can you actually save?

AWS says up to ~35%, and that number is real - but mostly for serverless or modern database workloads.

For traditional provisioned RDS or Aurora instances, savings are usually more modest, but still meaningful.

The key thing is predictability.

Instead of asking:
“Which instance should I reserve for the next year?”

You’re asking:
“How much database spend do we consistently have every hour?”

That’s a much safer question.

What happens if usage changes?

This is where Database Savings Plans shine.
You can change instance families.
Move between regions
Shift from RDS to Aurora
Adopt serverless

The discount still applies as long as the usage qualifies and you’re within your hourly commitment.

If you exceed the commitment, the extra usage is billed at on-demand rates.
If you underuse it, you’re still paying for the commitment.

So yes - forecasting still matters.

Just less painfully than before.

The catch (because there’s always one)

Not everything is covered.

Older instance generations and some niche setups may still require Reserved Instances. In reality, many teams will end up with a hybrid approach:

Database Savings Plans for modern workloads

RIs for legacy or unsupported systems

That’s not a bad thing - just something to plan for.

Where most teams go wrong

The mistake isn’t choosing the wrong discount model.

It’s committing too aggressively.

Teams see potential savings and lock in a number based on peak usage instead of baseline usage. A few architecture changes later, and suddenly the commitment becomes a liability.

The smarter approach is conservative:
Cover what you’re confident will run no matter what. Let the rest stay flexible.

This is where having proper visibility into historical usage really matters - otherwise, you’re just guessing with bigger numbers.

So… are Database Savings Plans worth it?

If your AWS environment is static and predictable, Reserved Instances can still work fine.

But if your databases evolve — and most modern systems do - Database Savings Plans are easier to manage, harder to mess up, and much better aligned with how cloud actually works.

They won’t magically fix bad architecture or forgotten databases.
But they do reduce the penalty for change.

And that’s a pretty solid upgrade.

And that's pretty much it. Let me know your thoughts in the comments.