AWS Security Group Rule Generator

The AWS Security Group Rule Generator creates EC2 security group rules from structured CSV input. Enter rules as rows with direction, protocol, port range, source/destination, and description columns, and get AWS CLI commands, Terraform aws_security_group_rule resources, or CloudFormation template snippets ready for scripted, repeatable deployments.

Understanding AWS Security Groups

If you run workloads on AWS, security groups are the primary mechanism for controlling network access to your EC2 instances, RDS databases, Lambda functions, and most other networked resources. Unlike traditional firewalls that sit in front of your network, security groups are attached directly to network interfaces and follow your instances wherever they go -- if you stop and restart an instance or attach it to a different subnet, its security groups travel with it.

The most important thing to understand about AWS security groups is that they are stateful and allow-only. Stateful means that if you allow inbound traffic on port 443, the return traffic for that connection is automatically permitted regardless of outbound rules. Allow-only means there is no "deny" action -- you cannot write a rule that explicitly blocks a specific IP. If an IP address is not matched by any allow rule, it is implicitly denied. This is fundamentally different from iptables or Azure NSGs where you can write explicit deny rules, and it means that security groups are best suited for defining what you want to permit rather than what you want to block. For explicit denials, you need Network ACLs at the subnet level.

Managing security groups through the AWS Console works for a handful of rules, but it breaks down quickly in production environments. A typical three-tier web application might have separate security groups for the load balancer, web servers, application servers, and database -- each with five to ten rules. Changes made through the Console are not tracked, cannot be reviewed before deployment, and are difficult to replicate across multiple environments. This generator enables an Infrastructure as Code workflow: define your rules in a spreadsheet, generate CLI commands or Terraform code, review in a pull request, and deploy consistently across development, staging, and production.

How to Generate AWS Security Group Rules

1. Prepare your rule data in CSV format with columns: direction, protocol, port range, source/destination, and description.
2. Paste or upload the CSV into the generator.
3. Select the output format: AWS CLI, Terraform HCL, or CloudFormation JSON/YAML.
4. Enter the target security group ID (e.g., sg-0123456789abcdef0).
5. Copy the generated commands or configuration blocks for deployment.

CSV Input Format and Generated Output

CSV Input

direction,protocol,from_port,to_port,source,description
ingress,tcp,443,443,0.0.0.0/0,HTTPS from internet
ingress,tcp,22,22,10.0.0.0/8,SSH from internal
ingress,tcp,3306,3306,sg-0abcdef1234567890,MySQL from app tier
egress,tcp,443,443,0.0.0.0/0,HTTPS outbound
ingress,-1,-1,-1,sg-0abcdef1234567890,All traffic from app tier

AWS CLI Output

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0","Description":"HTTPS from internet"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":22,"ToPort":22,"IpRanges":[{"CidrIp":"10.0.0.0/8","Description":"SSH from internal"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"UserIdGroupPairs":[{"GroupId":"sg-0abcdef1234567890","Description":"MySQL from app tier"}]}]'

Terraform Output

resource "aws_security_group_rule" "https_from_internet" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "HTTPS from internet"
}

resource "aws_security_group_rule" "ssh_from_internal" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["10.0.0.0/8"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "SSH from internal"
}

AWS Security Group Source Types

When to Use the AWS Security Group Generator

• VPC buildout -- Generate all security group rules for a new VPC deployment from a single CSV planning document.
• Compliance automation -- Convert security policy spreadsheets into enforceable AWS CLI commands or Terraform code.
• Multi-account consistency -- Generate identical security group rulesets for deployment across development, staging, and production accounts.
• Migration from on-premises -- Translate existing iptables or firewall rules into AWS security group format during cloud migration.
• Audit and documentation -- Export existing rules as CSV, review them, and regenerate clean configurations.

How AWS Security Groups Work

Stateful Behavior

