# AWS Security Groups’ Best Practices

> Best practices for AWS security groups, the virtual firewalls of EC2, RDS and other resources: naming, groups as sources, least privilege and rule descriptions.

- Source: https://www.itwonderlab.com/aws-security-groups-best-practices/
- Published: 2023-09-07
- Updated: 2026-10-05
- Author: Javier Ruiz Jiménez (https://www.javierruizjimenez.com/)
- Site: IT Wonder Lab (https://www.itwonderlab.com/)

---

## AWS Security Groups

[Security groups](https://www.itwonderlab.com/aws-security-groups/) are the main firewall of the resources of a [VPC](https://www.itwonderlab.com/aws-vpc/). A few simple rules keep them understandable and secure.

### Create a small number of groups that can be combined

Create a small number of security groups that can be combined to build the desired security configuration. We recommend having a **generic group for each type of resource** with all the common rules, and **a specific group for each individual resource** (or application) with its particularities.

- **A generic default group for each resource type**: it holds the rules that apply to every resource of that type, for example the SSH access to EC2 instances from a fixed administration IP address, or the access to the database port for administration.
  - **ditwl-sg-rds-mariadb-def**: default security group for all the MariaDB RDS resources. It is specific to MariaDB because another type of database uses a different port.
  - **ditwl-sg-ec2-def**: default security group for all EC2 instances. It has the SSH access rule.
- **A specific group for each resource or application**: named with part of the resource name, with a prefix for the cloud and the resource type.
  - **ditwl-sg-rds-mariadb-pro-pub-01**: security group of the production MariaDB RDS instance.
  - **ditwl-sg-ec2-pro-pub-01**: security group of the production web servers.

### Use groups as sources, not IP addresses

Avoid creating too many groups, and do not use a CIDR block as a source, except for the Internet. It is better to use **another security group as the source**: an element gets access to other resources by being a member of a group, not by having a specific IP address that can change. This is the pattern used in the [AWS RDS](https://www.itwonderlab.com/aws-terraform-tutorial-aws-rds/) tutorial, where only the back-end security group can reach the database port.

### Apply the principle of least privilege

- Open only the ports that are needed, and to the smallest possible source.
- Do not open SSH (22) or RDP (3389) to `0.0.0.0/0`. Use a fixed administration address, a VPN, or better [AWS Systems Manager Session Manager](https://www.itwonderlab.com/aws-systems-manager/), which needs no inbound rules.
- Databases and back-end servers belong in private [subnets](https://www.itwonderlab.com/aws-subnets/) and never accept traffic from the Internet.
- Restrict the outbound rules of sensitive resources (for example, to the ports and groups that they need) instead of allowing all outbound traffic.
- Review the groups regularly and delete the ones that are not used.

### Describe and tag every rule

Write a description for every rule that explains why it exists, and use tags (`Name`, `owner`, `environment`) to identify the group. It makes audits and reviews much easier.

### Manage them with code

Define the security groups with [Terraform or OpenTofu](https://www.itwonderlab.com/aws-terraform-tutorial-aws-security-groups/) and use a scanner such as Trivy or Checkov (see [Terraform Tools](https://www.itwonderlab.com/aws-terraform-tutorial-terraform-tools/)) to detect open rules before they are deployed. Use `aws_vpc_security_group_ingress_rule` and `aws_vpc_security_group_egress_rule` for the rules, and do not mix them with in-line rules in the same group.

### Do not rely only on security groups

For defense in depth, combine them with [Network ACLs](https://www.itwonderlab.com/aws-network-acl/) for coarse subnet-level rules, [AWS WAF](https://www.itwonderlab.com/aws-waf/) for web applications and [CloudTrail](https://www.itwonderlab.com/aws-cloudtrail/) to audit the changes.