6

I haven't been able to find any best practices for AWS security groups. I figure there are two approaches I could take, but I'm not sure on if there are any particular drawbacks to either one.

Scenario 1:
Define small, specialized security groups such as "ssh," "mongodb," "web," etc, and then in essence "stacking" multiple security groups on each EC2 instance to specify which ports are open.

Scenario 2:
Define larger, more generic security groups such as "web1" which opens ports 80, 443, ssh, database, and apply this to any appropriate EC2 instances.

I think I'd rather go with scenario #1, but don't know if there are any disadvantages or technical issues with this approach. Is there a best practice?

ffxsam
  • 493
  • 2
  • 4
  • 10

1 Answers1

2

AWS limits the amount of groups you can apply to a network interface: Security groups per network interface 5

A common approach is to create SGs such that it's easy to update your fleet of servers, but in a way that still makes sense for all the hosts they're applied to.

Consider these points

These factors will shape what you'll want to open up for your instance security groups.

  • Use NACLs for course grain permissions
  • Use SGs for more specific access
  • Put your instances in a private subnet (this advice is for non-public facing instances. e.g where you've used an ELB to connect to your web instance)

A generic approach

Given all this, a common approach would be:

  • All Instances get a common security group (this has rules you want applied for every instance)
  • Each Instance has a role, like "web server" or "mail server" or "postgres db" and each role has an associated security group
  • Your specific instance may have an additional security group for any customisations that aren't covered by the first two groups

Variations on the "common" SG:

  • "common_linux OR common_windows"
  • "common" AND "common_linux OR common_windows".
Drew Khoury
  • 4,697
  • 8
  • 29
  • 29