Pricing
Gateway endpoints are provided at no charge, other than the cost generated for using the service and transferring data.
Endpoints powered by AWS PrivateLink—that is, interface endpoints and GWLB endpoints—are priced against two dimensions: the time the endpoint exists (per hour, for each AZ where the endpoint is deployed) and the amount of data that goes through it (per GB).
For enterprises, it becomes cost-efficient to centralize interface endpoints—for example, in a VPC within a central shared services or network services account—and to share them within the rest of the organization. This allows not just better control over connectivity aspects, but by avoiding duplicated interface endpoints (times the number of VPCs in use), you are able to save on costs as well, especially if the number of accounts in your organization grows significantly over time.
You are now ready to investigate yet another service that can help you optimize your organization’s network infrastructure, AWS Transit Gateway.
AWS Transit Gateway is a central hub construct to interconnect multiple VPCs on AWS and on-premises networks together.
Its purpose is to do the following:
AWS Transit Gateway is a regional network construct, so in the case where you need to operate in more than one AWS region, you would end up with (at least) one TGW in each region. If you need to establish connectivity between VPCs in different regions, you have the option to create a cross-region peering connection between two TGWs.
TGWs are highly available by design, so you do not need to rely on more than one TGW for the resiliency purposes of the network transit hub. That said, when you attach a
VPC to a TGW, you need to specify on which subnet(s) in which AZ(s) you want that attachment to be effective. So, although the TGW is highly available, it is a best practice to specify subnets in more than one AZ when attaching a VPC to make the VPC attachment itself highly available. That said, resources deployed in a subnet within a specific AZ can only reach a TGW if there exists a TGW attachment to a subnet within the same AZ. In other words, even if you specify a route in a subnet’s route table to reach the TGW, if there is no TGW attachment to a subnet in the same AZ, then the TGW will not be reachable from that subnet. So, it is key to make sure to tie one subnet in each AZ to a TGW attachment wherever your resources need access to the TGW. It is usually recommended to use a separate subnet for that in each AZ, with a small Classless Inter-Domain Routing (CIDR) range (for example, a /28) so that you keep more IP addresses for your own resources. This allows you to have distinct network ACLs for the subnets where you deploy your resources and the subnets associated with the TGW, and you can also use separate route tables for those two types of subnets.
For organizations that intend to use stateful network appliances on their AWS environment, a specific mode called appliance mode can be enabled on the TGW.
The idea is to enable that appliance mode on the VPC attachment corresponding to the VPC where the appliance is deployed. It has then the effect of routing ingress and egress traffic through the same AZ in that VPC (for the sake of statefulness), which is not guaranteed otherwise.
Another important consideration for complex organizations that may have an AWS environment spread across multiple AWS regions is that you will not be charged extra for additional TGWs. Indeed, TGW usage is priced along two dimensions: per VPC attachment and per volume of traffic (GB) going through the TGW. So, unless you decide to attach some VPCs to more than one TGW, these costs will stay the same. TGW peering does not affect the costs either since there is no extra cost for peering, and the TGW traffic costs are not accounted for twice but only at one of two peered TGWs (typically at the sending TGW). The only additional costs in the case of cross-region peering between two TGWs would be inter-region data transfer charges.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
