What is VPC Network Security in AWS?
VPC network security is the foundation of protecting workloads running on AWS. It defines how traffic is allowed to flow between users, applications, and infrastructure components – both inside your AWS environment and from external networks.
AWS achieves this through a layered security model, combining network isolation, segmentation, and traffic controls. The core components include:
- Amazon Virtual Private Cloud (VPC)
- Subnets and Availability Zones
- Security Groups
- Network Access Control Lists (NACLs)
This layered approach aligns directly with the AWS Well-Architected Framework, particularly the Security, Reliability, and Operational Excellence pillars, and is essential for building secure, scalable production environments.
What Is an Amazon VPC?
An Amazon Virtual Private Cloud (VPC) is a logically isolated network within your AWS account. It allows you to define:
- IP address ranges using CIDR blocks
- Subnets and routing behaviour
- Internet and private connectivity
- Network-level security controls
AWS provides a default VPC to simplify onboarding, but default VPCs are not suitable for production workloads. Production environments require custom VPCs to enforce tighter security boundaries, predictable traffic flows, and clearer separation between application tiers.
From an architectural standpoint, the VPC represents the primary trust boundary for all AWS resources deployed within it.
Subnets, Availability Zones, and Network Segmentation
A VPC is divided into subnets, which are smaller IP ranges carved from the VPC CIDR block.
Key characteristics of subnets in AWS:
- Each subnet belongs to a single Availability Zone (AZ)
- Subnets enable high availability when workloads are spread across multiple AZs
- They define access tiers within your architecture
Common subnet patterns include:
- Public subnets for internet-facing resources such as load balancers or bastion hosts
- Private subnets for application servers and internal services
- Isolated subnets for databases or sensitive workloads with no internet access
Effective subnet design helps control traffic flow, manage IP allocation, and enforce security boundaries between application layers. However, subnets alone do not enforce traffic rules – this is handled by Security Groups and NACLs.
What Are Security Groups in AWS?
Security Groups act as stateful, instance-level virtual firewalls for AWS resources, including:
- EC2 instances
- Elastic Load Balancers
- RDS databases
- ECS and EKS services
Security Groups control inbound and outbound traffic based on rules that specify protocol, port, and source or destination.
Key characteristics of Security Groups:
- All inbound traffic is denied by default
- Only explicitly allowed traffic is permitted
- They are stateful – if inbound traffic is allowed, the return traffic is automatically permitted
This stateful behaviour simplifies configuration while still enforcing strong access control.
Common Security Group Use Cases
Restricting Traffic Between the Internet and Your VPC
Public-facing resources should expose only what is necessary, such as HTTPS (port 443), and ideally only from trusted IP ranges. Reducing exposed ports and avoiding unrestricted access significantly lowers the attack surface.
Restricting Traffic Within the VPC
Not all internal resources should communicate freely. For example, application servers may require database access, but other services should not. Security Groups enable role-based access control and reduce the risk of lateral movement if a resource is compromised.
Security Group Best Practices
- Apply the principle of least privilege
- Create role-specific Security Groups (e.g.
alb-sg,app-sg,db-sg) - Avoid overly permissive rules such as
0.0.0.0/0unless absolutely required - Expose only load balancers to the internet
- Use Security Group references instead of static IP addresses
- Allow backend services to accept traffic only from known Security Groups
- Regularly audit and remove unused rules
- Enable VPC Flow Logs to monitor traffic patterns and support investigations
These practices are commonly assessed during AWS Well-Architected Framework reviews.
What Are Network Access Control Lists (NACLs)?
Network Access Control Lists (NACLs) operate at the subnet level and provide an additional layer of network security.
Unlike Security Groups, NACLs are stateless, meaning:
- Inbound and outbound rules are evaluated separately
- Both allow and deny rules are supported
- Rules are processed in numerical order
NACLs are most effective when used to enforce broad traffic policies before traffic reaches individual resources.
When Should You Use NACLs?
NACLs are well suited for:
- Separating public and private subnet traffic
- Blocking known malicious IP ranges
- Enforcing baseline network restrictions
- Supporting a defence-in-depth security strategy
They are not a replacement for Security Groups, but a complementary control that strengthens overall network security.
NACL Best Practices
- Use separate NACLs for public and private subnets
- Explicitly deny unnecessary traffic
- Place specific rules before general ones
- Keep configurations simple and well-documented
- Review and update NACLs as architectures evolve
Securing Traffic Within Your AWS VPC: Practical Checklist
To secure traffic effectively within a VPC:
Restrict Internet Access
Lock down public-facing Security Groups to only required ports and trusted sources.Control Internal Communication
Enforce strict Security Group relationships between application tiers and prevent direct access to sensitive services.Apply Subnet-Level Controls
Use NACLs to enforce high-level traffic boundaries between public, private, and isolated subnets.
When implemented together, these controls reduce risk, limit blast radius, and improve compliance posture.
Talk to an AWS specialist
Through our AWS Well-Architected Framework reviews, we help organisations strengthen their infrastructure by embedding resilience, operational excellence, and automated best practices into every layer of their cloud environment.
As an AWS Advanced Tier Partner, we can also help unlock AWS funding programmes to subsidise your review – making it easier to identify risks, improve recovery readiness, and build customer trust before an incident occurs.
To arrange a free AWS Well-Architected consultation, visit our information page or explore our AWS Marketplace listing.
