+ All Categories
Home > Documents > Washington, D.C.d36cz9buwru1tt.cloudfront.net/145AB-1030-Laying-the... · 2013-09-09 · VPC vs....

Washington, D.C.d36cz9buwru1tt.cloudfront.net/145AB-1030-Laying-the... · 2013-09-09 · VPC vs....

Date post: 22-Jun-2020
Category:
Upload: others
View: 3 times
Download: 0 times
Share this document with a friend
16
2013 AWS Worldwide Public Sector Summit Washington, D.C. VPC Construction Nathan McCourtney Senior Consultant, Professional Services
Transcript

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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!

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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)

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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

2013 AWS Worldwide Public Sector Summit

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


Recommended