# Identity and access management in AWS Transit Gateway
AWS uses security credentials to identify you and to grant you access to your AWS resources. You can use features of AWS Identity and Access Management (IAM) to allow other users, services, and applications to use your AWS resources fully or in a limited way, without sharing your security credentials.
By default, IAM users don't have permission to create, view, or modify AWS resources. To allow a user to access resources such as a transit gateway, and to perform tasks, you must create an IAM policy that grants the user permission to use the specific resources and API actions they'll need, then attach the policy to the group to which that user belongs. When you attach a policy to a user or group of users, it allows or denies the users permission to perform the specified tasks on the specified resources.
To work with a transit gateway, one of the following AWS managed policies might meet your needs:
+ [AmazonEC2FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html)
+ [AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html)
+ [PowerUserAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/PowerUserAccess.html)
+ [ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ReadOnlyAccess.html)
## Example policies to manage transit gateways
The following are example IAM policies for working with transit gateways.
**Create a transit gateway with required tags**
The following example enables users to create transit gateway. The `aws:RequestTag` condition key requires users to tag the transit gateway with the tag `stack=prod`. The `aws:TagKeys` condition key uses the `ForAllValues` modifier to indicate that only the key `stack` is allowed in the request (no other tags can be specified). If users don't pass this specific tag when they create the transit gateway, or if they don't specify tags at all, the request fails.
The second statement uses the `ec2:CreateAction` condition key to allow users to create tags only in the context of `CreateTransitGateway`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateTaggedTGWs",
"Effect": "Allow",
"Action": "ec2:CreateTransitGateway",
"Resource": "arn:aws:ec2:us-east-1:123456789012:transit-gateway/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/stack": "prod"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"stack"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:transit-gateway/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateTransitGateway"
}
}
}
]
}
```
------
**Working with transit gateway route tables**
The following example enables users to create and delete transit gateway route tables for a specific transit gateway only (`tgw-11223344556677889`). Users can also create and replace routes in any transit gateway route table, but only for attachments that have the tag `network=new-york-office`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteTransitGatewayRouteTable",
"ec2:CreateTransitGatewayRouteTable"
],
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:transit-gateway/tgw-11223344556677889",
"arn:aws:ec2:*:*:transit-gateway-route-table/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTransitGatewayRoute",
"ec2:ReplaceTransitGatewayRoute"
],
"Resource": "arn:aws:ec2:*:*:transit-gateway-attachment/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/network": "new-york-office"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTransitGatewayRoute",
"ec2:ReplaceTransitGatewayRoute"
],
"Resource": "arn:aws:ec2:*:*:transit-gateway-route-table/*"
}
]
}
```
------
# Use service-linked roles for transit gateways in AWS Transit Gateway
Amazon VPC uses service-linked roles for the permissions that it requires to call other AWS services on your behalf. For more information, see [Service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) in the *IAM User Guide*.
## Transit gateway service-linked role
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.
### Permissions granted by the service-linked role
Amazon VPC uses the service-linked role named **AWSServiceRoleForVPCTransitGateway** to call the following actions on your behalf when you work with a transit gateway:
+ `ec2:CreateNetworkInterface`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:DeleteNetworkInterface`
+ `ec2:CreateNetworkInterfacePermission`
+ `ec2:AssignIpv6Addresses`
+ `ec2:UnAssignIpv6Addresses`
The **AWSServiceRoleForVPCTransitGateway** role trusts the following services to assume the role:
+ `transitgateway.amazonaws.com`
**AWSServiceRoleForVPCTransitGateway** uses the managed policy [AWSVPCTransitGatewayServiceRolePolicy](security-iam-awsmanpol.md#AWSVPCTransitGatewayServiceRolePolicy).
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions) in the *IAM User Guide*.
### Create the service-linked role
You don't need to manually create the **AWSServiceRoleForVPCTransitGateway** role. Amazon VPC creates this role for you when you attach a VPC in your account to a transit gateway.
### Edit the service-linked role
You can edit the description of **AWSServiceRoleForVPCTransitGateway** using IAM. For more information, see [Edit a service-linked role description](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console) in the *IAM User Guide*.
### Delete the service-linked role
If you no longer need to use transit gateways, we recommend that you delete **AWSServiceRoleForVPCTransitGateway**.
You can delete this service-linked role only after you delete all transit gateway VPC attachments in your AWS account. This ensures that you can't inadvertently remove permission to access your VPC attachments.
You can use the IAM console, the IAM CLI, or the IAM API to delete service-linked roles. For more information, see [Delete a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr) in the *IAM User Guide*.
After you delete **AWSServiceRoleForVPCTransitGateway**, Amazon VPC creates the role again if you attach a VPC in your account to a transit gateway.
# AWS managed policies for transit gateways in AWS Transit Gateway
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
To work with a transit gateway, one of the following AWS managed policies might meet your needs:
+ [AmazonEC2FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html)
+ [AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html)
+ [PowerUserAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/PowerUserAccess.html)
+ [ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ReadOnlyAccess.html)
## AWS managed policy: AWSVPCTransitGatewayServiceRolePolicy
This policy is attached to the role [AWSServiceRoleForVPCTransitGateway](service-linked-roles.md). This allows Amazon VPC to create and manage resources for your transit gateway attachments.
To view the permissions for this policy, see [AWSVPCTransitGatewayServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSVPCTransitGatewayServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
## Transit gateway updates to AWS managed policies
View details about updates to AWS managed policies for transit gateways since Amazon VPC began tracking these changes in March 2021.
| Change | Description | Date |
| --- | --- | --- |
| Amazon VPC started tracking changes | Amazon VPC started tracking changes to its AWS managed policies. | March 1, 2021 |
# Network ACLs for transit gateways in AWS Transit Gateway
A network access control list (NACL) is an optional layer of security.
Network access control list (NACL) rules are applied differently, depending on the scenario:
+ [Same subnet for EC2 instances and transit gateway association](#nacl-tgw-same-subnet)
+ [Different subnets for EC2 instances and transit gateway association](#nacl-tgw-different-subnet)
## Same subnet for EC2 instances and transit gateway association
Consider a configuration where you have EC2 instances and a transit gateway association in the same subnet. The same network ACL is used for both the traffic from the EC2 instances to the transit gateway and traffic from the transit gateway to the instances.
NACL rules are applied as follows for traffic from instances to the transit gateway:
+ Outbound rules use the destination IP address for evaluation.
+ Inbound rules use the source IP address for evaluation.
NACL rules are applied as follows for traffic from the transit gateway to the instances:
+ Outbound rules are not evaluated.
+ Inbound rules are not evaluated.
## Different subnets for EC2 instances and transit gateway association
Consider a configuration where you have EC2 instances in one subnet and a transit gateway association in a different subnet, and each subnet is associated with a different network ACL.
Network ACL rules are applied as follows for the EC2 instance subnet:
+ Outbound rules use the destination IP address to evaluate traffic from the instances to the transit gateway.
+ Inbound rules use the source IP address to evaluate traffic from the transit gateway to the instances.
NACL rules are applied as follows for the transit gateway subnet:
+ Outbound rules use the destination IP address to evaluate traffic from the transit gateway to the instances.
+ Outbound rules are not used to evaluate traffic from the instances to the transit gateway.
+ Inbound rules use the source IP address to evaluate traffic from the instances to the transit gateway.
+ Inbound rules are not used to evaluate traffic from the transit gateway to the instances.
## Best Practices
Use a separate subnet for each transit gateway VPC attachment. For each subnet, use a small CIDR, for example /28, so that you have more addresses for EC2 resources. When you use a separate subnet, you can configure the following:
+ Keep the inbound and outbound NACL that is associated with the transit gateway subnets open.
+ Depending on your traffic flow, you can apply NACLs to your workload subnets.
For more information about how VPC attachments work, see [Resource attachments](how-transit-gateways-work.md#tgw-attachments-overview).