Get the Most, from the Best!!

Get the Most, from the Best!!

Topics
 Networking and Amazon
Virtual Private Cloud (VPC)
 Securing your network
 Troubleshooting networks on
AWS
 Get the Most, from the Best!!

Internet
gateway
EC2 Instances
Internet Clients

Security Group
Subnet

EC2 Instance EC2 Instance

Security Group Security Group
Virtual Customer
Private gateway
Subnet Gateway Corporate Clients
Availability Zone
corporate data center

AWS networking products enable you to isolate your cloud infrastructure, scale your
request handling capacity, and connect your physical network to your private virtual
network.

These services work together to meet the needs of your application. For example,
Elastic Load Balancing works with Amazon Virtual Private Cloud (VPC) to provide
robust networking and security features. In the Computing on AWS – Servers module
we briefly went over VPC, subnets, internet gateways, virtual private network
gateways, customer gateways and security groups. As the system operator, you have
control over your virtual networking environment. Let’s review cloud networking and
then dive deeper into networking topics.

Review (if necessary):

VPC
Amazon Virtual Private Cloud (Amazon VPC) enables you to define a virtual network
in your own logically isolated area within the AWS cloud. You can launch your AWS
resources, such as instances, into your VPC. Your VPC closely resembles a traditional
network that you might operate in your own data center.
Subnet
Subnets are logical network segments within your VPC, and are associated with a
single Availability Zone.

Internet Gateway
An internet gateway is a horizontally scaled, redundant, and highly available VPC
component that allows communication between instances in your VPC and the
internet.

A VPN connection consists of the following components.

Virtual Private Gateway

A virtual private gateway is the VPN concentrator on the Amazon side of the VPN
connection. You create a virtual private gateway and attach it to the VPC from which
you want to create the VPN connection. Note: this represents just one possible VPN
solution.

Customer Gateway
A customer gateway is a physical device or software application on your side of the
VPN connection.

Security Group
A security group is a set of “firewall” rules for your instances, allowing or blocking
inbound and outbound traffic. Security groups act at the instance level, not the
subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a
different set of security groups. If you don't specify a particular group at launch time,
the instance is automatically assigned to the default security group for the VPC.
 Get the Most, from the Best!!

Data Center

Internet
AWS Network
Secondary VPC Private IP Address Space:
10.50.0.0 – 10.50.255.255

At its most basic, a cloud-based network is a private IP address space into which you
can deploy computing resources. These resources may be individually managed
resources, such as Amazon EC2 instances, or certain managed AWS services such as
Amazon Relational Database Service (Amazon RDS) instances. You define how (and
whether) your private network space can connect with the internet, any of your
hybrid architectures.
Get the Most, from the Best!!
 Get the Most, from the Best!!

Provision a logically isolated section of the AWS Cloud

in a virtual network you define

 Supports logical separation with subnets

 Fine-grained security
 Optional Hardware Virtual Private Network (VPN)

Let’s break down specifically what Amazon Virtual Private Cloud can do for you. Virtual
private clouds (VPCs) are simply isolated portions of the AWS cloud that customers may
provision for deploying their AWS infrastructure in (i.e., Amazon EC2 instances and
Amazon RDS instances). They are virtual networks, and as such, they support multiple
subnets, routing, and fine-grained security mechanisms. You have complete control
over your virtual networking environment, including selection of your own IP address
range, creation of subnets, and configuration of route tables and network gateways.
You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and
applications.

When a VPC’s tenancy property is set to “dedicated”, you can only launch dedicated
instances in it. Dedicated instances are instances hosted on AWS hardware without any
other customer’s instances.
Some common use cases include:
Setting up typical three-tier systems (web, application, and database) where each tier
resides in its own subnet and is locked down only to those TCP ports that facilitate
communication between the tiers.
Amazon VPC provides advanced security features, such as security groups and network
access control lists, to enable inbound and outbound filtering at the instance level and
subnet level. In addition, you can store data in Amazon S3 and restrict access so that it’s
only accessible from instances in your VPC. Optionally, you can also choose to launch
dedicated instances which run on hardware dedicated to a single customer for
additional isolation.
Extending an on-premises corporate data center by creating a VPN connection to the
VPC. Provisioned AWS resources and on-premises infrastructure may then
communicate with each other as if they were part of the same network. Additionally,
implementing a direct connection with AWS will allow you to provision a dedicated
network connection, thus improving bandwidth and reducing associated network
costs.
 Get the Most, from the Best!!

 Valid private IP address ranges defined by RFC 1918

 Can only define networks between /16 and /28 in Amazon
VPC
 Best practice:
◦ Use non-overlapping IP address ranges
◦ Restrict VPCs to ranges defined in RFC1918 to avoid potential routing
issues

