# Control traffic to your AWS resources using security groups A *security group* controls the traffic that is allowed to reach and leave the resources that it is associated with. For example, after you associate a security group with an EC2 instance, it controls the inbound and outbound traffic for the instance. When you create a VPC, it comes with a default security group. You can create additional security groups for a VPC, each with their own inbound and outbound rules. You can specify the source, port range, and protocol for each inbound rule. You can specify the destination, port range, and protocol for each outbound rule. The following diagram shows a VPC with a subnet, an internet gateway, and a security group. The subnet contains an EC2 instance. The security group is assigned to the instance. The security group acts as a virtual firewall. The only traffic that reaches the instance is the traffic allowed by the security group rules. For example, if the security group contains a rule that allows ICMP traffic to the instance from your network, then you could ping the instance from your computer. If the security group does not contain a rule that allows SSH traffic, then you could not connect to your instance using SSH. ![\[VPC with 2 subnets, 2 security groups, servers in subnets associated with different security groups\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/security-group-overview.png) **Topics** + [ ## Security group basics ](#security-group-basics) + [ ## Security group example ](#security-group-example-details) + [ # Security group rules ](security-group-rules.md) + [Default security groups](default-security-group.md) + [Create a security group](creating-security-groups.md) + [ # Configure security group rules ](working-with-security-group-rules.md) + [ # Delete a security group ](deleting-security-groups.md) + [ # Associate security groups with multiple VPCs ](security-group-assoc.md) + [ # Share security groups with AWS Organizations ](security-group-sharing.md) **Pricing** There is no additional charge for using security groups. ## Security group basics + You can assign a security group to resources created in the same VPC as the security group or to resources in other VPCs if using the [Security Group VPC Association feature](security-group-assoc.md) to associate the security group to other VPCs in the same Region. You can also assign multiple security groups to a single resource. + When you create a security group, you must provide it with a name and a description. The following rules apply: + A security group name must be unique within the VPC. + Security group names are not case-sensitive. + Names and descriptions can be up to 255 characters in length. + Names and descriptions are limited to the following characters: a-z, A-Z, 0-9, spaces, and .\$1-:/()\$1,@[]\$1=&;\$1\$1\$1\$1\$1. + When the name contains trailing spaces, we trim the space at the end of the name. For example, if you enter "Test Security Group " for the name, we store it as "Test Security Group". + A security group name can't start with `sg-`. + Security groups are stateful. For example, if you send a request from an instance, the response traffic for that request is allowed to reach the instance regardless of the inbound security group rules. Responses to allowed inbound traffic are allowed to leave the instance, regardless of the outbound rules. + Security groups do not filter traffic destined to and from the following: + Amazon Domain Name Services (DNS) + Amazon Dynamic Host Configuration Protocol (DHCP) + Amazon EC2 instance metadata + Amazon ECS task metadata endpoints + License activation for Windows instances + Amazon Time Sync Service + Reserved IP addresses used by the default VPC router + There are quotas on the number of security groups that you can create per VPC, the number of rules that you can add to each security group, and the number of security groups that you can associate with a network interface. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md). **Best practices** + Authorize only specific IAM principals to create and modify security groups. + Create the minimum number of security groups that you need, to decrease the risk of error. Use each security group to manage access to resources that have similar functions and security requirements. + When you add inbound rules for ports 22 (SSH) or 3389 (RDP) so that you can access your EC2 instances, authorize only specific IP address ranges. If you specify 0.0.0.0/0 (IPv4) and ::/ (IPv6), this enables anyone to access your instances from any IP address using the specified protocol. + Do not open large port ranges. Ensure that access through each port is restricted to the sources or destinations that require it. + Consider creating network ACLs with rules similar to your security groups, to add an additional layer of security to your VPC. For more information about the differences between security groups and network ACLs, see [Compare security groups and network ACLs](infrastructure-security.md#VPC_Security_Comparison). ## Security group example The following diagram shows a VPC with two security groups and two subnets. The instances in subnet A have the same connectivity requirements, so they are associated with security group 1. The instances in subnet B have the same connectivity requirements, so they are associated with security group 2. The security group rules allow traffic as follows: + The first inbound rule in security group 1 allows SSH traffic to the instances in subnet A from the specified address range (for example, a range in your own network). + The second inbound rule in security group 1 allows the instances in subnet A to communicate with each other using any protocol and port. + The first inbound rule in security group 2 allows the instances in subnet B to communicate with each other using any protocol and port. + The second inbound rule in security group 2 allows the instances in subnet A to communicate with the instances in subnet B using SSH. + Both security groups use the default outbound rule, which allows all traffic. ![\[A VPC with two security groups and servers in two subnets. The servers in subnet A are associated with security group 1. The servers in subnet B are associated with security group 2.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/security-group-details.png) # Security group rules The rules of a security group control the inbound traffic that's allowed to reach the resources that are associated with the security group. The rules also control the outbound traffic that's allowed to leave them. You can add or remove rules for a security group (also referred to as *authorizing* or *revoking* inbound or outbound access). A rule applies either to inbound traffic (ingress) or outbound traffic (egress). You can grant access to a specific source or destination. **Topics** + [ ## Security group rule basics ](#security-group-rule-characteristics) + [ ## Components of a security group rule ](#security-group-rule-components) + [ ## Security group referencing ](#security-group-referencing) + [ ## Security group size ](#security-group-size) + [ ## Stale security group rules ](#vpc-stale-security-group-rules) ## Security group rule basics The following are the characteristics of security group rules: + You can specify allow rules, but not deny rules. + When you first create a security group, it has no inbound rules. Therefore, no inbound traffic is allowed until you add inbound rules to the security group. + When you first create a security group, it has an outbound rule that allows all outbound traffic from the resource. You can remove the rule and add outbound rules that allow specific outbound traffic only. If your security group has no outbound rules, no outbound traffic is allowed. + When you associate multiple security groups with a resource, the rules from each security group are aggregated to form a single set of rules that are used to determine whether to allow access. + When you add, update, or remove rules, your changes are automatically applied to all resources associated with the security group. For instructions, see [Configure security group rules](working-with-security-group-rules.md). + The effect of some rule changes can depend on how the traffic is tracked. For more information, see [Connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) in the *Amazon EC2 User Guide*. + When you create a security group rule, AWS assigns a unique ID to the rule. You can use the ID of a rule when you use the API or CLI to modify or delete the rule. **Limitation** Security groups cannot block DNS requests to or from the Route 53 Resolver, sometimes referred to as the 'VPC\$12 IP address' (see [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) in the *Amazon Route 53 Developer Guide*), or as [AmazonProvidedDNS](DHCPOptionSet.md). To filter DNS requests through the Route 53 Resolver, use [Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html). ## Components of a security group rule The following are the components of inbound and outbound security group rules: + **Protocol**: The protocol to allow. The most common protocols are 6 (TCP), 17 (UDP), and 1 (ICMP). + **Port range**: For TCP, UDP, or a custom protocol, the range of ports to allow. You can specify a single port number (for example, `22`), or range of port numbers (for example, `7000-8000`). + **ICMP type and code**: For ICMP, the ICMP type and code. For example, use type 8 for ICMP Echo Request or type 128 for ICMPv6 Echo Request. For more information, see [Rules for ping/ICMP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-ping) in the *Amazon EC2 User Guide*. + **Source or destination**: The source (inbound rules) or destination (outbound rules) for the traffic to allow. Specify one of the following: + A single IPv4 address. You must use the `/32` prefix length. For example, `203.0.113.1/32`. + A single IPv6 address. You must use the `/128` prefix length. For example, `2001:db8:1234:1a00::123/128`. + A range of IPv4 addresses, in CIDR block notation. For example, `203.0.113.0/24`. + A range of IPv6 addresses, in CIDR block notation. For example, `2001:db8:1234:1a00::/64`. + The ID of a prefix list. For example, `pl-1234abc1234abc123`. For more information, see [Managed prefix lists](managed-prefix-lists.md). + The ID of a security group. For example, `sg-1234567890abcdef0`. For more information, see [Security group referencing](#security-group-referencing). + **(Optional) Description**: You can add a description for the rule, which can help you identify it later. A description can be up to 255 characters in length. Allowed characters are a-z, A-Z, 0-9, spaces, and .\$1-:/()\$1,@[]\$1=;\$1\$1\$1\$1\$1. For examples, see [Security group rules for different use cases](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html) in the *Amazon EC2 User Guide*. ## Security group referencing When you specify a security group as the source or destination for a rule, the rule affects all instances that are associated with the security groups. The instances can communicate in the specified direction, using the private IP addresses of the instances, over the specified protocol and port. For example, the following represents an inbound rule for a security group that references security group sg-0abcdef1234567890. This rule allows inbound SSH traffic from the instances associated with sg-0abcdef1234567890. | Source | Protocol | Port range | | --- | --- | --- | | sg-0abcdef1234567890 | TCP | 22 | When referencing a security group in a security group rule, note the following: + You can reference a security group in the inbound rule of another security group if any of the following is true: + The security groups are associated with the same VPC. + There is a peering connection between the VPCs that the security groups are associated with. + There is a transit gateway between the VPCs that the security groups are associated with. + You can reference a security group in the outbound rule if any of the following is true: + The security groups are associated with the same VPC. + There is a peering connection between the VPCs that the security groups are associated with. + No rules from the referenced security group are added to the security group that references it. + For inbound rules, the EC2 instances associated with a security group can receive inbound traffic from the private IP addresses from the network interfaces for the EC2 instances associated with the referenced security group. + For outbound rules, the EC2 instances associated with a security group can send outbound traffic to the private IP addresses from the network interfaces for the EC2 instances associated with the referenced security group. + We do not authorize against referenced security groups in the following actions: `AuthorizeSecurityGroupIngress`, `AuthorizeSecurityGroupEgress`, `RevokeSecurityGroupIngress`, and `RevokeSecurityGroupEgress`. We only check whether the security group exists. This results in the following: + Specifying the referenced security group in IAM policies for these actions has no effect. + When a referenced security group is owned by another account, the owner account does not receive CloudTrail events for these actions. **Limitation** If you configure routes to forward the traffic between two instances in different subnets through a middlebox appliance, you must ensure that the security groups for both instances allow traffic to flow between the instances. The security group for each instance must reference the private IP address of the other instance or the CIDR range of the subnet that contains the other instance as the source. If you reference the security group of the other instance as the source, this does not allow traffic to flow between the instances. **Example** The following diagram shows a VPC with subnets in two Availability Zones, an internet gateway, and an Application Load Balancer. Each Availability Zone has a public subnet for web servers and a private subnet for database servers. There are separate security groups for the load balancer, the web servers, and the database servers. Create the following security group rules to allow traffic. + Add rules to the load balancer security group to allow HTTP and HTTPS traffic from the internet. The source is 0.0.0.0/0. + Add rules to the security group for the web servers to allow HTTP and HTTPS traffic only from the load balancer. The source is the security group for the load balancer. + Add rules to the security group for the database servers to allow database requests from the web servers. The source is the security group for the web servers. ![\[Architecture with web and db servers, security groups, internet gateway, and load balancer\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/security-group-referencing.png) ## Security group size The type of source or destination determines how each rule counts toward the maximum number of rules that you can have per security group. + A rule that references a CIDR block counts as one rule. + A rule that references another security group counts as one rule, no matter the size of the referenced security group. + A rule that references a customer-managed prefix list counts as the maximum size of the prefix list. For example, if the maximum size of your prefix list is 20, a rule that references this prefix list counts as 20 rules. + A rule that references an AWS-managed prefix list counts as the weight of the prefix list. For example, if the weight of the prefix list is 10, a rule that references this prefix list counts as 10 rules. For more information, see [Available AWS-managed prefix lists](working-with-aws-managed-prefix-lists.md#available-aws-managed-prefix-lists). ## Stale security group rules If your VPC has a VPC peering connection with another VPC, or if it uses a VPC shared by another account, a security group rule in your VPC can reference a security group in that peer VPC or shared VPC. This allows resources that are associated with the referenced security group and those that are associated with the referencing security group to communicate with each other. For more information, see [Update your security groups to reference peer security groups](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) in the *Amazon VPC Peering Guide*. If you have a security group rule that references a security group in a peer VPC or shared VPC and the security group in the shared VPC is deleted or the VPC peering connection is deleted, the security group rule is marked as stale. You can delete stale security group rules as you would any other security group rule. # Default security groups for your VPCs Your default VPCs and any VPCs that you create come with a default security group. The name of the default security group is "default". We recommend that you create security groups for specific resources or groups of resources instead of using the default security group. However, if you don't associate a security group with some resources at creation time, we associate them with the default security group. For example, if you don't specify a security group when you launch an EC2 instance, we associate the instance with the default security group for its VPC. ## Default security group basics + You can change the rules for a default security group. + You can't delete a default security group. If you try to delete a default security group, we return the following error code: `Client.CannotDelete`. ## Default rules The following table describes the default inbound rules for a default security group. | Source | Protocol | Port range | Description | | --- | --- | --- | --- | | sg-1234567890abcdef0 | All | All | Allows inbound traffic from all resources that are assigned to this security group. The source is the ID of this security group. | The following table describes the default outbound rules for a default security group. | Destination | Protocol | Port range | Description | | --- | --- | --- | --- | | 0.0.0.0/0 | All | All | Allows all outbound IPv4 traffic. | | ::/0 | All | All | Allows all outbound IPv6 traffic. This rule is added only if your VPC has an associated IPv6 CIDR block. | ## Example The following diagram shows a VPC with a default security group, an internet gateway, and a NAT gateway. The default security contains only its default rules, and it is associated with two EC2 instances running in the VPC. In this scenario, each instance can receive inbound traffic from the other instance on all ports and protocols. The default rules do not allow the instances to receive traffic from the internet gateway or the NAT gateway. If your instances must receive additional traffic, we recommend that you create a security group with the required rules and associate the new security group with the instances instead of the default security group. ![\[VPC with 2 subnets, default security group, 2 EC2 instances, internet gateway, and NAT gateway\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/default-security-group.png) # Create a security group for your VPC Your virtual private cloud (VPC) comes with a default security group. You can create additional security groups. Security groups can be used only with resources in the VPC for which it is created. By default, new security groups start with only an outbound rule that allows all traffic to leave the resource. You must add rules to enable any inbound traffic or to restrict the outbound traffic. You can add rules when you create a security group or later on. For more information, see [Security group rules](security-group-rules.md). **Required permissions** Before you begin, ensure that you have the required permissions. For more information, see the following: + [Manage security groups](vpc-policy-examples.md#vpc-security-groups-iam) + [Manage security group rules](vpc-policy-examples.md#vpc-security-group-rules-iam) **To create a security group using the console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security groups**. 1. Choose **Create security group**. 1. Enter a name and description for the security group. You can't change the name and description of a security group after it is created. 1. For **VPC**, choose the VPC in which you'll create the resources to which you'll associate the security group. 1. (Optional) To add inbound rules, choose **Inbound rules**. For each rule, choose **Add rule** and specify the protocol, port, and source. For more information, see [Configure security group rules](working-with-security-group-rules.md). 1. (Optional) To add outbound rules, choose **Outbound rules**. For each rule, choose **Add rule** and specify the protocol, port, and destination. 1. (Optional) To add a tag, choose **Add new tag** and enter the tag key and value. 1. Choose **Create security group**. **To create a security group using the AWS CLI** Use the [create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html) command. Alternately, you can create a new security group by copying an existing one. When you copy a security group, we automatically add the same inbound and outbound rules as the original security group and use the same VPC as the original security group. You can enter a name and description for the new security group. You can optionally choose a different VPC, and you can modify the inbound and outbound rules as needed. However, you can't copy a security group from one Region to another Region. **To create a security group based on an existing one** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security groups**. 1. Select a security group. 1. Choose **Actions**, **Copy to new security group**. 1. Enter a name and description for the security group. 1. (Optional) Choose a different VPC if needed. 1. (Optional) Add, remove, or edit the security group rules as needed. 1. Choose **Create security group**. # Configure security group rules After you create a security group, you can add, update, and delete its security group rules. When you add, update, or delete a rule, the change is automatically applied to the resources that are associated with the security group. **Required permissions** Before you begin, ensure that you have the required permissions. For more information, see [Manage security group rules](vpc-policy-examples.md#vpc-security-group-rules-iam). **Protocols and ports** + With the console, when you select a predefined type, **Protocol** and **Port range** are specified for you. To enter a port range, you must select one of the following custom types: **Custom TCP** or **Custom UDP**. + With the AWS CLI, you can add a single rule with a single port using the `--protocol` and `--port` options. To add multiple rules, or a rule with a port range, use the `--ip-permissions` option instead. **Sources and destinations** + With the console, you can specify the following as sources for inbound rules or destinations for outbound rules: + **Custom** – An IPv4 CIDR block, an IPv6 CIDR block, a security group, or a prefix list. + **Anywhere-IPv4** – The 0.0.0.0/0 IPv4 CIDR block. + **Anywhere-IPv6** – The ::/0 IPv6 CIDR block. + **My IP** – The public IPv4 address of your local computer. + With the AWS CLI, you can specify an IPv4 CIDR block using the `--cidr` option or a security group using the `--source-group` option. To specify a prefix list or an IPv6 CIDR block, use the `--ip-permissions` option. **Warning** If you choose **Anywhere-IPv4**, you allow traffic from all IPv4 addresses. If you choose **Anywhere-IPv6**, you allow traffic from all IPv6 addresses. It is a best practice to authorize only the specific IP address ranges that need access to your resources. **To configure security group rules using the console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security groups**. 1. Select the security group. 1. To edit the inbound rules, choose **Edit inbound rules** from **Actions** or the **Inbound rules** tab. 1. To add a rule, choose **Add rule** and enter the type, protocol, port, and source for the rule. If the type is TCP or UDP, you must enter the port range to allow. For custom ICMP, you must choose the ICMP type name from **Protocol**, and, if applicable, the code name from **Port range**. For any other type, the protocol and port range are configured for you. 1. To update a rule, change its protocol, description, and source as needed. However, you can't change the source type. For example, if the source is an IPv4 CIDR block, you can't specify an IPv6 CIDR block, a prefix list, or a security group. 1. To delete a rule, choose its **Delete** button. 1. To edit the outbound rules, choose **Edit outbound rules** from **Actions** or the **Outbound rules** tab. 1. To add a rule, choose **Add rule** and enter the type, protocol, port, and destination for the rule. You can also enter an optional description. If the type is TCP or UDP, you must enter the port range to allow. For custom ICMP, you must choose the ICMP type name from **Protocol**, and, if applicable, the code name from **Port range**. For any other type, the protocol and port range are configured for you. 1. To update a rule, change its protocol, description, and source as needed. However, you can't change the source type. For example, if the source is an IPv4 CIDR block, you can't specify an IPv6 CIDR block, a prefix list, or a security group. 1. To delete a rule, choose its **Delete** button. 1. Choose **Save rules**. **To configure security group rules using the AWS CLI** + **Add** – Use the [authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) and [authorize-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-egress.html) commands. + **Remove** – Use the [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) and [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) commands. + **Modify** – Use the [modify-security-group-rules](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-security-group-rules.html), [update-security-group-rule-descriptions-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-ingress.html), and [update-security-group-rule-descriptions-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-egress.html)commands. # Delete a security group When you are finished with a security group that you created, you can delete it. **Requirements** + The security group can't be associated with any resources. + The security group can't be referenced by a rule in another security group. + The security group can't be the default security group for a VPC. **To delete a security group using the console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security groups**. 1. Select the security group and choose **Actions**, **Delete security groups**. 1. If you selected more than one security group, you are prompted for confirmation. If some of the security groups can't be deleted, we display the status of each security group, which indicates whether it will be deleted. To confirm deletion, enter **Delete**. 1. Choose **Delete**. **To delete a security group using the AWS CLI** Use the [delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) command. # Associate security groups with multiple VPCs If you have workloads running in multiple VPCs that share network security requirements, you can use the Security Group VPC Associations feature to associate a security group with multiple VPCs in the same Region. This enables you to manage and maintain security groups in one place for multiple VPCs in your account. ![\[A diagram of security group associated with two VPCs.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/sec-group-vpc-assoc.png) The diagram above shows AWS account A with two VPCs in it. Each of the VPCs has workloads running in a private subnet. In this case, workloads in VPC A and B subnets share the same network traffic requirements, so Account A can use the Security Group VPC associations feature to associate the security group in VPC A with VPC B. Any updates made to the associated security group are automatically applied to the traffic to workloads in the VPC B subnet. **Requirements of the Security Group VPC Associations feature** + You must own the VPC or have one of the VPC subnets shared with you to associate a security group with the VPC. + The VPC and security group must be in the same AWS Region. + You cannot associate a default security group with another VPC or associate a security group with a default VPC. + Both the security group owner and the VPC owner can view the security group VPC associations. **Services that support this feature** + Amazon API Gateway (REST APIs only) + AWS Auto Scaling + CloudFormation + Amazon EC2 + Amazon EFS + Amazon EKS + Amazon FSx + AWS PrivateLink + Amazon Route 53 + Elastic Load Balancing + Application Load Balancer + Network Load Balancer ## Associate a security group with another VPC This section explains how to use the AWS Management Console and the AWS CLI to associate a security group with VPCs. ------ #### [ AWS Management Console ] **To associate a security group with another VPC** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. On the left navigation pane, choose **Security groups**. 1. Choose a security group to view the details. 1. Choose the **VPC associations** tab. 1. Choose **Associate VPC**. 1. Under **VPC ID**, choose a VPC to associate with the security group. 1. Choose **Associate VPC**. ------ #### [ Command line ] **To associate a security group with another VPC** 1. Create a VPC association with [associate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/associate-security-group-vpc.html). 1. Check the status of a VPC association with [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html) and wait for the status to be `associated`. ------ The VPC is now associated with the security group. Once you’ve associated the VPC with the security group, you can, for example, [launch an instance into the VPC and choose this new security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) or [reference this security group in an existing security group rule](security-group-rules.md#security-group-referencing). ## Disassociate a security group from another VPC This section explains how to use the AWS Management Console and the AWS CLI to disassociate a security group from VPCs. You may want to do this if your goal is to delete the security group. Security groups cannot be deleted if they are associated. You can only diassociate a security group if there are no network interfaces in the associated VPC using that security group. ------ #### [ AWS Management Console ] **To disassociate a security group from a VPC** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. On the left navigation pane, choose **Security groups**. 1. Choose a security group to view the details. 1. Choose the **VPC associations** tab. 1. Choose **Disassociate VPC**. 1. Under **VPC ID**, choose a VPC to disassociate from the security group. 1. Choose **Disassociate VPC**. 1. View the **Status** of the disassociation in the VPC associations tab and wait for the status to be `disassociated`. ------ #### [ Command line ] **To disassociate a security group from a VPC** 1. Disassociate a VPC association with [disassociate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disassociate-security-group-vpc.html). 1. Check the status of a VPC disassociation with [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html) and wait for the status to be `disassociated`. ------ The VPC is now disassociated with the security group. # Share security groups with AWS Organizations The Shared Security Group feature enables you to share a security group with other AWS Organizations accounts within the same AWS Region and make the security group available to be used by those accounts. The following diagram demonstrates how you can use the Shared Security Group feature to simplify security group management across accounts in your AWS Organizations: ![\[A diagram of security group sharing with other accounts in a shared VPC subnet.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/sec-group-sharing.png) This diagram shows three accounts that are part of the same Organization. Account A shares a VPC subnet with Accounts B and C. Account A shares the security group with Accounts B and C using the Shared Security Group feature. Accounts B and C then use that security group when they launch instances in the shared subnet. This enables Account A to manage the security group; any updates to the security group apply to the resources that Accounts B and C have running in the shared VPC subnet. **Requirements of the Shared Security Group feature** + This feature is only available for accounts in the same Organization in AWS Organizations. [Resource sharing](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html) must be enabled in AWS Organizations. + The account that shares the security group must own both the VPC and the security group. + You cannot share default security groups. + You cannot share security groups that are in a default VPC. + Participant accounts can create security groups in a shared VPC but they cannot share those security groups. + A minimum set of permissions is required for an IAM principal to share a security group with AWS RAM. Use the `AmazonEC2FullAccess` and `AWSResourceAccessManagerFullAccess` managed IAM policies to ensure your IAM principals have the required permissions to share and use shared security groups. If you use a custom IAM policy, the `c2:PutResourcePolicy` and `ec2:DeleteResourcePolicy` actions are required. These are permission-only IAM actions. If an IAM principal doesn’t have these permissions granted, an error will occur when attempting to share the security group using the AWS RAM. **Services that support this feature** + Amazon API Gateway + Amazon EC2 + Amazon ECS + Amazon EFS + Amazon EKS + Amazon EMR + Amazon FSx + Amazon ElastiCache + AWS Elastic Beanstalk + AWS Glue + Amazon MQ + Amazon SageMaker AI + Elastic Load Balancing + Application Load Balancer + Network Load Balancer **How this feature affects existing quotas** [Security group quotas](amazon-vpc-limits.md#vpc-limits-security-groups) apply. For the 'Security groups per network interface' quota, however, if a participant uses both owned and shared groups on an Elastic network interface (ENI), the minimum of owner and participant's quota applies. Example to demonstrate how the quota is affected by this feature: + Owner account quota: 4 security groups per interface + Participant account quota: 5 security groups per interface. + Owner shares groups SG-O1, SG-O2, SG-O3, SG-O4, SG-O5 with participant. Participant already has groups of their own in the VPC: SG-P1, SG-P2, SG-P3, SG-P4, SG-P5. + If participant creates an ENI and uses only their owned groups, they can associate all 5 security groups (SG-P1, SG-P2, SG-P3, SG-P4, SG-P5) because that's their quota. + If the participant creates an ENI and uses any shared groups on it, they can only associate up to 4 groups. In this case, the quota for such an ENI is the minimum of owner and participant's quotas. Possible valid configurations will look like this: + SG-O1, SG-P1, SG-P2, SG-P3 + SG-O1, SG-O2, SG-O3, SG-O4 ## Share a security group This section explains how to use the AWS Management Console and the AWS CLI to share a security group with other accounts in your Organization. ------ #### [ AWS Management Console ] **To share a security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. On the left navigation pane, choose **Security groups**. 1. Choose a security group to view the details. 1. Choose the **Sharing** tab. 1. Choose **Share security group**. 1. Choose **Create resource share**. As a result, the AWS RAM console opens where you’ll create the resource share for the security group. 1. Enter a **Name** for the resource share. 1. Under **Resources - optional**, choose **Security Groups**. 1. Choose a security group. The security group cannot be a default security group and cannot be associated with the default VPC. 1. Choose **Next**. 1. Review the actions that principals will be allowed to perform and choose **Next**. 1. Under **Principals - optional**, choose **Allow sharing only within your organization**. 1. Under **Principals**, select one of the following principal types and enter the appropriate numbers: + **AWS account**: The account number of an account in your Organization. + **Organization**: The AWS Organizations ID. + **Organizational unit (OU)**: The ID of an OU in the Organization. + **IAM role**: The ARN of an IAM role. The account that created the role must be a member of the same Organization as the account creating this resource share. + **IAM user**: The ARN of an IAM user. The account that created the user must be a member of the same Organization as the account creating this resource share. + **Service principal**: You cannot share a security group with a service principal. 1. Choose **Add**. 1. Choose **Next**. 1. Choose **Create resource share**. 1. Under **Shared resources**, wait to see the **Status** of `Associated`. If there is a security group association failure, it may be due to one of the limitations listed above. View the details of the security group and the **Sharing** tab on the details page to see any messages related to why a security group may not be shareable. 1. Return to the VPC console security group list. 1. Choose the security group you shared. 1. Choose the **Sharing** tab. Your AWS RAM resource should be visible there. If it’s not, the resource share creation may have failed and you may need to recreate it. ------ #### [ Command line ] **To share a security group** 1. You must first create a resource share for the security group that you want to share with AWS RAM. For steps on how to create a resource share with AWS RAM using the AWS CLI, see [Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) in the *AWS RAM User Guide* 1. To view created resource share associations, use [get-resource-share-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/get-resource-share-associations.html). ------ The security group is now shared. You can select the security group when [launching an EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) in a shared subnet within the same VPC. ## Stop sharing a security group This section explains how to use the AWS Management Console and the AWS CLI to stop sharing a security group with other accounts in your Organization. ------ #### [ AWS Management Console ] **To stop sharing a security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. On the left navigation pane, choose **Security groups**. 1. Choose a security group to view the details. 1. Choose the **Sharing** tab. 1. Choose a security group resource share and choose **Stop sharing**. 1. Choose **Yes, stop sharing**. ------ #### [ Command line ] **To stop sharing a security group** Delete the resource share with [delete-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-resource-share.html). ------ The security group is no longer being shared. After the owner stops sharing a security group, the following rules apply: + Existing participant Elastic Network Interfaces (ENIs) continue to get any security group rule updates that are made to unshared security groups. Unsharing only prevents the participant from creating new associations with the unshared group. + Participants can no longer associate the unshared security group with any ENIs they own. + Participants can describe and delete the ENIs that are still associated with unshared security groups. + If participants still have ENIs associated with the unshared security group, the owner cannot delete the unshared security group. The owner can only delete the security group after participants disassociate (remove) the security group from all their ENIs. + Participants cannot launch new EC2 instances using an ENI associated with an unshared security group.