Introduction

This blog post is a continuation of Introduction to Network Transformation on AWS – Part 1. To recap, as your organization begins to embrace cloud, you extend your network to AWS using a hybrid connectivity architecture. When we work with customers, we see that their network traffic patterns have been changing as more applications are hosted in the cloud. Customers are using this shift as an opportunity to re-think their architecture and also take advantage of the AWS network backbone and global infrastructure to connect data centers, branches, and users directly to applications on AWS. In part 1, we shared the five simple use cases to transform your network, accelerate your workload migrations, and reduce costs. In this blog (part 2), we start with building out a foundation and build upon it towards the target state architecture.  At the end, we provide key considerations and best practices along with next steps.

Use cases and technical details

In this section, you are going to see how you can transform your network with prescriptive guidance for each use case. To recap, these five use cases are:

• Connectivity within AWS
• Connectivity to data centers
• Connectivity to branches
• Connectivity to the internet
• Network security

While your starting point and applicable use cases may not be exactly in this order, you can determine the most applicable use cases and the order for your network transformation based on your business priorities.

Connectivity within AWS: this use case covers connectivity of VPCs within AWS. We establish a foundation for the rest of network transformation, such as facilitation of branch connectivity, data center connectivity, and network security.

AWS customers often rely on hundreds of AWS accounts and Amazon Virtual Private Clouds (VPCs) to segment their workloads. Your connectivity needs may require you to interconnect VPCs within the same AWS Region and across AWS Regions. To support transitive routing, and scale to many hundreds of VPCs, AWS came up with a Regional connectivity solution named AWS Transit Gateway. As part of Network Transformation, we recommend that you use Transit Gateway and Transit Gateway peering. Transit Gateway helps you to solve the following use cases:

• Scalable VPC-to-VPC connectivity
• Transit between AWS Regions and spoke networks with hybrid connectivity solutions, such as AWS Site-to-Site VPN, AWS Direct Connect (DX), and Transit Gateway Connect
• Multicast support – may be required in industries like financial services and media and entertainment
• Network segmentation – using Transit gateway routing tables.

You can also securely access your applications in other VPCs using AWS PrivateLink. This is recommended when you want to use services securely within the AWS network, with all network traffic staying on the global AWS backbone, without the need for an Internet Gateway (IGW) attached to your VPC.

In the following diagram (figure 1), we show a multi-VPC architecture in each AWS Region. VPCs are interconnected with Transit Gateway. Each VPC within an AWS Region has optional access to interface VPC endpoints that are powered by AWS PrivateLink. Inter-Region connectivity is done using Transit Gateway peering. You can route traffic from any resource in one AWS Region to any resource in another AWS Region. All traffic stays on the AWS backbone.

Figure 1: Connectivity within AWS, focus area of network transformation highlighted in red.

Connectivity to data centers: Provides hybrid connectivity by connecting data centers to the AWS Cloud.

We see our customers adopting two types of approaches to hybrid connectivity to data centers. The first approach is to migrate all existing IT resources to the cloud and require short to medium-term hybrid connectivity to migrate assets before shutting down data centers. With the other approach, you may intend to maintain IT resources both on premises and in the cloud and will continue to operate in a hybrid state for the long term. There could be requirements, such as low latency processing and/or data residency. If you have such requirements, you can use AWS Outposts for consistent experience both on premises and in the cloud.

