Setting up and understanding a VPC

Let’s dig into VPCs or Virtual Private Clouds. Essentially a VPC is a logical boundary, or essentially an encapsulated environment with no default ingress or egress. The thing with cloud is it’s so very network dependent but in AWS cloud everything is defaulted to no access. That’s why we use security groups, NATs, and Internet Gateways (IGWs). VPCs are the construct of how we draw a demarcation around services in a shared resource model. A VPC is a /28 to /16 netmask CiDR block at its core.

Ok that’s a lot of words so how does this look, well when you initially sign up for AWS and log in you are given a default VPC. This is great but not the best to use for building out your actual workloads. Therefor you will want to build a VPC but is just one VPC the answer? Well it depends on your needs and your architecture.

As I mentioned before a VPC is a set of IP addresses in a CiDR block, it is important when designing your VPC to ensure you have enough IP addresses to perform all of the functions that you are planning. Therefor you start with a /16 which gives you 254 /24 subnets. The best practice guidance is to use private IP space to create your VPC, as specified in RFC 1918.

10.0.0.0 – 10.255.255.255 (10/8 prefix)

172.16.0.0 – 172.31.255.255 (172.16/12 prefix)

192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

As mentioned this block of addresses will be carved into subnets with 5 IPs reserved for management activities (the first 4 and last 1 in the range).

x.x.x.0: Network address.

x.x.x.1: Reserved by AWS for the VPC router.

x.x.x.2: Reserved by AWS. The IP address of the DNS server is always the base of the VPC network range plus two; however, we also reserve the base of each subnet range plus two. For more information, seeAmazon DNS Server.

x.x.x.3: Reserved by AWS for future use.

x.x.x.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.

Subnets are restricted to a VPC and cannot span across VPCs. We can however create peering points between VPCs, and have a single VPC that peers to two VPCs that contain the same subnet, this could be useful in deployments where we want to reuse the same IPs for Test&Dev/Prod or Blue/Green. There are other variations of how and why to peer VPCs but let’s set that aside for a future post and just get our first VPC stood up.

screen-shot-2016-11-02-at-4-55-05-pmWe can do a custom build, but the AWS console has a sweet little VPC wizard we can use. Let’s use the Wizard cause why not.  So as you can see you have 4 options. We are going to select Option 2: a VPC with one public and one private subnet.

 

 

 

We select which AZs we want each of the subnets to sit in and determine if we want a NAT, screen-shot-2016-11-02-at-8-14-58-pmin this case I am choosing a NAT gateway instead of a NAT instance. There are several reasons to choose one over another, one of the main differences is a NAT gateway will auto-scale whereas a NAT instance screen-shot-2016-11-02-at-8-15-52-pmrequires a script for failover. Compare your options here.

 

 

screen-shot-2016-11-02-at-8-52-23-pmBy using the VPC wizard once it’s completed it’s set up our public subnet is also assigned an internet gateway. This means we now have external connectivity to our public subnet.
screen-shot-2016-11-02-at-8-56-44-pmWith that same setup the Private subnet is behind the NAT. We are ready to start building out our EC2 instances.

 

I highly recommend this video to understand VPC networking even further.


Next up we will discuss storage options in AWS. Feedback on if any of this is useful is helpful for me to make sure I am writing to the correct audience.

IAM quick and dirty

In our first post for VDM30in30 we touched on AWS terminology, today we are going to get into IAM since it is at the root of your AWS management. When you first create an AWS account you will set up the root account. It is imperative you lock this account down, for realzies this is not the account you want to use to do your day to day administration or to hand out to other users. It’s best practice to enable multi-factor authentication (MFA) on the root account there are several MFA options you can use find out more here.

IAM allows you to create users but wait there’s more, it also is the service that manages roles and access policies for users and service accounts. It’s also the spot where you perform your key creation for encryption, and tie in other Identity Providers like Active Directory.  screen-shot-2016-11-02-at-11-15-45-am

Policies set access levels to resources. There are predefined policies, you can use policy generator which allows you to select from a list or you can create your own policy from scratch via JSON.

Roles are assigned to users and used to assume policies. You can audit a role and it’s underlying policy and determine which policies are actually being used, which allows for a security practice of least privilege to be applied.  That’s something we talk about in the world of on-screen-shot-2016-11-02-at-11-16-47-amprem administration that is very rarely followed or implemented easily. Here it is just a click of a tab away and an administrator can see what is actually being accessed and make a determination if that role should be limited even further.

 

