<img height="1" width="1" style="display:none;" alt="LinkedIn" src="https://px.ads.linkedin.com/collect/?pid=1310905&amp;fmt=gif">


Explore CloudZero

Overview Icon

Discover the power of cloud cost intelligence.

Services Icon

Give engineering a cloud cost coach.

Pricing Icon

Learn more about CloudZero's pricing.

Demo Icon

Request a demo to see CloudZero in action.

About Icon

Learn more about CloudZero and who we are.

Connect With Us

Got questions? We have answers.

Questions Icon

Speak with our Cloud Cost Analysts and get the answers you need.

Get in touch arrow-right


How SeatGeek Decoded Its AWS Bill and Measured Cost Per Customer

Read customer story arrow-right
User Icon

By Role


Enable engineering to make cost-aware development decisions.


Give finance the context they need to make informed decisions.


Decentralize cloud cost and mature your FinOps program.

Use Case Icon

By Use Case

Provider Icon

By Provider

Amazon Web Services (AWS)

Measure, monitor, and optimize cloud spend on AWS.


Combine cloud cost intelligence from AWS and Snowflake.

Resources Icon



Discover the best cloud cost optimization content in the industry.

Cloud Cost Assessment

Gauge the health and maturity level of your cost management and optimization efforts.

Content Library

Browse helpful webinars, ebooks, and other useful resources.

Case Studies

Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and more.


Guide: How To Overcome Tagging And Accelerate Cloud Cost Allocation

See guide arrow-right

3 AWS Architectural Changes You Can Make To Reduce Cloud Costs

Optimize costs by making these three AWS cloud architecture changes. This guide for engineers identifies areas for proactive improvement.

Is your current cloud cost tool giving you the cost intelligence you need?  Most tools are manual, clunky, and inexact. Discover how CloudZero takes a new  approach to organizing your cloud spend.Click here to learn more.

Cloud costs can come with significant sticker shock, especially since many businesses do not have an easy way to track or predict actual cost before the bill arrives.

However, there are several AWS cloud architecture changes that businesses can make that will help rein in cloud spend. In some cases, optimal engineering decisions should be made up-front, while in other cases certain areas should be monitored over time to identify opportunities to retool architecture and optimize cloud costs.

We consider either approach “proactive,” because ideally this happens long before a shocking cloud bill comes due. 

Of course, engineering teams must have visibility into cloud spend to know what choices to make in the first place. With the appropriate data at hand on a timely basis, it becomes possible to make more cost-effective AWS cloud architecture decisions.

Let’s take a look at three key areas where proactive AWS cloud architecture decisions can prevent or correct excessive cloud spend and optimize cloud costs.

Percentages of Non-Compute and Outdated EC2 Compute

The first area we recommend examining for potential cloud cost savings is compute. Since compute is typically the lion’s share of cost on a given account, it makes sense to examine two ratios related to compute to see whether anomalies are present and identify opportunities for cloud cost optimization.  


We find that compute is roughly 30% of cost in a typical account with an EC2-centric architecture. Keep an eye on non-compute costs, if an account has very little compute costs, something may be amiss.

Of course, audit AWS accounts and smaller accounts that are being used for a niche purpose may not necessarily conform to typical ratios. However, a typical AWS account with an EC2-centric architecture — e.g., applications being hosted — is likely to have a minimum of 30% compute.

Examine any accounts you have that are spending more than 70% on non-compute and make sure that is appropriate based on your goals and the purpose for that account. 

Allocating compute resources thoughtfully across your accounts is an example of an architectural choice that can be made at the outset — and one that should be monitored for anomalies later on and changed when appropriate to avoid wasteful spending in the cloud. 

Outdated Compute

Another ratio we recommend is Outdated Compute to Total Cost, which is more likely to be an issue down the road vs. one that would impact early architecture decisions.

It is a problem that’s inherently more likely to arise over time, since it’s a matter of upgrading resources (or failing to do so). As you know, AWS has many different product families. Periodically, they will deprecate one product family and bring a new one online.

These new product families typically perform better and cost less, so outdated compute is almost always an opportunity to save money. Often, because development environments do not receive the same focus as production, they can be a common, pernicious source of outdated compute. 

Migrating to the latest generation compute may or may not be a quick change, and often requires testing and script updates. The performance improvements and cost savings resulting from the improved architecture usually justify the effort.

If you set up cloud cost alerting, you may not want to get an alert on every instance of outdated compute, but we recommend keeping an eye on the ratio and noting anytime it goes above 10% for a given account, as this is likely a valuable opportunity to upgrade.

Storage & Snapshot Requirements

Next, take a look at your storage and snapshot requirements. These are common areas where businesses overspend in the cloud. The typical storage costs we see are around 25% of the total cost.

However, it’s common for teams to set up lifecycles for storage and databases improperly. It may feel like the “safe” choice to just hang onto everything forever, but storage costs can really add up over time. 

When engineering a new component, it’s a good idea to define what the actual storage requirements are, rather than guessing or erring on the cautious side (which can, in fact, rack up major charges).

For architecture that has already been built, monitoring storage costs can help flag when spend ratios get too high (as we mentioned, a good rule of thumb is that storage should be 25% or less of the total bill). If it gets higher than that, find out what you really need to be storing.  

Snapshotting is a similar issue to storage in that it may seem like no big deal when it is set up, but costs can quickly spiral out of control. This is another area, like outdated compute, that can also become a problem over time if teams do not upgrade infrastructure.

Before AWS had fully featured backup capabilities, engineers would often use snapshots for the same purpose. For this reason, legacy architectures may spend 15 or even 20% of their resources on snapshots.

In general, we recommend setting a threshold of 10%. If you are spending more than that on snapshots, examine whether this is necessary and look for opportunities to optimize cloud costs by reducing snapshotting. 

Some useful questions to ask include:

  • Do we need to use snapshots in this way?
  • Should we keep these snapshots for a limited amount of time?
  • Is there a better backup system we could use?

We have heard of businesses spending hundreds of thousands of dollars per year on snapshots, and there is rarely a case where the value of those snapshots is justified by the cost they incur.

Almost always, there is a way to better architect the system so that backups are conducted and stored efficiently and cloud costs can be optimized.

Data Transfer

Finally, as you likely know, AWS’ data transfer systems can be confusing to understand. As a result, it’s not uncommon for engineers to build architectures that unintentionally have very high data transfer costs.

If you have an account with high data transfer costs (i.e. more than 25% of the cloud bill), it’s worth at least asking whether this is reasonable. In the case of a video streaming application, this number may make perfect sense.

However, for a more typical application, anything higher than 25% is an opportunity to rethink how data transfer is structured and look for opportunities to optimize cloud costs. 

Proactive Cloud Cost Optimization: The Way Forward

Any time an engineering team can architect a product or service from the get-go with cost in mind, there are massive cost savings to be realized.

Similarly, gaining full visibility into live cloud costs and setting alerts when thresholds get out of whack, as described above, can help engineers make proactive changes to AWS cloud architectures that are already in place.

In both instances, teams can save significant cloud costs, while often increasing efficiency and performance at the same time. The more proactive you can be, the less surprising that AWS bill will be at the end of the month, and the less friction there will be between engineering and business priorities. 


Join thousands of engineers who already receive the best AWS and cloud cost intelligence content.