AWS Direct Connect and AWS Site-to-Site VPN are two commonly used methods to interconnect and create a hybrid network. Using AWS Direct Connect, you create a private connection between AWS and your data center, office, or colocation environment. This can increase bandwidth throughput and provide a more consistent network experience than internet-based connections. Direct Connect helps you to comply with regulations that mandate private network connectivity to the cloud, and may also lower your data transfer costs. With up to 100-Gbps port connectivity and MACsec encryption, you can secure and scale AWS hybrid connectivity architectures. AWS Site-to-Site VPN is fast to provision and supports encrypted connectivity. AWS managed VPN endpoints support automated redundancy and failover built into the AWS side of the VPN connection. You can integrate AWS Site-to-Site VPN with Transit Gateway, using the Transit Gateway VPN attachment. This provides the option of creating an IPsec VPN connection between your remote network and Transit Gateway, over the internet. You could also combine AWS Direct Connect and VPN. That solution combines the benefits of end-to-end secure IPsec connections, with the low latency and increased bandwidth of AWS Direct Connect. This combination can provide a more consistent network experience than internet-based VPN connections. You can route data center to data center traffic through the AWS global network instead of leveraging MPLS or point-to-point leased lines.

Our recommendation is to use Transit Gateway with both AWS Direct Connect and AWS Site-to-Site VPN. While other options exist, such as a Virtual Private Gateway attached directly to a VPC, Transit Gateway provides traffic transit capability in a hub-and-spoke model, inspection VPC patterns, and the ability to manage network traffic.

With AWS Site-to-Site VPN, you also have an option of using AWS Accelerated Site-to-Site VPN connections. These connections work with AWS Global Accelerator to route traffic from your on-premises network to the AWS edge location that is closest to your gateway device. AWS Global Accelerator optimizes the network path, using the congestion-free AWS global network to route traffic to the endpoint that provides the best application performance. It is only available when AWS Site-to-Site VPN is used with Transit Gateway.

For critical production workloads that require high resiliency, we recommend that you create AWS Direct Connect connections at more than one location. Such a topology enhances resiliency in the event of a fiber cut or a device failure, in addition to a complete location failure. You can use Direct Connect Gateway to access any AWS Region (except AWS Regions in China) from any AWS Direct Connect location. The AWS Direct Connect Resiliency Recommendations guide has more details on this topic.

In the following diagram (figure 2), we show a hybrid connectivity architecture across different datacenters and AWS. The datacenters are connected via Direct Connect or Site-to-Site VPN and global accelerator.

Figure 2: Connectivity to data centers, focus area of network transformation highlighted in red.

Connectivity to branches: You can connect your branches directly to the cloud for better performance to applications hosted in AWS, and also use the AWS global network as the transport between your branches.

There are two main transformative trends in branch connectivity. The first one is a shift from private connectivity, such as Site-to-Site VPN or MPLS, to user-to-application centric view of connectivity. In this view, users connect directly to cloud-based applications over internet. There is no private network uplink from a branch, such as MPLS or IPsec VPN, and all users are accessing applications the same way irrespective of their location. With the second trend, you maintain private network uplink from a branch to AWS. It can be IPsec VPN or you can transform branch connectivity with Software Defined Wide Area Networks (SDWAN). SDWAN orchestrates the provisioning of encrypted network tunnels to AWS and can integrate with Transit Gateway. By connecting branches directly to AWS, you can reduce reliance on your existing data centers, improve performance, reduce cost, and improve security. You benefit from rapid provisioning of new branches over internet link, with no long-term commitments, and price elasticity. AWS further enhances SDWAN with integrated network security. AWS Partners with SDWAN vendors to deliver seamless integration with AWS using the Transit Gateway Connect feature. If you have no immediate plans to introduce SDWAN, you can continue to use IPsec based VPNs with AWS Accelerated Site-to-Site VPN over the internet and connect directly to Transit Gateway. You can leverage any of the aforementioned options that suits best to your requirements.

When it comes to users in your branch accessing the internet, you can either send the traffic to AWS or have direct internet access (DIA) from branch. If you send all traffic to AWS, including internet bound, you can leverage AWS services to secure internet egress for your branch. With DIA, each branch has separate internet egress. It allows you to access SaaS applications directly. With this approach, you will have to incorporate network security controls at each branch.

Finally, you may opt to have all of your users connect to AWS via remote access VPNs (also known as client VPN). This is a common for mobile users who do not work permanently from the same location. AWS offers both fully managed options with AWS Client VPN and bring your own remote access options. Another alternative here is to use virtual desktop infrastructure (VDI) such as Amazon Workspaces. VDI gives users an ability to securely connect to a desktop that is running on AWS, within a VPC. It naturally gives connectivity to the rest of the network built on AWS.

