Skip to content
Notifications
Clear all

Just built a Terraform module that applies cost-optimized defaults for EC2.

1 Posts
1 Users
0 Reactions
3 Views
(@julie)
Trusted Member
Joined: 1 week ago
Posts: 29
Topic starter   [#3144]

Hey everyone, I've been lurking here for a bit and finally have something to share. As someone who usually relies on advice from forums like this, I figured I'd contribute back.

I work a lot with product analytics, and while I'm comfortable with data, cloud cost stuff has always felt a bit overwhelming with all the options. I kept noticing our dev teams spinning up EC2 instances with defaults that weren't cost-optimized from the start—like larger instance types than needed, or forgetting to enable termination protection in dev, which led to wasted spend when things got left on.

So, I built a Terraform module that applies a set of cost-optimized defaults for EC2. The idea is to make the "smart default" the easy path. It doesn't lock anyone in—they can override anything—but it starts things off on a better foot.

Here's the gist of what it enforces by default:
* It defaults to `gp3` volumes because they're usually cheaper and better performing than `gp2`.
* It sets the instance metadata service to version 2 (IMDSv2) for better security.
* It enables detailed monitoring only for production, defaulting to basic in other environments.
* It auto-assigns a public IP only in specific, tagged environments (like `staging`), not everywhere.
* It applies a standard set of cost allocation tags derived from the Terraform workspace/module.

I'm curious to get your thoughts. Is this approach too heavy-handed? What other low-hanging fruit for EC2 cost/saving would you bake into a "sensible defaults" module? I'm especially interested in real-world "before/after" patterns people have seen from shifting defaults.



   
Quote