Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Clouds > AWS Regions > EC2 Security Groups > Concepts > About EC2 Security Groups

About EC2 Security Groups

Overview

Amazon Web Services (AWS) EC2 security groups serve as firewalls for EC2 servers, for restricting ingress (incoming) communications based on protocol type (TCP, UDP, ICMP), IP address, and ports. Each EC2 server you launch must have at least one assigned security group.

Security groups determine who can communicate with servers that belong to that group.  By default, all incoming network traffic to an EC2 server is rejected unless the server belongs to one or more security groups whose rules specifically allow that traffic. With the exception of Amazon Virtual Private Cloud (VPC) security groups, discussed under VPCs, EC2 security groups only affect incoming communications and do not prevent a server from initiating outbound communications.

Table of Contents

Things to Consider

  • A security group's permissions include ingress rules that apply to ports and IP protocols (TCP, UDP, ICMP).
  • You cannot change a security group's name.
  • Security groups are AWS-region-specific, but not availability-zone specific. For example, you can assign a security group in AWS region US-East to servers in any availability zone within that region. However, you cannot assign an EC2 server in region US-West to a security group that you created and defined in the US-East region. 
  • Each AWS account can have up to 500 security groups across all AWS regions.
  • When you create your AWS account, AWS automatically creates a "default" security group in each region that will be used if an instance is launched and no security group is specified. As a safety precaution, the default security group is predefined to disallow all ingress traffic (i.e. It is closed to all incoming traffic that does not come from instances within the same security group). Although you can use the "default" security group in each AWS region, we recommend that you create your own security groups with ingress rules that are specific to your deployment or application.
  • You must assign each server to at least one security group. A server can have multiple security groups assigned (see Assign Multiple Security Groups to an Instance).
  • Security groups are assigned to a server when it is launched. After you launch a server, you cannot add additional security groups to it or remove assigned security groups from it.
  • IP-address-based permissions apply to both private and public IP addresses. You can bypass IP-address-based permissions for communications coming from other EC2 servers, however, by adding an entire EC2 security group to itself or another security group, as described in Add a Security Group to Itself or Add a Security Group to Another Security Group. Otherwise, IP-addressed based permissions are always considered.  
  • Although servers in the same security group can communicate with each other over private or public IP addresses, connections should be made using private IP addresses when possible. Regular data-transfer costs apply to all connections made to a server's public IP address—even connections from another EC2 server in the same availability zone.
  • Ingress rules are additive in nature. See Assign Multiple Security Groups to an Instance.
  • You can change ingress rules in a security group at any time. Changes will take effect immediately on running servers unless you remove an open port that is being used in an active session. For example, if you remove port 80 access from the security group used by your load balancer servers, any new requests over port 80 will immediately be denied, but any active sessions over port 80 will be preserved until the sessions are ended. Conversely, if you open a port (e.g., 443) for a security group, all servers using that security group will immediately have that port open.
  • You may want to use different security groups for different deployments in your Dashboard account. For example, you might have a couple security groups for your production deployment, but only one group for your internal staging deployment.

Access Permissions

Security groups use CIDR-based notation, illustrated in the diagram below, to grant access permissions to servers. For CIDR-based rules, you can also specify the protocol and port range.

diag-permissions-v2.png

Example Diagrams

Important! Many of these scenarios only apply to EC2-Classic accounts and not EC2-VPC accounts. EC2-VPC accounts are new (or legacy) accounts that require the use of a default VPC and subnet when launching instances, and VPC security groups do not allow other security groups or private IPs from other VPCs to be added to them. Instances in one VPC will not communicate over their private IPs with other instances in another VPC. For more info, see EC2-Classic and EC2-VPC Behavioral Differences.

 

Scenario 1: Servers are in the same security group, and the group is not added to itself. The servers are in the same AWS region, though they could be in different availability zones in that region. Servers in the security group establish connections to each other over private IP addresses through the designated opened ports. In this example, instead of designating 0.0.0.0/0 to enable protocol and port access to any IP address, we applied a more restrictive setting (10.0.0.0/8) that still allows these servers to communicate with each other since they are in the same AWS region. (All EC2 servers are assigned a private IP address starting with "10.")

diag-SecurityGroupScenarios1-v1.png

 

Scenario 2: Each server is assigned a different security group within the same AWS region. In this example, even though the servers are not using the same security group, they can still communicate with each other across public and private IP addresses because they are in the same AWS region. However, a better option might be adding each server's security group to each other (as depicted in Scenario 5 or 6 below).

diag-SecurityGroupScenarios2-v1.png

 

Scenario 3: Requests are made to a server from outside its AWS region (either from EC2 servers in a different AWS region or servers outside of AWS). A server in a different AWS region is treated the same way as a server outside of EC2. In this example, any server can communicate with the instance in Security Group "A" via its public IP address, over port 3306.

Note: Requests made from EC2 instances in a different AWS region via a private IP address will be redirected to use the public IP address.

diag-SecurityGroupScenarios3-v1.png

 

Scenario 4: Add a security group to itself. Servers establish connections over private (not public) IP addresses and can use any protocols and ports specified during permissions setup. In this example, all servers in security group "A" can access servers in the same group, using any protocol and port, while the administrator at IP address 1.2.3.4 can access servers in group "A" using port 3306 and the server's public IP address.

Important! When adding EC2-Classic security groups to themselves or to another group, the rules for the group(s) will only apply to private IP address connectivity. See the AWS documentation for more details.

diag-SecurityGroupScenarios4-v1.png

 

Scenario 5: Add a security group to another security group. In this case, servers in the first security group establish connections over private (not public) IP addresses to servers in the other security group using specified ports and protocols. In this example, all servers in security group "B" can access servers in group "A" using any protocol and port combination, while only the administrator at 1.2.3.4 can access servers in group "A" using port 3306 and the server's public IP address.

Important! When adding EC2-Classic security groups to themselves or to another group, the rules for the group(s) will only apply to private IP address connectivity. See the AWS documentation for more details.

diag-SecurityGroupScenarios5-v2.png

 

Scenario 6: Add a security group to another security group with limited protocol and/or port access. Servers establish connections via private (not public) IP addresses but can only use a specific protocol port or range of protocol ports for access. In this example, all servers in security group "B" can access servers in group "A" using TCP over port 3306.

Important! When adding EC2-Classic security groups to themselves or to another group, the rules for the group(s) will only apply to private IP address connectivity. See the AWS documentation for more details.

diag-SecurityGroupScenarios7-v1.png

 

Scenario 7: Restrict access to only receive requests from a server with a specific IP address. This can be especially useful when using Elastic IP (EIP) addresses, when a server will only receive requests from another server using a specific EIP.

diag-SecurityGroupScenarios6-v1.png

You must to post a comment.
Last modified
12:08, 19 Nov 2013

Tags

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.