VPC stands for virtual private cloud. VPC is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.
Following are the key components of VPC
- Virtual private cloud (VPC) — A virtual network dedicated to your AWS account.
- Internet gateway — A gateway that you attach to your VPC to enable communication between resources in your VPC and the internet.
- Route table — A set of rules, called routes, that are used to determine where network traffic is directed. You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table.
- Network ACL – It is a list of rules to determine whether traffic is allowed in or out of any subnet associated with the network ACL
- Subnet — A subnet is a logical partition within a VPC. It is a range of IP addresses in your VPC. You can launch AWS resources into a specified subnet. Use a public subnet for resources that must be connected to the internet, and a private subnet for resources that won’t be connected to the internet .
- VPC endpoint — Enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
- CIDR block —Classless Inter-Domain Routing. An internet protocol address allocation and route aggregation methodology. For more information, see Classless Inter-Domain Routing in Wikipedia.
When new account is created, following components are already created for you.
- Default VPC
- Internet Gateway
- Main route table
- Main network ACL : Associated with all subnets
- Subnets in each of the availability zones
- Security Group
When you create new VPC, it does not create subnet. In each region, AWS automatically provides a default VPC with default subnets, a main route table, a default security group, and a default NACL.
If you delete VPC following is deleted
There are different ways to represent a range of IP addresses. The shortest way is by CIDR notation, sometimes called slash notation. For example, the CIDR 172.16.0.0/16 includes all addresses from 172.16.0.0 to 172.16.255.255—a total of 65,536 addresses!
Valid IPv4 prefix lengths range from /0 to /32. Although you can specify any valid IP range for your VPC CIDR, it’s best to use one in the RFC 1918 range to avoid conflicts with public Internet addresses.
- 10.0.0.0–10.255.255.255 (10.0.0.0/8)
- 172.16.0.0–172.31.255.255 (172.16.0.0/12)
- 192.168.0.0–192.168.255.255 (192.168.0.0/16)
192.988.0.0/24 – 24 indicates the first 6 numbers of network. When you manually creates Subnet IP range must fall within VPC IP range
- VPC 126.96.36.199/16
- sub 188.8.131.52/24
- /32 is a network mask of 255.255.255.255
- /24 is a network mask of 255.255.255.0
Point to be noted:
192.168.0.254/32 = ip address of 192.168.0.254
192.168.0.1/24 = range of ip’s from 192.168.0.1 to 192.168.0.255
A subnet is a logical partition within a VPC that holds your EC2 instances. A subnet lets you isolate instances from each other, control how traffic flows to and from your instances, and lets you organize them by function. For example, you can create one subnet for public web servers that need to be accessible from the Internet and create another subnet for database servers that only the web instances can access.
Each subnet has its own CIDR block that must be a subset of the VPC CIDR that it resides in. For example, if your VPC has a CIDR of 172.16.0.0/16, one of your subnets may have a CIDR of 172.16.100.0/24. This range covers 172.16.100.0–172.16.100.255, which yields a total of 256 addresses
A subnet can exist within only one availability zone
aws ec2 create-subnet-vpc-id [VPC resource ID] --cidr-block 172.16.100.0/24 --availability-zone us-east-1a
Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet. Every subnet that you create is automatically associated with the main route table for the VPC. You can change the association, and you can change the contents of the main route table.
To connect to internet following is needed
- connection to internet (IGW)
- route (Route table)
- public ip (IP)
An Internet gateway gives instances the ability to receive a public IP address, connect to the Internet, and receive requests from the Internet.
When you create a VPC, it does not have an Internet gateway associated with it. You must create an Internet gateway and associate it with a VPC manually. You can associate only one Internet gateway with a VPC. But you may create multiple Internet gateways and associate each one with a different VPC.
A route table contains a set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed.
Main route table The route table that automatically comes with your VPC. It controls the routing for all subnets that are not explicitly associated with any other route table.
Your VPC has an implicit router, and you use route tables to control where network traffic is directed. Each subnet in your VPC must be associated with a route table, which controls the routing for the subnet (subnet route table). You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table. A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same subnet route table.
IP routing is destination-based, meaning that routing decisions are based only on the destination IP address , not the source.
To enable Internet access for your instances, you must create a default route pointing to the Internet gateway
- A local route that allows instances in different subnets to communicate with each other.
- enable your subnet to access the internet through an internet gateway
Any subnet that is associated with a route table containing a default route pointing to an Internet gateway, meaning if a subnet’s traffic is routed to an internet gateway, it is called a public subnet. Contrast this with a private subnet that does not have a default route.
- A security group acts as a virtual firewall for your instance to control inbound and outbound traffic.
- Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC can be assigned to a different set of security groups.
Distributed firewalls and firewalls are stateful
- You can specify allow rules, but not deny rules.
- You can specify separate rules for inbound and outbound traffic.
- Security group rules enable you to filter traffic based on protocols and port numbers.
- Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
- You can add and remove rules at any time. Your changes are automatically applied to the instances that are associated with the security group.
- When you associate multiple security groups with an instance, the rules from each security group are effectively aggregated to create one set of rules.
When you create a security group, it doesn’t contain any inbound rules. Security groups use a default-deny approach, also called whitelisting, which denies all traffic that is not explicitly allowed by a rule.
Inbound rules specify what traffic is allowed into the attached ENI. An inbound rule consists of three required elements:
- Port range
- SSH access only from IP 198.51.100.10
- HTTPS access from internet. The prefix 0.0.0.0/0 covers all valid IP addresses
the outbound rules of a security group will be less restrictive than the inbound rules. When you create a security group, AWS automatically creates the outbound rule listed
- Port range
Network Access Control Lists
Like a security group, a network access control list (NACL) functions as a firewall in that it contains inbound and outbound rules to allow traffic based on a source or destination CIDR, protocol, and port. Also, each VPC has a default NACL that can’t be deleted. But the similarities end there.
A NACL differs from a security group in many respects. Instead of being attached to an ENI, a NACL is attached to a subnet. The NACL associated with a subnet controls what traffic may enter and exit that subnet. This means that NACLs can’t be used to control traffic between instances in the same subnet. If you want to do that, you have to use security groups.
- NACL rule order matters! Create a new NACL
- NACL rules are processed in ascending order of the rule number. Any traffic not matching this rule would be processed by next rule.
Inbound rules determine what traffic is allowed to ingress the subnet. Each rule contains the following elements:
- Rule number
- Port range
As you might expect, the outbound NACL rules follow an almost identical format as the inbound rules. Each rule contains the following elements:
- Rule number
- Port range
Using Network Access Control Lists and Security Groups Together
You may want to use a NACL in addition to a security group so that you aren’t dependent upon users to specify the correct security group when they launch an instance. Because a NACL is applied to the subnet, the rules of the NACL apply to all traffic ingressing and egressing the subnet, regardless of how the security groups are configured.
When you make a change to a NACL or security group rule, that change takes effect immediately
Network Address Translation Devices
Although network address translation occurs at the Internet gateway, there are two other resources that can also perform NAT.
AWS calls these NAT devices. The purpose of a NAT device is to allow an instance to access the Internet while preventing hosts on the Internet from reaching the instance directly. This is useful when an instance needs to go out to the Internet to fetch updates or to upload data but does not need to service requests from clients.
When you use a NAT device, the instance needing Internet access does not have a public IP address allocated to it. Incidentally, this makes it impossible for hosts on the Internet to reach it directly. Instead, only the NAT device is configured with a public IP. Additionally, the NAT device has an interface in a public subnet
Configuring Route Tables to Use NAT Devices
Instances that use the NAT device must send Internet-bound traffic to it, while the NAT device must send Internet-bound traffic to an Internet gateway. Hence, the NAT device and the instances that use it must use different default routes. Furthermore, they must also use different route tables and hence must reside in separate subnets.
Route Table for private instance using NAT gateway
Route table for public instance
A NAT gateway is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services cannot initiate a connection with those instances.
- It automatically scales to accommodate your bandwidth requirements. You set it and forget it.
- You create a public NAT gateway in a public subnet and must associate an elastic IP address with the NAT gateway at creation.
- you can use a public NAT gateway to connect to other VPCs or your on-premises network. In this case, you route traffic from the NAT gateway through a transit gateway or a virtual private gateway.
When you create a NAT gateway, you must assign it an EIP. A NAT gateway can reside in only one subnet, which must be a public subnet for it to access the Internet. AWS selects a private IP address from the subnet and assigns it to the NAT gateway. For redundancy, you may create additional NAT gateways in different availability zones.
A NAT instance is a normal EC2 instance that uses a preconfigured Linux-based AMI. You have to perform the same steps to launch it as you would any other instance. It functions like a NAT gateway in many respects, but there are some key differences.
Unlike a NAT gateway, a NAT instance doesn’t automatically scale to accommodate increased bandwidth requirements. Therefore, it’s important that you select an appropriately robust instance type. If you choose an instance type that’s too small, you must manually upgrade to a larger instance type.
||Highly available. NAT gateways in each Availability Zone are implemented with redundancy. Create a NAT gateway in each Availability Zone to ensure zone-independent architecture.
||Use a script to manage failover between instances.
||Scale up to 45 Gbps.
||Depends on the bandwidth of the instance type.
||Managed by AWS. You do not need to perform any maintenance.
||Managed by you, for example, by installing software updates or operating system patches on the instance.
||Software is optimized for handling NAT traffic.
||A generic AMI that’s configured to perform NAT.
||Charged depending on the number of NAT gateways you use, duration of usage, and amount of data that you send through the NAT gateways.
||Charged depending on the number of NAT instances that you use, duration of usage, and instance type and size.
|Type and size
||Uniform offering; you don’t need to decide on the type or size.
||Choose a suitable instance type and size, according to your predicted workload.
|Public IP addresses
||Choose the Elastic IP address to associate with a public NAT gateway at creation.
||Use an Elastic IP address or a public IP address with a NAT instance. You can change the public IP address at any time by associating a new Elastic IP address with the instance.
|Private IP addresses
||Automatically selected from the subnet’s IP address range when you create the gateway.
||Assign a specific private IP address from the subnet’s IP address range when you launch the instance.
||You cannot associate security groups with NAT gateways. You can associate them with the resources behind the NAT gateway to control inbound and outbound traffic.
||Associate with your NAT instance and the resources behind your NAT instance to control inbound and outbound traffic.
||Use a network ACL to control the traffic to and from the subnet in which your NAT gateway resides.
||Use a network ACL to control the traffic to and from the subnet in which your NAT instance resides.
||Use flow logs to capture the traffic.
||Use flow logs to capture the traffic.
||Manually customize the configuration to support port forwarding.
||Use as a bastion server.
||View CloudWatch metrics for the NAT gateway.
||View CloudWatch metrics for the instance.
||When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempt to continue the connection (it does not send a FIN packet).
||When a connection times out, a NAT instance sends a FIN packet to resources behind the NAT instance to close the connection.
||Supports forwarding of IP fragmented packets for the UDP protocol. Does not support fragmentation for the TCP and ICMP protocols. Fragmented packets for these protocols will get dropped.
||Supports reassembly of IP fragmented packets for the UDP, TCP, and ICMP protocols.
NAT getway allows only response to come back and does not allow internet to reach private submnet
Elastic IP Addresses
An elastic IP address (EIP) is a type of public IP address that AWS allocates to your account when you request it. Once AWS allocates an EIP to your account, you have exclusive use of that address until you manually release it. Outside of AWS, there’s no noticeable difference between an EIP and an automatically assigned public IP.
When you initially allocate an EIP, it is not bound to any instance. Instead, you must associate it with an ENI. You can move an EIP around to different ENIs, although you can associate it with only one ENI at a time. Once you associate an EIP with an ENI, it will remain associated for the life of the ENI or until you disassociate it.
Ingress traffic is composed of all the data communications and network traffic originating from external networks and destined for a node in the host network.
Egress traffic is the reverse of ingress traffic. Egress is all traffic is directed towards an external network and originated from inside the host network.
If you want your instances to be accessible from the Internet, you must provision an Internet gateway, create a default route, and assign public IP addresses. Those are the basics. If you choose to use a NAT gateway or instance or a VPC peering connection, you’ll have to modify multiple route tables.
NAT instance enables hosts in a private subnet within your VPC, outbound access to the internet. a NAT instance allows instances within your VPC to go out to the internet.
Bastion host allows inbound access to known IP addresses and authenticated users. Bastion host allows access to internal private services to approved sources.
Mostly the bastian host is used for incoming access
NAT instance is for providing outgoing access to the instance
VPC Flow logs
It captures the ip logs. Can be stored on S3 and send to CloudWatch logs.
- CloudTrail : API Calls
- Flow Logs : IP Traffic
All encompassing VPC design
Here are sample design presented in our of the AWS presentation
Hope this is helpful !