You can use any IPv4 address range, including RFC 1918 or publicly routable IP ranges,
for the primary CIDR block. For the secondary CIDR blocks, certain restrictions apply.
Publicly routable IP blocks are only reachable via the Virtual Private Gateway and
cannot be accessed over the Internet through the Internet gateway. AWS does not
advertise customer-owned IP address blocks to the Internet. You can allocate an
Amazon-provided IPv6 CIDR block to a VPC by calling the relevant API or via the AWS
Management Console. RFC 1918 defines the private address ranges that can be used
by private networks. This standard exists to prevent potential IP collisions between
resources in your private network, and public resources that may be available on the
internet.

Note that you can only define VPCs with CIDR blocks of /16 through /28 inclusive in
an Amazon VPC. That is, the VPC can contain from 16 to 65,536 IP addresses.

You assign a single Classless Internet Domain Routing (CIDR) IP address range as the
primary CIDR block when you create a VPC and can add up to four (4) secondary CIDR
blocks after creation of the VPC. Subnets within a VPC are addressed from these CIDR
ranges by you. Please note that while you can create multiple VPCs with overlapping
IP address ranges, doing so will prohibit you from connecting these VPCs to a
common home network via the hardware VPN connection. For this reason we
recommend using non-overlapping IP address ranges. You can allocate an Amazon-
provided IPv6 CIDR block to your VPC.
 Get the Most, from the Best!!

x.x.x.x/n

IP address Length of
prefix prefix

10.50.1.0/24 00001010 00110010 00000001 xxxxxxxx

10.50.1.0/27 00001010 00110010 00000001 000xxxxx

10.50.1.132/32 00001010 00110010 00000001 10000100 /32 specifies a single

address
0.0.0.0/0
0.0.0.0/0 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
specifies all
addresses

When you create a VPC and its associated subnets, you specify the range of IP
addresses that the VPC and its subnets can use, using Classless Inter-Domain Routing
(CIDR). CIDR notation specifies a block (known as a CIDR block) of IP addresses using
the format x.x.x.x/n, where x.x.x.x is an IP address prefix, and /n specifies which bits
constitute the fixed prefix of the block, starting from the most significant bit. Because
IPv4 is a 32-bit addressing protocol, the /n value can be a number from 0 to 32. In
AWS VPC, the /n is restricted to /16 - /28
 Get the Most, from the Best!!

Region
Default Route Table
Destination Target
10.0.0.0/16 local

VPC: 10.0.0.0/16
Availability Zone A Availability Zone B

-VPCs can span multiple Availability Zones within an AWS Region

-VPCs have an implicit router and a default route table that routes local traffic within
the VPC

VPCs are private networks until associated with an internet gateway and a route table
rule routing traffic through it
Default VPCs are assigned a CIDR range of 172.31.0.0/16. Default subnets within a
default VPC are assigned /20 netblocks within the VPC CIDR range. The base
component of a VPC is the VPC itself. Use a CIDR address range to specify the size of
its private address space.
 Get the Most, from the Best!!

Region
Default Route Table
Destination Target
10.0.0.0/16 local

Private Subnet Private Subnet

10.0.10.0/24 10.0.20.0/24
VPC: 10.0.0.0/16
Availability Zone A Availability Zone B

-Subnets segment VPC address ranges even further

-Subnets can exist within one and only one Availability Zone
-Subnet CIDR blocks within a VPC must not overlap
-Subnet inbound and outbound traffic can be restricted using network ACLs

Subnets are used to further segment the VPC address ranges and to provide logical
groupings for resources divided by team, department, visibility (public or private), or
resource type. Currently, you can create 200 subnets per VPC. With sizing, the
minimum size of a subnet is a /28 (or 16 IP addresses.) for IPv4. Subnets cannot be
larger than the VPC in which they are created. For IPv6, the subnet size is fixed to be a
/64. Only one IPv6 CIDR block can be allocated to a subnet.
 Get the Most, from the Best!!

 Auto-Assign Public IP
◦ Automatically assigns a public IP address to new Amazon EC2
instances
◦ Activated by default in the Default VPC
◦ Set via Modify Auto-Assign Public IP on Subnet settings
◦ Can be overridden when creating a new instance
◦ Not an elastic IP address, which must be explicitly allocated and
associated with an instance

A subnet is a component within your larger VPC. Therefore, it must use an address
range (specified in CIDR notation) that exists within the current address range of the
VPC. Also, it must not overlap any existing address range already used by another
subnet within the same VPC.

After you have created a subnet, you can specify whether new Amazon EC2 instances
launched into that subnet should, by default, have public IP addresses automatically
assigned to them. This is a very useful feature for public subnets that used to be a
capability only granted to the public subnets in your default VPC. With this feature,
you can enable default public IP assignment on any subnet. After creating a subnet,
select the subnet in the AWS Management Console, and then click the Modify Auto-
Assign Public IP button to change the behavior of new instances.

Keep in mind that these are not elastic IP addresses, and will be released from your
instance when the instance is terminated.
 Get the Most, from the Best!!

Region Internet Gateway

Router
Custom Route Table Default Route Table
Destination Target Destination Target

10.0.0.0/16 local 10.0.0.0/16 local

