AWS Transit Gateway and Service-linked Role
By Ronnie Quan
Overview
By employing a “hub-and-spoke”architecture, AWS Transit Gateway centralizes connectivity between large IT deployments both on-premises and in the AWS Cloud. With additional features such as AWS Transit Gateway Inter-Region Peering and AWS Transit Gateway Network Manager, organizations can build out simplified global enterprise network architectures.
Amazon VPC uses service-linked roles for the permissions that it requires to call other AWS services on your behalf when you work with a transit gateway.
In this article, we will do a lab and learn more about transit gateway and service-linked role.
We will create service-linked role to delegate permission to transit gateway, we will create transit gateway, two VPCs, connecting VPC with AWS Transit Gateway via a transit gateway attachment.
Lab
System Diagram
I will only be able to configure and test connectivity in AWS cloud, wish to find a way to mimic site-to-site VPN and direct connect.

Service-linked Role
From AWS IAM console, create role for AWS service, select VPC, then select VPC transit gateway.
AWS managed policy AWSVPCTransitGatewayServiceRolePolicy has all the required permission to attach to the role. The role name is AWSServiceRoleForVPCTransitGateway, and it’s not editable from console.

Transit Gateway
You can optionally associate one or more IPv4 or IPv6 CIDR blocks with your transit gateway. You specify an IP address from the CIDR block when you establish a Transit Gateway Connect peer for a transit gateway Connect attachment. You can create a transit gateway Connect attachment to establish a connection between a transit gateway and third-party virtual appliances (such as SD-WAN appliances) running in a VPC.
Since we will only do VPC attachment, we won’t assign CIDR to the transit gateway.
We leave all default options. After submit the request, it shows pending state, after a minute or two, the state turns to available.


VPCs
I have attached following two subnets to transit gateway,
- A subnet from us-east-1b from default VPC
- A subnet from us-east-1a from my testvpc
Update VPC route tables which are associated to the subnet, configure a route that has a destination for non-local routes and the target of the transit gateway ID.
Below is one example route.

CloudTrail
IAM and AWS STS are integrated with AWS CloudTrail, a service that provides a record of actions taken by an IAM user or role. CloudTrail captures all API calls for IAM and AWS STS as events, including calls from the console and from API calls. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket. If you don’t configure a trail, you can still view the most recent events in the CloudTrail console in Event history.
Service-linked roles also help you meet your monitoring and auditing requirements because all actions performed on your behalf by an AWS service using a service-linked role appear in your AWS CloudTrail logs.
After create transit gateway, cloud trail event shows an event from my IAM user to create the transit gateway.

After I attached two VPCs to the transit gateway, cloudtrail logs show that AWS transit gateway calls other AWS services on my behalf using the service-linked role.

Validation
Let’s create EC2 instances in default VPC and in testvpc, and test the connectivity.
Besides VPC route table updates, you may also need to update your security group associated with the EC2 instance, if the ICMP is not opened to the other subnet, you will have to add a rule to allow ICMP inbound from other subnet.
From the security group of the 172.31.x.x EC2 instance, allow ICMP inbound from 10.0.1.0/24.
From EC2 10.0.1.26, I’m able to ping the EC2 in another transit gateway connected VPC.
PING 172.31.36.255 (172.31.36.255) 56(84) bytes of data.
64 bytes from 172.31.36.255: icmp_seq=1 ttl=254 time=2.14 ms
64 bytes from 172.31.36.255: icmp_seq=2 ttl=254 time=1.56 ms
64 bytes from 172.31.36.255: icmp_seq=3 ttl=254 time=1.64 ms
64 bytes from 172.31.36.255: icmp_seq=4 ttl=254 time=1.67 ms
64 bytes from 172.31.36.255: icmp_seq=5 ttl=254 time=1.59 ms
64 bytes from 172.31.36.255: icmp_seq=6 ttl=254 time=1.58 ms
64 bytes from 172.31.36.255: icmp_seq=7 ttl=254 time=1.56 ms
64 bytes from 172.31.36.255: icmp_seq=8 ttl=254 time=1.58 ms
From the security group of the 10.0.x.x EC2 instance, allow ICMP inbound from 172.31.32.0/20.
From EC2 172.31.36.255, I’m able to ping the EC2 in another transit gateway connected VPC.
ING 10.0.1.26 (10.0.1.26) 56(84) bytes of data.
.x64 bytes from 10.0.1.26: icmp_seq=1604 ttl=254 time=1.78 ms
64 bytes from 10.0.1.26: icmp_seq=1605 ttl=254 time=1.71 ms
64 bytes from 10.0.1.26: icmp_seq=1606 ttl=254 time=1.66 ms
64 bytes from 10.0.1.26: icmp_seq=1607 ttl=254 time=1.67 ms
64 bytes from 10.0.1.26: icmp_seq=1608 ttl=254 time=1.63 ms
64 bytes from 10.0.1.26: icmp_seq=1609 ttl=254 time=1.68 ms
64 bytes from 10.0.1.26: icmp_seq=1610 ttl=254 time=1.86 ms
64 bytes from 10.0.1.26: icmp_seq=1611 ttl=254 time=1.68 ms
Conclusion
In this article, we learned transit gateway and service-linked role through a lab, in next article, we will explore more about logging, monitoring and network manager.
In case you are wondering what’s the Azure counterpart of transit gateway or service role, the answer is none.
Azure vnet Transitive peering is not supported, but in enterprise environment when utilize express route, connectivity is there without direct vnet peering.
Azure PaaS services create dependent resources on your behalf, but it’s not clear what exact permission is required, of if it’s checked per requestor, or per managed identity or sometime the resource provider just create whatever needed. Azure activity log captures all the administrative log entries, it shows which identity initiates the event.
References
https://docs.aws.amazon.com/vpc/latest/userguide/route-table-options.html#route-tables-tgw