The Journey to Cloud Networking

IP networking is often seen as a means to an end, an abstract aspect of your business. You don’t say, “I really want a fast network…just to have a fast network.” Quite the contrary. As a business, you set out to accomplish your mission and goals, and then find you need applications to get there. In turn, these applications must speak to each other. Hence, the requirement for network connectivity is born. But networking is often overlooked; it’s often seen as a byproduct of the main objective of the business. But don’t be fooled—the network is a necessary component of any application.

If we did a comparison of an IP network to a house, the network could be analogous to the plumbing of the house, a foundational component. It must be planned somewhere between the architectural blueprints for the structure of the house and the carpenters closing and finishing the walls. It would be a major reconstruction to open the walls to fix the plumbing. This may be an overly simplified analogy, but it helps illustrate the headache involved for application teams if they forget to spend the time properly designing their network architecture.

Amazon Virtual Private Cloud (Amazon VPC) is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network. You have complete control to customize and design software-defined networks based on your requirements.

Customers can launch VPCs through the AWS Management Console or use APIs to automate provisioning and operations. Within an AWS account, there is a default VPC where you can launch Amazon Elastic Compute Cloud (EC2) instances and other AWS resources, without any network configuration. While the default VPC is a great way to start, most customers need multiple isolated networks, which translates into having multiple VPCs (for example, creating a different VPC for prod and non-prod). As an application scales or must be integrated, different connectivity needs arise.

Customers are adopting a multi-account strategy and using the “AWS account” as a logical boundary for segmentation. The AWS account can segment different environments (dev, test, and prod), different applications or application teams, increase security, and help simplify pricing. This influences the networking architecture because for every AWS account, there is one or more VPCs, and oftentimes, these VPCs must connect to each other.

Network architecture should be carefully planned before provisioning applications to avoid running into common pit falls, including:

#1: Overlapping IPs are never fun

When it comes to designing network architectures, there is one universal truth: don’t use overlapping IP addresses. It doesn’t end well. When you want these applications to talk to each other, it won’t work without a Network Address Translation (NAT). You either have NAT in one direction or you may end up with NAT in two directions. This doesn’t scale; it adds an unnecessary operational burden to network operators that slows them down. In addition, if you find yourself in this situation, it’s a tedious process to get out of. The best option is to design a new network environment and slowly migrate resources to it.

#2: DNS must be planned for hybrid architectures

Customers migrating to the cloud can have Domain Name System (DNS) architectures that require a hybrid approach that considers the on-premises DNS domains and the requirements for cloud resources to share domain names. Often, on-premises resources need to resolve cloud resources and the other way around. AWS has simplified this with the introduction of Amazon Route 53 resolver hybrid endpoints that can forward to, or receive DNS queries from, on-premises servers. This removes the burden of customers having to manage EC2 instances for the purposes of DNS forwarding.

#3: Scalable architectures require dedicated network teams for architecture and operations

As networks grow, they become more important to the business. One of the age-old questions remains true: how much money does your business lose for every minute, every hour, and every day that the applications are offline? This helps you clearly see how dependent you are on the uptime and availability of your network. The optimal network architecture puts the control and operations of network management into the hands of the network team and enables application developers to focus on building great applications.

#4: AWS is constantly evolving and innovating, and so are network architectures

New services can simplify architectures, improve performance, and save costs. A service worth mentioning is AWS Transit Gateway, which lets you scale connectivity across thousands of Amazon VPCs, AWS accounts, and on-premises networks. Transit Gateway introduces a hub-and-spoke architecture with it being the hub and your VPCs being the spokes. It is highly scalable and performant, and it simplifies network operations. In addition, it enables advanced network architectures such as centralized firewalls for outbound (or egress) filtering, centralized NAT, or multicast.

For other designs, teams and applications may require tighter integration. That would be a good use case for VPC sharing. VPC sharing allows multiple AWS accounts to provision resources in the same centrally managed VPC. VPC sharing can allow network administrators to centralize network resources and have complete control. With a multi-account strategy, more accounts can be created and VPCs can be shared from the network team across to the application and development teams. This gives the network operations team complete control over the architecture and operations of the networking, and ensures that application teams don’t need to worry about properly configuring the network.

#5: Every network design is different

The AWS Well-Architected Framework provides a methodology to help guide customers to build resilient and fault-tolerant applications. But often, the pillars of the Well-Architected Framework are at odds with each other. For example, to build in resiliency may compete with cost optimization. You must define your own requirements. If you’re a large customer, you may prefer to build with more complexity because it keeps costs lower at high scale. In contrast, others may prefer to architect for simplicity and performance with a few added costs.

In closing, I recommend you read the whitepaper, Building a Scalable and Secure Multi-VPC AWS Network Infrastructure. We wrote this paper to help you create scalable, performant, highly available, and secure cloud networks that take your business and applications to the next level. We are in the midst of a technology revolution, and we are your partners in the journey.

Correction 2/13/2024 – This post originally referred to ‘Amazon Elastic Cloud Compute (EC2)’. This has been changed to the correct name: ‘Amazon Elastic Compute Cloud (EC2)’.