{"id":78120,"date":"2026-03-15T09:05:32","date_gmt":"2026-03-15T03:35:32","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=78120"},"modified":"2026-03-16T09:54:04","modified_gmt":"2026-03-16T04:24:04","slug":"why-right-sizing-is-not-a-one-time-activity","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/why-right-sizing-is-not-a-one-time-activity\/","title":{"rendered":"Why Right-Sizing Is Not a One-Time Activity"},"content":{"rendered":"<h1><span style=\"text-decoration: underline;\"><strong>Introduction<\/strong><\/span><\/h1>\n<p>If you\u2019ve worked in production long enough, you\u2019ve probably heard this: \u201cLet\u2019s right-size the services and reduce the AWS bill.\u201d So we do it.<\/p>\n<ul>\n<li>We check CPU and memory metrics for a week.<\/li>\n<li>We reduce task sizes.<\/li>\n<li>Costs drop.<\/li>\n<\/ul>\n<p>Everyone\u2019s happy. And then\u2026. six months later, the bill increases again. Nothing \u201cdramatic\u201d changed. No massive traffic spike. No big architecture shift. Just normal growth. Normal engineering. Normal entropy. That\u2019s when you realize something important: Right-sizing is not a project. It\u2019s a habit.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>Production Never Stays the Same<\/strong><\/span><\/h2>\n<p>The mistake most teams make is assuming workloads are stable. They\u2019re not.<\/p>\n<ul>\n<li>Traffic pattern changes.<\/li>\n<li>Features get added\/removed.<\/li>\n<li>Payload sizes increase.<\/li>\n<li>Retries get introduced.<\/li>\n<li>More logging gets enabled.<\/li>\n<li>Tracing &amp; logging agents get added.<\/li>\n<li>Background jobs grow quietly.<\/li>\n<\/ul>\n<p>All of this shifts resource usage. That service that was perfectly tuned at<strong> 0.5 vCPU and 2GB RAM<\/strong> last quarter? It might now need more \u2014 or sometimes less. But if no one checks, it just drifts.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>In ECS\/Fargate, Drift Is Expensive<\/strong><\/span><\/h2>\n<p>In Fargate, you don\u2019t pay for what you use. You pay for what you allocate. For example, if\u00a0your task is allocated 2GB but consistently uses 800MB, you\u2019re burning money 24\/7.<\/p>\n<p>Now multiply that by:<\/p>\n<ul>\n<li>20 microservices<\/li>\n<li>2 environments<\/li>\n<li>365 days<\/li>\n<\/ul>\n<p>Small inefficiencies compound quietly. The dangerous part? Nothing breaks. Overprovisioning doesn\u2019t alert you. It just invoices you.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>Underprovisioning Is Just as Risky<\/strong><\/span><\/h2>\n<p>The opposite mistake is worse. If you aggressively downsize without monitoring:<\/p>\n<ul>\n<li><strong>CPU throttling increases<\/strong><\/li>\n<li>Latency spikes<\/li>\n<li>Autoscaling becomes unstable<\/li>\n<li><strong>OOM kills<\/strong> start appearing<\/li>\n<\/ul>\n<p>And these issues are subtle. They don\u2019t always cause immediate outages. They degrade performance slowly. Right-sizing isn\u2019t just about saving money. It\u2019s about maintaining predictable performance.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>What Actually Changes Over Time<\/strong><\/span><\/h2>\n<p>Here\u2019s what I\u2019ve seen in real production systems:<\/p>\n<ul>\n<li>A new feature adds heavier <strong>database queries<\/strong>.<\/li>\n<li>The marketing team launches a campaign, and traffic patterns shift.<\/li>\n<li>Logging level moves from <strong>INFO to DEBUG<\/strong> during an incident\u2026. and never goes back.<\/li>\n<li>An <strong>SDK update<\/strong> increases the memory footprint.<\/li>\n<li>A sidecar gets added for observability.<\/li>\n<li>No one plans for these as <strong>\u201ccapacity changes.\u201d <\/strong>But they are.<\/li>\n<\/ul>\n<p>And if you don\u2019t revisit sizing regularly, you\u2019re either overpaying or running closer to instability than you think.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>The Mindset Shift<\/strong><\/span><\/h2>\n<p>Right-sizing should be part of the operational rhythm.<\/p>\n<ul>\n<li>Not a cost-cutting exercise.<\/li>\n<li>Not a quarterly panic.<\/li>\n<li>Not a one-time optimization sprint.<\/li>\n<\/ul>\n<p>It should be a recurring review:<\/p>\n<ul>\n<li>What\u2019s the <strong>p95 CPU?<\/strong><\/li>\n<li>What\u2019s the <strong>p95 memory?<\/strong><\/li>\n<li>Are we scaling too aggressively?<\/li>\n<li>Are we allocating far more than we consume?<\/li>\n<li>Did a recent deployment change behavior?<\/li>\n<\/ul>\n<p>If you\u2019re doing incident, cost, and performance reviews, sizing should sit alongside them. Infrastructure has uncertainty. Left alone, systems drift.<\/p>\n<ul>\n<li>They drift in complexity.<\/li>\n<li>They drift in cost.<\/li>\n<li>They drift in performance characteristics.<\/li>\n<\/ul>\n<p>Right-sizing is how you fight that drift. It\u2019s not glamorous work. No one cares about reducing <strong>512MB from a task definition<\/strong>. But across dozens of services, that discipline makes a real difference.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>AWS Compute Optimizer: Your Continuous Right-Sizing Assistant<\/strong><\/span><\/h2>\n<p>One AWS Service that really helps turn right-sizing from a<strong> \u201cone-time task\u201d<\/strong> into an ongoing habit is<strong> AWS Compute Optimizer<\/strong>. It analyzes your<strong> ECS tasks, EC2 instances, Lambda functions, RDS,<\/strong> and more, and recommends optimal CPU and memory allocations based on actual usage patterns.<\/p>\n<p>The beauty? It\u2019s not just a report you run once. Compute Optimizer continuously tracks your workloads, so you can catch inefficiencies before they become a cost leak. Pair it with regular operational reviews, and suddenly right-sizing isn\u2019t guesswork \u2014 it\u2019s a data-driven routine that keeps your cloud spend aligned with reality.<\/p>\n<h2><span style=\"text-decoration: underline;\"><strong>The Real Lesson<\/strong><\/span><\/h2>\n<p>Right-sizing is not about squeezing every dollar out of AWS. It\u2019s about alignment. Your infrastructure should reflect:<\/p>\n<ul>\n<li>Current traffic<\/li>\n<li>Current architecture<\/li>\n<li>Current behavior<\/li>\n<\/ul>\n<p>Not assumptions from six months ago. If you treat right-sizing as a one-time task, it will silently undo itself. If you treat it as ongoing routine work, it becomes one of the easiest long-term wins in cloud and finops operations. Right-sizing isn\u2019t something you do once and forget. It\u2019s a habit that keeps your systems running smoothly and your cloud bills under control. If you want help optimizing your cloud costs and keeping your workloads efficient, reach out to us. Our <strong>DevOps and FinOps engineers<\/strong> at <a href=\"https:\/\/www.tothenew.com\/\">To The New<\/a> have the experience to make it happen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction If you\u2019ve worked in production long enough, you\u2019ve probably heard this: \u201cLet\u2019s right-size the services and reduce the AWS bill.\u201d So we do it. We check CPU and memory metrics for a week. We reduce task sizes. Costs drop. Everyone\u2019s happy. And then\u2026. six months later, the bill increases again. Nothing \u201cdramatic\u201d changed. No [&hellip;]<\/p>\n","protected":false},"author":1601,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":7},"categories":[2348],"tags":[248,7571,8392,7322,6279,8426,5210,1892,3688,6131,7541,7917,3979,8386,7539],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78120"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1601"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=78120"}],"version-history":[{"count":5,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78120\/revisions"}],"predecessor-version":[{"id":78506,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78120\/revisions\/78506"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=78120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=78120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=78120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}