Simplify Amazon VPC security groups management with VPC associations and security groups sharing

In this post we explain how you can use Amazon Virtual Private Cloud (Amazon VPC) security group associations and security group sharing to configure consistent security rules across your workloads in multiple VPCs and accounts on AWS. We outline the steps to configure the two new security group features, their use cases, and best practices for managing security groups in your AWS Organization.

AWS now supports two new capabilities for existing and new security groups: security group VPC associations and shared security groups. With security group VPC associations, you can create a security group and use it across multiple VPCs in the same account and AWS Region. Furthermore, you can create security groups in a VPC with shared subnets and use AWS Resource Access Manager (AWS RAM) to share them with participant accounts. Participants can then use the shared security groups across workloads deployed in the VPC.

These features allow users to ensure security group consistency, and simplify the configuration and maintenance workflows for administrators and application owners. By enabling the reuse of security groups across VPCs and accounts, you can efficiently manage your security policies and reduce the overhead associated with maintaining separate security group configurations.

Prerequisites

We assume you are familiar with fundamental networking constructs on AWS, such as Amazon VPC, VPC sharing, security group referencing, and subnets. We also assume you are familiar with AWS compute services such as Amazon Elastic Compute Cloud (Amazon EC2) and EC2 Auto Scaling groups. We don’t focus on defining these services, but we do use them to show use cases for the new security groups features. Before discussing the configuration and best practices for using the new security group features, let’s review Amazon VPC security groups and how you can use them to secure your workloads on AWS.

Amazon VPC security groups

An Amazon VPC security group is a virtual firewall that controls inbound and outbound traffic to and from resources it is associated with. When you create an Amazon VPC, a default security group is also created and associated with your VPC. You can create more security groups in a VPC, each with their inbound and outbound rules. Inbound security group rules contain the source, port range, and protocol from which you want to allow traffic, while outbound rules contain the destination, port range, and protocol you want to allow traffic to. For example, you can configure the rules on a database security group to allow inbound access from web servers on Transmission Control Protocol (TCP) port 3306 (MySQL). You can find security groups considerations in the documentation.

By default, you can associate a security group only with resources in the VPC and account where you create it. However, the two new security groups features enhance the flexibility to use your existing and new security groups in multi-VPC and multi-account scenarios. Let’s explore use cases, configuration steps, and considerations for the two new features.

Security group VPC associations

By default, when you create security groups in a VPC, you can associate them only with resources in that VPC. To accommodate for different network connectivity requirements, you can deploy workloads across multiple VPCs in an AWS account. Regardless of VPC boundaries, workloads often require a common set of security group rules to allow only authorized access to and from other resources in your environment. With security group VPC associations, you can define purpose-specific security groups containing a set of rules that meets your enterprise-wide security policy. You can use the associated security groups across multiple VPCs in your AWS account, in the AWS Region. This helps you maintain security rules consistency across multiple workloads, and allow only authorized resource access.

Using security group VPC associations

The following considerations apply to using security groups VPC associations:

• You can associate security groups that you create only with VPCs in your AWS account and AWS Region.
• To delete a security group with VPC associations, you must first delete the associations. However, you can delete VPCs with associated security groups.
• You can apply security groups associated with a VPC on the services described in the documentation.

Setup example

For this post, we consider an example deployment (as shown in Figure 1) using three web services deployed across three VPCs in an AWS account and AWS Region. The application endpoints are fronted by Application Load Balancers (ALBs) to allow for workload elasticity, scalability, and resilience. We use security group VPC associations to ensure that the following security groups are consistently applied on all services, as follows:

• For ALBs, we configure a security group named ALB-SG with the following security rules:
  • inbound access from the internet allowed only on TCP port 443
  • inbound access on port 80 allowed only from an enterprise internal set of Internet Protocol (IP) addresses defined in a user-managed prefix list, named enterprise-prefix-list
• For web application servers, we configure a security group named WEB-APP-SG with the following security rules:
  • inbound traffic allowed only from the ALBs, on TCP port 80. For this we use security group referencing between the WEB-APP-SG and the ALB-SG security groups

The following diagram shows the overall example setup.

Figure 1: Security group VPC association setup

Let’s review the current configuration of the ALB-SG and WEB-APP-SG security groups. Figure 2 shows the ALB-SG inbound rules, allowing traffic from any IPv4 or IPv6 source on TCP port 443, and from the enterprise prefix list on TCP port 80:

Figure 2: ALB-SG inbound rules

