Configure ElastiCache clusters with a custom subnet group

ElastiCache is the in-memory cache layer most applications use to stay fast — it holds frequently accessed data so the app doesn't have to hit the main database every time. Where that cache lives on the network matters, because it often holds sensitive working data: session tokens, partial customer records, cached lookups. This finding says a cluster was launched on the "default" network configuration AWS provides out of the box rather than a deliberately restricted one your team designed.

The default configuration exists to make getting started painless, which means it's permissive by design. Using it for a real workload is the equivalent of standing up a filing cabinet of working data in an unlocked shared hallway because that was the first room available. Nothing has gone wrong yet, but the exposure is wider than anyone intended, and it stays that way silently until an audit or an incident surfaces it.

From a risk and compliance standpoint this is a posture finding, not a cost finding. It maps to network-segmentation requirements in frameworks like NIST 800-53, so it shows up in security reviews and customer security questionnaires. The fix carries no recurring cost — it's a one-time configuration change — but ignoring it is the kind of unforced error that turns a routine audit into a finding and a routine incident into a much larger one.

Priya runs the security-and-compliance cadence with the platform team. A High-severity ElastiCache.7 finding lands on the posture dashboard against the production session cache. Her first question isn't technical — it's "is anything exposed right now, and how long has it been like this?" The answer is that the cache holds live session data and has been on default networking since a hackathon eighteen months ago. That's enough to prioritise it.

The conversation that follows is about sequencing, not subnets. Priya doesn't ask which CIDR ranges or route tables — she asks three things: is this a free fix or does it add cost, does fixing it require downtime, and when can it land. The engineer confirms it's a one-time configuration change with no recurring cost, needs a brief maintenance window because the cluster has to be rebuilt on the new network, and can be done this week. Priya schedules it, notes it on the compliance tracker, and flags it to the customer-trust team because this exact control shows up on the security questionnaire a large prospect just sent over.

A week later the finding is cleared and the posture report is clean on this control. Priya's lasting move isn't the one fix — it's adding "no resource ships on a default subnet group" to the release checklist so the next cache is born compliant. The finding was free to fix; her job is making sure it's the last time it appears.

This finding has essentially no recurring cost attached — moving a cache to a custom subnet group doesn't change what you pay AWS. So the budget angle isn't about saving money; it's about avoiding a category of cost that doesn't show up on the cloud bill: the cost of a security incident, a failed audit, or a stalled enterprise deal.

It's a High-severity control mapped to network-segmentation requirements in NIST 800-53. In practice that means it appears in your compliance posture, in audit evidence packs, and on the security questionnaires that enterprise customers send before they'll sign. An open High finding against a data store holding live session or customer data is a real friction point in those processes — the kind of thing that turns a two-week procurement security review into a two-month one.

The economics strongly favour fixing it immediately. The remediation is a one-time engineering task with no ongoing cost and no performance trade-off — there's no "we'll save more by waiting" argument and no recurring spend to budget for. The only real decision is sequencing, because the cluster has to be rebuilt on the new network, which usually means a short maintenance window.

As a governance signal, clusters on default subnet groups indicate that infrastructure is being created ad hoc rather than from a hardened template. If this finding keeps reappearing on new resources, the issue isn't the individual cache — it's that the team's default deployment path doesn't bake in network discipline, and that pattern predicts other posture findings down the line.

ElastiCache is the fast in-memory layer that keeps applications responsive, and it frequently holds sensitive working data. This finding means one or more of those caches was deployed onto the default, deliberately-permissive network configuration AWS ships for convenience, rather than a restricted network your team controls.

This is a network-hygiene and segmentation issue, not a cost one. The remediation is free and one-time; the risk of leaving it is that a high-value data store sits in the most exposed part of the network, which is exactly the kind of thing that turns up in security audits, customer questionnaires, and post-incident reviews. The broader signal is whether the organisation defaults to deliberate network design or to whatever AWS hands you first.

At one company a High-severity finding — a production cache sitting on default networking — surfaced during prep for an enterprise customer's security review. The exec sponsor's instinct wasn't to ask how it gets fixed; it was to ask why it existed at all: "Why is a store of customer session data on the network we ship by default? Who signed off on that, and how many more are like it?"

The team fixed the one cache in under a day at no recurring cost. The more important change was structural: deploying anything onto a default VPC or default subnet group became a release-blocking check, so the question could never come up in a customer audit again. Within a quarter the security questionnaire answer flipped from an awkward "we're remediating" to a clean "all data stores run on purpose-built private networks."

That's the right outcome state. The goal isn't to chase individual findings to zero by hand — it's to make "deliberate network design" the default so this class of finding stops being generated. The posture report becomes a confidence signal rather than a recurring to-do.

This is a High-severity security finding with no associated cost — the fix is free and one-time. It's on the report because it represents a meaningful, easily-avoided exposure: a high-value data store placed in the most permissive part of the network. The risk is real, the remediation is cheap, and that combination makes leaving it unaddressed an unforced error.

The reason to care beyond the single finding is what it signals. A clean record here means infrastructure is being built from deliberate, hardened patterns. A recurring stream of these findings means new resources are being deployed on whatever AWS provides by default — and the same gap that puts a cache on the default network tends to show up across the rest of the estate. This control sits squarely in the security and audit-readiness conversation, and it's exactly the sort of thing enterprise customers probe before they trust you with their data.