In the following diagram (figure 3), we show a branch connectivity architecture. Each AWS Region is connected from your branches using client VPN or SDWAN. You can also leverage IPsec VPN for branch connectivity.

Figure 3: Connectivity to branches and remote users, focus area of network transformation highlighted in red.

Connectivity to internet: securely publish applications to the internet on AWS Cloud and secure internet egress.

For internet connectivity, your Amazon VPC requires an internet gateway (IGW). You only associate IGW to Amazon VPCs that require and facilitate internet access. IGW is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. It manages internet uplink redundancy and capacity using the many terabits of internet connectivity with many transit and peer networks that interconnect AWS Regions.

For publishing applications to the internet, you may use inbound (or internet ingress) solutions such as load balancing with Elastic Load Balancing, web application security with AWS WAF, Domain Name System (DNS) with Amazon Route 53, and content distribution at a local and global scale with Amazon CloudFront. Applications built on top of the HTTP protocol are commonly secured with AWS WAF, and scaled through Amazon CloudFront for content caching and acceleration. Container workloads also use Elastic Load Balancing, such as AWS Load Balancing Controller with Amazon EKS.

Applications migrated or built on AWS often require internet connectivity out of AWS (internet egress). As you transform your network on AWS, you increasingly use it as an internet egress point, isolating and inspecting outbound internet traffic flows for consistent security. One popular use case is when applications reach out to internet for API access or the latest software versions. Another use case is Amazon Workspaces, where cloud desktop users access websites on the internet. You may also prefer to host explicit forward proxy servers within AWS. We recommend exploring a centralized internet egress pattern, as deploying a separate internet egress solution in each VPC may become expensive. Additional costs are incurred for running NAT gateways or other ISV solutions from individual VPCs. You can also use this pattern to provide internet access to Transit Gateway attachments by setting up a default route toward egress VPC.

In the following diagram (figure 4), we show an internet connectivity architecture. Internet facing applications here are published through a combination of services, like Amazon Route 53, Amazon CloudFront and AWS WAF. The resources in VPCs access endpoints in internet via NAT gateways provisioned within that AWS Region.

Figure 4: Connectivity to internet, focus area of network transformation highlighted in red.

Network Security: is important across all the use cases of Network Transformation. We encourage you to invest in learning network security in AWS.

Traditional AWS firewall techniques, such as the use of security groups and network access control lists, limit the attack surface for potential attackers and deny traffic to and from the source and destination of the attack. AWS Web Application Firewall provides deep packet inspection for web traffic and filters malicious traffic like XSS and SQL injection. AWS Shield Standard provides always-on network flow monitoring that inspects incoming traffic to AWS services. It applies a combination of traffic signatures and anomaly algorithms to provide inline attack mitigation techniques. This protects the underlying AWS services against commonly occurring infrastructure attacks with no additional cost. You can use AWS Shield Advanced, which provides extended DDoS attack protection at the edge of AWS network. You can tailor your detection based on application traffic patterns. Shield Advanced provides advanced attack mitigation, health based detection, and proactive event response–along with global availability and centralized protection management.  With AWS Gateway Load Balancer, you can expose network security as a service, providing new ways to deliver Network Function Virtualization (NFV) solutions. Gateway Load Balancer natively provides high availability and handles scaling of third-party appliance fleets. The Amazon Route 53 Resolver DNS Firewall helps protect against DNS threats such as DNS exfiltration attempts. With AWS Network Firewall, you can achieve fine-grained network protections for all your VPC and ensure that traffic is inspected, monitored and logged. Network Firewall scales automatically with your network traffic and offers built in redundancies designed to provide high availability. You can also choose from a variety of third-party firewall appliances from AWS Marketplace to monitor and analyze network traffic, log files, access, or spot any traffic generated by malware. Another way to enhance the security of your applications is by encrypting its data while in transit using features like SSL/TLS and adding authentication between source and destination using mTLS and IAM roles. Finally, you can have a comprehensive view of your security state with AWS Security Hub, which helps you compare your AWS environment against security industry standards and best practices. Security Hub collects security data from across AWS accounts, services, and supported third party partner products. It helps you analyze your security trends and identify the highest priority security issues. Amazon GuardDuty integration with Security Hub surfaces the findings in the Security Hub. Security Hub uses those findings in its analysis of the overall security posture of your AWS environment.

