Cloud computing has been around for two decades, and despite the data pointing to business efficiencies and cost-benefits, there are still a slew of ways for businesses to lose money and end up with a hole in their pockets. Not architecting applications correctly is one of those ways.
This is the first part of a two-part article on identifying and addressing the functionality that contributes to the high cost of the AWS SQS service. The cost of SQS service is examined in this article, and the functionality that contributes the most to the overall cost is identified. The series' next post will go deeper into the root cause and provide potential solutions for dealing with it and, as a result, lowering SQS costs.
So you received your AWS bill and noticed that the SQS cost was greater than expected, but you don't have enough information to triage it. According to the bill, only the Requests-Tier1 usage type contributes to the SQS cost. We need more than that if we need to address cost.
The first step is to go to the AWS Cost Explorer and filter the costs by SQS service and API Operation. This graph shows the cost of various SQS API operations for the selected time frame. The Receive API operation is the one that contributes the most, as shown in the screenshot below.
Above information is sufficient if you have single application interacting with SQS. But what if you have multiple applications? You need a way to drill down further to identify which application associated with SQS is contributing the most to the cost.
At this point, I want to emphasis the significance of tagging. Because I have multiple applications interacting with SQS, tagging becomes REALLY REALLY important. Tagging allows you to organise your AWS resources in a variety of ways, such by purpose, application, owner, and environment. As a result, in my case, drilling down the SQS cost by application will be difficult without tagging.
During SQS creation, a custom tag called "ApplicationId" was added to it.
So, in the AWS Cost Explorer, the next step is to group the costs by the tag. This view categorises costs based on a custom tag. As shown in the screenshot below, the SQS connected with App01 (blue) is the one that contributes the most. We now know that App01 SQS should be our primary focus.
The final step is to filter SQS service by tag and group the cost by API operations. This is to validate that the Read API operation that we identified in the previous step is still the operation that contributes the most to the APP01 SQS cost. And the answer is yes from the below screenshot.
At this stage, we've determined that the Read SQS API operation is the one that has the most significant influence on SQS costs. So there's the "What". We do not, however, know "Why". The next question will be "How" to address it once we know the "Why". The "Why" and "How" questions will be addressed in the subsequent post in the series.
Thanks for reading!
If you enjoyed this article feel free to share on social media 🙂
Top comments (0)