0% found this document useful (0 votes)
19 views

Lecture 3

Uploaded by

Karai Nava
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views

Lecture 3

Uploaded by

Karai Nava
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 35

Cloud Computing

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?

 Are you choosing the most cost-effective


region?
 Service costs vary by region.
 Some services (like Amazon S3) have costs
when you transfer data out of their original
region.
 If you want to replicate your environment
across more than one region, is that the most
cost-effective solution?
How many Availability Zones
should you use?
How Many Availability Zones
Should I Use?

 Recommendation: Start with two Availability Zones


per region.
 Best practice: If resources in one Availability Zone are
unreachable, your application shouldn't fail.
 Most applications can support two Availability Zones.
 Using more than two Availability Zones for HA is not
usually cost-effective.
Using Two Availability Zones
Internet
gateway

Elastic load
balancer

Web Web Public


Public
server server Subnet 2
Subnet 1

Availability Zone 1 Availability Zone 2

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:

 Single IT team? Multi-VPC

 Large organization with many IT teams? Multi-account

 High workload isolation required? Multi-account


Multi-VPC Pattern
 Features:
 Uses one AWS Account
 Uses two or more VPCs to organize application environments
 Best suited for:
 Single team or single organizations, such as Managed Service Providers
 Why?
 Limited teams make maintaining standards and managing access far easier.
 Exception:
 Governance and compliance standards may require workload isolation
regardless of organizational complexity.
Multi-Account Pattern
 Features:
 Uses two or more AWS accounts to organize application environments
 Uses one VPC per AWS account
 Best suited for:
 Large organizations and organizations with multiple IT teams, such as
Enterprise-level corporations or government agencies
 Medium-sized organizations that anticipate rapid growth
 Why?
 Managing access and standards can be more challenging in more complex
organizations.
How should you divide your
VPCs into subnets?
VPCs and IP Addresses
 When you create your VPC, you specify its set of IP addresses with
CIDR notation.

 Classless Inter-Domain Routing (CIDR) notation is a simplified way to


show a specific range of IP addresses.

 Example: 10.0.0.0/16 = all IPs from 10.0.0.0 to 10.0.255.255

 How does that work? What does the 16 define?


IPs and CIDR (1 of 3)
 Every set of 3 digits in an IP address represents a set of 8 binary values (8 bits).

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

 The unlocked bits can change between 1 and


0, allowing the full range of possible values.
CIDR Example: 10.0.0.0/16
 Lowest
possible IP 10 . 0 . 0 . 0
00001010 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:

CIDR / Total IPs


/16 /17 /18 /19 /20 /21 /22
65,53 32,76 16,38 8,192 4,096 2,048 1,024
6 8 4
/23 /24 /25 /26 /27 /28
512 256 128 64 32 16
What are Subnets?
 Subnets are segments or partitions of a network, divided by CIDR range.

Example: Subnet 1 Subnet 2


251 251
A VPC with CIDR /22
includes 1,024 total 1024
IPs Subnet 4
251
IPsSubnet
251
3

Note: In every
subnet, the first four
and last one IP
addresses are
reserved for AWS
use.
How to Use Subnets

 Recommendation: Use subnets to define Internet accessibility.

Public subnets Private subnets


• Include a routing table • Do not have a routing table entry to
entry to an Internet an Internet gateway and are not
gateway to support directly accessible from the public
inbound/outbound access Internet.
to the public Internet. • Typically use a "jump box"
(NAT/proxy/bastion host) to support
restricted, outbound-only public
Internet access.
Subnet Types
Which subnet type (public or private) should you use for
these resources?
• Data store instances
• Private

• Batch processing instances


• Private
• Back-end instances
• Private
• Web application instances
• Public or private*
Directing Traffic to Your VPC (1 of 2) users

 Internet gateways:
10.0.0.0/16
 Allow communication between instances in
Internet
your VPC and the Internet. gateway

 Are horizontally scaled, redundant, and highly


available by default.
 Provide a target in your VPC route tables for Instance A
with public IP
Internet-routable traffic.
10.0.10.0/24
Public Subnet
Directing Traffic to Your VPC (2 of 2)

 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.

 Ensure that instances in your subnet have public IP addresses or Elastic IP


addresses.
 Ensure that your NACLs and security groups allow the relevant traffic to flow
to and from your instance.
Can you connect multiple VPCs to
each other?
Is This the Most Efficient Way of
Connecting VPCs?
 Customer gateway (CGW)
Corporate data center
 One per VPN tunnel
 One public IP per CGW
 AWS provides two tunnel destinations per
region

Public-facing Internal Internal Internal Internal


applications company app 1 company app 2 company app 3 company app 4

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.

 Keep subnets simple and divide by Internet accessibility (public/private).

 Use Multi-AZ deployments in VPC for high availability.

 Use security groups to control traffic between resources.

 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.

You might also like