Cloud computing has brought speed to developing products, scaling applications, and launching new features. However, this same ease causes many companies to accumulate almost imperceptible waste over time. Machines larger than necessary, development environments running all night, forgotten snapshots, unused volumes, and resources that remain active even after projects are closed end up driving up the AWS bill month after month.

This scenario is more common than it seems. According to the Flexera State of the Cloud 2026, about 29% of cloud spend is still considered waste, primarily a result of the lack of continuous governance over infrastructure. Instead of relying solely on a dedicated FinOps team or hiring consultancies to find these bottlenecks, many companies are discovering that the Product Engineer themselves possesses the necessary insight to identify savings opportunities while developing and evolving the product.

Why do companies waste so much money on AWS even when using modern services?

The flexibility of AWS allows for creating environments, scaling applications, and making new resources available in just a few minutes. This agility accelerates development but also facilitates the emergence of costs that go unnoticed when infrastructure grows without governance. Forgotten testing environments, oversized instances, old snapshots, and resources that remain active after the end of a project are some of the most common forms of waste.

The problem is not with AWS, but with the lack of continuous monitoring of resource usage. Often, these costs are small individually, but when summed up over the months, they represent a significant portion of the bill. According to Flexera's State of the Cloud 2026 report, organizations estimate they waste, on average, 29% of cloud spend, primarily due to the absence of consistent optimization and governance practices.

More than cutting expenses, the challenge is to create a culture of constant infrastructure review. This is precisely the scenario where the Product Engineer stands out, using their insight on product and technology to identify waste before it impacts the budget and scalability of the operation.

What differentiates a Product Engineer from a traditional developer?

While a traditional developer usually focuses their efforts on implementing features, the Product Engineer participates in the entire product lifecycle, making decisions that balance user experience, performance, scalability, and business sustainability. Their focus is not just on delivering functional code, but on ensuring that each choice generates value for the product as a whole.

This role requires a broad view of architecture, infrastructure, reliability, and operational costs. Before implementing a solution, for example, the Product Engineer assesses whether it will be scalable, easy to maintain, and financially viable over time, avoiding decisions that could unnecessarily increase cloud spending.

This working model is directly linked to the concept of ownership, where the professional takes responsibility for the product's results after delivery. Instead of just developing a feature and moving on to the next task, they monitor its impact, track indicators, and seek continuous improvements, including in infrastructure efficiency and cost optimization. It is this integrated vision that makes the Product Engineer a strategic ally for companies wishing to grow sustainably.

The waste a Product Engineer can identify before it becomes a loss

In most companies, the greatest waste in AWS does not arise from wrong decisions, but rather from the lack of constant reviews of the infrastructure. As they follow the product from development to operation, the Product Engineer can identify these bottlenecks before they turn into recurring costs.

Oversized EC2s and development environments turned on 24 hours a day

It is common for instances to be created with configurations above what is needed to handle traffic peaks or accelerate testing. Over time, demand changes, but these machines continue to consume resources and increase the bill. The same happens with development and staging environments that remain on during nights, weekends, and holidays, even when not in use. Periodic reviews of utilization, rightsizing, and automatic shutdown routines usually generate immediate savings without impacting team productivity.

Orphaned EBS volumes and old snapshots

When an EC2 instance is terminated, its storage volumes and snapshots do not always cease to exist. Unattached volumes continue to be billed normally, while old snapshots accumulate over time, often without any retention policy. AWS itself recommends reviewing these resources regularly and automating their lifecycle to avoid unnecessary costs.

Forgotten Load Balancers and cross-region transfers

Changes in architecture can leave Load Balancers active even when not receiving traffic or serving few resources. Furthermore, an inadequate configuration can increase costs with transfer of data between different availability zones or regions, an expense that usually goes unnoticed in the initial reviews of the bill. Designing the architecture considering the location of services and reviewing components that no longer make operational sense help reduce this type of waste.

Databases with capacity far above demand

Databases also tend to grow out of precaution. It is common to find instances provisioned to handle a load much larger than what is actually used, as well as storage and replicas maintained unnecessarily. By tracking usage metrics and product evolution, the Product Engineer can adjust these resources according to actual demand, balancing performance, availability, and operational cost.

How FinOps practices naturally fit into the development workflow

FinOps is not a task exclusive to finance or infrastructure. In product-oriented teams, technical decisions made during development already directly influence the AWS bill. Therefore, practices such as consistent tagging, cost monitoring, rightsizing, autoscaling, and the proper use of Savings Plans become part of engineering's daily routine, rather than just a review done at the end of the month.

In this scenario, the Product Engineer acts with a sense of accountability for the product: they monitor the impact of features not only on performance and user experience, but also on operational cost. Periodic reviews of the architecture, analysis of utilization metrics, and continuous adjustments cease to be isolated initiatives and become a natural part of the development cycle, creating a culture where each technical decision considers its financial efficiency.

Optimizations that can generate double-digit savings

It is not always necessary to redesign the entire architecture to reduce AWS costs. In many cases, the biggest gains come from the combination of simple adjustments that go unnoticed in daily operations. Automating the shutdown of development environments outside of working hours, replacing oversized instances with more appropriate options, removing orphaned resources, and periodically reviewing storage are measures that, when applied together, can represent double-digit savings, especially in environments that have never gone through a structured optimization process.

Another important point is to leverage the features offered by AWS itself. Migrating compatible workloads to AWS Graviton-based instances can reduce costs while maintaining or even improving performance in various applications. Likewise, assessing when to use On-Demand instances and when to adopt Savings Plans avoids unnecessary expenses on predictable capacity. The secret lies not in a single change, but in the combination of small, data-driven decisions that are continuously reviewed. The lower the maturity of infrastructure management, the higher the savings potential tends to be in the first analyses.

Why waiting for an optimization project costs more than continuous optimization

Many companies only review AWS costs when the bill spikes or when they decide to start a specific cost reduction project. The problem is that, during this interval, small wastes accumulate and become part of the operation. Underutilized resources, forgotten services, and configurations that no longer reflect the reality of the product continue to consume budget for months, making correction more laborious and less efficient than it would be with continuous monitoring.

Therefore, infrastructure optimization must be part of the development cycle itself. With financial observability practices, constant monitoring, and a culture of incremental improvement, teams can identify deviations quickly and correct problems before they impact the budget. For the Product Engineer, monitoring the financial health of the infrastructure is just as important as monitoring metrics for performance, availability, and user experience, ensuring that the product evolves in a sustainable manner.

Product Engineering, FinOps, and culture: when savings stop being the responsibility of a single team

As companies mature, optimizing costs stops being an exclusive responsibility of infrastructure or finance. Development, product, architecture, and operations begin to share this commitment, incorporating FinOps practices into the development cycle and treating efficiency as an indicator as important as performance, availability, and quality. It is this culture that allows for the continuous reduction of waste without compromising the evolution of the product.

At Codebit, we believe that this optimization should be part of the routine and not happen only when the AWS bill becomes a problem. Therefore, our infrastructure services include architecture reviews, recurring FinOps monitoring, and specialized management of AWS environments to identify improvement opportunities before they impact business costs. If you want to understand where your infrastructure can gain more efficiency, get in in touch with our team and learn about our solutions. And, to deepen the discussion on Product Engineers, FinOps, and good engineering practices, it's also worth following Deploy de Sexta, a podcast we support in partnership with Felipe Barreiros.