AWS security groups are stateful -- if you allow inbound traffic on port 443, the return traffic is automatically allowed regardless of outbound rules. This is different from iptables or nftables where you must explicitly allow return traffic or use connection tracking.

Rule Limits

Each security group supports up to 60 inbound rules and 60 outbound rules by default (adjustable via quota increase request). Each CIDR block, security group reference, or prefix list counts as one rule. Use the Allowlist Builder to minimize the number of CIDR entries.

Evaluation

All rules in a security group are evaluated together -- there is no ordering. If any rule allows the traffic, it is permitted. There is no "deny" action in security groups; absence of a matching allow rule is an implicit deny. For explicit deny rules, use Network ACLs instead.

Security Group References

One of the most powerful features of AWS security groups is the ability to reference other security groups as sources or destinations. Instead of specifying CIDR blocks for your application servers, you reference the application tier's security group ID. This means that when you add or remove instances from the application tier, the database security group automatically allows or revokes access without any rule changes.

Practical Advice for AWS Security Groups

The most common mistake in security group management is using 0.0.0.0/0 (all traffic) too liberally. In a rush to get things working, engineers open SSH (port 22) to 0.0.0.0/0 "temporarily" and forget to restrict it later. AWS Security Hub and Config Rules can detect this, but prevention is better than detection. Use security group references for inter-tier communication, restrict SSH to your VPN or bastion host's security group, and limit 0.0.0.0/0 to ports that genuinely need public access (typically just 80 and 443 on load balancers).

When working with Terraform, prefer using aws_security_group_rule resources (which this generator produces) over inline ingress and egress blocks within an aws_security_group resource. Inline rules and separate rule resources conflict with each other, and separate resources are easier to manage, review, and conditionally apply. They also prevent the "all rules change when one changes" problem that inline blocks cause.

Rule descriptions are not optional -- they are your future self's documentation. AWS displays descriptions in the Console, and they show up in security audits and compliance reports. Every rule should answer "why" this access exists: "SSH from VPN gateway" is better than "SSH" or no description at all. The generator preserves your CSV descriptions in the output, so take the time to write meaningful ones.

Frequently Asked Questions

What does protocol -1 mean in AWS security groups? Protocol -1 means "all traffic" -- it matches TCP, UDP, ICMP, and all other IP protocols. When using protocol -1, set both from_port and to_port to -1 as well. This is how AWS represents an "allow all" rule.

Can I reference a security group in a different VPC? Yes, for peered VPCs. Use the full security group ID and ensure VPC peering is configured. The generator outputs the GroupId reference; for cross-account references, you also need the account owner ID.

How do I handle both IPv4 and IPv6 CIDR blocks? The generator produces separate IpRanges (for IPv4) and Ipv6Ranges (for IPv6) entries automatically based on the address format. A rule for 0.0.0.0/0 only covers IPv4; add a separate rule for ::/0 to cover IPv6.

What is the difference between security groups and Network ACLs? Security groups are stateful, instance-level, and allow-only. Network ACLs are stateless, subnet-level, and support explicit deny rules. Most configurations use security groups as the primary control and Network ACLs for additional defense-in-depth.

How do I stay within the 60-rule limit? Aggregate CIDR blocks using the Allowlist Builder, use security group references instead of individual IPs for inter-tier communication, and combine port ranges where possible (e.g., from_port: 8000, to_port: 8080 instead of 80 individual rules). You can also request a quota increase through the AWS Service Quotas console.

Can I generate rules for multiple security groups at once? The generator targets a single security group per run. For multi-group configurations, run it once per security group with the appropriate rules for each tier. This matches best practices for separation of concerns in security group design.

Related Tools

• Azure NSG Rule Generator - Generate Azure NSG rules from CSV
• iptables Rule Generator - Generate iptables rules from CSV
• Allowlist Builder - Build minimal CIDR allowlist from IP list
• Blocklist Builder - Build minimal CIDR blocklist from IP list
• Rule Conflict Finder - Find duplicate, shadowed, or overlapping firewall rules