Figure 3 shows the ALB-SG outbound rules, using security group referencing to allow HTTP traffic only to the WEB-APP-SG:

Figure 3: ALB-SG outbound rules

Figure 4 shows the WEB-APP-SG inbound rules, allowing inbound HTTP traffic only from the ALB-SG:

Figure 4: WEB-APP-SG inbound rules

The two security groups, ALB-SG and WEB-APP-SG, are associated with Web App 1 ALB and Web App 1 EC2 Auto scaling group respectively, in VPC A. To maintain consistent security group rules across the ALB and web applications, we use security group VPC associations. The following section outlines the configuration steps to achieve this.

Configuration steps

To use the two security groups with Web App 2 and Web App 3 ALBs, and target groups respectively, we associate the security groups with VPC B and VPC C in the account.

Step 1: First, we associate the ALB-SG with VPC B. To associate a security group with a VPC, choose the security group (VPC Console > Security Groups > ALB-SG), and go to the VPC associations tab, as shown in Figure 5:

Figure 5: Security group VPC associations tab

Step 2: Choose Associate VPC, choose the VPC ID (VPC B in this example) with which we want to associate the security group, and confirm the selection, as shown in Figure 6:

Figure 6: Select VPC ID for security group association and confirm selection

Step 3: We follow the same steps for VPC C, so that ALB-SG is now associated with both VPCs, as shown in Figure 7:

Figure 7: ALB-SG associated with VPCs B and VPC C

Step 4: Similarly, we associate the second security group, WEB-APP-SG, with both VPC B and VPC C, as shown in Figure 8:

Figure 8: WEB-APP-SG associated with VPC B and VPC C

Step 5: Once the two security groups are associated with VPC B and VPC C, we proceed to associate ALB-SG with Web App 2 and Web App 3 ALBs, and the WEB-APP-SG with the web application 2 and web application 3 servers, as shown in Figure 9:

Figure 9: WEB-APP-SG and ALB-SG associated with the three deployments across the three VPCs

Shared security groups

Customers use multiple AWS Accounts to scale their environments and ensure security, quotas, and billing separation for each team or application. VPC subnet sharing allows multiple AWS accounts to create their application resources, such as EC2 instances and Elastic Load Balancers (ELB) into centrally-managed VPCs. In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same AWS Organization.

VPC security groups are account-specific by default. With VPC subnet sharing, participant accounts create their security groups and associate them with resources in the shared subnets. Security group sharing allows multiple AWS accounts to use centrally managed, shared security groups on resources launched in a shared VPC. With shared security groups, the VPC owner account can create and share one or more security groups with shared VPC participant accounts. This helps you simplify security group management, and apply consistent security policies across multiple accounts sharing a VPC within an Organization.

Using shared security groups

The following considerations apply to using shared VPC security groups:

• To share security groups with accounts in your AWS Organization, resource sharing must be enabled from the management account for your Organization. This setting grants the necessary permissions for accounts within the Organization to share and use shared resources, such as security groups.
• You can share security groups only with accounts that belong to the same AWS Organization.
• A shared security group can be applied only on resources deployed by participants in the shared subnets of VPCs owned by the same account as the security group.
• You must create a resource share using AWS RAM for the security group you want to share with participant accounts in the VPC.
• A participant account cannot add/delete/modify a shared security group or its rules. However, participant accounts can perform describe actions on shared security groups, and use the shared security groups.
• You can use shared security groups with the services described in the documentation.

Setup example

We consider an example deployment for the previous three web services, this time deployed across three participant accounts in a shared VPC, as shown in the following diagram (Figure 10):

Figure 10: Shared VPC security groups architecture

We create two security groups, ALB-SG and WEB-APP-SG, in the shared VPC. Our intent is to associate the two security groups with the ALBs and web application servers deployed by the participant accounts 1, 2, and 3, in the shared subnets. The security group rules are the same as shown in the previous example (Figures 2, 3, and 4). To achieve the desired functionality, we share the ALB-SG and the WEB-APP-SG security groups with the three participant accounts (1, 2, and 3) in the shared VPC. In the next section we review the configuration steps for shared security groups.

Configuration steps

Step 1: To share a security group with participant accounts in a shared VPC, we create an AWS RAM resource share for the two security groups. We navigate to the VPC Console > Security Groups section, choose the ALB-SG, and open the Sharing tab (Figure 11):

Figure 11: Security Group Sharing tab

Step 2: We select Share security group, and the AWS RAM Console is automatically opened. We choose Resource shares, and configure a new resource share named SG_Resource_Share (Figure 12), selecting the two security groups ALB-SG and WEB-APP-SG:

