The default VPC security group should restrict all traffic because it is a shared baseline that can otherwise become an easy path for unintended east-west communication or exposure. A deny-by-default posture forces administrators to create explicit rules for required traffic only. Watch for new instances attached to permissive defaults.
Why a default security group must start from deny-by-default
The default VPC security group is a shared baseline, so any permissive rule attached to it can silently spread to new workloads and create unintended east-west paths. A deny-by-default stance forces teams to treat every connection as an explicit design decision rather than inherited access.
That matters most in AWS environments where instances are created quickly, autoscaled, or moved between teams. If the default group allows broad traffic, a new instance may become reachable before anyone has reviewed its intended role, and the resulting exposure is often discovered only after segmentation assumptions break.
When teams use Cloud Network Security Guide, the practical pattern is to treat the default group as a safety net, not a working policy. Its job is to keep unknown assets from talking until a specific security group or network path is assigned for a real use case.
What restricting all traffic actually protects
Restricting all inbound and outbound traffic at the default layer helps preserve network intent. It reduces accidental adjacency between services, limits the blast radius of newly launched instances, and prevents inherited rules from becoming a hidden dependency across accounts, VPCs, or deployment pipelines.
This control is especially useful when the environment includes shared subnets, shared services, or multiple application owners. A permissive default can create a shortcut around intended boundaries, while a strict baseline makes any allowed traffic visible in the rule set that actually owns it.
Cloud Misconfiguration Guide is relevant here because permissive security groups are a classic misconfiguration pattern, not just a network preference. The issue is less about one rule and more about preventing configuration drift from turning a temporary exception into an enduring exposure.
How to use a restrictive default without breaking operations
The safest operating model is to keep the default security group empty and rely on purpose-built groups for each workload tier. That gives you a clean baseline while still allowing controlled ingress for load balancers, admin paths, or service-to-service traffic where it is actually required.
For AWS teams, the discipline should be to review any instance that lands in the default group, confirm why it was attached there, and decide whether it belongs in a narrower rule set. The same review should cover automation that creates instances, because the failure mode is usually an automation path that forgets to attach the intended group.
AWS Security Guide fits this operational view because default-network posture is part of wider AWS hardening, including account guardrails, logging, and secure baseline design. The point is to make the safe state the easiest state for every new resource.
Risk and Threat Considerations
Permissive default security groups create a low-friction path for unintended connectivity, and that can turn a single misattached instance into an internal foothold. In practice, the risk is not only exposure to the internet, but also quiet east-west movement between workloads that were assumed to be separated.
Failure mechanism: A new instance inherits the default group, receives broad ingress or egress, and becomes reachable before the owner applies the intended security group. Attackers or accidental internal traffic can then use that opening to probe services, move laterally, or bypass segmentation assumptions.
Impact: The result can be unauthorized access, service-to-service trust leakage, and a larger blast radius for any compromised host or misrouted internal request. In cloud environments, the damage often scales with automation, because the same unsafe baseline can be replicated across many launches.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Restricting default VPC traffic is network boundary protection for workload isolation. |
| Recommendation — Enforce boundary rules that block unnecessary VPC traffic by default. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Default security group hardening is a core network infrastructure safeguard. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Empty default security groups are a secure baseline configuration control. | |
| Recommendation — Harden default network objects and remove permissive baseline rules. Set the default security group to deny traffic and prevent configuration drift. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | The question is about secure baseline configuration for a shared AWS control. |
| PR.AA-05 — Network Integrity | Restricting traffic in the default group preserves intended network paths and segmentation. | |
| Recommendation — Define the default security group as a locked baseline and monitor for drift. Use network controls to block unintended east-west paths from default resources. | ||
Practitioner Guidance
What to verify: Check whether the default security group is truly empty for both inbound and outbound rules, and confirm that new instances are not landing there by mistake. Also verify that deployment automation assigns the correct security group every time, rather than relying on manual cleanup.
What good looks like: Every workload has an explicit security group tied to its function, the default group contains no traffic rules, and any exception is documented as temporary and owned. If an instance still depends on the default group for real traffic, treat that as a design gap, not a normal state.
Practitioner takeaway: The default group should fail safe, because the real control is not just blocking traffic, it is preventing hidden baseline connectivity from becoming the environment’s unreviewed default architecture.
Related resources from NHI Mgmt Group
- What breaks when teams keep using the AWS default security group for different EC2 workloads?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should organizations prioritize security in their MCP implementations?
- How should security teams restrict IAM:PassRole in AWS environments?