0.0.0.0/0 IGW-id

Public Subnet Private Subnet

10.0.10.0/24 10.0.20.0/24
VPC: 10.0.0.0/16
Availability Zone A Availability Zone B

Each VPC comes with an implicit router that directs traffic between resources in each
subnet and out of the subnet.

A route table is a mechanism used for routing traffic originating from an associated
subnet within a VPC. It contains a set of rules (also called routes) that determine where
traffic is sent. For more information on VPC and subnets, see
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/amazon-vpc-
limits.html#vpc-limits-vpcs-subnets.

When a VPC is created, a main route table is also created, which simply routes local
traffic anywhere within the VPC’s IP address range. (Additional routes may be added.)
Any subnet that is not explicitly associated with a custom route table will be associated
to the main route table. Subnets must be associated with a route table that specifies
the allowed routes for outbound traffic leaving the subnet. Subnets without a route
through an internet gateway are private.

A route table contains a set of rules, called routes, that are used to determine where
network traffic is directed. Routes within a route table consist of a destination and a
target. The VPC reads the route like this: “Any traffic going to destination should be
routed via target.” A target may be a specific instance ID, an elastic network interface
ID, an internet gateway or a virtual private gateway; a special VPC construct that routes
traffic to the internet.

Each VPC may have an internet gateway attached to it. Think of an internet gateway
as a service that routes traffic to the internet. A default VPC with a public subnet will
already have a route table entry to route traffic via an internet gateway.

If no internet gateway exists for a VPC, simply create one from the AWS Management
Console and attach it to a VPC. When an internet gateway has been attached to a
VPC, route tables belonging to public subnets may use it to forward traffic out to the
internet.
 Get the Most, from the Best!!

Region Internet Gateway

Destination Target

172.31.0.0/16 local
0.0.0.0/0 IGW-id

Router

Public Subnet Public Subnet

172.31.0.0/20 172.31.16.0/20
VPC: 172.31.0.0/16
Availability Zone A Availability Zone B

After provisioning the first Amazon EC2 instance in your account, AWS creates a default
VPC for you that occupies the private address range 172.31.0.0/16, i.e., the IP
addresses 172.31.0.0 to 172.31.255.255.
This default VPC allows you to start using VPC features when you’re ready.

The default VPC comes with a main route table with a rule to send all traffic not
targeted to instances within your VPC to the internet gateway.

The default VPC automatically creates a public subnet in each Availability Zone. These
subnets have the Auto-Assign Public IP option enabled so that any instance launched
within the default VPC automatically gets a private and a public IP address.

Because the subnets created within the default VPC don’t have custom route tables,
they are associated with the default (main) route table by default.

The first route in the main route table allows all instances created within the VPC to
communicate with every other instance in the VPC, barring any rules defined in
network ACLs and security groups.
The second route sends all traffic, not targeting instances in your VPC, to the internet
gateway.

To make a public subnet private in the default VPC:

1. Create a custom route table in your VPC which comes with one route by default,
allows communication between instances in your VPC, and is unchangeable.
2. Navigate to the subnet that you want to make private, and associate it with your
new custom route.
 Get the Most, from the Best!!

VPC Peering Relationship

Routes traffic to
192.168.20.0/24
Router Router

Routes traffic to
Account 1 VPC 10.10.0.0/16 Account 2 VPC
10.10.0.0/16 192.168.20.0/24

VPC peering enables you to connect two VPCs—for example, two or more VPCs run
under different accounts by different departments in the same company, or VPCs
belonging to two separate companies.

VPC peering involves establishing a two-way connection through the AWS

Management Console that must be initialized and accepted by both parties. In
addition, owners of both VPCs must establish routes that allow traffic to be sent
between the networks. This routing relationship means that the two networks must
not have overlapping address spaces.

Possible use cases:

-Partner company VPCs
-Connections between multiple divisions

Inter-region VPC peering is available in which case data between regions will traverse
privately on the AWS backbone. For more information about VPC peering, see
https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-
inter-region-vpc-peering/.
 Get the Most, from the Best!!

 Issuing connection: the

owner of other VPC must
confirm B C
 Add route table entries in
both the participating VPCs. 10.0.0.0/16 192.168.0.0/16

 Restrictions applicable:
◦ No overlapping IP ranges A
◦ No transitive peering, edge
routing, IGW access 172.16.0.0/16
◦ No NAT routing between VPCs

The following restrictions are enforced on VPC peering:

• No overlapping private IP ranges: For example, a VPC with 10.2.0.0/16 private IP
address space cannot peer to a VPC with 10.2.2.0/24 private IP address space.
• No transitive peering: If VPC A is peered to VPC B, and VPC B is peered to VPC C,
resources in VPC A have no direct route to resources in VPC C, or vice versa.
• No transitive edge routing through Direct Connect: If VPC A and VPC B are peered,
and VPC A is also connected to your data center through Direct Connect, your data
center cannot directly contact resources in VPC B.
• No transitive internet gateway access: If VPC A and VPC B are peered, VPC B would
not have access to VPC A’s internet gateway; it would have to define its own route to
the Internet.
• No NAT routing between VPCs: VPC A cannot route traffic through VPC B’s NAT
server.
• Cannot resolve private IP addresses: If you do a DNS lookup in VPC A of an address in
VPC B, it will not resolve.
• No cross-referencing of security groups: VPC A cannot specify a security group to
apply to its resource that exists within VPC B, however it can reference one. Use
CIDR block to allow access to resources across the two networks.

