washington, d.c.d36cz9buwru1tt.cloudfront.net/145ab-1030-laying-the... · 2013-09-09 · vpc vs....

2013 AWS Worldwide Public Sector Summit Washington, D.C.

VPC Construction

Nathan McCourtney

Senior Consultant, Professional Services

2013 AWS Worldwide Public Sector Summit

What is a Amazon Virtual Private Cloud (VPC)?

• “A virtual private cloud (VPC) is a virtual network that closely resembles a

traditional network that you'd operate in your own data center” – AWS VPC

Getting Started Guide

• “Resembles” does not mean “identical”

• Let’s examine some of the best practices for VPC


VPC vs. EC2 Classic

• Original recipe Amazon EC2 was a huge, flat address space in which all hosts

could route to one another

– Security Groups are the means to control network flows

• Amazon VPC closes off your instances into private non-routable address

spaces

– Adds a variety of mechanisms to control network flows


Basic Moving Parts

• The VPC itself (it’s a thing)

• The Subnets within it

• The Route Tables that point traffic toward the exits

• The Gateways that allow traffic into and out of the VPC

• The Security Groups – stateful firewalls dynamically bound to instances

• The Network ACLs – stateless firewalls bound to subnets


Subnetting from a High Level

• Traditional switching concerns don’t apply

• No ARP or other broadcast limitations to worry about

• Putting thousands of nodes in a subnet is no problem

• Don’t over-use subnets given variety of other control mechanisms

– E.g., fewer subnets = more address space available to handle dynamic

workloads


Subnetting from a High Level (continued)

• Reasons to make a new subnet:

– Traffic needs to route differently

• E.g., Public vs. Private

• Route Tables are bound to subnets

– To distribute address space across multiple AZs

• Subnets are AZ-specific

– Belt-and-suspenders flow control with NACLs

• NACLs are bound to subnets

• But Security Groups usually easier and more flexible


Subnetting: Don’t Forget

• Divide your address space equally across AZ’s, then subdivide

those AZ-level blocks into subnets

– Result should be symmetrical (same number, same size) subnets

across every AZ in region

– Multi-AZ is mandatory for high availability

• Leave yourself unassigned address space within each AZ for

things that might come up later

– Trust me on this one!


Routing in a VPC

• All hosts within a VPC can route to all other hosts within that VPC. Period

• The only routes you need to worry about defining are for leaving the VPC

(generally speaking)

– Internet through the Internet Gateway (IGW)

– Your premises via IPSec Virtual Gateway (VGW)

– NAT’ing traffic through a NAT instance

– Host-level routing can override VPC routes in certain edge cases

• Hosts that don’t have a route out via one of those methods cannot reach the

outside world


Route Tables

• Have a One-to-Many relationship with Subnets

– i.e., one route table can serve many subnets, but subnets have only one route table

• Use CIDR notation (’0.0.0.0/0’) to define routes and Elastic Network Interfaces

(ENIs) or Gateways (IGW, CGW) to define the next hop

• Unless you go out of your way to override it, host-based routing is overruled by

the VPC routes

– Source and Destination is checked on every packet (can be disabled)

– No central chokepoints caused by “routing”; packets pass through a routing

emulation layer that actually picks each packet up and drops it off at the destination


NAT Instances

• If a host does not both have an EIP and reside in a subnet with a route through

an IGW, it must send its Internet traffic to a NAT instance

• NAT instances are themselves residing in a public subnet with an EIP. They

obey the same rules as all other instances

• Elastic IP’s (EIP) are one-to-one static NATs to instance private Ips

• NAT instances represent a Global (subnet or larger) NAT of a port-address-

translation variety (NAT/PAT)


VPC Security Groups

• As mentioned: dynamic, stateful firewalls

• If you define an ingress rule, it’s smart enough to allow the response to egress

(and vice versa)

• Security Groups (SGs) can operate inside any subnet and across any AZ; they

are completely orthogonal to routing and subnet NACLs

• SGs are can be applied and removed from VPC-based instances at any time;

multiple SGs per instance are allowed

• SGs rules can reference not only CIDRs and ports numbers but also other SGs

• SGs can be applied to AutoScaling Groups, allowing for a powerful and simple

framework for enforcing firewalling across all application tiers


Using Security Groups Effectively

• SG rulesets are allow-only; should be normalized to create building blocks that

can then be combined on instances at runtime

• For example:

– WebSG – Allow Port 80

– AdminSG – Allow Port 22

– DBSG – Allow port 3306 from WebSG

– Two Hosts: Web Server in WebSG and AdminSG; DB Server in DBSG and AdminSG

– Changes to AdminSG can be made in one place

• Note how SGs can permit traffic from other SGs – use that feature for internal

rules

– Except in rare cases, SG’s shouldn’t be defined using CIDRs from the VPC-internal

address space


Network ACLs

• Stateless firewalls protecting subnets

• Rules written in traditional notation (CIDR/port)

• One-to-many relationship with subnets (one NACL can manage many subnets,

but each subnet can only have one NACL)

• If you define ingress, you have to manually configure all possible egress ports

(and vice versa)

– E.g., all ephemeral ports to which traffic returns; that makes them tricky!

• Specific to subnets, so you can’t tie them to ASG’s directly

• Useful for separation-of-concerns model of security, but should be used

sparingly


Security Groups vs. NACLs: Keep it Simple

• Excessive NACL and Security Group use exponentially increases the

complexity of a VPC with limited or no benefit

• Use Security Groups as much as possible; more dynamic, flexible and easier to

understand behavior

• If you need to use NACLs, set some broad rules at the beginning and then

leave them alone; don’t use for fine-grained flow control

• Too much complexity leads to difficulty of change; which leads to

operational instability


AWS – Inside the VPC

• Some AWS services provision resources inside your VPC

– Amazon ELB

– Amazon RDS

– Amazon ElastiCache

– Amazon Elastic MapReduce

– Etc.

• Others Do Not

– Amazon S3

– Amazon SQS

– Amazon DynamoDB

– Etc.

• For your hosts to reach those AWS services, they must be set up to route out as though they were calling any other web service

Thank You

washington, d.c.d36cz9buwru1tt.cloudfront.net/145ab-1030-laying-the... · 2013-09-09 · vpc vs....

Documents