networking on Alperen Doc

regions-and-availability-zones

Mon, 01 Jan 0001 00:00:00 +0000

Regions and Availability Zones#

AWS has many regions to choose from. Each region is where your services are geographically located.

An outage in one region will (usually) not affect another region.
The farther a server is from the user, the higher the latency. Choose a region close to the folks using your service.
Some services are available only in certain places, or are significantly more expensive in some regions. So we need to make sure a region meets our needs.
As a service grows, we may want to host in more than one region. We also pay a toll for transferring data between regions.

virtual-private-cloud-vpc

Mon, 01 Jan 0001 00:00:00 +0000

Virtual Private Cloud (VPC)#

we need a network “box” to put cloud resources into. AWS calls this box a VPC, or Virtual Private Cloud.

We choose what region this virtual network will be in.
We choose how many things we plan to put into it, i.e., the size of the address space.

This box (the VPC) is really just a group of IP addresses within a region we choose.

Sometimes we want multiple VPCs, for example to separate production resources from development servers. Or we might want some servers in a primary location and others in a backup region.

aws-subnetting

Mon, 01 Jan 0001 00:00:00 +0000

Subnetting#

A VPC’s address space is split into smaller networks called subnets. Each subnet lives in exactly one Availability Zone and gets its own CIDR block inside the VPC CIDR.

Public subnets have a route to an Internet Gateway - resources here can be reached from (and reach out to) the internet.
Private subnets have no direct route to the internet - good for databases and internal services.

internet-gateways-igw

Mon, 01 Jan 0001 00:00:00 +0000

Internet Gateways (IGW)#

The eagle-eyed among you may have noticed that there is currently no difference between our “public” and “private” subnets.

Anything we put in either type of subnet cannot access the internet, and nothing on the internet can access it. Our environment looks like this:

There is a gap between our network and the internet. Usually when folks refer to a subnet as public, they mean the servers inside can access the internet (egress), and with limitations, the internet can access them (ingress).

route-tables

Mon, 01 Jan 0001 00:00:00 +0000

Route Tables#

We’ve attached an internet gateway to our VPC, but nothing tells the subnets it exists or when to use it.

To do that we need a route, and routes live in the creatively named route table. It is literally just a list of routes.

We can add a special kind of route, a “default route,” to our table. It is a catch-all rule that says:

“If you don’t have a specific address for something, look here.”

private-subnets

Mon, 01 Jan 0001 00:00:00 +0000

Private Subnets#

A subnet becomes public by connecting it to a route table and an internet gateway, but what about our private subnets?

An IGW would make the subnet non-private and expose it to the internet. That is too risky for some resources.

On the other hand, we don’t want to completely cut off private infrastructure from internet access. Using a floppy disk to download updates is not exactly an option in the cloud.

connecting-to-the-aws-cloud

Mon, 01 Jan 0001 00:00:00 +0000

Connecting to the AWS Cloud#

With so many different types of networks, on-premises datacenters, and remote workers, companies need a wide range of ways to connect to the AWS Cloud. In the following section, you will learn four ways to connect to the AWS Cloud:

AWS Client VPN
AWS Site-to-Site VPN
AWS PrivateLink
AWS Direct Connect

Securely connect a remote workforce to AWS Cloud resources#

Imagine a company with a recent acquisition needing to securely connect their new remote workforce to their AWS Cloud resources. Even the largest companies with worldwide remote workers can quickly scale up and connect to the AWS Cloud. That’s where AWS Client VPN can help.