Introducing security group referencing for AWS Transit Gateway

Today, we are introducing support for security group referencing on AWS Transit Gateway. This new feature allows you to create inbound security rules that reference security groups defined in other Amazon Virtual Private Clouds (Amazon VPCs) attached to a transit gateway within the same Amazon Web Services (AWS) Region. Outbound security rules referencing over Transit Gateway aren’t supported at this time.

Transit Gateway is a network transit hub that helps you build hub and spoke networks, connecting multiple Amazon VPC and on-premises networks, without needing you to provision third-party virtual appliances so you can streamline, control and improve the security of your architecture. Transit Gateway is a fully managed service that is highly available, scalable, seamless to set up, and can support thousands of VPC attachments per Transit Gateway in a Region. Refer to the quota documentation for details.

The new security referencing feature for Transit Gateway streamlines security group management. To do this, you create rules using security group referencing instead of IPv6 or IPv4 addresses or CIDRs. This enables easier migration from VPC peering to Transit Gateway, particularly if you are relying heavily on security group referencing. The feature also supports higher-scale networking across thousands of VPCs while providing an improved security posture through a streamlined security group management.

The following sections show how to enable and disable security group referencing across Transit Gateway, and then show how it’s used in some common scenarios.

Getting started: How to use security group referencing through Transit Gateway

You can enable or disable the security group referencing support option when creating a new or editing an existing transit gateway or Transit Gateway VPC attachment using the AWS Management Console, AWS SDK, or AWS API.

It’s important to understand the difference between the security group referencing support setting at the Transit Gateway level as opposed to the Transit Gateway VPC attachment level. Doing this allows you to select the set of access controls to meet the security needs of your network architecture.

To use this feature, security group referencing support must be enabled on both the transit gateway and the Transit Gateway VPC attachment.

In this figure, we show three VPCs connected through a transit gateway

Figure 1. Three VPCs connected through a transit gateway

Consider the architecture illustrated in Figure 1:

1. If security group referencing is enabled on the transit gateway and the three attachments (VPC 1, VPC 2, and VPC 3), then security group referencing becomes possible across the three VPCs through the transit gateway.
2. If security group referencing is enabled on the transit gateway and only on the attachments for VPC 1 and VPC 2 (but not VPC 3), then security group referencing through the transit gateway is possible between VPC 1 and VPC 2, but not with VPC 3.
3. If security group referencing is disabled on the transit gateway, then you can’t use security group referencing across this transit gateway, regardless of whether the option is enabled on the individual Transit Gateway VPC attachments.

1. Security group referencing support at the Transit Gateway level

The Security Group Referencing Support feature is disabled by default at the Transit Gateway level, including those transit gateways created before the feature’s introduction.

To enable this feature at the Transit Gateway level, check the Security Group Referencing Support option in the Console (Figure 2). As of this writing, this feature isn’t supported when extending your VPC to selected AWS Local Zones or AWS Outposts through a transit gateway.

For further information, you can refer to the security group referencing documentation.

In this figure, we show the Security Group Referencing Support option at the Transit Gateway level within the Console

Figure 2. Security Group Referencing Support option at the Transit Gateway level within the Console

To disable the feature, uncheck the Security Group Referencing Support option.

When disabled, Security Group Referencing doesn’t function for the entire transit gateway. Consequently, instance-to-instance traffic that relies solely on referenced security groups is dropped, unless it matches another rule using IPv4 or IPv6 address/CIDR that isn’t dependent on Transit Gateway security group referencing.

You can also enable and disable this feature with the SecurityGroupReferencingSupport option using APIs/CLI. The following are a few examples:

Enabling on a new transit gateway, called MyTransitGateway:

aws ec2 create-transit-gateway --description MyTransitGateway --options SecurityGroupReferencingSupport=enable

Enabling on an existing transit gateway, with Transit Gateway ID tgw-1234abcd:

aws ec2 modify-transit-gateway --transit-gateway-id tgw-1234abcd --options SecurityGroupReferencingSupport=enable

Disabling on an existing transit gateway, with Transit Gateway ID tgw-1234abcd:

aws ec2 modify-transit-gateway --transit-gateway-id tgw-1234abcd --options SecurityGroupReferencingSupport=disable

Modifying the Transit Gateway-level setting doesn’t affect the configuration of individual Transit Gateway attachments. Each attachment maintains separate settings for this feature.

2. Security group referencing support at the Transit Gateway VPC attachment Level

By default, the Security Group Referencing Support feature is enabled on the Transit Gateway VPC attachments, such as those created prior to the feature’s introduction.

To control this option through the Console, locate the Security Group Referencing Support option (Figure 3). Check this box to enable the feature or uncheck to disable.

In this figure, we show the Security Group Referencing Support option at the Transit Gateway VPC attachment level within the Console

Figure 3. Security Group Referencing Support option at the Transit Gateway VPC attachment level within the Console

Modifying the Security Group Referencing Support setting at the VPC attachment level operates independently from the Transit Gateway level setting. However, for the feature to function properly, it must be enabled at both the transit gateway and the individual VPC attachment levels.

This dual configuration approach provides granular control allowing admins to disable or opt out of security group referencing feature for specific VPC attachments while having it enabled at the Transit Gateway level.

This option can also be enabled/disabled through the API/CLI. The following example creates a new Transit Gateway VPC attachment with the security group referencing enabled:

aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0262a0e521EXAMPLE 
--vpc-id vpc-07e8ffd50f49335df 
--subnet-id subnet-0752213d59EXAMPLE 
--options SecurityGroupReferencingSupport=enable

If you didn’t define the SecurityGroupReferencingSupport in the API/CLI call, then the default setting is enabled.