There are a lot of options that AWS offers to build a layered security and help you meet regulatory and compliance requirements, such as adopting NIST cyber security framework. As part of network transformation, we recommend you follow a defense in depth strategy to minimize risk and secure your applications. You can achieve this by following these principles:

• Secure your internet facing applications at the edge using services like AWS Shield and AWS WAF.
• Secure your VPC boundary by taking advantage of features and services like AWS Network Firewall, Gateway Load Balancer, DNS Firewall, Network Access Control List, and Security Groups. Try to deploy your applications in private subnets within VPC boundary without exposing them to internet whenever possible.
• Secure your branch and on-premises data centers. You can do this in two ways. You can send all traffic from your branch and on-premises data centers to AWS and secure your applications using the security services and features we discussed in the preceding section. The other option is to split tunnel at the branch or data center by establishing direct internet access. In this case, you must provide additional network security in each branch.
• Lock access to your applications within the VPC boundary by leveraging IAM roles and using features like SSL/TLS and mTLS.

The Networking best practices and tips within well architected framework and Advanced VPC connectivity patterns videos provide further insights on how to incorporate these security best practices into your applications.

In the following diagram (figure 5), we show an architecture for network security. The application traffic is being inspected through AWS Network Firewall. You can additionally leverage AWS WAF to secure your internet facing applications as depicted.

Figure 5: Network security layer added as part of network transformation.

Target state of the fully transformed network on AWS

Many target architectures are possible depending on your requirements. The core component with network transformation is the use of Transit Gateway. Transit Gateway works as a connecting block for a variety of networks and connectivity options, such as AWS Site-to-Site VPN, Amazon VPC, and AWS Direct Connect. The following diagram (figure 6), shows two different AWS Regions serving as regional network hubs for their respective geographical area. This architecture allows you to minimize latency to applications hosted on AWS, and improve user experience. Branches connect to Transit Gateway either using managed services from AWS, such as AWS Accelerated Site-to-Site VPN, or using SDWAN technology over commodity internet. AWS is a centralized traffic inspection and security point and all attached networks can use AWS as a secure path for internet ingress and egress by way of proxies on EC2 and NAT Gateways. Branches also have an option to have direct internet access (DIA) and egress directly to internet as long as you provide the appropriate branch network security.

In our example, target state architecture makes use of cloud scale services provided by AWS and extended with virtualized SDWAN network appliances from AWS Marketplace. Every workload within AWS and on premises can consume SaaS services using AWS PrivateLink. One additional point to consider is that all of the AWS network is software-defined, and could be managed with Infrastructure as Code (IaC). We have previously shared why and how to build such automated and global networks, as well as talked about it at re:Invent conference.

Figure 6 shows a subset of traffic flows to give you an overview of how this target state interconnects various networks:

1. Branch to branch using SDWAN and AWS global network
2. Branch to existing data center in remote region
3. Branch to a workload VPC in the same AWS Region using a firewall
4. A workload using a firewall and egress VPC to the internet
5. Remote user using Client VPN and a firewall to AWS PrivateLink

Figure 6: Target state architecture with a number of network flows shown

Considerations and best practices

Here are the key considerations to keep in mind as you begin your network transformation journey in AWS.

