AWS & Cloud Networking Design Patterns

AWS Networking Wizard

I attended a session at AWS re:Invent titled “Planning for your advanced AWS networking architectures” that was held by Matt Lehwess and Nick Matthews, who were rightfully dressed as networking wizards.

Without going into the details of the presentation, I have a few “meta” comments:

It’s so easy to set up networking in a public clouds (you set up VPCs and elastic load balancers without the need to purchase and configure hardware) that we are tempted to experiment with different architectures to see what happens.

However, one needs to still plan appropriately. There are several issues that cannot be ignored.

  1. Limits to be aware of. Cloud computing deployments are inherently elastic, so it’s tempting to believe that all aspects of networking are also equally elastic. It is certainly more flexible than physical deployment, but it’s not infinite. There are published limits, such as IP addresses per network, interface per instance type, or virtual interfaces per AWS Direct Connect connection, that one needs to adhere to. Be aware of them.
  2. Being open to third party networking solutions. Products designed for cloud use, such as Cisco Cloud Services Router 1000V Series, Juniper vMX 3D Universal Edge Router, or Aviatrix’s Cloud InterConnect for VPCs, fill in what AWS does not natively provide adequately, or provide the compatibility you need for complex environments.
  3. Software, not hardware. As flexible as software-based solutions are, they're a double-edged sword. There are cases where having software means that there may be performance limits if there is no dedicated networking hardware involved. On the other hand, software implementations also mean that soft limits may be increased upon request! An example of this is the number of virtual private gateways per Direct Connect gateway.
  4. Monitoring for service levels. It’s traditionally been difficult to monitor performance and service assurance levels in public clouds. This is starting to change, as firms like NETSCOUT provide cloud editions of their solutions such as nGeniusONE that will run in the cloud, and assist in an on-premises to cloud migration project.

What does this mean for practitioners? Follow good design patterns. It’s tempting to try to experiment endlessly, or try to force fit a design into your architecture, only to realize it’s brittle or not scalable. There are active forums, best practices published, and even real-live solution architects from AWS who can help customers. The challenge is that the world of cloud networking is evolving rapidly, so a best practice document published a year ago may have become out of date. But this should not discourage you. Changes are a sign of progress and many limitations are being overcome. Thus, it’s good to use a design pattern that can evolve into the future.

Topics: Networking AWS re:Invent Cloud Services & Orchestration