Accessing an EC2 instance with RDP when deployed to a VPC

My Amazon experiments are coming along but I’ve had to step back from some of my ambitious plans to cover key workloads like DR and HA to focus on the AWS foundations first. Things like virtual networks or what Amazon calls VPC. Up until now most of what I’ve done has been simple provisioning and accessing of an instance. Things stay pretty easy in that mode. For example I had deployed at least a half dozen EC2 instances into what they call EC2-Classic which just means you’re dropping it into a canned tenant specific network and you don’t really need to configure the subnets or IP addresses or DHCP or wire up access to the internet.  There is also all the wizards in the AWS management portal that just setup things like an RDP security group to the EC2 instance you want to access.

downloadAs a side note I also discovered an important factor in my AWS research. This stuff costs money … shocking right 🙂 So I have decided that I’m willing to spend about $50 a month on this stuff and I went and setup billing alerts on my AWS account to email me the minute I hit that $50 mark. Pretty cool right …  I will say there is a lot of visibility into the usage in Azure for MSDN accounts which is nice. You can clearly see how much of your overall allotment ($150 for Ultimate and $100 for Pro) remains and the days you have left to consume it. I look forward to the day that same thing translates to full Azure subscriptions that are somehow governed by budget settings configured by enterprise administrators. There are some 3rd party tools making that possible today for both AWS and Azure but I want it native and the closest thing I have in either platform is an alerting system in AWS.

That’s a lot of words to just say that I decided to stop being lame and doing the intro level setup stuff and configure a VPC the same way I would a Virtual Network in Azure. So off I went and I started with a simple VPC. First good news I got was that this doesn’t cost me anything and I tracked down the section in the AWS environment easy peasy. You go to click on “VPC” and then click “Create VPC” and here is what you see.


Ok this is pretty simple but first thing that jumped out at me was the Tenancy drop down. If that were opened up you’d see “Default” or “Dedicated”. With dedicated you are informed that this will be on single tenant hardware but there are additional charges. You get a $2 per hour tax for this privilege and you pay more for each instance. Makes sense, nice option if you are not comfortable running next to anyone but sort of a silly fear in a mult-tenant cloud where underlying resources are all shared (firewalls, load balancers, storage subsystem, etc..). The other thing that was different for me from the Azure world was this forced CIDR block system. I’m just s dumb developer I have never had to worry about this magic system of slash something to define the subnet mask that gives me an idea of what IP addresses are available.

download (1)

Well guess what … I had a cool “a ha” moment with this one and I can’t believe it took me this long to figure this out. There are really only three key CIDR ranges you need to know. They are /24, /16, and /8. Why is that, well it’s because they represent the main digits of the subnet mask and will give you 256 addresses for every number you subtract. So a /24 is just two full ranges of 256. When you get to /16 it ends up being 256 * 256 for a total of 65,536 addresses and then if I remove one to /15 then I have two full ranges of that. I am pretty sure some professor showed me this in college since it’s all numbers and I literally took a math programming track but I’m sure I was either dozing off or hung over.

Ok now that I’m a CIDR expert I should have no problem creating Subnets. I will say I am kind of surprised you can’t label these VPCs to make it easier to select them later on when deploying an instance but it’s probably not a big deal since the IP address scheme will be something I am using to drive the deployments. I also had to decide if I wanted to let Amazon handle DNS resolution and DNS host name creation. Apparently my only option here is to use Amazon or create what is called a DHCP option set which specifies how I want to manage DNS myself. I’ll stick with the Amazon stuff for now since I’m not looking to run up my bill just to do DNS. And now we’re onto adding subnets. This wasn’t part of the VPC creation you have to jump to a new “Subnet” section in the console. No biggie, “Create Subnet” Go.


So here you can see that I can choose from a list of previously built VPCs and then I get to start defining a subnet that is within that range. Good thing I mastered that CIDR notation because I am sure I would screw this up if I didn’t understand how to set the starting address after a subnet range is added here. Also notice the availability zone option. This is unique to AWS and actually takes the region (East US/West US/etc..) and subdivides it into three sub region datacenters. Very nice way to provide resiliency beyond the internal server clusters. Now I was only able to pick between the three east availability zones and it turns out that was because I provisioned the VPC in the east region by selecting that region before I started creating it. This is a little less than obvious actually because I never told the VPC to be in the east region but I was defaulted to that in the console because that was what I had chosen in the top right corner (or at least that is what was set originally because I had no idea).

