Welcome!

Websphere Authors: Yeshim Deniz, Roger Strukhoff, Liz McMillan, Rajiv V. Joshi, Bruce W. McGaughy

Blog Feed Post

First of Five Enterprise Lessons Learned in the AWS Virtual Private Cloud

Public Cloud is cool and it's the only kind of Cloud my company works with. Yet enterprise financial services firms and others require controlled access. And in 2013 AWS not only won the contract to build an actual Private Cloud for the CIA (any further legal maneuvers from IBM notwithstanding), but AWS also seems to have conceded that Virtual Private Cloud is a first class AWS Cloud offering. It's not that VPC was ignored, it's just than in 2011 and most of 2012 new capabilities of the Oracle Relational Database Service (RDS) were available first in EC2, then VPC. The customers we work with require AWS VPC. In this post and four more to follow, I'm taking note of some of the lessons learned working with VPC in the hope that I may entertain if not educate.

Some Opening Remarks on Enterprise and VPC
Networking is hard. And to define a VPC you need to have more than a passing knowledge of networks. I'm not an expert, however I've spent a lot of time reading about and configuring VPCs and I'm still learning.

Defining the VPC
When you define a VPC you get one chance to define the CIDR Block, or IP space. They're free, and it's very likely you will provision or at least define many VPCs if you work in the Enterprise Cloud space.  Although the VPC is free, if you need to change it, the only way to do so is to delete it and recreate it, or create a new VPC with the CIDR range you need, and then migrate your instances and certain other stuff to the new VPC. It's a lot of work and if you're working in a corporate environment leery of automation, people will really scream and moan when they find out stuff needs to change. Then they get angry and show up with torches and pitchforks like the angry villagers in a Frankenstein movie.

On the one hand you can say: "Welcome to the Cloud, my friends, wait until we have a real problem before you set this place on fire or poke each other with those sharp sticks, " but enterprise journey to Cloud offers many opportunities to tease people and for now it's easier for you to set aside this sort of early delectable brush with enterprise IT culture for a later point in time. At this stage you're the one waiting because you have no VPC and you can't build much until you get it up and running.

First Lesson(s) Learned (they were more or less clustered together, but I'll count them as One)
Choose a CIDR Block that is significantly larger than your network team will offer you. Choose is a loaded word in the enterprise. Likely somebody else will choose for you, or will see your request and decide that there's a better way. Your request for a /21 network will likely be met with disbelief and in the name of saving string somebody will quickly alter the request to a mostly useful /24.

Lots of People in the Enterprise Are Eager to Selectively Review and Even Alter Your Solution Design
At first glance people not familiar with AWS will simply try to determine how many serves a given business segment or application will deploy. Even though the IP addresses are free and there are a lot of them, datacenter network teams try to avoid issues like address ranges that overlap with those of business partners, and a dark day when perhaps internal IP addresses will be scarce.

Explain to them that you need a lot more IP space that at first glance may be required. Each VPC availability zone requires a separate subnet in order for instances or services like RDS to be able to run in those subnets. RDS for example requires a group of subnets, and requires more than just one. If you only have a single subnet, you won't be able to run RDS.

ELB in a VPC Requires Public IP Subnets
In 2012 for most of the year the AWS Elastic Load Balancer (ELB) required a minimum sized subnet in each availability zone where it would "run." The reason is that ELB, even though its a service, actually runs instances. Those instances require ip addresses in each public subnet of each availability zone in a VPC. In 2012 the minimum for a public facing ELB was something like 104 ip addresses per public subnet per availability zone. So for me that meant three availability zones at a minimum of 104 ip addresses per subnet. A kind soul who had looked over my solution wisely concluded that based on the number of expected instances, I only needed around 250 ip addresses in the CIDR range. Yet even after defining the public subnets, I still needed subnets for the remainder. In any event, we had to ask for a new VPC and this and that and it was a really big headache. So now you know. Today the public ELB doesn't require as many IP addresses. However keep in mind that the word Elastic, in the acronym ELB implies expanding and contracting. And also, if you're using ELB the only other instance type I would conceivably place in the public subnet is a NAT instance. Everything else can be placed in private subnets. And nothing other than the NAT instances should be competing with the ELB for ip addresses in any of the public subnets.

[Stay tuned for Second Lesson Learned to be published later this week...]

Read the original blog entry...

More Stories By Brian McCallion

Brian McCallion, founder of New York City-based consultancy Bronze Drum focuses on the unique challenges of Public Cloud adoption in the Fortune 500. Forged along the fault line of Corporate IT and line of business meet, Brian successfully delivers successful enterprise public cloud solutions that matter to the business. In 2011, while the Cloud was just a gleam in the eye of most Fortune 500 firms Brian designed and proved the often referenced hybrid cloud architecture that enabled McGraw-Hill Education to scale the web and application layer of its $160M revenue, 2M user higher education platform in Amazon Web Services. Brian recently designed and delivered the JD Power and Associates strategic customer facing Next Generation Content Platform, an Alfresco Content Management solution supported by a substantial data warehouse and data mart running in AWS and a batch job that processes over 500M records daily in RDS Oracle.”