|By Brian McCallion||
|October 20, 2013 11:12 PM EDT||
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...]
Apr. 29, 2016 05:45 AM EDT Reads: 2,394
Apr. 29, 2016 04:45 AM EDT Reads: 2,341
Apr. 28, 2016 07:00 PM EDT Reads: 1,468
Apr. 28, 2016 04:45 PM EDT Reads: 1,732
Apr. 28, 2016 04:30 PM EDT Reads: 1,620
Apr. 28, 2016 02:45 PM EDT Reads: 1,363
Apr. 28, 2016 02:30 PM EDT Reads: 1,555
Apr. 28, 2016 01:15 PM EDT Reads: 1,088
Apr. 28, 2016 01:00 PM EDT Reads: 1,505
Apr. 28, 2016 12:45 PM EDT Reads: 1,455
Apr. 28, 2016 12:15 PM EDT Reads: 1,605
Apr. 28, 2016 12:00 PM EDT Reads: 536
Apr. 28, 2016 11:30 AM EDT Reads: 2,177
Apr. 28, 2016 11:00 AM EDT Reads: 1,395
Apr. 28, 2016 10:30 AM EDT Reads: 532
Apr. 28, 2016 10:15 AM EDT Reads: 939
Apr. 28, 2016 10:00 AM EDT Reads: 718
Apr. 28, 2016 10:00 AM EDT Reads: 680
Apr. 28, 2016 09:30 AM EDT Reads: 2,499
The IETF draft standard for M2M certificates is a security solution specifically designed for the demanding needs of IoT/M2M applications. In his session at @ThingsExpo, Brian Romansky, VP of Strategic Technology at TrustPoint Innovation, will explain how M2M certificates can efficiently enable confidentiality, integrity, and authenticity on highly constrained devices.
Apr. 28, 2016 09:00 AM EDT Reads: 943