For more information on security groups and referencing peer VPC groups, see
https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html.
For more information about invalid VPC peering configurations, see
http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-
configurations.html.
 Get the Most, from the Best!!

Single gateway to connect multiple VPCs and on-

premises networks

 Attach to VPCs and VPNs AWS Transit

 Propagate routes from the Gateway Amazon EC2 instances
virtual private cloud

route tables for the

attached VPCs and VPN
connections
VPN

Servers
Corporate data center

Amazon EC2 instances

virtual private cloud

Region

AWS Transit Gateway enables customers to connect their Amazon Virtual Private
Clouds (VPCs) and their on-premises networks to a single gateway. As you grow the
number of workloads running on AWS, you need to be able to scale your networks
across multiple accounts and Amazon VPCs to keep up with the growth. Today, you
can connect pairs of Amazon VPCs using peering. However, managing point-to-point
connectivity across many Amazon VPCs, without the ability to centrally manage the
connectivity policies, can be operationally costly and cumbersome. For on-premises
connectivity, you need to attach your AWS VPN to each individual Amazon VPC. This
solution can be time-consuming to build and hard to manage when the number of
VPCs grows into the hundreds.

With AWS Transit Gateway, you only have to create and manage a single connection
from the central gateway in to each Amazon VPC, on-premises data center, or remote
office across your network. Transit Gateway acts as a hub that controls how traffic is
routed among all the connected networks which act like spokes. This hub and spoke
model significantly simplifies management and reduces operational costs because
each network only has to connect to the Transit Gateway and not to every other
network. Any new VPC is simply connected to the Transit Gateway and is then
automatically available to every other network that is connected to the Transit
Gateway.
Routing through a transit gateway operates at Layer 3, where the packets are sent to
a specific next-hop attachment, based on their destination IP addresses. Your transit
gateway routes IPv4 and IPv6 packets between attachments using transit gateway
route tables. You can configure route tables to propagate routes from the route tables
for the attached VPCs and VPN connections. You can also add static routes to the
transit gateway route tables. When a packet comes from one attachment, it is routed
to another attachment using the route table that matches the destination IP address.

A transit gateway attachment is both a source and a destination of packets. You can
attach the following resources to your transit gateway, if they are in the same Region
as the transit gateway:
• One or more VPCs
• One or more VPN connections

For more information, see https://aws.amazon.com/transit-gateway/.

 Get the Most, from the Best!!

Main Route Table

Destination Target

10.0.0.5
10.0.0.0/16 local
10.0.0.6
10.0.0.7 192.168.10.0/2
VGW-id
4
EC2 Instances
Availability Zone A VPN-only Subnet 10.0.0.0/24

VPN connection

Router Virtual private gateway

Customer gateway

Availability Zone B

VPC
10.0.0.0/16 192.168.10.0/24
Region
Corporate data center

Virtual Private Gateway

-Gateway access point in AWS

Customer Gateway
-On-premises hardware/software appliance
-Must have routable public/static IP address
-Specific number and type supported by AWS

The configuration for this scenario includes the following:

• A virtual private cloud (VPC) with a size /16 CIDR (example: 10.0.0.0/16). This
provides 65,536 private IP addresses.
• A VPN-only subnet with a size /24 CIDR (example: 10.0.0.0/24). This provides 256
private IP addresses.
• A VPN connection between your VPC and your network. The VPN connection
consists of a virtual private gateway located on the Amazon side of the VPN
connection and a customer gateway located on your side of the VPN connection.
• Instances with private IP addresses in the subnet range (examples: 10.0.0.5,
10.0.0.6, and 10.0.0.7), which enables the instances to communicate with each
other and other instances in the VPC.
• The main route table contains a route that enables instances in the subnet to
communicate with other instances in the VPC. Route propagation is enabled, so a
route that enables instances in the subnet to communicate directly with your
network appears as a propagated route in the main route table.

For more information, see the Amazon VPC Network Administrator Guide:
http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Welcome.ht
ml.
 Get the Most, from the Best!!

Customer
Gateway
ASN: 6500
Customer Network
EC2 Instances

VPC Subnet 1
Availability Zone A
Customer
Gateway
ASN: 6501
Virtual Customer Network
Private
Gateway
EC2 Instances

VPC Subnet 2 Customer

Availability Zone B Gateway
ASN: 6502
Customer Network

