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.

Example Diagrams

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.")

Scenario 2: Each server is assigned a different security group within the same AWS region. In this example, since the servers are not using the same security group, they can only communicate with each other across public IP addresses. However, these servers would be able to communicate over their private IP addresses if the security groups were added to each other (as depicted in Scenario 3).

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.

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.

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.

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.

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.

See Also

• Create a New EC2 Security Group