Accounts in the different cloud providers have different implementations of networking. This is usually where you will find the biggest differences between the different clouds. Azure has the whole Microsoft backbone, Google has their own extensive interconnections where almost all traffic can go through their own wires and Amazon relies on separation of networking functions to deliver high availability. It is hard to say which implementation is better, but you can see certain trends where the different cloud providers are implementing networking structures on an organizational level instead of account level.

First thing to remember is that networks live within projects / accounts and they may consist of multiple regions. Regions may consist of multiple zones but even so, locations within a region have roundtrip network latency of 5ms wich makes it barely noticable. Subnets may span zones within each network as well so the typical separation of subnets is a bit different from the traditional approach.

There are some resources that are regional. Some functions exist not yet in certain regions OR zones so there is a need to either support multiple regions or zone or choose one that supports the most functionality. Older regions are generally the most supported ones.

All elements of a network may talk to one another, firewall rules permitting. Note that firewalls are usually denying all traffic by default, which means that you must explicitally permit access. You could say that the public cloud presents a new security model where traditional firewall and networking concepts will not always apply. Consider introducing more platforms into the mix - both AWS, Azure and GCP. Making security policies behave in the same way across public cloud platforms will make management easier, so implementing a good structure from the beginning is key.

• There has not been a single good single pane of glass implementation for networking without loss of functionality, performance, higher cost and less flexibility

• Most resources should be in private subnets

• Utilize the managed firewalls for your infrastructure instead of using on-compute firewalls or traditional firewalls since they do not add any additional value

• Utilize built in log exports for tracking all traffic within a VPC

• Use Cloud native security tooling for Web application firewalls, analysis and more instead of appliances

Key questions to ask yourself when structuring the networking

1. What strategies will be used to connect with corporate networks?

2. How will cloud resources communicate with each other?

3. How will cloud resources communicate with the internet?

4. How will resources be segmented into networks and subnets?

5. To what degree is redundancy, reliability, and scalability a factor in your network architecture?

6. Public internet/VPN, direct connect/hosted direct connect for on-prem and/or multi-cloud connectivity?

7. How to host compute in accounts, networks, and subnets?

8. How to implement IAM and security aspects of networking?

Planning connectivity

Implementing a IP Administration management tool is essential to connectivity planning. The tool should be fully API driven and be able to be queried for the next IP range that will be used for account setup. Not doing this will slow down adoption and create major contention challenges because of overlapping IP address space.

Virtual networks and Virtual private clouds should be created as part of account creation with sane defaults based on company requirements and cloud best practices. Not including networking in standardized account creation is an anti-pattern.

Remember that cloud providers reserve around 5 IP-addresses in each subnet range for their own caching, metadata, DNS and other networking services.

Some cloud services require their own dedicated subnets and some services cannot live within your Virtual private cloud.

• Plan for non-overlapping IP address space across both cloud and on-premises well in advance

  • Use overlapping IP ranges for environment that shouldn’t have access to each other; ProjectAbc-Prod 10.0.0.1/24, ProjectAbc-Dev 10.0.0.1/24 for example

• Concider using IP6 instead of IP4

• Do not create larger networks than /23 if possible to ensure no unnessesary wastage of IP address space

DNS resolution

DNS will be critical for your cloud infrastructure. You will use it to identify, manage and discover resources in an automated fashion. It is good to concider on-prem connectivity early for DNS forwarding of specific zones. In some clouds you will also need to specify zones for public services when you are using private networking for your services, but this is being solved as we speak due to private link / private network connectivity to internal services within VPCs.

• Utilize the managed DNS solutions from the cloud providers for ease of use and automation

• Standardize naming so that you can programatically discover resorces

  • .accountalias.friendlydomain.tld.

• All services that can should have their own private DNS automatically registered on creation so that the underlying service can be easily replaced or upgraded

Back to Home