The following example disables the feature for the Transit Gateway VPC attachment ID tgw-attach-09fbd47ddf, even if the Transit Gateway level setting is different:

aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-09fbd47ddf
--options SecurityGroupReferencingSupport=disable

If you disable security group referencing at the VPC attachment level, then you can’t configure new inbound security group references. Instance-to-instance traffic previously allowed by cross-referenced rules is dropped if you relied only on this feature.

When deleting a VPC attachment with referencing enabled, security group referencing goes stale. We recommend using describe-security-group-references and describe-stale-security-groups API/CLI calls prior to this operation.

Finally, when you delete a security group that is cross-referenced by another security group, your rules using security group referencing go stale.

Use cases for security group referencing

The following common examples demonstrate where security group referencing can help you exercise tight access control to resources that span multiple VPCs attached to a transit gateway within the Region.

1.Resource sharing between different application tiers deployed across different VPCs connected by a transit gateway

The following architecture (Figure 4) consists of web, application, and database tiers spanning three VPCs: VPC 1, VPC 2 and VPC 3. A transit gateway connects the VPCs, thus enabling interconnectivity. The goal is to allow the web tier instances in VPC 1 to access the app tier instances in VPC 2. The app tier instances in VPC 2 need access to the database tier instances in VPC 3.

Security groups are independent of the VPC IP address family (IPv4 or IPv6), thus they can allow instance-to-instance traffic across dual stack (IPv4 or IPv6) VPCs or IPv6-only subnets. Therefore, the web, application, and database instances can use IPv4 addresses, IPv6 addresses, or a combination of both.

In this figure, we show a web, application, and database tiers communicating through a transit gateway

Figure 4. Web, application, and database tiers communicating through a transit gateway

To allow the web tier instances access to the app tier instances on port 443 (HTTPS), we can reference the web tier security group defined in VPC 1 in the inbound rule of the application tier security group in VPC 2:

aws ec2 authorize-security-group-ingress —group-name SG-App-Tier —protocol tcp —port 443 —source-group SG-Web-Tier —groupowner vpc1-web-tier-owner

Similarly, to allow the app tier instances access to the database tier instances on port 3306, we can reference the app tier security group defined in VPC 2 in the inbound rule of the database tier security group in VPC 3:

aws ec2 authorize-security-group-ingress —group-name SG-DB-Tier —protocol tcp —port 3306 —source-group SG-App-Tier —groupowner vpc2-app-tier-owner

2.Enhancing and streamlining secure access to a centralized shared services VPC

Sometimes you want to strengthen security access to a shared services VPC for only specific applications without a firewall or worrying about security group management complexity.

In the following architecture (Figure 5), there are multiple application tier instances in VPC 1 that need access to the AWS Directory Service in the shared services VPC. The two VPCs are connected through a transit gateway.

To allow the application tier instances in VPC 1 to access the directory, you can add the security group for the application tier in VPC 1 as an inbound rule in the security group for the Directory Service tier in the shared services VPC. This allows the instances in VPC 1 to communicate with the directory through security group referencing.

In this figure, we show an application tier instances connected to Directory Service through a transit gateway

Figure 5. Application tier instances connected to Directory Service through a transit gateway

If you have an inspection VPC, then security group referencing through the transit gateway does not work across AWS Gateway Load Balancer or an AWS Network Firewall.

3.Resource sharing in a shared VPC model

In a shared VPC model (not to be confused with shared services VPC as discussed in the previous use case), applications can span multiple shared VPCs connected through a transit gateway. To strengthen security while streamlining security access controls, security group referencing through the transit gateway can be used.

In the following example (Figure 6), you have an application instance in the private subnet of AWS Account 1 within Shared VPC 1 that needs access to another application in the private subnet of AWS Account 5 in Shared VPC 2. Cross-referencing security groups from a VPC in a different AWS account through Transit Gateway is now possible, thus you can reference the application tier instances security group defined in AWS Account 1 within Shared VPC 1 in the inbound rule of the application tier security group in AWS Account 5 in Shared VPC 2.

In this figure, we show through a shared VPC model, an application tiers instances in one shared VPC connected through a transit gateway to another application tier in another shared VPC

Figure 6. Application tiers instances connected through a transit gateway

Considerations

1. As of this writing security group referencing isn’t supported with Outposts and some types of Local Zones. You must keep security group referencing flag disabled for VPCs extended in some types of Local Zones and Outposts to avoid service interruptions. Refer to the documentation for more information.
2. As of this writing, you can’t reference security groups in a different AWS Region. To connect two VPCs, both VPCs must be attached to the same transit gateway and reside in the same Region.
3. Security group referencing doesn’t work across third-party middle-box or bump-in-the-wire (BITM) appliances. Instance-to-instance traffic across a third-party middle-box or BITM appliance can’t be allowed using security group references.
4. As of this writing security group referencing isn’t supported by multicast on Transit Gateway.
5. As of this writing security group referencing isn’t supported for outbound security groups.

More considerations are mentioned in the Reference security groups across a transit gateway entry in our documentation.

The behavior of the transit gateway is summarized in the following table:

Conclusion

With the introduction of security group referencing across Transit Gateway, you now have a direct and convenient method to strengthen security access controls on resources across Transit Gateway. This new feature provides a direct migration path from VPC peering to Transit Gateway, particularly if you have deployed many security group references in production.

In this post, we showed how to enable and disable security group referencing across Transit Gateway, and the benefits of this feature in some use cases.

This feature is now available in the AWS commercial Regions, AWS GovCloud (US) Regions, and AWS China Regions.

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

Author bios