• IPv6 Support – if you have a SDWAN environment and your applications require IPv6 support for multiple protocols, you must configure your Transit Gateway with Connect attachments enabled with multi-protocol extensions with BGP (MP-BGP). If you are using Amazon VPN for connectivity, separate VPN connections must be established with Transit Gateway for your IPv6 workloads.
• EC2 Classic – if you still have any resources in EC2 Classic, make moving them to Amazon VPC a priority. AWS recently announced the retirement of EC2 Classic. Having your resources in an Amazon VPC is a prerequisite for network transformation on AWS.
• Branch internet access – we recommend that your branch has direct internet access (DIA) with necessary network security guard rails in place. Ideally, the branch should not backhaul internet traffic via AWS to have the best user experience.
• Access to AWS services and SaaS hosted on AWS – consider using AWS PrivateLink for added security benefits (via resource based policies) and simplicity (enabling third party integrations and seamlessly handle overlapping IP addresses).
• IP Address Management – we recommend proper segmentation of your AWS and on-premises environments. As a best practice, avoid overlapping CIDRs. Allocate large IP supernets per AWS Region to minimize the amount of routes in your VPC and Transit Gateway route tables. Summarize your routes where possible as it simplifies overall network route management in AWS.
• Network Management at scale – as your network footprint in AWS expands, management becomes critical. We recommend that you provision all networking resources with Infrastructure as Code and CI/CD. The code must be version controlled. We also recommend that you validate your networking changes in a development environment before promoting them to production.
• Usage considerations – this blog provides overview of data transfer for common AWS architectures.  AWS can help with a comprehensive data driven total cost of ownership (TCO) assessment.
• Last mile connectivity – consider replacing existing private leased lines and MPLS circuits with commodity internet. This can be achieved by running overlay tunnels using IPsec VPN or SD-WAN. Last mile connectivity is your responsibility.

Recommendation and next steps

As you begin to transform your network on AWS, you should build a two-to-three-year plan. Challenge your assumptions as you evaluate different aspects of your network. As your applications move to the cloud, and depending on several factors, we recommend that you connect your users directly to AWS. These factors include, the life cycle of the equipment in your data centers and branches, service provider contracts, and other compelling events, like SDWAN adoption. Sending your user traffic through additional data center hops when most of your workloads are in the cloud results in suboptimal traffic patterns, lack of automation, increased costs, network security management overhead, and compromised business agility.

To summarize, the key benefits of network transformation: connecting directly to AWS gives you the ability to quickly scale up or down network capacity, and the AWS network backbone and global infrastructure gives you increased flexibility and agility, helping you adapt to changing business requirements. It enables provisioning of network using an infrastructure as code and a config as code approach for repeatable and automated network configuration.

We recommend that you start your network transformation on AWS with a pilot in your environment. During the pilot, build a Transit Gateway and connect at least one pilot branch with your preferred connectivity method. This helps you gain operational insights and build a more accurate total cost of ownership (TCO) analysis to underpin your decision to implement network transformation on AWS.

Here is the list of next steps:

1. Review your existing networking use cases.
2. Decide your target state architecture for your overall network with a two-to-three-year horizon in mind. Your target state must be mapped to a business outcome that is achieved through the network transformation.
3. Evaluate return on investment (ROI) and TCO. If you need help with TCO/ROI, reach out to your AWS account team who can help you with your TCO calculation using AWS TCO tools. In the blog post part 1, we demonstrated a number of customers who were able to achieve up to 60% TCO saving while improving user experience, security posture, and business agility.
4. Evaluate transformative aspects of connectivity within AWS and how your remote sites and users will connect directly to AWS.
5. Consider your network security roadmap and how it is aligned to your network transformation journey.
6. Run a pilot for a test branch or set of branches, and create migration procedures and automation.
7. Implement the five use cases of network transformation as per your business requirements. You could use help for AWS ProServe, AWS partner network (APN), or do it yourself based on AWS prescriptive guidance and AWS samples on GitHub.

We hope this blog post helps you in your network transformation journey on AWS. If you need any further assistance, please contact us and stay tuned for the part 3.

About the Authors