Yes, I know. When Hamlet holds the skull… It’s not the “To be or not to be” speech… but the one about Yorick. 🙂

Acknowledgment:

I’d like to thank Tim Hynes for reviewing this blog post and giving me valuable feedback. Tim is a fellow vExpert, he is @railroadmanuk on twitter and blogs at http://virtualbrakeman.wordpress.com/

The Conceptual Stuff

I was curious about Amazon options to use NAT inside the VPC construct, so I decide to do some research about its merits. Before I delve into the practicalities – here’s the whys and wherefores.

Amazon recommend a NAT configuration if you have Internet facing web-servers, with backend servers that they communicate to. That statement shows how much the AWS geared around “Web Services”, although it’s fair to say that most applications these days have web-based front-end, with an application server/database server back-end. The alternative to this NAT configuration is to merely have public/private subnets protected with Security Groups – with no NAT. In this setup a heavily secured “jumpbox” or “bastion” instance is used as the access point for those environments – this would be a very typical setup for a test/dev environment where only developers need access to whatever Amazon AWS is hosting…

To get a NAT system up and running you have two main options:

• “NAT Instance” – The NAT runs as just another instance amongst your other instances. You can use a number of different sized instances provided by Amazon.
• “NAT Gateway” – This service is configured in the VPC, and has features such as high availability, higher bandwidth capabilities, and less administrative overhead (this method is recommended by Amazon).

I found the NAT Instance method is very easy to setup, and the VPC wizard does a good job updating the VPC “Routing Tables” in order to make sure traffic flows in the right directions. You do however, have to update the Security Groups around the “NAT Instance” to allow it to send and receive traffic – just like any other instance really.

The NAT Gateway method is a tiny bit trickier to setup, and critically is not a Freeium service (remember neither is the NAT Instance really). With the NAT Gateway as you create it you associate it with one of the public subnets inside a VPC, and assign an Elastic IP to it. You do have to manually update the routing tables for the affected (or should that be afflicted?) subnets before traffic flows. The easiest thing is to setup the VPC first, so you can then attach the NAT Gateway to the appropriate public subnet. There are other ways (in terms of order of the process) to do this, but I found this easiest way and the most logical for my brain to wrap its head round. The NAT Gateway is created within a particular “Availability Zone” (AZ) and is implemented with redundancy in mind. And I think it’s for this reason that Amazon recommends it. The NAT Gateways availability is set by which Public Subnet its associated with – so it is possible to create more than one NAT Gateway associated with multiple public subnets in different AZ’s. This web page contains this statement:

“If you have resources in multiple Availability Zones and they share one NAT gateway, in the event that the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose Internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone.”

And here’s some other nuggets and facts worth highlighting:

• A NAT Gateway supports 10Gbps of bandwidth;
• You can’t swap out an elastic IP to an existing NAT Gateway – you have to destroy and re-create it to change the IP
• Although you can’t wrap a Security Group around NAT Gateway, it does support network ACLs to restrict the traffic it will pass
• Finally, NAT Gateway’s cannot be used with EC2 Classic-Link. However, this is really a legacy issue and would only impact on customers who have been using Amazon AWS for sometime.

The Practical Stuff

Read the rest of this entry »

VPC Peering is the way that two VPC’s with distinct CIDR spaces within the same REGION can be linked together. Whether you actually need to do this could be moot – but I can imagine a scenario where each VPC were different companies within in a holding group, or else you were using VPC’s on a departmental basis. You could still maintain separate “root” accounts for billing purposes, as VPC peering can be setup with multiple “root” AWS user accounts. For legal reasons the VPC’s might need to be separated, but they maybe “natural synergies” between companies within the same group or between departments where communication is desirable or needed.

Aside: You should normally be VERY worried when management uses the term “natural synergies”, as it is term that normally suggests two companies merging and job redundancies. Such are the euphemisms of modern employee relations!

Note: I found this Rackspace article useful especially as it outlined some of the limits around using VPC connections and some of the pitfalls of excessive VPC and VPC Peer Connections – https://blog.rackspace.com/vpc-peering-architecture-use-cases-guidance

There are two main “rules” around VPC Peer Connection in Amazon AWS. Firstly, The two VPC’s to be connected together must have own unique CIDR. It’s not possible to VPC Peer a VPC where they both have the same CIDR such as 10.0.x.y/16. Secondly, the VPC can be managed by the SAME Amazon “root” account or as I said a moment ago – DIFFERENT Amazon “root” accounts. If it different accounts the later then the two “root” administrators of the VPC’s would have to work together as credentials are needed on both sides.

I see this as being a lot like the “trust” relationships we used to make manually in the not so good old days of Windows NT4 (God, how that ages me!). However, if you of my generation you might remember that before “Active Directory” those trust relationships were not transitive. So just because VPC1 connects to VCP2 and VCP2 connects to VCP3, it does NOT follow that VCP1 can communicate to VCP3. So the VCP Peering Connections do not flow from one VPC seamlessly to another.

