Quantcast
Channel: The Ravello Blog
Viewing all articles
Browse latest Browse all 333

8 ways how networking in AWS VPC differs from data-center

$
0
0

Advanced Enterprise Networking In AWS EC2 - A Hands On Guide

Public cloud is great. It brings to table agility, on-demand capacity, unlimited resources, global reach and most importantly ability to align costs with operational needs. More and more organizations are embracing cloud to augment their datacenter capacity or to move their existing workloads off their datacenters. As datacenter and network architects embark on this journey, they need to be aware that there are some inherent differences in the way networking works in an Amazon VPC when compared to datacenters – so that they can plan ahead.

  1. Broadcast & Multicast unsupported – Over the years, networking vendors have developed many cutting-edge features that rely on broadcast and multicast packets. Advanced functionality such as High Availability and clustering rely on broadcast packets (e.g. GARP, HSRP) for efficient failover. Since public cloud heavily filters broadcast and multicast packets, network architects need to rethink their deployment topology, or rely on other mechanisms to achieve similar objectives.
  2. No Bridge – Many sophisticated data-center setups require Layer 2 bridging for variety of business reasons – such as extending the application framework developed for a campus beyond its geographical area, workload mobility across zones etc. Public cloud doesn’t offer Layer 2 bridging capabilities, and while there are ways to ensure the same business objectives on public cloud, they all require one to re-architect the application and rely on Layer 3 protocols that offer a different scale of performance objectives than what is available in data-centers.
  3. Different appliances (and limitations) – One doesn’t have access to the same version of the network appliances (and hence the feature-set) that they are used to in datacenters on public cloud. Most network vendors have launched a version of their appliance on public cloud – but capabilities supported by the Amazon Machine Image or Google Compute Image of these appliances are typically ‘stunted’ compared to their data-center cousins.
  4. Limited number of Network Interfaces – Certain deployments (e.g. deploying a leaf-spine switching architecture) typically requires >20 NICs / VM. The number of NICs available per compute instance on public cloud may prove to be prohibitive forcing one to re-architect the deployment from scratch (e.g. ENIs supported by AWS vary between 2-8 depending on the instance).
  5. Single CIDR address block/VPC – AWS supports a single CIDR address block per VPC. Subnets within a VPC need to be addressed from this range. Default VPCs are assigned a CIDR range of 172.31.0.0/16 and subnets within are assigned /20 netblocks within the VPC CIDR range. If your existing datacenter based application topology uses multiple addressing ranges and different netmasks, you will need to reconfigure the setup before you can migrate it to a VPC.
  6. No replication of IP addresses – Datacenter admins have complete control of the network inside their DC, where they can create isolated networks that can run parallel copies of application with same IP address for pre-production testing. VPC doesn’t allow one to replicate IP addresses. An IP address assigned to a running instance in a VPC can only be used again by another instance once that original running instance is in a “terminated” state.
  7. No Span Ports / Port Mirroring – Many enterprises and security companies require span ports, or mirrored ports to tap the traffic on the wire for monitoring purposes. Due to lack of support for Layer 2 networking on public cloud, span ports is unsupported on AWS VPCs.
  8. Limited supported Gateway devices – AWS VPC does have a growing number of customer gateway devices that work with it, but the list is currently limited to seven vendors. If your organization doesn’t use one that is in the list, you will have to switch vendors to be able to support vendors.

Ravello is an overlay cloud that runs on top of AWS and Google cloud and overcomes the limitations mentioned above. Ravello’s networking overlay and nested virtualization technology enables organizations to run their existing data-center workloads and virtual appliances (same version as they have in DC) with complete Layer 2 capabilities on top of AWS and Google cloud – without modifying application, networking or configuration.

Interested in trying Ravello? Just open a Ravello trial account, and drop us a line.

The post 8 ways how networking in AWS VPC differs from data-center appeared first on The Ravello Blog.


Viewing all articles
Browse latest Browse all 333

Trending Articles