imagesAnother important factor here is the ability to create subnets that are in different availability zones to allow for snap-shotting and HA configurations beyond one AZ. See this is where I really needed to focus before I could start looking at HA and DR scenarios. Without these foundations I am basically clueless as to how it all works and is setup. So I went ahead and created a few subnets and as I did that i noticed I had the option to specify Network ACLs for each individual subnet. The default basically allows everything straight through but I could do some nice lock down work here if I wanted a private subnet. That’s only the start though I also have route tables and security groups to jump into. This is some crazy tight control you can have but any Network admin I’ve met is a borderline control freak so this probably works nicely. With Azure today there are inbound ACLs but only on the edge so this is clearly an area where our platform has some catching up to do.

By the way, I’ll mention this again, when you deploy into EC2-Classic you don’t encounter any of this stuff. I thought I was a bad ass when I could deploy and RDP into an instance in no time at all but this stuff all started to become real complex real fast. Lots of layering and I haven’t even gotten to the part where I was completely stuck. I basically knew I couldn’t RDP into my instance yet so I went and did a little google searching and found the AWS instructions for setting up a Security group. That was actually straight forward and FWIW I realized something important here too. You can only control inbound and outbound flow if you are on a VPC. I had always wondered why the security groups on my EC2 instance only had inbound because I knew AWS had outbound control. That’s the key, you need to use  VPC to get access to more advanced controls like that. So I went to security groups and added one and you can see I have to pick with VPC I am adding this to. Remember what I mentioned before, it sure would be nice if these labels weren’t so cryptic.

CreateSecurityGroupOnce created the subnet can be updated to include additional rules for how flow can come into our out of the VPC. So of course I added 3389 to flow in (AWS has a nice feature to plug in your current IP address in /32 CIDR notation if you don’t want it open to the world). And I honestly thought I was pretty much done. My experiences in Windows Azure gave me a little false confidence that I had setup everything and exposed access in a logical way similar to an endpoint on our Azure firewall. Oh how wrong I was. The next thing I did was jump over to EC2 and deploy an instance into one of the subnets on that VPC and waited the 5 minutes or so for it to launch and tried to connect. FAIL #1

download (2)Back to the internet for some searching, I do have to say there is an abundance of information out there and the documentation AWS produces is very good. I realized that I absolutely screwed up by not creating an Elastic IP and associating that with my EC2 instance. Without a public address there was no way I would be able to access the instance from the internet. Then I also realized that I hadn’t deployed this thing called an internet gateway. What the hell is that? So I read about it a bit and it’s a key component to wire up the VPC to the outside world. You have to make an intentional deployment choice to start making anything accessible over the internet. Confusing … nice … but confusing for this dumb developer. So I must be ready now … I must have everything setup now right. Nope, still get no connection over RDP. FAIL #2

Now this was a good hour or so of head scratching before I finally found some good information. I actually went back and deployed an EC2 instance into classic to prove that I could even connect from my home network. The key missing element was a wire up step that took the internet gateway using a custom route table and set an association to my subnet. That did the trick! I was able to access my instance via RDP and holy crap I could control and block it in like 20 different ways. This is complex but after spending the last year and half talking to network specialists I understand why these things exist.

So just to recap, in order to setup an EC2 windows instance (linux as well just do SSH instead of RDP) that you can access remotely on a custom VPC you have to do the following:

  1. Create a VPC with a CIDR range that has private IPs you want to use. Use AWS for DNS and host name resolution or bring your own.
  2. Create Subnets and associate those with your VPC
  3. Create an EC2 instance and deploy that to your VPC
  4. Create an ElasticIP and associate that with your instance. (FYI, you can create multiple vNICs and multiple Elastic IPs and host multiple paths into your node … very nice)
  5. Create a Security Group and associate that with your VPC
  6. Create an internet gateway
  7. Create a custom route table and add an association to your subnet and the internet gateway.
  8. Pound your chest if you’re a developer and you just figured out how to configure an advanced software defined network 🙂

download (3)

So what’s next for me, I think I’ll be doing either some cloud formations experiments or identity and access management . Both are very interesting and I’ve been watching a ton of youtube videos on them. Role based access for all AWS resources is very cool but cloud formations and JSON templates to drive multi node deployments is kind of hitting me in the developer nerve. That said, IAM is free and I may not have a ton of dollars left in February if I’m going to stay under $50.

This entry was posted in AWS, Cloud Computing, IaaS, Virtual Networking. Bookmark the permalink.

One Response to Accessing an EC2 instance with RDP when deployed to a VPC

  1. Matthew says:

    Could you please mention what tools are available for Azure regular accounts to manage billing? I don’t know of any paid services available yet that shut down VMs or turn off your account for you (like the MSDN or free trial does), would love to know if there is.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s