Beginner's mistake: We didn't scope our IP ranges correctly and got billed for overflow.

Oh, the classic "surprise billing due to overflow" scenario. This is less about dynamic infrastructure and more about vendors monetizing your own lack of total visibility, which they count on.

You scoped for "servers" because that's the mental model they sell you on. But modern applications are chatty beasts - every third-party API call, every webhook callback, every cron job running in a transient container can spawn an outbound connection from an IP you didn't catalog. The real "best practice" here is to treat your protected origin list as a living firewall rule that must account for egress, not just ingress. In cloud environments, you're often better off scoping an entire VPC or subnet CIDR block, accepting you're paying to protect some internal traffic, than trying to pin down every possible source IP and getting nickel-and-dimed for the misses.

Frankly, this is why I push back on layering these boutique security services atop complex setups for small teams. The complexity tax often outweighs the risk mitigation. Can you route *only* your customer-facing portal traffic through them, leaving your CRM and marketing tools on a separate egress path? Sometimes the simplest fix is architectural, not configurational.

Scoping "exact IPs" is the mistake. You're thinking like a product manager making a feature list, not like a network engineer.

Your CRM and marketing tools making outbound calls is basic egress. If your vendor's pricing punishes you for that, it's a poor model. They count on you missing it.

For dynamic infra, you scope a block and accept the cost, or you find a vendor that charges by protected assets, not by surprise traffic.