SBB – AWS Transit Gateway

In the journey to the Cloud, many companies face the challenge of having to interconnect multiple on-premises workloads with their cloud workloads. While segmentation is key to network design in order to have a secure architecture, interconnecting several networks can be challenging, especially from the point of view of scalability and manageability. Typically, connecting on-premises offices and data centers to the cloud requires the use of point-to-point connections, such as IPsec Virtual Private network (VPN) tunnels or private network fiber connections. Connecting virtual networks (groups of networked cloud resources) with each other also requires point-to-point connections. However, as the number of on-premises offices and virtual networks increases, the number of point-to-point connections grows, resulting in a large mesh network that can be difficult, cumbersome, and costly to manage. Organizations using AWS have typically used AWS Direct Connect and AWS Site-to-Site Virtual Private Network (VPN) connections for connecting their on-premises environment to individual Amazon VPCs and VPC peering for connecting their Amazon VPCs with each other.

The main problem of such a scenario is that setting up VPC peering connections between separate accounts became unmanageable and cumbersome. For a VPC peering connection to be established, one account sends the connection request, while the other account must accept it.

The account accepting the request must manually configure the Amazon VPC to accommodate the new connection. While this may be a simple process when dealing with a small number of connections, SBB anticipated repeating this process and reconfiguring connections as part of their normal operations.

This root problem, generates many other issues:

– Networking becomes fast too complex to manage

– Automation is challenging, as VPC peering requires manual intervention.

– Level of visibility and control over traffic flow is reduced.

– Monitoring of traffic becomes challenging, as multiple logs need to be collected from different sources and accounts.

AWS Transit Gateway simplifies how organizations connect their Amazon VPCs with one another and to their on-premises networks within a region   by serving as a central point for Layer 3 network connectivity. By enabling a “hub-and-spoke” topology, the solution can help organizations reduce the number of VPC peering connections and consolidate access to the on-premises network.

Even though the number of VPCs is small and there is only one enterprise location in the previous figure, it is easy to see how the Transit Gateway simplifies the environment. Imagine how much complexity is removed when there are additional enterprise locations and hundreds or thousands of Amazon VPCs. Now, organizations can simply connect their on-premises networks and Amazon VPCs via AWS Transit Gateway.

Integrating cloud and on-premises IT environments remains a challenge for organizations when pursuing a hybrid cloud strategy. A necessary part of that integration is ensuring that resources both in the cloud and on-premises locations are networked to respond to business needs without the need for extensive architecture planning, management, and administration.

AWS Transit Gateway enables organizations to network their cloud and on-premises environments. With this managed, distributed, and scalable service, large enterprises can develop global private networks connecting on-premises locations to Amazon VPCs in any AWS region without the need for multiple point-to-point connections. Enterprises can leverage AWS Transit Gateway Network Manager to monitor the performance and availability of their AWS Transit Gateways and corresponding attachments. AWS Transit Gateway also offers other features that help organizations to build out and manage global enterprise-grade networks. With AWS Transit Gateway, organizations can ultimately decrease the time and resources required to deploy and manage a global network architecture with less complexity, decreasing both network infrastructure and operational costs.

As in this case the main target it’s to separate the traffic from the VPC’s and ensure that external companies connecting through VPN can only access the respective workloads on their VPC, the architecture we decided to implement consists on using 2 different routing tables, one for the VPN, allowing only the routes to the relevant VPC’s and restricting the access to the on-premises network, and another for the VPC’s, which ensures the no interconnection between accounts and VPC’s and allows only northbound-southbound traffic (VPC-VPN and back).