To use the AWS VPN CloudHub, you must create a virtual private gateway with
multiple customer gateways. You must use a unique Border Gateway Protocol (BGP)
Autonomous System Number (ASN) for each customer gateway. Customer gateways
advertise the appropriate routes (BGP prefixes) over their VPN connections. These
routing advertisements are received and re-advertised to each BGP peer, enabling
each site to send data to and receive data from the other sites. The sites must not
have overlapping IP ranges. Each site can also send and receive data from the VPC as
if they were using a standard VPN connection.

Sites that use AWS Direct Connect connections to the virtual private gateway can also
be part of the AWS VPN CloudHub. For example, your corporate headquarters in New
York can have an AWS Direct Connect connection to the VPC and your branch offices
can use VPN connections to the VPC. The branch offices in Los Angeles and Miami
can send and receive data with each other and with your corporate headquarters, all
using the AWS VPN CloudHub.

To configure the AWS VPN CloudHub, use the AWS Management Console to create
multiple customer gateways, each with the public IP address of the gateway and the
ASN. Next, create a VPN connection from each customer gateway to a common
virtual private gateway. Each VPN connection must advertise its specific BGP routes.
This is done using the network statements in the VPN configuration files for the VPN
connection. The network statements differ slightly depending on the type of router
you use.

When using an AWS VPN CloudHub, you pay typical Amazon VPC VPN connection
rates.

For more information about CloudHub, see

https://docs.aws.amazon.com/vpn/latest/s2svpn/VPN_CloudHub.html.
 Get the Most, from the Best!!

VPN via Internet

Router
Router

Customer
Virtual Gateway
Account 1 VPC Gateway
172.31.0.0/16
Customer Data Center
AWS Direct
Connect

When your own VPC is established, you can integrate it with additional corporate
networks. Using AWS Direct Connect, you can create a physical connection between
your data center and AWS, creating a secure, dedicated, encrypted endpoint between
your internal networks and your cloud network. Amazon VPC also supports creating
dedicated or Internet VPN connections using third-party VPN solutions, thus providing
your employees, partners, and other personnel with connectivity to your private
network from anywhere in the world.

Note that this is a site-to-site scenario. It is also possible to use VPN technology such as
OpenSWAN to enable client-to-site scenarios, as outlined in this AWS white paper:
https://media.amazonwebservices.com/AWS_Amazon_VPC_Connectivity_Options.pdf.

If you have multiple sites/locations (remote/branch offices) with existing VPN

connections, you can also use AWS VPN CloudHub to provide secure communication
between sites and AWS. For more information, see
https://docs.aws.amazon.com/vpn/latest/s2svpn/VPN_CloudHub.html.
 Get the Most, from the Best!!
Software updates

Challenge
Amazon EC2 instances in a private
subnet need to connect to the
internet

Solutions
 NAT Gateway
 NAT Instance
Private Instance
10.50.2.191

Private Subnet
10.50.2.0/24

You can use a NAT device to enable instances in a private subnet to connect to the
internet (for example, for software updates) or other AWS services, but prevent the
internet from initiating connections with the instances. A NAT device forwards traffic
from the instances in the private subnet to the internet or other AWS services, and
then sends the response back to the instances. When traffic goes to the internet, the
source IP address is replaced with the NAT device’s address and similarly, when the
response traffic goes to those instances, the NAT device translates the address back
to those instances’ private IP addresses.

AWS offers two kinds of NAT devices: a NAT gateway and a NAT instance. We
recommend NAT gateways, as they provide better availability and bandwidth over
NAT instances. The NAT gateway service is also a managed service that does not
require your administration efforts. A NAT instance is launched from a NAT AMI. You
can choose to use a NAT instance for special purposes.

For more information about networking in your VPC – NAT, see

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat.html.

Image: https://pixabay.com/en/update-internet-network-software-97888/
 Get the Most, from the Best!!

Characteristics: Create a NAT gateway:

 AWS managed service 1. Specify:
 Built-in redundancy for  Public subnet where the gateway
high availability will reside
 Supports bursts of up to  Elastic IP address
10 Gbps of bandwidth
2. Update:
 Supports protocols:
Route tables of private subnets
◦ TCP, UDP, and ICMP 

You can use a NAT gateway to enable instances in a private subnet to connect to the
internet or other AWS services, but prevent the Internet from initiating a connection
with those instances. NAT is used only for outbound-initiated traffic, and cannot be
used to initiate inbound traffic.

To create a NAT gateway, you must specify the public subnet in which the NAT
gateway will reside. You must also specify an Elastic IP address to associate with the
NAT gateway when you create it. After you've created a NAT gateway, you must
update the route table associated with one or more of your private subnets to point
Internet-bound traffic to the NAT gateway. This enables instances in your private
subnets to communicate with the Internet.

Each NAT gateway is created in a specific Availability Zone and implemented with
redundancy in that zone. You have a limit on the number of NAT gateways you can
create in an Availability Zone.

For more information about VPC NAT gateways, see

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html.
 Get the Most, from the Best!!

Custom Route Table

Destination Target

