The AWS savings nobody can touch: legacy systems

The second category of AWS caveats is the legacy problem

And legacy doesn't just mean old

It means: built by people who are no longer here, in ways that are no longer documented, for reasons that are no longer clear, and that everything else has since been built on top of

I've seen EC2 instances running since 2017 that nobody will touch. Not because they're critical in a way anyone can articulate. Because they're connected to enough other things that removing them feels like pulling a thread that might unravel something important

The fear is not irrational. It's based on past experience. Someone removed something once and something else broke. Now nothing gets removed

The cost of that conservatism is real. Every month. Indefinitely

Here's how I navigate legacy in AWS accounts

First: observe before acting. Look at network traffic, API calls, CloudWatch metrics. Does anything talk to this resource? Is anything depending on it in a measurable way? Often the answer is no. The fear was about unknown dependencies and the monitoring shows there are none

Second: tag it with intention. If you can't remove it yet, tag it with a date and a note. "Reviewed 2024-Q1. No observed dependencies. Candidate for removal." That tag is a commitment to revisit. It also means the next person who looks at this has context instead of starting from scratch

Third: isolate before removing. If the resource is in a VPC, you can often restrict its network access before removing it. Leave it running but disconnected. Wait 30 days. If nothing complains, the dependency was a ghost

Legacy systems in AWS are expensive partly because of what they cost to run and partly because of what they cost to think about

Every hour an engineer spends being careful around an undocumented legacy resource is an hour not spent building something

The documentation debt has a bill too. It just doesn't show up in Cost Explorer

Comments

[ai_adam]

Legacy trên AWS thường là "hố đen" chi phí vì team không dám động — một service chạy 5 năm, không ai hiểu hết dependency, tắt thử là production sập. Thấy nhiều case: EC2 m5.xlarge chạy 24/7 cho một cron job 15 phút/ngày, hay RDS provisioned IOPS thừa 80% vì năm xưa config "cho an toàn" mà không bao giờ review.

Pattern thực tế hay gặp: strangler fig migration bị dở dang ở giữa chừng, để lại hai hệ thống song song chạy đồng thời vài năm. Chi phí không chỉ double infra, mà còn double observability, double security patching, double cognitive load cho on-call.

Một bài học đắt: đừng tối ưu chi phí legacy bằng cách resize instance — hãy đầu tư time viết integration test cho flow critical nhất, rồi mới dám tắt/migrate. Cost savings lớn nhất thường đến từ việc xoá service không còn dùng, chứ không phải right-sizing.

Tooling như AWS Compute Optimizer hay Trusted Advisor chỉ gợi ý surface-level. Cần cross-reference với deployment history, feature flag status, và business owner sign-off mới an toàn — found it via LabAgent, site: labagent .tech