Before diving into Virtual Private Cloud concepts useful for the exam, let's start with the main concepts/components of AWS Global Infrastructure, in regards with closeness to the end user, and where our resources resides - on-premises or in the cloud.
AWS Global Infrastructure
- Region: collection of AZ geographically closely located (usually same city) so that worldwide customer base can take advantage of low latency connections; regions also allow compliance with with regulations, laws and governance relating data storage. (currently 26+)
- Availability Zone : essentially physical data centers; 2 or more in each region, isolated from each other using separate power and network connectivity.
- CloudFront: is a CDN, to get content closer to users
- Edge location: AWS sites deployed in major cities/ highly populated areas. Not used for deployment our own infrastructure, but used by many services like CloudFront and Lambda@Edge to cache and reduce latency.
-
Regional Edge Cache: AWS sites located between Cloudfront Origin servers and Edge Location; they have a larger cache than individual Edge location and lower latency than Cloudfront.
- AWS Outposts: with outpost you can run some AWS services on dedicated hardware within your on-prem data centers
- AWS Local Zones: for ultra low latency applications (live video, MRL, AR/VR)
- AWS Wavelength Zones: similar to LocalZone but for 5G devices (single digit ms latency)
- VPC (Virtual Private Cloud): a logically isolated portion of AWS cloud within a region
- Private and Public subnets: a range of IP addresses in the VPC where we can place groups of isolated resources
Also some introductory concepts as IP Addressing, CIDR Blocks and Subnetting is necessary to understand how to properly configure a VPC:
IPv4 and IPv6 Addressing
An IPv4 address is 32 bits long (4 octets ): this means there are 4.3 billion addresses available which are going to be soon exhausted.
The first 3 binary octects are Network Id, while the last one is the Host ID
Different Computers on same Network will have same NetworkId, ( like 192.168.0) but have unique HostIDs.
IPv6 addresses are 128 bits long and use hexadecimal instead of dotted decimal.
When using IPv6 for VPC CIDR Block AWS will provide a /56 CIDR block from their own pool.
All IPv6 addresses are publicly routable and no NAT is necessary. If we want to allow only outbound traffic, we can use egress-only internet gateway.
Subnetting and CIDR blocks
Subnetting is the process of splitting a CIDR (Classless InterDomain Routing ) block into smaller blocks.
When you create a VPC you are required to enter a CIDR block range.
A lot of consideration must be put when choosing the CIDR block, because we need to ensure there will be enough IP addresses for our instances within each subnet, and because, as we see later, CIDR block should never overlap.
CIDR guidelines/considerations
- block size must be between /16 and /28
- CIDR block must not overlap any existing blocks associated with the VPC
- CIDR block size can't be increased or decreased
- AWS recommends using CIDR blocks from RFC 1918 ranges
- when setting the size of the subnets keep in mind that first four and last IP addresses are not available for use
- bigger CIDR blocks give more flexibility but smaller subnets are ok for most use cases
Imagine we have a VPC CIDR Block of 10.0.0.0/16 and that we want to create 16 subnets. To do so, we use a mask of /20 (which gives us a total of 4096 hosts (16*256).
Considering that for each subnet 5 addresses ( first 4 and the last one) are reserved by AWS, we are left with 251 hosts in each subnet for our instances
If you want to dig more into this topic this is one of the best articles about VPC Design / CIDR Blocks and Subnetting I have ever read. Highly suggested.
Also these tools proved very useful to better understand these CIDR Blocks and masks:
Now finally, let's dig into the exam topics!
What is a VPC?
A VPC is a logically isolated portion of AWS cloud within a region.
Each VCP has a different CIDR, it is like having your own data center inside AWS.
By default you can create up to 5 VPCs per region per AWS account.
Components of a VPC
-Subnet : A segment of IP address range within the VPC where you can place groups of isolated resources
-Internet Gateway: VPC side of the connection to public internet -
-NAT Gateway: highly available, managed Network Address Translation service to resources in private subnets that need access to internet (check here for more info)
-Peering connection: enables traffic routing via private IP addresses between 2 VPCs
-VPC Endpoints: enable private connectivity to services hosted in AWS from the VPC ( without using Internet Gateway, VPN, NAT etc)
-Egress Only Internet Gateway : Stateful gatway that allows egress only access for IPv6 traffic (only outbound )
-Hardware VPN Connection: Hardware-based VPN connection between your datacenter / location and the VPC.
-Virtual Private gateway and Customer Gateway: one is the Amazon side of a VPN connection, while the other is ..well.. the customer side of it.
-Router: via route tables we can map interconnections between subnets and map direct traffic between gateways and subnets.
Let's now see these components individually in more detail
Public and private Subnets
Subnets are a range of IP addresses in the VPC and, as the name suggest Public Subnets have direct access to the internet while Private Subnets have NO access to the internet.
When you first create a public and a private subnet and all subnets will have a local route, so they look absolutely the same.
In order for a Public Subnet to be Public and have access to the internet:
- VPC must have a IGW (Internet Gateway) attached
- we need to attach that Internet Gateway to the subnets route table
- instances in the subnet must have a public IP address ( or we must enable Autoassign public IPv4 address to the subnet)
- NACL associated with the subnet must be properly configured to allow inbound and outbound traffic.
Each subnet can only be associated with one route table, so that traffic can be routed within the VPC or to the internet.
Subnets are created within AZ, by having a multi-tier application and placing multiple subnets into different AZ you can set up Highly Available and resilient Architectures.
Security Groups and Network ACLs
A security group acts as a virtual firewall on your Instances controlling incoming and outgoing (with inbound and outbound rules) traffic.
Since Security Groups apply at the instance level the same security group can be applied to instances in different subnets.
Security Groups have a deny list by default and support only Allow Rules.
All inbound traffic is denied by default (in custom groups ), while in default groups traffic from within the group is allowed by default.
Outbound traffic is always enabled by default.
Security groups are stateful, this means that traffic as response is allowed to return automatically ( without the need of processing rules).
Network Access Control Lists, aka Network ACLs, aka NACLs,
apply to the traffic at the subnet level, entering or exiting the subnet. It will apply to all instances in the subnet, but not to a group of EC2 instances (in different subnets).
NACLs are stateless therefore a rule check is applied for both connections (request & response).
NACLs deny all inbound and outbound traffic by default, but support both allow and deny rules.
NACLs do not apply to traffic within the subnet.
Pay attention to the Rules Order, Rules are evaluated from top to bottom, and whatever does not match a rule will be evaluated by the next one. That means that if you have a Rule that allows everything and then a rule that denies , the denies will not work..
Since Security Groups can't block specific ranges of IPs, NACLS are the preferred option in this scenario.
VPC Connectivity
Depending on your current network designs and requirements (like across VPCs or between VPC and your network/VPN), you have several ways of connecting to a VPC
- VPC Peering
- Transit Gateway
- VPC Endpoints
- AWS Managed VPN
- Software Site-to-Site VPN
- Software VPN-to-AWS Managed VPN
- PrivateLink
- Direct Connect
- CloudHub
- ... and many more
VPC Peering
Simply put, VPC Peering allows routing between VPCs keeping traffic encrypted and without going to the internet .
A VPC peering connection is a networking connection between two VPCs. Instances in either VPC can communicate with each other as if they are within the same network.
Traffic always stays on the global AWS backbone, and never traverses the public internet.
There is no single point of failure for communication or a bandwidth bottleneck. from the docs
Transitive Peering does not work.
VPC Peering is a 1-1 connection, if we need peering connection among multiple VPCs, we need multiple VPC peering (one for each pair of VPC we want to connect)
In the picture above VPC B and VPC cannot communicate because they don't have they own VPC Peering.
VPC peering works among different regions, and different accounts.
VPC peering requires non-overlapping CIDR blocks ( even if they belong to different accounts)
AWS Transit Gateway
When we have lots of VPCs and different on-prem networks, things can get very complicated and expensive.
AWS Transit Gateway provides full transitive routing among VPCs across regions.
Data is automatically encrypted and never travels over the public internet.
VPC Endpoints
VPC Endpoints (Interface and Gateway) allow you to privately access AWS services using AWS internal network ( backbone ) instead of traversing the public internet and therefore without imposing availability risks or bandwidth constraints on network traffic.
- Gateway endpoints Gateway endpoints are targets in a Route table that redirect traffic to specific AWS services ( currently just S3 and DynamoDB) In order for connection to work you will still need to set up VPC endpoint policies ( and resource policy )
For example, this Bucket Policy will Deny all actions on the bucked unless the request is coming from the VPC
{
"Version": "2012-10-17",
"Id": "Policy1415115909152",
"Statement": [
{
"Sid": "Access-to-specific-VPCE-only",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::MY_BUCKET",
"arn:aws:s3:::MY_BUCKET/*"],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "MY_VPC_ENDPOINT_ID"
}
}
}
]
}
alternatively, you can have a bit broader policy allowing access not only from that specific VPC endpoint but from the entire VPC
aws:SourceVpc": "VPC_ID"
Be careful when trying this out, because after setting that bucket policy you will not have access to the bucket anymore, ( nor from your computer neither from your AWS UI Console ). to restore access you have to login to your root account and delete the bucket policy. see here
- Interface endpoints they are essentially ENIs (Elastic Network Interfaces) (some more about ENI here placed within a subnet. They rely on AWS PrivateLink to allow a private and secure connection between VPCs, on-prem apps and AWS services. An Interface endpoint allows for example the connection from an EC2 instance inside a Private subnet to AWS services like APIGateway or CloudWatch
AWS Client VPN
AWS Client VPN allows you to access your AWS resources inside a VPC (like instances using private IP Address) from you local network) with an encrypted connection.
Basically, a VPN Endpoint is associated with subnets in our VPC; from our client computer, using our VPN Software of choice, we establish a connection over SSL/TLS (443) to the VPN Endpoint that will perform SNAT to the CIDR block associated with the VPC.
AWS Site to Site VPN
By default instances inside a VPC can't communicate with your own remote network. You can enable access to your remote network from your VPC by creating an AWS Site-to-Site VPN (Site-to-Site VPN) connection
SiteToSite VPN supports InternetProtocol Security (IPsec) VPN connections.
SiteToSite VPN requires a Customer Gateway Device (physical or software) on the Client Side of the VPN (your network / office / data-center ) plus a Customer Gateway on AWS to provide AWS with the info about your device) and a Virtual Gateway on the Amazon side of the VPN.
The VGW (Virtual Gateway) is attached to the VPC and then it can communicate with the Customer Gateway via VPN Tunnel.
AWS Direct Connect (DX)
WS Direct Connect uses private network connections into the AWS Cloud and is high-bandwidth and low-latency.
Build Hybrid Networks
- private connectivity between AWS and your data-center/office (it uses AWS backbone)
- increased speed/latency and bandwidth/throughput
- cost effective if transferring large volumes of data from your data center to AWS.
Direct Connect does allows connection with a Region, not only to a VPC ( using virtual gateway - VGW) to private subnets, but to any other AWS resource (like S3 Buckets)
Cons are that it is costly and requires additional telecom and hosting provider relationships; also, traffic in transit is NOT encrypted by defaultand if you need encryption you will need an IPSec S2S VPN connection over a VIF (Virtual Interface).
Direct Connect + VPN
This solution combines the benefits of the AWS Managed VPN with those of Direct Connect to provide an end-to-end secure IPSec connection
VPN CloudHub
When you want multiple Remote Offices to connect to a VPC or AWS Resources in a hub and spoke model.
Hub and Spoke model is a distribution model that, as opposed to Point2Point, has not direct communication among different points in the system, rather everything has to go to a central hub and is then forwarded to the other spoke.
The cool thing about this architecture is that you can reuse existing Internet connections - each remote office will have its own Customer Gateway and can communicate with each other via the Virtual Private Gateway. The main con is that, it is dependent on internet connections and has no inherent redundancy.
You can use Site2Site VPN to establish a routing topology among Customer Offices and VPC itself.
Read more about Providing secure communication between sites using VPN CloudHub here
As a final topic, it is interesting to know that traffic information flowing to and within your VPC can be logged using VPC Flow Logs.
VPC Flow Logs
VPC Flow Logs allows you to capture IP traffic information that flows between your Network Interfaces of your resources within your VPC.
This is useful to help resolve incidents with network communication and for security purposes like spotting traffic from or to destination that are not allowed.
Logs are saved to CloudWatch or S3.
Flow Logs can be set up against:
- a specific NI on one specific instance
- a subnet with the VPC
- the VPC itself
DHCP traffic and traffic that goes to Route53 is excluded from monitoring.
Photo by Alexander Grey on Unsplash
Digital Cloud AWS Solutions Architect Associate Certification Hands On Lab
Cloud Academy AWS Solutions Architect Associate Certification Preparation
Top comments (0)