Lecture 3
Lecture 3
Designing Your
Environment
How do you choose a
region?
How Do You Choose a Region?
Does the region meet your environment’s data policy
and compliance requirements?
Do you meet data security laws of the country and
locality in which your data is stored?
Can your customer’s data legally exist outside of the
country where you are operating?
Will you be able to meet your governance
requirements by placing your environment in the
region where you plan to place it?
How Do You Choose a Region?
How close is the region to your users or data centers?
Most organizations choose an initial region closest to data
centers or customers, e.g.:
New York: US East (N. Virginia)
Netherlands: EU (Ireland) or EU (Frankfurt)
Philippines: Asia Pacific (Singapore)
Two equidistant regions to choose from? Consider which has
lower costs.
Proximity is a major reason behind choosing your
region, especially when latency is critically important,
as it is in most applications. In most cases, the latency
difference between using the closest region and the
farthest away region is relatively small, but even small
differences in latency can impact customer experience.
An internal study in 2006 found that for every
100-ms Amazon.com is delayed, there was a
corresponding 1% drop in sales. A Google
study in 2006 similarly found that a 500ms delay
for displaying their search results caused a 20%
drop in traffic and revenue.
How Do You Choose a Region?
Does the region you’re considering offer all of the
services and features your environment might require?
Not all services and features are available in all regions.
Although some services might not be available in your
region, typically you can still use those services within
your environment, but they may experience increased
latency.
New services typically launch in a limited number of
regions, with more regions added regularly.
How Do You Choose a Region?
Elastic load
balancer
AWS Region
Other Reasons to Use Two
Availability Zones
How many Availability Zones would be recommended for each scenario?
1. Applications heavily use Amazon EC2 Spot Instances:
• Two Availability Zones or more for more price options
2. Applications have data sources such as MySQL, MS SQL Server, and Oracle:
• Two Availability Zones to support active/passive
3. Applications have data sources such as Cassandra or MongoDB:
• Two Availability Zones or more for extremely high availability
Should you just fit everything
into one VPC?
Using One VPC
There are limited use cases where one VPC could be appropriate:
High-performance computing
Identity management
Small, single applications managed by one person or very small
team
For most use cases, there are two primary patterns for organizing
your infrastructure:
Multi-VPC and Multi-Account
AWS Infrastructure Patterns
VPC pattern
Shared Services Development Test Production
Amazon VPC Amazon VPC Amazon VPC Amazon VPC
Account
pattern Shared Services Development Test Production
AWS Account AWS Account AWS Account AWS Account
Choosing a Pattern
How do you know which pattern to use?
The primary factors for determining this are the complexity of your organization
and your workload isolation requirements:
10 . 0 . 0 . 0
00001010 00000000 00000000 00000000
10 . 0 . 255 .
00001010 255 11111111 11111111
00000000
IPs and CIDR (2 of 3)
The 16 in the CIDR notation example represents how many
of those bits are "locked down" and cannot change.
10 . 0 . 0 .
00001010 0 /16
00000000 00000000 00000000
16 bits
locked
IPs and CIDR (3 of 3)
10 . 0 . 0 .
00001010 0 /16
00000000 00000000 00000000
Highest 10 . 0 . 255 .
possible IP
00001010 255 11111111 11111111
00000000
VPCs and IP Addresses
AWS VPCs can use CIDR ranges between /16 and /28.
For every one step a CIDR range increases, the total number of IPs is cut in half:
Note: In every
subnet, the first four
and last one IP
addresses are
reserved for AWS
use.
How to Use Subnets
Internet gateways:
10.0.0.0/16
Allow communication between instances in
Internet
your VPC and the Internet. gateway
To enable access to or from the Internet for instances in a VPC subnet, you
must:
Attach an Internet gateway to your VPC.
Ensure that your subnet's route table points to the Internet gateway.
AWS Region
VPC Best Practices
VPC Considerations and Best
Choose CIDR blocks wisely. Plan ahead.
Practices
Use large subnets instead of a higher number of small subnets.
Use VPC Flow Logs to track and monitor your VPC traffic.
Check the health of your VPN link via API calls or the AWS Management Console.