How to Configure AWS Security Groups Using CIDR Blocks

AWS security groups are stateful firewalls that control inbound and outbound traffic for EC2 instances, RDS databases, load balancers, and other resources. Every rule in a security group specifies a CIDR block — the set of IP addresses permitted to initiate or receive connections. Writing these rules correctly is foundational to cloud security.

How Security Group Rules Work

A security group rule defines a protocol (TCP, UDP, ICMP), a port range, and a source or destination CIDR. AWS evaluates inbound rules when traffic arrives and outbound rules when traffic leaves. Because security groups are stateful, the return traffic for an allowed inbound connection is automatically permitted — you do not need a matching outbound rule.

The 0.0.0.0/0 Rule — Use With Extreme Caution

The CIDR block 0.0.0.0/0 means "all IPv4 addresses" — effectively the entire internet. Many tutorials use it for convenience, but it exposes your resource to every scanner, bot, and attacker on the internet. Reserve it only for resources that genuinely need public access, such as a load balancer accepting HTTP/HTTPS traffic. Never apply it to SSH (port 22), RDP (port 3389), or database ports. Use the 0.0.0.0/0 calculator page to understand exactly what this range covers.

Restricting to Your VPC

For resources that should only communicate within your VPC, use your VPC's CIDR block as the source. If your VPC is 10.0.0.0/16, a security group rule with that CIDR as the source allows traffic from any resource in the VPC. This pattern is correct for internal services: application servers connecting to databases, microservices calling each other, or health check endpoints.

Allowing Office or Home IP Ranges

For administrative access — SSH to a bastion host, or direct database access from a developer machine — use your office's public IP as a /32 CIDR. A /32 is a single IP address: 203.0.113.42/32 allows only that exact IP. If your office uses a range of IPs, check with your ISP for the appropriate CIDR block. See the /32 subnet reference for a reminder of why this notation works.

Allowing Traffic from AWS Services

Some scenarios require allowing traffic from specific AWS services. For example, if your EC2 instances sit behind a CloudFront distribution, you may want to restrict direct HTTP access to CloudFront's IP ranges only. AWS publishes all its service IP ranges in a machine-readable file — browse them on the AWS IP ranges page. You can filter by service to find just the CloudFront prefixes.

Security Group vs Network ACL

Security groups operate at the instance level and are stateful. Network ACLs (NACLs) operate at the subnet level and are stateless — you must explicitly allow return traffic. For most use cases, security groups are sufficient. Use NACLs only when you need explicit subnet-level deny rules or a defence-in-depth layer on top of security groups. The CIDR notation is identical in both contexts.

Practical Checklist

• Never allow SSH or RDP from 0.0.0.0/0
• Use /32 for individual IP allowlists
• Use your VPC CIDR for internal traffic rules
• Use service-specific IP ranges from the AWS ranges feed for service-to-service traffic
• Audit rules quarterly — IPs change, people leave, ranges get deprecated