AWS’ New Networking Capabilities – Sucking Less ;)
I still haven’t had my coffee and this is far from being complete analysis, but it’s pretty darned exciting…
One of the biggest challenges facing public Infrastructure-as-a-Service cloud providers has been balancing the flexibility and control of datacenter networking capabilities against that present in traditional data center environments.
I’m not talking about complex L2/L3 configurations or converged data/storage networking topologies; I’m speaking of basic addressing and edge functionality (routing, VPN, firewall, etc.) Furthermore, interconnecting public cloud compute/storage resources in a ‘private, non-Internet facing role) to a corporate datacenter has been less than easy.
Today Jeff Barr ahsploded another of his famous blog announcements which goes a long way solving not only these two issues, but clearly puts AWS on-track for continuing to press VMware on the overlay networking capabilities present in their vCloud Director vShield Edge/App model.
The press release (and Jeff’s blog) were a little confusing because they really focus on VPC, but the reality is that this runs much, much deeper.
I rather liked Shlomo Swidler’s response to that same comment to me on Twitter 🙂
This announcement is fundamentally about the underlying networking capabilities of EC2:
Today we are releasing a set of features that expand the power and value of the Virtual Private Cloud. You can think of this new collection of features as virtual networking for Amazon EC2. While I would hate to be innocently accused of hyperbole, I do think that today’s release legitimately qualifies as massive, one that may very well change that way that you think about EC2 and how it can be put to use in your environment.
The features include:
- A new VPC Wizard to streamline the setup process for a new VPC.
- Full control of network topology including subnets and routing.
- Access controls at the subnet and instance level, including rules for outbound traffic.
- Internet access via an Internet Gateway.
- Elastic IP Addresses for EC2 instances within a VPC.
- Support for Network Address Translation (NAT).
- Option to create a VPC that does not have a VPC connection.
You can now create a network topology in the AWS cloud that closely resembles the one in your physical data center including public, private, and DMZ subnets. Instead of dealing with cables, routers, and switches you can design and instantiate your network programmatically. You can use the AWS Management Console (including a slick new wizard), the command line tools, or the APIs. This means that you could store your entire network layout in abstract form, and then realize it on demand.
That’s pretty bad-ass and goes along way toward giving enterprises a not-so-gentle kick in the butt regarding getting over the lack of network provisioning flexibility. This will also shine whcn combined with the VMDK import capabilities — which are albeit limited today from a preservation of networking configuration. Check out Christian Reilly’s great post “AWS – A Wonka Surprise” regarding how the VMDK-Import and overlay networking elements collide. This gets right to the heart of what we were discussing.
Granted, I have not dug deeply into the routing capabilities (support for dynamic protocols, multiple next-hop gateways, etc.) or how this maps (if at all) to VLAN configurations and Shlomo did comment that there are limitations around VPC today that are pretty significant: “AWS VPC gotcha: No RDS, no ELB, no Route 53 in a VPC and “AWS VPC gotcha: multicast and broadcast still doesn’t work inside a VPC,” and “No Spot Instances, no Tiny Instances (t1.micro), and no Cluster Compute Instances (cc1.*)” but it’s an awesome first step that goes toward answering my pleas that I highlighted in my blog titled “Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye”
Thank you, Santa. 🙂
On Twitter, Dan Glass’ assessment was concise, more circumspect and slightly less enthusiastic — though I’m not exactly sure I’d describe my reaction as that bordering on fanboi:
…to which I responded that clearly there is room for improvement in L3+ and security. I expect we’ll see some 😉
In the long term, regardless of how this was framed from an announcement perspective, AWS’ VPC as a standalone “offer” should just go away – it will just become another networking configuration option.
While many of these capabilities are basic in nature, it just shows that AWS is paying attention to the fact that if it wants enterprise business, it’s going to have to start offering service capabilities that make the transition to their platforms more like what enterprises are used to using.
Great first step.
Now, about security…while outbound filtering via ACLs is cool and all…call me.
/Hoff
P.S. As you’ll likely see emerging in the comments, there are other interesting solutions to this overlay networking/connectivity solution – CohesiveF/T and CloudSwitch come to mind…
Related articles
- AWS – A Wonka Surprise ? (cloudave.com)
- The Benefits of a Virtualized Approach to Advanced-Level Network Services (blogs.cisco.com)
- VMware on Amazon Web Services or How the Cloud Becomes a Data Fabric (readwriteweb.com)
- CloudSwitch: Traitor To the [Public Cloud] Cause… (rationalsurvivability.com)
- CloudPassage & Why Guest-Based Footprints Matter Even More For Cloud Security (rationalsurvivability.com)
- Revisiting Virtualization & Cloud Stack Security – Back to the Future (Baked In Or Bolted On?) (rationalsurvivability.com)
- How VMware Differs from Amazon Web Services in its Approach to Importing Virtual Machines (readwriteweb.com)
- Amazon Launches CloudFormation To Simplify App Deployment (informationweek.com)
Recent Comments