198.51.100.1 10.0.0.5
10.0.0.0/1 local
198.51.100.2 10.0.0.6 6
198.51.100.3 10.0.0.7
NAT Gateway 0.0.0.0/0 IGW-id
198.51.100.4 (EIP)
Web Servers
Public Subnet 10.0.0.0/24

Router Internet Main Route Table

Gateway
Destination Target

10.0.0.0/1 local
Database Servers 6
Private Subnet 10.0.1.0/16
0.0.0.0/0 NAT-gateway-
Availability Zone A
id
VPC
10.0.0.0/16

Region

This diagram illustrates the architecture of a VPC with a NAT gateway. The main route
table sends internet traffic from the instances in the private subnet to the NAT
gateway. The NAT gateway sends the traffic to the internet gateway using the NAT
gateway’s Elastic IP address as the source IP address.

Note- It’s advisable to host a NAT Gateway in each AZ for better availability
 Get the Most, from the Best!!

VPC Endpoint
Subnet
10.10.1.0/24
Requires internet AZ us-west-2a
access using an IGW or
a NAT server

VPC Endpoint
Destination Target
Subnet
10.10.0.0/16 local
10.10.2.0/24
pl-1a2b3c4d vpce-11bb22cc AZ us-west-2b

A VPC endpoint enables you to privately connect your VPC to supported AWS services
and VPC endpoint services powered by AWS PrivateLink without requiring an internet
gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in
your VPC do not require public IP addresses to communicate with resources in the
service. Traffic between your VPC and the other service does not leave the Amazon
network.

Typically, to access an Amazon S3 bucket, you write application code that uses an
Amazon S3 endpoint and DNS resolves to a public IP address for your bucket. With a
VPC endpoint for Amazon S3, your packets will route directly to your Amazon S3 IP
addresses, but without ever leaving the AWS private cloud. You can now integrate
seamlessly between applications running within your VPC and services such as Amazon
Kinesis Streams, AWS Systems Manager (SSM), AWS Service Catalog, Amazon S3, and
DynamoDB. This means your applications no longer need to go through the internet to
reach the AWS services. Better yet, you can take advantage of this feature without
having to change any of your existing application code.

For more information about VPC endpoints, including supported services, see
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html.
 Get the Most, from the Best!!

 Highly available, scalable technology that enables private

connections to:
◦ Supported AWS services
◦ Services hosted by other AWS accounts (VPC endpoint services)
◦ Supported AWS Marketplace partner services
 Privately access AWS system manager APIs to configure
instances in private subnets
 Interface endpoints are powered by AWS PrivateLink

You can improve the security posture of your managed instances (including managed
instances in your hybrid environment) by configuring AWS Systems Manager to use an
interface VPC endpoint. Interface endpoints are powered by PrivateLink, a technology
that enables you to privately access Amazon EC2 and Systems Manager APIs by using
private IP addresses. In addition, there are many other AWS APIs that can be reached
via PrivateLink, for more information, see
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html.

AWS PrivateLink is a highly available, scalable technology that enables you to

privately connect your VPC to supported AWS services, services hosted by other AWS
accounts (VPC endpoint services), and supported AWS Marketplace partner services.
PrivateLink restricts all network traffic between your managed instances, Systems
Manager, and EC2 instances to the Amazon network (managed instances that don't
have access to the Internet). Also, you don't need an Internet gateway, a NAT device,
or a virtual private gateway.

For more information about PrivateLink and VPC endpoints, see

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html
#what-is-privatelink.
 Get the Most, from the Best!!

 A DNS server provided as part of VPC

 Your own DNS server, by setting Dynamic Host Configuration
Protocol (DHCP) options
◦ Private DNS called split-horizon DNS
 Amazon Route 53 Private Hosted Zones
 Amazon Route 53 Resolver
◦ Endpoint for inbound, outbound or both

When you launch an instance into a VPC, the instance will only be provided a public and
private DNS hostname if DNS hostnames support is enabled for the VPC. DNS
hostnames support is automatically enabled for the Default VPC as well as any VPC
created using the VPC wizard in the management console.

To use your own DNS server, update the DHCP options set for your account.
If you want to access the resources in your VPC using custom DNS names, instead of
using private IP addresses or AWS-provided private DNS hostnames, you can create a
private hosted zone in Amazon Route 53. You can then create Amazon Route 53
resource record sets, which determine how Amazon Route 53 responds to queries. This
allows you to manage the internal DNS names for your application resources (web
servers, application servers, databases, and so forth) without exposing this information
to the public Internet.

One common use case for private DNS is called Split-horizon DNS, which resolves to one
IP address when a lookup is initiated from within a VPC and a different IP address when
the lookup originates elsewhere.

Another common use case for private DNS allows you to map a custom DNS name to a
primary IP address that you can change to a secondary IP address as a fail-over
mechanism.

