AWS by the book.

Three Steps to Build a More Cost-Effective Solution on AWS

Cover Image for Three Steps to Build a More Cost-Effective Solution on AWS
This post was originally published on Medium, where people are continuing the conversation by highlighting and responding to this story. To view the post on Medium, click here.

When managing costs in AWS, the need for savings is often clear, but sometimes there’s a lack of precise insight into how much needs to be saved within a specific timeframe. Whether you work for a company that wants you to respond to budget pressures or are looking for ways to optimize your environment, some daily reflections can help you speed up your cost-saving efforts and plant the seed for the future of your application.

In this post, I’ll share three simple steps to help you build a more cost-effective solution on AWS.

Do you really need it?

During the AWS re:Invent 2024 keynote, Werner Vogels emphasized the importance of “simplexity” — the art of designing architectures that are powerful yet simple. “Simplexity” isn’t just a fancy term; it’s a mindset that drives innovation while avoiding unnecessary complexity.

Inspired by these principles, I’ve found one question to be a true game-changer: Do you really need it?

This question forces us to challenge assumptions and well-known architectures and focus on what truly matters. It aligns with the goals of keeping your architecture simple and driving sustainability and cost efficiency.

Step one: challenge decisions made in the past

How often have you encountered the response, “because we’ve always done it this way,” when questioning why certain setups exist?

If you find yourself still using this rationale, it’s time to reconsider — after all, it’s 2024 (almost 2025!). Technology, particularly in the AWS ecosystem, evolves quickly every day. Continuously reevaluating these decisions is essential, both for the performance of your applications and for optimizing costs.

Imagine the following architecture diagram:

CloudTrail log ingestion to CloudWatch and S3 Bucket

This AWS CloudTrail log aggregation solution centralizes logs from all member accounts in an AWS Organization into a single account. Each account sends its CloudTrail logs to both a CloudWatch Log Group and an S3 bucket in the central account. This setup provides centralized governance and storage for auditing and compliance purposes.

Looking at this diagram, I asked myself: do we really need to store the logs in both locations? A CloudWatch Log Group offers real-time monitoring capabilities, such as using Log Insights, while an S3 bucket provides long-term, cost-efficient storage that can be easily queried with Athena.

In this case, real-time monitoring through CloudWatch was not required. Challenging this past decision allowed us to eliminate CloudWatch log ingestion and retain only the S3 bucket — reducing unnecessary complexity.

CloudTrail log ingestion to S3 Bucket

The result of this simple change was a reduction of $4,038.81 per month in CloudWatch costs:

CloudWatch costs comparision: reduction of $4,038.81

Simplifying the setup resulted in significant cost savings. The key takeaway is that past decisions may no longer be relevant today — it’s essential to continuously challenge them.

Step two: challenge assumptions

Another common sentence people use is “because I think it is more secure”. However, it’s important to question whether this assumption still holds. What may have been considered correct in the past might no longer be the best approach today. Continuously reassessing decisions — based on facts — ensures you’re adopting the most effective and efficient solutions for your current needs.

Let’s have a look at another scenario in the same large AWS Organizations setup, where each member account had its own S3 Bucket used for CloudFormation deployment assets:

S3 Bucket + SS3-KMS encryption type

Do we really need to have an SSE-KMS encryption type with a Customer Managed Key in KMS? Reflecting on use cases for that: key rotation, centralized key management, and detailed access control over who can use the key. None of that applied to this scenario. We decided to remove the key and have SSE-S3 encryption type, where AWS owns and manages the encryption key.

S3 Bucket + SSE-S3 encryption type

The result of this simple change was a reduction of $2,040.43 per month in KMS costs:

KMS costs comparision: reduction of $2,040.43

This change allowed a simpler solution — while the data is still encrypted at rest, reducing maintainability since the KMS keys were removed. As a consequence, more cost reduction.

Regularly challenging assumptions is crucial for improving efficiency, reducing complexity, and optimizing costs. Continuous evaluation helps ensure that solutions evolve alongside technological advancements.

Step three: adopt “simplexity”

Cost efficiency in AWS is as much about avoiding unnecessary expenses as it is about building efficient systems — adopting “simplexity”.

Reflecting on these steps daily can help you achieve quick wins that not only save some money today but also set your application up for a sustainable future.