In this article, we’ll introduce the best practices and the most common architecture of virtual private clouds (VPCs), as well as its design principles with AWS, Azure, or Google Cloud.

‍

We’ve listed all of the essential steps in creating and managing complex network solutions. This detailed guide ensures that your Virtual Private Cloud will meet current standards while remaining future-proof, and upgrade-ready. 

Setup for success

Determine your timeline, decision-makers, and start your pre-work

Addressing stakeholder requirements is a top priority, so the first thing to do when starting your VPC network designs is to identify your decision-makers. But don’t forget to set up clear timelines and clarify how much pre-work is necessary.

‍

Stakeholders can include anyone from the application owner to a general operations manager. But, they can also be solutions architects, security architects, and other employees. It’s important to keep in mind that stakeholders change and depend on your situation. Whether you’re working on a project, or trying to run an organization the scope of your stakeholders will vary. 

‍

The key concept to keep in mind is that VPCs need to be designed to meet your current needs as well as future ones.

Work on Virtual Private Cloud network designs as early as possible

When creating an organizational setup, it’s important to consider a VPC network design as early as possible. Careful planning at this stage ensures a solid structure that can scale in tandem with your workloads. A hastily patched-up network design may prove somewhat effective in the beginning but is prone to quickly turn into a mishmash of nearly unmanageable data. 

‍

Start with a solid structure that meets your needs, keep future developments in mind, and you’ll be able to evade maintenance and organizational issues. 

‍

The quality of the VPC network configuration can impact most aspects of any business including security, routing, and scale. This makes it imperative to carefully plan Virtual Private Clouds. When the foundation is strong, you can always add and expand, but when it is not, the system crumbles. 

‍

By following these principles you’ll be able to create a strong foundation that can handle incremental workload growth.

Simplify as much as possible

Creating a simple VPC network topology is the optimal way to provide a reliable and efficient cloud architecture.

Use clear nomenclature and naming conventions

Another important tip is to create clear and simple naming conventions. Confusing names with seemingly no connection can derail the workflow. Therefore you need to ensure the naming scheme is intuitive, consistent, and simple.

‍

Use two simple rules: 

Abbreviation: Shorten long words for brevities sake.

Familiar terminology: Where application is possible, this will increase readability. 

Some of the elements usually abbreviated are company names and business units, as well as application codes that handle specific tasks, and region and environment codes. Using these conventions helps organize VPCs and turn them into efficient global spaces.

‍

Here’s an example to better understand the optimal naming convention: 

Company name: CenterInfrastructure Company: centinfra

Business unit: Human Resources: hr

Application code: Compensation system: comp

Region code: northamerica-northeast1: na-ne1, europe-west1: eu-we1

Environment codes: dev, test, uat, stage, prod

‍

Other common networking recourses and their proper networking patterns:

Firewall rule

<pre class="codeWrap"><code>{company-name}-{description(App or BU)-label}
{source-label}-{dest-label}-{protocol}-{port}-{action}</code></pre>

Example:

<pre class="codeWrap"><code>centinfra-hr-internet-internal-tcp-80-allow-rule</code></pre>

Subnet

<pre class="codeWrap"><code>{company-name}-{description(App or BU)-label}-{region/zone-label}</code></pre>

Example:

<pre class="codeWrap"><code>centinfra-hr-na-ne1-dev-subnet</code></pre>

VPC network