When you create a VPC using Amazon VPC, you automatically get DNS resolution
within the VPC from Route 53 Resolver. By default, Resolver answers DNS queries for
VPC domain names such as domain names for EC2 instances or ELB load balancers.
Resolver performs recursive lookups against public name servers for all other domain
names. The Route 53 Resolver console includes a wizard that guides you through the
following steps for getting started with Resolver: Create endpoints: inbound,
outbound, or both. For outbound endpoints, create one or more forwarding rules,
which specify the domain names for which you want to route DNS queries to your
network and choose the VPC that you want to associate the rules with.

For more information on VPC and DNS, see

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html.

For more information about Route 53 Private Hosted Zones, see

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-
private.html.
 Get the Most, from the Best!!

Virtual network interface card (NIC)

attached to an Amazon EC2 instance

 Up to 15 network interfaces per instance

 50 elastic IP addresses per network interface
 Use cases:
◦ “Multi-homed” instances connected to multiple networks
◦ Connecting network and security appliances to your VPC

An elastic network interface is a virtual network interface card (NIC) attached to an

Amazon EC2 instance. Each network interface has one primary IP plus additional
secondary IPs. They also have their own mac address and security groups. There can
be up to 15 network interfaces per instance and 50 elastic IP addresses per network
interface. This however does not increase networking capacity. So what are the use
cases for multiple network interfaces on an instance? They include “multi-homed”
instances connected to multiple networks and connecting network and security
appliances to your VPC. The limits are directly linked to the instance type. For more
information, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-
eni.html#AvailableIpPerENI.
Get the Most, from the Best!!
 Get the Most, from the Best!!

1: VPC route tables

2: Subnet ACLs: inbound/outbound

OS
3: EC2/ENI security groups: inbound/outbound

4: Third-party host-based protection

AWS Shield Standard defends against most common, frequently

occurring network and transport layer DDoS attacks that target your web
site or applications.

Your virtual network can and should be secured at several different levels.
The most broadly scoped level of security is at the route-table level. As we have seen
in the networks we have built here, having a private subnet with no direct path to the
internet is one of the best ways to protect your internal computing resources against
unauthorized access.

The second level is network access control lists (network ACLs). Network ACLs
provide the ability to define default security behavior for your subnets.
The VPC/subnet layer security is typically controlled by the network security team.

Security groups can be used at the third level to control behavior at the
instance/network interface level.

At the fourth level, you may choose to use some form of third-party host-based
detection software that monitors individual Amazon EC2 instances for specific threats
such as malware intrusion, known operating system vulnerabilities, and security
auditing.

For more information, see

https://d1.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf.
 Get the Most, from the Best!!

 Used to allow traffic to/from at the network interface

(interface) level
 Configured by default to:
◦ Deny all inbound traffic
◦ Allow all outbound traffic
 Stateful: If rules allow traffic to flow in one direction,
responses can automatically flow in the opposite direction
 Usually administered by application developers

In addition to network ACLs, security groups can also be used to restrict traffic in and
out of network interfaces that are associated with them. Some important things to
note with security groups:

• The number of VPCs in the region multiplied by the number of security groups per
VPC cannot exceed 5000.
• You can have 50 inbound and 50 outbound rules per security group (giving a total
of 100 combined inbound and outbound rules).
• By default, no inbound traffic is allowed.
• By default, all outbound traffic is allowed.
• You can create a custom network ACL and associate it with a subnet. By
default, each custom network ACL denies all inbound and outbound traffic
until you add rules.
• All outbound traffic in response to an inbound request is permitted.
• Instances that are part of the same security group cannot communicate with each
other by default.

For more information, see

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/amazon-vpc-
limits.html#vpc-limits-security-groups.
 Get the Most, from the Best!!

 Allow/deny traffic in and out of subnets

 Default network ACL:
◦ Allows all inbound and outbound traffic
 Stateless: Even if rules allow traffic to flow in one direction,
you have to explicitly allow responses to flow in the opposite
direction
 Hardens security as a secondary level of defense at the subnet
level

Within a VPC, security is controlled using security groups and network ACLs. Network
ACLs are associated with specific subnets within a VPC. Because they are stateless,
both inbound and outbound rules (ingress and egress) must be defined.

Inbound and outbound rules are defined by:

• Specifying the type of rule, e.g., custom TCP
• Providing a rule number (rules are processed lowest to highest)
• Defining the port range that will be allowed or denied in/out
• Specifying the source or destination IP address/range that will be allowed or denied
in/out
• After the network ACL has been defined, it can be associated to subnets within the
VPC.

Network ACLs are usually administered by Network Security or Network

Administration. AWS officially recommends a set of network ACLs for each of the four
configurations offered by the VPC wizard. Because these configurations involve
supplying values that are specific to your private network, they must be implemented
manually. For a full list of recommended network ACLs for each VPC wizard
configuration, see
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.ht
ml.
 Get the Most, from the Best!!

Local
 Bastion host/jump box Computer
◦ Public to private subnet access
 Do not store private keys on bastion
◦ Use agent forwarding (for Linux instances) NA Bastion Host
T

Public Subnet
10.50.1.0/24

Log in to private
instance via bastion