Figure 12: RAM resource share SG_Resource_Share for ALB-SG and WEB-APP-SG

Step 3: The RAM resource share for security groups has a set of managed permissions named AWSRAMDefaultPermissionsSecurityGroup (Figure 13). You can also use custom permissions with shared security groups. We click Next.

Figure 13: RAM resource share managed permissions for shared security groups

Step 4: We share the two security groups with the participant accounts in the shared VPC, and part of the same Organization. We add them to the resource share as Selected principals (Figure 14) and click Next:

Figure 14: Add principals to the RAM resource share

Step 5: We review the configuration and choose Create Resource Share. Figure 15 shows the AWS RAM resource share that we created for the two security groups:

Figure 15: AWS RAM resource share for the WEB-APP-SG and ALB-SG security groups

Step 6: You can check the security group sharing status in the VPC console by selecting each security group you shared using AWS RAM (Figure 16):

Figure 16: WEB-APP-SG security group sharing status in the VPC Console

Step 7: After creating the security groups resource share, principals can associate the shared security groups with resources deployed in their accounts, in the shared VPC, as shown in Figure 17:

Figure 17: WEB-APP-SG and ALB-SG associated with the three deployments across the three VPCs

Shared security group quotas

The quotas for security groups continue to apply when you share them with participant accounts. Consider the following rules for quotas:

• When the shared security group owner modifies a shared security group, AWS enforces the ‘Inbound or Outbound Rules per Security Group’ quota of the security group owner account.
• When participant accounts use a shared security group on their resources, AWS enforces the minimum ‘Security Groups per network interface’ quota between the participant account and the security group owner account.

This prevents AWS resources from exceeding the service quotas.

Let’s review an example based on our test setup. Account A is the owner of the shared VPC, and Accounts B, C and D are participants in the shared VPC. Account A shares the security group WEB-APP-SG with Accounts B, C, and D in our example. The following quotas are configured for each account (Table 1):

Table 1: Example of security group quotas for owner and participant accounts

• In this example, any rules Account A wants to add to WEB-APP-SG must be within the ‘Inbound or Outbound Rules per Security Group’ quota Account A has, which is 250.
• When Account B uses WEB-APP-SG on their resources in the shared VPC, Account A’s ‘Security Groups per network interface’ quota is enforced (4 in this example), because it’s the lowest quota between Account A (4) and Account B (5). Therefore, when Account B uses a shared security group on an interface, it can have only four security groups on that network interface in total.
• When Account C uses a shared security group, Account A’s ‘Security Groups per network interface’ quota is enforced (4 in our example), because it’s the lowest quota between Account A (4) and Account C (5).
• When Account D uses a shared security group, Account D’s ‘Security Groups per network interface’ quota is enforced (3 in this example), because it’s the lowest quota between Account A (4) and Account D (3). This way, the effective rules per resource can’t exceed 1,000.

Considerations

When using the two new security group features, consider the following:

• Security group VPC associations and shared security groups are features that complement existing capabilities such as security group referencing within a VPC, across VPC peering inside an AWS Region, and across an AWS Transit Gateway. You can use these features together to meet the security requirements and connectivity needs of your organization.
• You cannot use security groups VPC associations and shared security groups with default security groups or default VPCs.
• You can get a list of security groups that can be associated with workloads inside a VPC, both in the AWS Console and using the AWS CLI/API.
• Modifying security groups affects the workloads using them, regardless of whether the security groups are associated with multiple VPCs in your account or shared with multiple accounts participating in a VPC.
• You can use AWS Firewall Manager security group policies to manage Amazon VPC security groups with VPC associations and shared security groups. These allow you to apply centrally controlled security group policies to your entire organization or to a select subset of your accounts and resources. You can use AWS Firewall Manager to monitor the security group policies implemented in your organization and manage their usage.

Conclusion

In this post we discussed how you can use AWS security groups VPC associations and shared security groups to configure consistent security rules across your workloads in multiple VPCs and accounts on AWS. We reviewed how to configure the two new security group features, their use cases, and best practices for managing security groups in your AWS Organization. These features allow users to ensure security group consistency, and simplify the configuration and maintenance workflows for administrators and application owners. By enabling the reuse of security groups across VPCs and accounts, you can efficiently manage your security policies and reduce the overhead associated with maintaining separate security group configurations.

To learn more about security groups, refer to the Amazon VPC documentation. If you have questions about this post, please start a new thread on AWS re:Post, or contact AWS Support.

About the authors