So that’s a quick and dirty on IAM, Roles and Policies. Stay tuned for the next #VDM30in30 post tomorrow. Hopefully this is useful to someone other than just my mind dump.

Back to Blogging: AWS Terminology

Shhh listen … no no stop talking and just listen. 

That’s the sound of a blog too long silenced being reawakened with a new and invigorated passion.

My focus has shifted from that of the world of virtualization to that of the world of cloud first. It truly feels like such a natural part of the evolution of technology and my career. I thought what better time to break out of my silence than with VDM30in30. This year we are going to focus less on the career and ephemeral and try and get into some AWS goodness. Nothing private or NDA will be shared with reInvent so close you can wait. But I want to share what I have learned and what I am doing.

Because language is important, terminology is the first thing we need to tackle so the rest of these posts make sense, I am going to give you a quick and dirty guide to AWS terms and how they map to what you may already know from VMware systems administration.

Region – a region is a geographic boundary that contains multiple availability zones (see availability zone), multiple regions can be used for DR\CooP scenarios beyond a multiple availability zone deployment. Regions are subject to distance & latency from each other.

Availability Zone (AZ) – an availability zone is a single or group of physical facilities that house AWS resources. AZ’s are highly available and low latency within a region. Applications and services can be used within a regions AZs to provide high availability and continuity of operations.

Virtual Private Cloud (VPC) – a VPC is essentially an isolation boundary for a customer’s AWS environment. VPC’s can be peered 1:1 but the communications are not transitive connections must exist in a hub spoke or lollipop design using direct connect. You will have a default VPC when you create your AWS account, don’t use this for your environment create a new VPC we will get into why in another post.

Instances – Instances are the cloud term for VMs and other services being used within the AWS environment. (ie – you are running an EC2 T2 Micro instance, or you have an instance of RDS running in multi-AZ mode)

Security Groups (SGs) – Security Groups are stateful firewalls. That’s really the best way to think of them and will save you headaches later if you wrap your head around this.

Services – Everything in AWS is a service presented by a series of API endpoints anything you can consume in AWS is a service.

EC2 Elastic Cloud Compute – This is the compute\vm environment there are multiple families that we will touch on in a later post

EBS Elastic Block Storage – Block storage for EC2 instances, can be shared across instances, set into RAID groups, snapshotted

S3 Simple Storage Service – Object storage that is HA across all AZ’s in which it is created

Lollipop network – a lollipop network is the term used for the way a direct connect environment uses the on-premises router to act as the VPC peering point, using VLAN abstractions to route the various subnets.

Reserved Instances (RIs) – a reserved instance is a billing construct where instance resources are reserved, leading to substantial savings.  There are two types of RIs there are Standard or Convertible. (not like the car) A Standard RI is purchased and tied to an AZ, whereas a convertible RI is tied to a region. For you VMware folks RIs are like Resource Pools used in vRA you can set the allocated resources for a tenant to consume and they are guaranteed those resources. On Demand instances land in AZs somewhat dependent on resources available, RIs of both types can and do block off resources for your account.  We will delve into this deeper in another blog.

Amazon Machine Images (AMIs) – <noun pronounced A-Meez or AM-eez depending on what part of the country you are from> –   These are like your VMware templates, they are base OS images or partner provided machine images like OVAs that you can easily deploy in your VPC.

Elastic Load Balancers (ELBs) – ELBs are used for load balancing applications and instances both inter and intra AZ.

Tags – This one is interesting tags are used in various ways both as instance names and as a way to indicate an instance is part of a group of machines performing a set function. Use tags often you can have a max of 50 tags per resource. The best practice is to tag for simplicity

Roles – roles assume policies

Policies – provide granular permissions to resources

Identity Access Manager (IAM) – This is the crux of the operation creating user and service accounts, managing policy and role access and securing resources. Root account, Federation and Multi-Factor Authentication are all managed via IAM.

Multi-Factor Authentication (MFA) – It’s not but it should be mandatory for root accounts and really any account that’s accessing the AWS console.

This should be a good start I am sure I will loop back and update this periodically as new services or terms come up and need explaining.