The VPC Peering wizard creates a “PCX” target that can be referenced in the routing tables to allow communication to pass from one VCP to another. When using the VCP wizard one side of the relationship between the VCP acts as the “Requester”, and the opposite side acts as the “Acceptor”. The communication is automatically two-way so there’s no need to create the VPC Peering Connection twice. If you making the VCP Peering Connection between two VCP under the SAME Amazon “root” account you merely select two different VPCs – as you are both the “requestor” and “acceptor” at the same time.

So in the screen grab below the “Requestor” is my VCP called “Prod” using 10.0.x.y./16 as the CIDR, and the “Acceptor” is my VCP called “Dev” with the CIDR of 10.1.x.y/16. The fields are completed by merely browsing the VPC metadata queried using the currently used “root” account.

Read the rest of this entry »

Note: Just to say this title is meant to be a humorous and silly pun. I actually think the Amazon wizards in the main are pretty good, and in fact pretty invaluable.

Acknowledgement: I’d like to thank vExpert, Jame Kilby for reviewing this blog post prior to publication. You can follow James on twitter at https://twitter.com/jameskilbynet and he blogs at https://www.jameskilby.co.uk/

In my previous blog post I was writing about how important planning stuff upfront in any cloud environment is. Not just because this is a good practice in system design, but because so many cloud environments are resistant to the kind of arbitrary ad-hoc SysAdmin changes, that could be so easily done to fix problem in an on-premises virtualization platform. In this post I’m turning my attention to something less high-fluting and more down in the weeds.

When I was working my through the PluralSight SysOps Admin training I was following the demo’s with my Amazon AWS Console open. Mainly playing “spot the differences”. Let me make something clear – the Pluralsight training is pretty good and an excellent foundation to getting stuck in and learning more. I believe it’s going to get harder and harder to keep ALL training materials up to date and current. Cloud environments are almost naturally more “agile” (hateful word – sorry I have thing against the way our industry brutalizes my native tongue). This means it’s really hard for training materials and guides to keep track. It’s partly the reason I’ve abandoned the whole step-by-step tutorials that I did in the past. I will leave that work to the big boys – like Amazon/Microsoft/Google as they have for more resources and time. But my plan was always to go back through my notes on the course (48 pages!) to both revises what I learned; inspire new blogging content – but also go back a research those differences I’d noted. I didn’t do that there and then whilst the video rolled. It would have slowed up my pace of the training. But now I feel I have the time to check those out.

To whit. Once thing I notice is when you create a VPC in Amazon AWS using the wizard you get some new options that the Pluralsight videos didn’t dwell or mention. Incidentally, as a rule I despise wizards, however in the context of Amazon AWS I would recommend them. They often automate many tasks, and thus meet certain dependencies – and speed up the process of setup (unless you decide to go down the scripting route). I think the key with the Amazon AWS wizard is understanding exactly what is being automated, and where those settings reside. This reduces the feeling that it’s the “Wizard of Oz” pulling strings behind a curtain, with you being clueless on what he’s up to. The other thing I would recommend is that if they’re 4 different routes through a wizard – go through it four times. The best way to learn a technology is to expose your self to the reality, rather than the theory. When I was an Microsoft Certified Trainer in the ‘90s, there was an awful lot of “you can do this configuration” but then it was never gone through. One way I expanded my knowledge at the time was actually trying these “theoretical configurations” – you certainly learned that often you can do something, its often comes with major dental work, to replace all the teeth you lost putting it together…

So… less pre-amble, more amble. Here’s a screengrab of the VPC wizard from PluralSight…

Read the rest of this entry »

Acknowledgement: I’d like to thank fellow vExpert, Ed Grigson for proofing this and giving me valuable feedback. Help inspire a better conclusion than this piece originally had. You can find Ed’ own blog here, and he also tweets!

http://www.vexperienced.co.uk

https://twitter.com/egrigson

One thing I’ve learned pretty quickly using Amazon AWS, whilst following the PluralSight SysOps Admin course, is how resistant to changes the platform is. Now, this shouldn’t really come to a surprise to anyone who has interfaced with a virtualization layer, as mediated through a cloud UI. As I’ve said in previous posts – the layer of abstraction added by cloud means a great deal of the knobs and buttons you’re used to as a virtualization admin are by necessity redacted and not exposed. Remember, you’re meant to be the Little Happy Consumers of the Cloud now.

We’re all used to the experience where “dependencies” between one service or object prevents our arbitrary and ad-hoc administration changes which haven’t properly thought through. So it becomes impossible to change the “D” setting because of restrictions upstream in A, B, and C or without it affecting downstream dependencies in E, F, and G. I can pretty much live with this – although that does mean you do REALLY, REALLY need to think things through before you start creating stuff.

This is why I think a cloud architect is probably more valuable or useful to an organization than a SysOps Admin. However, I think where you learn the consequence of not architecting or pre-planning your development is leaping in as a SysOps Admin creating/changing stuff and then having to deal with the often painful consequences. Often the best lessons are learnt the hard way after all.

What I would say is this is a serious consideration often extends itself to even some of the most trivial of admin tasks which you would assume would be unrestricted. I don’t intend this as a criticism of Amazon AWS as such, but an observation that much public and private cloud solutions behave in precisely the same way, but some are more “restrictive” about this than others. For instance:

Read the rest of this entry »