<pre class="codeWrap"><code> {company name}-{description(App or BU)-label}-{environment-label}-{seq#} </code></pre>

Example:

<pre class="codeWrap"><code> centinfra-hr-dev-vpc-1</code></pre>

IP route

<pre class="codeWrap"><code>{priority}-{VPC-label}-{tag}-{next hop}</code></pre>

Example:

<pre class="codeWrap"><code> 1000-centinfra-hr-dev-vpc-1-int-gw</code></pre>

Using subnets and addresses

One of the main features of a VPC is that it’s easily divisible into subnets or subnetworks. But these subnets aren't isolation boundaries per se. They merely contain various routing policies.

Isolate with Firewall Rules or Security Groups

One of the ways to isolate data in your VPC network designs is through a Security Group (SG). An SG can be attached to the VM instances where your application is hosted. You can also do this by creating Network Firewall Rules (FWR) that work on your subnet levels.

‍

For example, when it comes to AWS SGs or FWR in GCP they are stateful firewalls. They track connections and ensure the allowance of return traffic. Through them, you control all incoming and outgoing access for any elastic network interface. Since they play a huge part in security, make sure to configure them to only allow access when needed. 

‍

It’s recommended that subnetworks be created with two principal categories: public and private. 

Divide workloads into fewer subnets that function in larger address ranges

Traditionally, enterprises tend to split networks into numerous smaller address ranges. This can be done to keep applications isolated, security access thigh, and broadcast domains smaller.

‍

But if you have a few similar applications it’s recommended to use larger address ranges with more manageable subnets.

‍

Because most cloud providers maintain globally accessible networks, they need fully reachable Virtual Private Clouds (VPCs). That’s why their data centers use a software-defined networking (SDN) approach that allows all their VMs to reach into the global VPC network. That being said these subnets do not affect routing behavior. 

‍

Additionally, opting for service accounts and network tags may be beneficial to applying certain routing policies and firewall rules.

Network user roles at subnet levels

While assigning user roles try to follow the principle of least privilege, and recommend that network user roles be granted on a subnet level. These roles can then correspond to associated users, groups, or service accounts.

‍

As subnets are generally regional this grouping can help you control which regions and projects get access to resources and their deployment.

Public versus private access

Private access always takes priority over public access. Don’t forget that. 

Prevent traffic that goes out of the cloud provider's backbone network

One of the most important aspects to keep track of during your VPC network design is the cloud backbone. Cloud backbone is a collection of data centers and other global points of presence that essentially serve as attachment points. These backbones can range from a single public cloud region to multiple clouds or even multiple cloud regions. 

‍

A provider’s network is usually a lot more secure and optimized for traffic and availability. By using PoPs content distribution can be kept closer to end users without increasing costs. 

Consider using private endpoints

To further increase customer security consider deploying a VPC endpoint. They allow users to privately connect to VPC services. In addition, they don’t require public IP addresses to communicate with your VM instances, therefore exponentially strengthening your security.

‍

By enabling Private Google Access in GCP you’re allowing free communication between workloads of differing VPCs.

‍

On the other hand, AWS PrivateLink enables communication with other AWS-managed services as well as services hosted by AWS partners and customers. AWS even supports  AWS Marketplace partner services, thus making the service owner the same as a service provider. In this situation, the service consumer creates the interface endpoint.

‍

It’s worth mentioning that Azure Private Link also enables access to other Azure PaaS Services such as their SQL Database, as well as Azure-hosted services over the private endpoints in your virtual network.

Keep an eye on Load Balancers (LB)

Depending on the complexity of your application, having multiple tiers of access could prove useful. For example, your web servers could require a separate connection to the database servers as well as the internet. Therefore creating a network architecture with internal and external load balancers could help.

‍

 All you have to do is create an internet-facing load balancer and register the web servers. You can also create an internal load balancer and simply register the database servers. That way your web server can communicate and coordinate with them separately.

VPC sharing and peering

These two principles are the key components of VPC communication. VPC sharing enables users and customers to share subnets between accounts, businesses, and even projects. 

‍

By taking full advantage of VPC sharing you can separate duties by controlling the VPC structure and trouting. Owners of the application can keep the ownership of resources and accounts. The efficiency of projects increases significantly and costs are optimized.

‍

VPC network peering on the other hand deals with multiple Virtual Private Clouds (VPCs) so they can exchange resources and communicate more efficiently. The benefits of VPC peering allow you to privately publish software as a service (SaaS) offerings in between VPC networks.

‍

Additionally, you can deliver information packets while remaining inside a backbone network. And on top of all that your network traffic tends to be cheaper. Plus, it works with Kubernetes cluster nodes, VM, and WebApp. 

Network Security

The infrastructure of cloud services offers strong security features that prevent any malicious actors from benefiting from your data. These security features range from physical security protecting data centers to software teams that prevent potential weaknesses from exploitation.

Recognize explicit security objectives

Before taking the final plunge make sure to identify and evaluate your security objectives. These should be clear and agreed upon by all stakeholders. Some important aspects to keep in mind are achievability, iteration, and documentation.

‍

By achieving those objectives you’ll be able to develop a robust security system, as well as reference them later in case of any potential upgrades.

Control external access

Internet should be accessed by only the resources that need it. Keeping resources within the internal IP addresses increases security and prevents any potential leaks. That being said, private access still allows resources to interact with the cloud provider, it only limits access to public internet.

‍

Before nulling Internet access, do think about the impact it could have on your VM instances. Yes, blocking Internet access can prevent data exfiltration, but that also means it blocks all other legitimate traffic that may be needed. 

‍

Some software can deteriorate without regular updates or won't even function without a connection. Additionally, you’ll only be able to access the VM instances through a locally connected network. And even then you’ll need a Cloud VPN tunnel or a DirectConnect/CloudInteconnect/ExpressRoute connection. 

‍

By using Cloud NAT, a virtual machine can initiate egress connections for specific traffic, but it still won’t expose public ingress connections. This method will allow only essential traffic thus keeping maximal safety.

Determine service perimeters for any sensitive data

Network perimeters are simple but effective tools. They are the boundary between a secured internal network of an organization and the internet. They can prevent online data leaks and even uncontrolled external networks from gaining access.

‍

These network perimeters make identity and access management (IAM) a key aspect of data access control as they ensure that data loss is prevented through DLP.

Follow the principles of least privilege

By following these principles in your VPC network designs you’ll be able to create an efficient and optimized organizational system:

• Keep broad firewall rulesets when you can
• Use cloud-native firewall rules whenever you can to manage traffic
• Use service accounts to isolate VMs when possible
• Monitor security policies when using tags via automation
• And try to keep using cloud-native tools