Private Instance

Private Subnet i
10.50.2.0/24

A bastion host serves as a jump point from the public internet to the Amazon EC2
instances and other resources in your private subnets. Using a bastion host, you can
access private resources publicly through the Internet, in a way that still keeps the
attack surface of your private subnet small. Users must have valid keys for both
bastion and private instances.

For Linux instances, we strongly recommend that you use different public/private key
pairs for the bastion host and any resources within your private subnets. The keys for
private subnet resources should NOT be stored on the bastion host, because that
would mean that any attacker who managed to break into your bastion host would
then have access to the resources in your private subnet. Most SSH clients support
what is known as agent forwarding. This allows your local SSH program, such as
PuTTY, to pass your private key from the client through the SSH connection with the
bastion host, and on to the SSH connection to your private network resources.

To simplify the connection to Amazon EC2 instances in private subnets you can use
the Session Manager feature of AWS Systems Manager as an alternative to setting up
bastion hosts.
 Get the Most, from the Best!!

Do they have to be in separate subnets?

Protocol Source Protocol Source

22 (SSH) 17.5.0.0/16 22 (SSH) sg-192d536a

Bastion
10.50.1.29 Private Instance
54.23.252.2 10.50.2.191

Security group sg-192d536a

Public Subnet Private Subnet

10.50.1.0/24 10.50.2.0/24

Let’s look at how to configure security groups in order to allow the bastion host to
access an instance in your private subnet.

First, configure your bastion host to only allow connections from within your
corporate network; this prevents anyone outside your organization from accessing
the bastion.

Next, if your bastion host has a security group named sg-192d536a, you can specify
that a server in your private subnet will only allow incoming connections from the
bastion by specifying the bastion host’s security group.
You can also restrict incoming connections to the IP of the bastion group. Specifying a
security group, however, is more flexible and more reusable.

Note that this example applies to using Linux instances; if you were deploying
Windows instances, you would open up the port for Remote Desktop Protocol (RDP).
 Get the Most, from the Best!!

Allow secure access from anywhere on the internet using RD Gateway

Server

Protocol Source Protocol Source

443 (SSL) 0.0.0.0/0 3389 (RDP) sg-92d536a

Bastion
10.50.1.29 Private Instance
54.23.252.2 Forwards RDP 10.50.2.191
requests on port
Security group sg-92d536a 3389
Public Subnet Private Subnet
10.50.1.0/24 10.50.2.0/24

When setting up a Windows bastion host, you can use a service called RD Gateway to
permit secure access from anywhere on the internet.

If you run Microsoft Windows instances in Amazon EC2, you will probably use the
Remote Desktop Protocol (RDP) for remote administration. To define the source IPs
that are allowed to connect to your Amazon EC2 instance’s RDP port (TCP/3389), you
configure the instance’s security group rules. When configuring your security groups,
it’s a best practice to apply the principle of least privilege, allowing only connections to
the RDP port from the IP addresses your administrators will be connecting from and
denying all others. However, in cases where an administrator could be connecting from
anywhere on the internet, it can be difficult to determine which IPs to allow. As a result,
we often see customers setting security groups for RDP access to allow every IP
(0.0.0.0/0), thereby failing to enforce least privilege at the network layer.

One solution to this problem is to protect your Windows instances at the network layer
using the Microsoft Remote Desktop (RD) Gateway server set up as a bastion. RD
Gateway can be configured to accept connections via HTTPS (TCP/443) from every IP on
the internet, then proxy them to your other Windows instances using RDP port
(TCP/3389). Only users who authenticate to your RD Gateway instance are allowed to
proceed to the protected Windows instances behind the proxy.
For more information on configuring a Windows bastion to use RD Gateway, see
http://blogs.aws.amazon.com/security/post/Tx2ZWDW1QA6D62Y/Controlling-
network-access-to-EC2-instances-using-a-bastion-server.
Get the Most, from the Best!!
 Get the Most, from the Best!!

If instances in subnets cannot communicate with one another:

◦ Verify that it is a network issue, not an instance issue
◦ Check network ACLs
◦ If enabled, check VPC flow logs
 Get the Most, from the Best!!

If the NAT configuration doesn’t work:

 NAT instance and NAT gateway
◦ Check route table association

 NAT instance
◦ Check to see if the Source/Dest Check is disabled
◦ Ensure that NAT has masquerade configured
◦ Restart NAT
◦ Check the inbound security group rules
 Get the Most, from the Best!!

If you cannot reach resources in a peered network:

◦ Peering request approval
◦ Route table configuration
◦ Check network ACLs: are you forbidding all external traffic?
◦ Check security group configurations on resources
◦ Use CIDR block rules in VPC A to allow access from VPC B
(Security groups can be utilized as well)
 Get the Most, from the Best!!

 Create and configure AWS networking components

◦ Amazon EC2
◦ Security groups
◦ Subnets
 Build a moderately complex VPC
 Secure your network with additional tools and features
 Explain possible troubleshooting solutions to network issues