5

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
  • 383
  • 2
  • 3
  • 9
  • Make sure to take a look at the limits imposed on security groups, especially the numbers of SGs allowed per region/VPC: http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html If you're in VPC you may be able to avoid certain performance problems if you don't use security groups at all for machines that don't have to be exposed to the Internet. – Karol Nowak Dec 16 '15 at 20:22
  • Both approaches have their uses IMHO. Find a good balance between the number of SGs and the complexity of each SG. Also bear in mind that different instances _might_ utilize different versions of, say, the "ssh" SG (e.g. in terms of from where inbound traffic is allowed). – Jukka Dec 16 '15 at 22: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,569
  • 8
  • 26
  • 28