Networking in AWS (Amazon Web Services) forms the backbone of cloud infrastructure, enabling seamless communication and resource management. This article delves into the key components of AWS networking, including Virtual Private Clouds (VPCs), subnets, and routing.
Amazon VPC (virtual private cloud)
- isolated network that you create in the AWS Cloud
- there are three things you need to define while creating VPC:
- name
- region where the VPC will live – VPC spans all the Availability Zones within the selected Region
- IP range for the VPC in CIDR notation – determines the size of your network. Each VPC can have up to five CIDRs: one primary and four secondaries for IPv4 (each of these ranges can be between /28 (in CIDR notation) and /16)
- VPC can operate in dual-stack mode, so we can have IPv4 and IPv6 at the same time, but you have to remember that then you have to define routing separately for both versions
- default quota is 5 VPC per region, but we can request to increase it
Creating a subnet:
- after you create your VPC, you must create subnets inside the network
- subnet must be entirely in one AZ (a subnet cannot span multiple AZs). There can be multiple subnets in one AZ. We can also add a subnet in the Local Zone, then our VPC extends to that Local Zone
- subnets are used to provide high availability and connectivity options for your resources
- public subnet – resources that must be connected to the internet
- private subnet – resources that won’t be connected to the internet
- there are three things you need to define while creating subnet:
- VPC
- AZ
- IPv4 CIDR block for your subnet
- when you launch an EC2 instance, you launch it inside a subnet, which will be located inside the Availability Zone that you choose
- to maintain redundancy and fault tolerance, create at least two subnets configured in two Availability Zones
Reserved IPs:
- AWS reserves five IP addresses in each subnet (for routing, Domain Name System (DNS), and network management)
- eg 10.0.0.0 – network address,
- 10.0.0.1 – VPC local router,
- 10.0.0.2 – DNS server,
- 10.0.0.3 – for future use,
- 10.0.2.255 – network broadcast.
How to create a public subnet?
- to make given subnet public you need to:
- connect the internet gateway to the VPC
- insert the internet gateway as a target in our route table
- make sure that our instance has a public IP or Elastic IP
- make sure that our security groups and network ACLs allow specific traffic
Subnets use cases:
- data store instances – private subnets
- batch-processing instances – private subnets
- backend instances – private subnets
- web app instances – public or private
Amazon VPC Routing
- when you create a VPC, AWS creates a route table called the main route table
- route table contains a set of rules, called routes, that are used to determine where network traffic is directed
- default configuration of the main route table is to allow traffic between all subnets in the local network (enables all resources in the VPC to communicate)
- each subnet must be associated with one route table. If we do not define it ourselves, it will be connected to the main table
- best practices is to create a separate route table for each subnet
Main table route:
- cannot be deleted
- gateway route table cannot be main route table
- main route table can be replaced with a custom subnet route table
- routes in main route table can be added/removed/modified
- subnet can be explicitly associated with the main route table, even if it is already implicitly associated
Custom route tables:
- if subnet has associated custom route table, it will use it instead of the main route table
- each custom route table has the local route installed by default (allowing communication between all resources and subnets inside the VPC)
- good practice to protect VPS is to leave the main route table in default state and explicitly associate each subnet with custom route table.
Amazon VPC Security
To secure subnets, you can use network ACL (Access Control Lists):
- Network ACLs are stateless (you need to include both the inbound and outbound ports used for the protocol, otherwise the server would respond, but traffic would never leave the subnet)
- Network ACLs, by default, allow incoming and outgoing traffic
VPC deployment model
- multi-VPC
- for single organizations or teams (managed service provider)
- for limited teams because it makes it easier to maintain standards and manage access
- exceptions may be: governance and compliance standards – they may require us to have greater isolation
- multi-account
- large organizations with multiple IT teams
- medium organizations that anticipate rapid growth
Gateways:
-
Internet gateway:
- connects your VPC to the internet (necessary to provide internet connection)
- an internet gateway is highly available and scalable (by default they are horizontally scalable, redundant and highly available)
- after you create an internet gateway, you attach it to your VPC
- we choose them as a target for internet-routable traffic
- it performs NAT (Network Address Translation)
-
Virtual private gateway (VPG):
- connects your VPC to another private network
- the gateway acts as anchor on the AWS side of the connection, the other side of the connection needs to be connected to a customer gateway in the other private network
- customer gateway device – physical device/software application on your side of the connection
- when you have both gateways, you can then establish an encrypted virtual private network (VPN) connection
Security groups
- they work like stateful firewalls controlling traffic to and from instances (stateful, i.e. return traffic is allowed by default, regardless of other rules)
- they work at the instance or network interface level
- traffic can be restricted to any internet protocol, service port, source and destination ip address
- by default there are no inbound rules, so any incoming traffic is blocked by default there is a rule allowing all outbound traffic, i.e. our instance can communicate with everyone. (if we remove it, no traffic from our instance will get out)
- rules can only allow or deny traffic
- most often we use chaining security group defining a separate security group for each tier with rules allowing traffic from a higher tier to a lower tier and back
Secure EC2 instances with security groups:
- security group, by default, blocks all inbound traffic and allows all outbound traffic (to allow inbound traffic, you must create inbound rules)
- security groups are stateful (they remember if a connection is originally initiated by the EC2 instance or from the outside, and temporarily allow traffic to respond without modifying the inbound rules)
- good practice it to organize resources into different groups and create security groups for each to control network communication between them (in on-premises environments, you isolate groups of resources with a VLAN configuration. In AWS, security groups allow you to achieve the same without tying the security groups to your network)
Network ACL
- they operate at the subnet level
- by default they allow all inbound and outbound traffic
- they are stateless firewalls, which means they require explicit rules for both directions (return traffic must be explicitly allowed, no request information is stored)
- each subnet must be associated with an acl (if not defined it is associated with the default acl)
- one acl can be associated with multiple subnets, but a subnet can only be associated with one acl
- by default each custom network ACL prohibits inbound and outbound traffic (i.e. the opposite of the default), recommended only for specific security requirements
Best practices are to provide protection at every layer by implementing the infrastructure in VPC and securing it with security groups and ACLs, thus ensuring security at the infrastructure and subnet level. Additionally, it is worth using a firewall at the operating system level
Elastic IP
- static, public IP address
- it can be connected to any instance or elastic network interface for any VPC on our account
- it allows for dynamic remapping of the address to another instance in the event of a failure
- using elastic ip and network interface, instead of assigning the address directly to the instance, allows for transferring all network interface attributes in one step
NAT gateway
- allows to initiate outbound connections from a private subnet to the Internet or other services, while blocking the initiation of inbound connections from the Internet
- when defining NAT, we select the public subnet to which it leads, the elastic IP that it will use and the private networks from which the traffic will go
Bastion host
- a server whose task is to provide access to a private network from an external network, minimizing the risk of attack on our architecture
AWS Site-to-Site VPN
- service that allows you to create a VPN connection between an on-premise network or a company branch and a VPC
- uses IPsec for encryption
- creates 2 tunnels per VPN connection, which we can use simultaneously
- you are charged per VPN connection-hour
- on the AWS side, the end is the Virtual Private Gateway (VPG), and on the client side the customer gateway
- when creating a site-to-site vpn connection, we must indicate what routing we will use (BGP or static) and update the routing tables
- we can establish several vn connections from customer gateway devices to a single virtual private gateway using AWS VPN CloudHub (which uses the hub-and-spoke model)
AWS Direct Connect (DX)
- establishes a secure physical connection between your on-premises data center and your Amazon VPC
- DX link connects our router to dx router in dx location using optical fiber. With such connection we can create public virtual interface to have access to public aws services (e.g. S3) or private virtual interface to have access to our VPC. We can have access to any VPC and aws service in any region (except China region) from any dx location. If we do not have equipment in dx location, we can access dx using DX AWS Partner Network (APN) Partner
- dedicated private network connection with 1Gbps or 10Gbps capacity
- similar to vpn to connect on-premise network to VPC
- uses 802.1q (VLANs) to establish dedicated private connection.
- allows for cost reduction, more coherent network and increased bandwidth
- useful for:
- hybrid environments (on-premise and AWS)
- transferring large datasets
- improving application performance
- security and compliance (regulations sometimes require its use)
DX and VPN
- to ensure high availability we can configure DX as a primary connection, with lower costs, and if something breaks, use VPN as a backup, which is billed per hour
VPC peering
- we usually want to have isolation between VPCs, but sometimes we may need to transfer some data between them, we can use VPC peering for this
- one-to-one connection between VPCs
- no gateways, VPNs and separate network appliances
- no single point of failure
- encrypted traffic always stays in AWS global backbone
- instances in vpn can communicate with each other as if they were in the same network
- we can even create a connection with a VPC that is on another aws account, or in another region
- to activate the connection, the owner of the VPC peer must accept the VPC peering connection request and we must add a route, pointing to the ip in the range of our peer, to one or more of our VPC route table. We also need to make sure that security groups do not stop this traffic
- ip addresses cannot overlap between CIDR blocks
- there can be only one peering resource between VPCs
- there is no support for transitive peering relationship
Consideration for peering multiple VPCs:
- connect only those VPCs that absolutely must be connected
- ensure that the solutions can scale
AWS Transit Gateway
- a service that allows you to connect VPCs and on-premise networks using a single gateway
- acts as a hub for all traffic
- connects up to 5,000 VPCs and on-premise environments using a single gateway
Connecting multiple VPCs:
- assumptions:non-overlapping addresses, one region
- we create a transit gateway
- deploy elastic network interfaces ENI (transit gateway connects to VPC using them. We make sure that each AZ included in the VPC has such an interface)
- update VPC route table (traffic intended for other vpcs should be sent through the gateway)
- update transit gateway route table (to route traffic between vpcs appropriately)
VPC endpoints
- allow for private connection of VPC to amazon services and to VPC endpoints services provided by AWS PrivateLink
- traffic does not leave amazon network
- does not require gateway, vpn, nat or firewall
- scalable redundant and highly available
Types of VPC endpoints
- interface endpoint – elastic network interface with private ip, created as an entry point for traffic supporting services. Powered by PrivateLink (e.g. Amazon CLoudWatch, EC2 API, Load Balancing)
- gateway endpoint – gateway that we will indicate in the route table as a target for traffic supporting aws service. Supported services: S3, dynamoDB
How to setup interface endpoint:
- specify the AWS service, endpoint service or aws marketplace service to which we want to connect
- select the VPC in which you want to create the endpoint interface
- select the subnet in the VPC that the endpoint interface will use. (you can select more than 1 subnet in different AZs)
- (optionally) enable DNS for the endpoint
- specify which security group to connect to the network interface
In this article, we explore the foundational elements of AWS networking. We begin with Virtual Private Clouds (VPCs), which are isolated networks that you create in the AWS cloud, defining key aspects like the VPC’s name, region, and IP range. Subnets are covered as crucial components within VPCs, designed to provide high availability and segregate resources into public and private areas. We delve into the roles of gateways, such as internet gateways and virtual private gateways, which facilitate internet access and secure connections to other private networks. The article also details the use of AWS Direct Connect for establishing secure physical connections to on-premises data centers. Finally, we highlight the importance of security through network ACLs and security groups, which manage and protect network traffic to ensure a secure cloud environment.