VPC
Amazon Virtual Private Cloud (VPC) is a web service that allows you to create a private network within the AWS cloud environment. With AWS VPC, you can define your own virtual network, including IP address ranges, subnets, and routing tables. This enables you to launch AWS resources, like Amazon EC2 instances, into a logically isolated section of the cloud. VPC provides control over your network's security, connectivity, and scalability, making it a fundamental building block for designing and deploying AWS applications.
Above image is a diagram that I used to testify my knowledge of VPC for preparing those AWS certifications.
Behaviour
AWS Global vs Regional vs AZ resources
Most of the AWS-managed services are regional-based services with few exceptions being Global (e.g. IAM, Route53, CloudFront, etc) or AZ bound.
- Virtual Private Cloud
- VPC -- Regional
- VPCs are created within a region
- Subnet -- Availability Zone
- A subnet can span only a single Availability Zone
- Security groups -- Regional
- A security group is tied to a region and can be assigned only to instances in the same region.
- VPC Endpoints-- Regional
- VPC Gateway & Interface Endpoints cannot be created between a VPC and an AWS service in a different region.
- VPC Peering --
Regional- VPC Peering can be performed across VPC in the same account of different AWS accounts
but only within the same region. They cannot span across regions - VPC Peering can now span inter-region
- VPC Peering can be performed across VPC in the same account of different AWS accounts
- Elastic IP Address -- Regional
- Elastic IP addresses created within the region can be assigned to instances within the region only.
- Elastic Network Interface -- Availability Zone
- VPC -- Regional
Future reading: AWS Global vs Regional vs AZ resources
Delete a VPC
- When you delete a VPC using the VPC console, AWS deletes all its components, such as subnets, security groups, network ACLs, route tables, Internet gateways, VPC peering connections, and DHCP options.
- When you delete a VPC using the command line, you must first terminate all instances, delete all subnets, custom security groups, and custom route tables, and detach any Internet gateway in the VPC.
Some points to remember
- Regardless of the type of subnet, the internal IPv4 address range of the subnet is always private. AWS never announces these address blocks to the internet.
- By default, all subnets can route between each other without the need for any further configuration, whether they are private or public. The main route table facilitates this communication.
- Every subnet that you create is automatically associated with the main route table for the VPC.
- If the public IP address of your instance in a VPC has been released, it will not receive a new one if there is more than one network interface attached to your instance. Reference: Unable to access EC2 Instance over the Public IP Address
EC2 communication within AWS network
When two instances communicate using public IP addresses, the following three scenarios are possible:
- Traffic between two EC2 instances in the same AWS Region stays within the AWS network, even when it goes over public IP addresses.
- Traffic between EC2 instances in different AWS Regions
- [Situation 1]: Traffic stays within the AWS network if there is an Inter-Region VPC Peering connection between the VPCs where the two instances reside.
- [Situation 2]: Traffic is not guaranteed to stay within the AWS network where there is no Inter-Region VPC Peering connection between the VPCs where these instances reside.
5 reserved IPs in each CIDR
In a VPC, the first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:
- 10.0.0.0: Network address.
- 10.0.0.1: Reserved by AWS for the VPC router.
- 10.0.0.2: Reserved by AWS. The IP address of the DNS server is the base of the VPC network range plus two. For VPCs with multiple CIDR blocks, the IP address of the DNS server is located in the primary CIDR. We also reserve the base of each subnet range plus two for all CIDR blocks in the VPC.
- 10.0.0.3: Reserved by AWS for future use.
- 10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.
Configuration
Configs with VPC wizard
A public subnet basically means that it has a route to the Internet Gateway and a private subnet does not.
4 Configurations that are supported by the Amazon VPC console wizard:
- VPC with a single public subnet
- We recommend this configuration if you need to run a single-tier, public-facing web application, such as a blog or a simple website.
- VPC with public and private subnets (with NAT)
- We recommend this scenario if you want to run a public-facing web application while maintaining back-end servers that aren't publicly accessible.
- VPC with public and private subnets and AWS Site-to-Site VPN access
- Plain english - can't access to the internet but allow access via Site-to-Site VPN access
- We recommend this scenario if you want to extend your network into the cloud and also directly access the Internet from your VPC.
- VPC with a private subnet only and AWS Site-to-Site VPN access
- The subnet is known as a VPN-only subnet
- We recommend this scenario if you want to extend your network into the cloud using Amazon's infrastructure without exposing your network to the Internet.
VPC Flow Logs
Source: Learn From Your VPC Flow Logs With Additional Meta-Data
VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. After you've created a flow log, you can retrieve and view its data in the chosen destination.
You can create a flow log for a VPC, a subnet, or a network interface. If you create a flow log for a subnet or VPC, each network interface in that subnet or VPC is monitored.
Flow log data for a monitored network interface is recorded as flow log records, which are log events consisting of fields that describe the traffic flow.
After you've created a flow log, you cannot change its configuration or the flow log record format. For example, you can't associate a different IAM role with the flow log or add or remove fields in the flow log record. Instead, you can delete the flow log and create a new one with the required configuration.
Routing table example
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. To put it simply, a route table tells network packets which way they need to go to get to their destination.
Within a VPC, route tables are assigned to individual subnets. With only 1 route table created in a VPC, all of the subnets would be assigned to that 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.
- Example 1
- Example 2
- Example 3
The following is an example of the route table for the public subnets, with routes for both IPv4 and IPv6. If you create IPv4-only subnets instead of dual stack subnets, your route table includes only the IPv4 routes.
Destination: 10.0.0.0/16 and Target: local
andDestination: 2001:db8:1234:1a00::/56 and Target: local
are the default entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other over IPv4 and IPv6.Destination: 0.0.0.0/0 and Target: igw-id
andDestination: ::/0 and Target: igw-id
route all other IPv4 subnet traffic to the Internet gateway (gw-id) which should have a value of 0.0.0.0/0 for its destination.
Destination | Target |
---|---|
10.0.0.0/16 | local |
2001:db8:1234:1a00::/56 | local |
0.0.0.0/0 | igw-id |
::/0 | igw-id |
The following is an example of a route table for one of the private subnets, with routes for both IPv4 and IPv6. If you created IPv4-only subnets, the route table includes only the IPv4 routes. The last route sends traffic destined for Amazon S3 to the gateway VPC endpoint.
Destination | Target |
---|---|
10.0.0.0/16 | local |
2001:db8:1234:1a00::/56 | local |
0.0.0.0/0 | nat-gateway-id |
::/0 | eigw-id |
s3-prefix-list-id | s3-gateway-id |
Split-tunnel
TL;DR - Split-tunnel allows only traffic destined to AWS is routed through the VPN tunnel, while other traffic goes directly to its destination, this it reduces the volume of outgoing traffic from AWS, therefore reducing the data transfer cost. Offical
By default, when you have a Client VPN endpoint, all traffic from clients is routed over the Client VPN tunnel. When you enable split-tunnel on the Client VPN endpoint, we push the routes on the Client VPN endpoint route table to the device that is connected to the Client VPN endpoint. This ensures that only traffic with a destination to the network matching a route from the Client VPN endpoint route table is routed over the Client VPN tunnel.
You can use a split-tunnel Client VPN endpoint when you do not want all user traffic to route through the Client VPN endpoint.
For example, split-tunnel is enabled on the Client VPN endpoint. Only traffic that's destined for the VPC (172.31.0.0/16) is routed over the Client VPN tunnel. Traffic that's destined for on-premises resources is not routed over the Client VPN tunnel.
Traffic Mirroring
Traffic Mirroring is an Amazon VPC feature that can be used to copy network traffic from an elastic network interface of type interface
. Users can send the traffic to out-of-band security and monitoring appliances for:
- Content inspection
- Threat monitoring
- Troubleshooting
The following diagram shows a traffic mirror session where the traffic mirror target is a network interface for an EC2 instance. Traffic Mirroring filters the traffic from the network interface of the mirror source and sends the accepted mirrored traffic to the mirror target.
The following are the key concepts for Traffic Mirroring:
- Source — The network interface to monitor.
- Filter — A set of rules that defines the traffic that is mirrored.
- Target — The destination for mirrored traffic.
- Session — Establishes a relationship between a source, a filter, and a target.
Packet truncation to the MTU value occurs when the following two conditions are true:
- The traffic mirror target is a standalone instance.
- The traffic packet size from the mirror source is greater than the MTU size for the traffic mirror target.
VPC peering
The architecture that VPC peering uses, is called Full Mesh
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account.
- VPCs can be in different Regions. Those VPCs would not be able to communicate unless you establish an inter-Region VPC peering connection. Some other methods can be public IP addresses, NAT gateway, NAT instances, VPN Connections or Direct Connect connections. reference
- Both VPCs for peering need to update their route table for communication
- You cannot create a VPC peering connection between VPCs that have matching or overlapping IPv4 or IPv6 CIDR blocks.
To mesh n VPCs together, you would need n*(n-1)/2 peering connections.
This creates huge complexity maintaining and configuring so many VPC Peering Connections at scale. For example:
- A full mesh of 10 VPC peers means 45 peering connections.
- A full mesh of 30 VPC peers mean 435 peering connections. That’s pretty horrible.
Not only that but VPC Peering only works between AWS VPCs. “VPC Peering” is not based on a standard protocol like BGP or IPSEC.
It’s something an AWS networking wizard/witch came up with in his/her dungeon (no sane person could have come up with AWS networking – it breaks many of the networking rules I’ve learned throughout my career).
You cannot use VPC peering to communicate with on-premises DCs or with other clouds
All the above are reasons why AWS introduced the concept of “Transit VPC” and subsequently “Transit Gateway” to support communications between multiple VPCs.
Imagine there are 2 VPCs, VPC-A (10.10.0.0/16) and VPC-B (192.168.0.0/16). To establish a VPC peering connection between the two VPCs which has an ID of pcx-tutsd0j0
, you need to declare the remote VPC IP block as Destination and choose the VPC peering connection ID as the target.
Endpoints
TL;DR - Enables private connectivity to services hosted in AWS, from within your VPC without using and Internet Gateway, VPN, NAT devices, or firewall proxies. Traffic between your VPC and the other service does not leave the Amazon network.
Source: What are VPC endpoints?
Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components. They allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.
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. There are two types of VPC endpoints:
- interface endpoints
- gateway endpoints
An interface endpoint
- Interface endpoint sits inside a subnet, and associated with a security group
- An interface endpoint is an elastic network interface with a private IP address from the IP address range of your subnet that serves as an entry point for traffic destined to a supported service.
A gateway endpoint
- Gateway endpoint sits inside a VPC and with a route table
- Gateway endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT device for your VPC. Gateway endpoints do not use AWS PrivateLink, unlike other types of VPC endpoints.
AWS PrivateLink
Interface endpoint and gateway endpoint are both backed by a technology called AWS PrivateLink
Source: Connect your VPC to services using AWS PrivateLink
AWS PrivateLink enables private network connectivity between VPCs and AWS services without using the public internet. It establishes a secure and direct connection over the AWS network backbone, allowing VPC resources to securely access AWS services, such as Amazon S3, Amazon EC2, or AWS Lambda, privately and without exposure to the internet.
PrivateLink ensures data privacy and reduces security risks by keeping traffic within the AWS network. It simplifies network architecture, eliminates the need for public IPs, and enhances performance and reliability by leveraging the low-latency, high-bandwidth AWS infrastructure.
Gateway
Transit Gateway
AWS Transit Gateway is a service that enables customers to connect their Amazon VPCs and their on-premises networks to a single gateway. With AWS Transit Gateway, you only have to create and manage a single connection from the central gateway into each Amazon VPC, on-premises data center, or remote office across your network.
It also supports IP Multicast. Multicast is a communication protocol used for delivering a single stream of data to multiple receiving computers simultaneously. Transit Gateway supports routing multicast traffic between subnets of attached VPCs, and it serves as a multicast router for instances sending traffic destined for multiple receiving instances.
Further reading: VPC peering vs. Transit VPC vs. Transit Gateway
- Without AWS Transit Gateway
- With AWS Transit Gateway
Complexity increases with scale. You must maintain routing tables within each VPC and connect to each onsite location using separate network gateways.
Your network is streamlined and scalable. AWS Transit Gateway routes all traffic to and from each VPC or VPN, and you have one place to manage and monitor it all.
Internet Gateway
TL;DR - To provide internet access for instnaces that have public IPs
An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet.
An Internet Gateway serves two purposes:
- to provide a target in your VPC route tables for internet-routable traffic
- to perform network address translation(NAT) for instances that have been assigned public IPv4 addresses.
To enable access to or from the internet for instances in a subnet in a VPC, you must do the following:
- Attach an Internet gateway to your VPC.
- Add a route to your subnet's route table that directs internet-bound traffic to the internet gateway.
- If a subnet is associated with a route table that has a route to an internet gateway, it's known as a public subnet.
- If a subnet is associated with a route table that does not have a route to an internet gateway, it's known as a private subnet.
- Ensure that instances in your subnet have a globally unique IP address (public IPv4 address, Elastic IP address, or IPv6 address).
- Ensure that your network access control lists and security group rules allow the relevant traffic to flow to and from your instance.
Egress-only Internet Gateway
An egress-only internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in your VPC to the internet, and prevents the internet from initiating an IPv6 connection with your instances.
- To enable outbound-only internet communication over IPv6, use a egress-only internet gateway instead.
- Don't forget to assign an IPv6 address to the instance in private subnet otherwise the instance cannot access IPv6 websites.
- To enable outbound-only internet communication over IPv4, use a NAT gateway instead.
- A public IPv4 address is not needed for the instance in private subnet. We can access IPv4 websites without it.
In the following diagram, the VPC has both IPv4 and IPv6 CIDR blocks, and the subnet both IPv4 and IPv6 CIDR blocks. The VPC has an egress-only internet gateway.
Reference: Enable outbound IPv6 traffic using an egress-only internet gateway
Dedicated vs Hosted connection
A dedicated connection is made through a 1 Gbps, 10 Gbps, or 100 Gbps Ethernet port dedicated to a single customer. Hosted connections are sourced from a AWS Direct Connect Partner that has a network link between themselves and AWS.
Direct Connect
AWS Direct Connect is a network service that provides an alternative to using the Internet to utilize AWS cloud services. AWS Direct Connect enables customers to have low latency and private connections to AWS for workloads that require higher speed or lower latency than the internet. Direct Connect is a paid service and is available only if the customer opts for it.
Source: Virtual interfaces (VIF)
You must create one of the following virtual interfaces to begin using your AWS Direct Connect connection.
- A public virtual interface (public VIF) enables access to public services such as Amazon S3 or Amazon Connect.
- A private virtual interface (private VIF) enables access to your VPC and hosted workloads.
- A transit virtual interface (transit VIF) is used to access one or more Amazon Transit Gateways associated with Direct Connect gateways.
For more information, see AWS Direct Connect virtual interfaces.
Direct Connect Resiliency
- Maximum Resiliency
- High Resiliency
- Non-Critical
Maximum resilience is achieved by separate connections terminating on separate devices in more than one location. This configuration offers customers maximum resilience to failure. As shown in the figure below, such a topology provides resilience to
- device failure
- connectivity failure
- complete location failure
You can use AWS Direct Connect gateway to access any AWS Region (except AWS Regions in China) from any AWS Direct Connect locations.
For critical production workloads that require high resiliency, it is recommended to have one connection at multiple locations. As shown in the figure below, such a topology ensures resilience to
- connectivity failure due to a fiber cut or a device failure
- a complete location failure
You can use AWS Direct Connect gateway to access any AWS Region (except AWS Regions in China) from any AWS Direct Connect location.
As shown in the figure below, such a topology helps in the case of the device failure at a location but does not help in the event of a total location failure.
Direct Connect vs Site-to-Site VPN
- AWS Direct Connect(拉線) is an excellent choice for businesses seeking a secure, ultra-low latency, and high bandwidth connection to AWS because it establishes a dedicated network connection from your premises to AWS. It links one end of the cable is connected to your router, and the other to an AWS Direct Connect router. Although configuring AWS Direct Connect may sometimes take more time due to the physical Ethernet connection, once a connection is established, it is worth it because the network performance is easy to predict, and you can save on data transfer costs.
- Connections go over private network
- AWS Site-to-Site VPN is a great connection option for businesses that are just starting to use AWS. It is quick and easy to set up. But keep in mind that the VPN connection normally uses the public Internet, which may have unpredictable performance, and although it is encrypted, there may still be security concerns.
- Connections go over public network
Direct Connect + Site-to-Site VPN
Source: AWS Direct Connect + AWS Site-to-Site VPN
This solution combines the benefits of the end-to-end secure IPsec connection with low latency and increased bandwidth of the AWS Direct Connect to provide a more consistent network experience than internet-based VPN connections.
A BGP connection session is established between AWS Direct Connect and your router on the public VIF. Another BGP session or a static route will be established between the virtual private gateway (also known as a VPN Gateway) and your router on the IPsec VPN tunnels.
NAT
NAT Gateway
TL;DR - To provide internet access for instnaces that don't have public IPs.
NAT Gateway enables private subnets within a Virtual Private Cloud (VPC) to access the internet while keeping the instances within those subnets private and protected. The NAT Gateway acts as a gateway between the private subnet and the public internet, allowing outgoing internet traffic from the private instances and providing them with a public IP address. It simplifies the configuration and management of outbound internet connectivity, ensuring secure and controlled access for resources within the private subnets.
The following 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.
Source: AWS NAT Gateways
Here are the stpes to create a NAT Gateway:
- 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.
The blackhole
status indicates that the route's target isn't available (for example, the specified gateway isn't attached to the VPC, the specified NAT instance has been terminated, and so on).
NAT instance vs NAT gateway
These are the most important points.
- NAT instance can be used as a bastion server
- Security Groups can be associated with a NAT instances
- NAT instance supports port forwarding
- Both NAT instance and NAT gateway need to sit in a public subnet (a subnet that has a route table with a route to the internet gateway) for the internet access.
The following is a high-level summary of the differences between NAT gateways and NAT instances. We recommend that you use NAT gateways because they provide better availability and bandwidth and require less effort on your part to administer.
Attribute | NAT gateway | NAT instance |
---|---|---|
Maintenance | 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. |
Cost | 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. |
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. |
Security groups | 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. |
Network ACLs | 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. |
Port forwarding | Not supported. | Manually customize the configuration to support port forwarding. |
Bastion servers | Not supported. | Use as a bastion server. |
Full table of comparision: Compare NAT gateways and NAT instances
Including bastion hosts in your VPC environment enables you to securely connect to your Linux instances without exposing your environment to the Internet. After you set up your bastion hosts, you can access the other instances in your VPC through Secure Shell (SSH) connections on Linux. Bastion hosts are also configured with security groups to provide fine-grained ingress control.
You need to remember that Bastion Hosts are using the SSH protocol, which is a TCP based protocol on port 22. They must be publicly accessible.
NAT instances allows outbound traffic from instances in VPC where as Bastion instance allows inbound SSH traffic to the instances in VPC.
NAT in multiple AZ
If you have resources in multiple Availability Zones and they share one NAT gateway, and if the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose internet access.
To incrase the availability of the system, you need to create an Availability Zone-independent architecture - which means you need to create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone.
VPN
When you create a Site-to-Site VPN connection, you must do the following:
- Specify the type of routing that you plan to use (static or dynamic)
- Update the route table for your subnet
Site-to-Site VPN Connection
Amazon VPC provides the facility to create an IPsec VPN connection (also known as site-to-site VPN) between remote customer networks and their Amazon VPC over the internet. The following are the key concepts for a site-to-site VPN:
- Virtual private gateway: A Virtual Private Gateway (also known as a VPN Gateway) is the endpoint on the AWS VPC side of your VPN connection.
- VPN connection: A secure connection between your on-premises equipment and your VPCs.
- VPN tunnel: An encrypted link where data can pass from the customer network to or from AWS.
- Customer Gateway: An AWS resource that provides information to AWS about your Customer Gateway device.
- Customer Gateway device: A physical device or software application on the customer side of the Site-to-Site VPN connection.
How to setup route table
When establishing a static VPN connection between an on-premises network and a VPC in AWS, the virtual private gateway (also known as a VPN Gateway) must be configured to route traffic to the customer gateway on the on-premises side, and the customer gateway must be configured to route traffic to the virtual private gateway on the AWS side.
From the AWS side, in order to enable instances in your VPC to reach your customer gateway, you must configure your route table to include the routes used by your VPN connection and point them to your virtual private gateway. You can enable route propagation for your route table to automatically propagate those routes to the table for you.
Reference: Site-to-Site VPN routing options
The type of routing that you select can depend on the make and model of your customer gateway device. If your customer gateway device supports Border Gateway Protocol (BGP), specify dynamic routing when you configure your Site-to-Site VPN connection. If your customer gateway device does not support BGP, specify static routing.
For static routing, the static IP prefixes that you specify for your VPN configuration are propagated to the route table when the status of the VPN connection is UP. Similarly, for dynamic routing, the BGP-advertised routes from your customer gateway are propagated to the route table when the status of the VPN connection is UP.
Imagine you have 3 subnets - 10.0.0.0/20
, 10.0.16.0/20
, and 10.0.32.0/20
and now you want to connect them to a route table to allow communication between them. To do so, you'll need to set the following route in the route table:
- Destination:
10.0.0.0/16
(WS automatically configures the route table for a VPC, it sets the route to cover the entire VPC's CIDR range.) - Target:
local
This route allows all traffic within the 10.0.0.0/16
range to be routed locally within the VPC, enabling communication between the specified subnets.
VPN CloudHub
Source: VPN CloudHub
There are 2 use cases that you may consider to use VPN CloudHub:
- If you have multiple AWS Site-to-Site VPN connections, you can provide secure communication between sites using the AWS VPN CloudHub. This enables your remote sites to communicate with each other, and not just with the VPC.
- Sites that use AWS Direct Connect connections to the virtual private gateway can also be part of the AWS VPN CloudHub.
Elastic IP
AWS releases your instance's public IP address when you associate an Elastic IP address with it. When you disassociate the Elastic IP address from your instance, it receives a new public IP address.
EIPs are used when
- You need a static + public IP. More infor about static and public ip, please check Static & Public IP Address
- You want to mask the failure of an instance or software by rapidly remapping the address to another instance in your account.
Within the AWS infrastructure, customers have virtual private clouds (VPC), within the VPCs, users have instances. So when you launch an EC2 instance, you receive a Public IP address by which that instance is reachable from internet. Once you stop that instance and restart the instance you get a new Public IP for the same instance. So it's basically a problem to connect your instance from internet for not having a static IP. To overcome this problem, we attach an Elastic IP to an Instance which doesn't change after you stop / start the instance.
In general, you should be good without Elastic IPs for most of the use-cases. If you're using AWS Load Balancers, you won't want to use Elastic IPs, as your gateway address (the last endpoint before going out to the internet) is be the Load Balancer itself, which has a static hostname (but not a static IP). The load balancer runs on AWS, and you associate it with instances based on their instance IDs, not the public IP address. But, if you're using an external CDN service like Fastly, you need to use Elastic IPs, as the gateway IP is the EC2 instance's public IP.
By default, all AWS accounts are limited to five (5) Elastic IP addresses per Region, because public (IPv4) internet addresses are a scarce public resource.
Use case
Let’s say you setup the apache to host a website. Now, you need to scale up that machine due to any reason or you need to move that machine into another reason , you need to stop that machine. Whenever you restart again, the public ip from associated with that machine can also change.
So it may be the case that you need to update all DNS entries again. However, You can reserve the public ip for you and that ip can be attached to any ec2 which you have, so there will be no issue regarding PUBLIC IP Change.
Elastic IP is a free service, but you’re limited to five in total (to prevent exhaustion of Amazon’s address pool). And, while they are entirely free to use, they’re actually the only AWS service that costs money if you don’t use it
Having an Elastic IP provisioned but not attached to a running machine will cost you $7.50 a month. Make sure your machine isn’t off for extended periods of time, and if you change servers or stop using the IP, make sure to release it so you aren’t charged for letting it sit idle in your account.
Reallocate Elastic IP address
You can move an Elastic IP (EIP) address in AWS from one EC2 instance to another within the same region. Elastic IPs are designed to be easily reassigned and are not bound to a specific EC2 instance permanently. This allows you to maintain the same public IP address even when you stop or terminate an EC2 instance, or when you want to associate the IP address with a different EC2 instance for uninterrupted service to your application.
How to avoid using Elastic IP
- Always think if other alternatives are available to you
- You could use a random public IP and register a DNS name to it
- Or use a Load Balancer with a static hostname
Troubleshooting & others
Share subnet across accounts
AWS Resource Access Manager (RAM) is a service that enables you to easily and securely share AWS resources with any AWS account or within your AWS Organization. You can share the subnet(s) within a VPC using RAM. This will allow all EC2 instances to be deployed in the same VPC (although from different accounts) and easily communicate with one another.
To set this up, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.
AWS RAM enables you to share specified AWS resources that you own with other AWS accounts. It's a centralized service that provides a consistent experience for sharing different types of AWS resources across multiple accounts.
NACL vs Security group
In most cases, security groups can meet your needs; however, you can also use network ACLs if you want an additional layer of security for your VPC.
AWS provides two features that you can use to increase security in your VPC: security groups and network ACLs. Security groups control inbound and outbound traffic for your instances, and network ACLs control inbound and outbound traffic for your subnets.
- Network Access Control List
- You can control what goes in and out of your VPC
- You can associate a network ACL with multiple subnets; howevery, a subnet can be associated with only one network ACL at a time.
- It is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.
- Your VPC automatically comes with a modifiable default network ACL. By default, it allows all inbound and outbound IPv4 and IPv6 on all ports.
- Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it's applied regardless of any higher-numbered rule that might contradict it. The Asterisk in for list is for 包底
- Security groups
- You can control what goes in and out your instances
- Security groups are associated with network interfaces
- Security groups only support allow rules to pass through
- 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.
Source: Security Group and Network Access Control List Migration between different VPCs
Source: Youtube: AWS Network Access Control List | AWS NACL | NACL
This is a VPC flow log to demostrate what it looks like when Network ACL permits inbound ICMP traffic but does not permit outbound ICMP traffic. In this example, I usde the ping command from your home computer (IP address is 203.0.113.12) to an EC2 instance (the network interface’s private IP address is 172.31.16.139)
Apparently, the first one is an ACCEPT
record, and the second one is a REJECT
record, which means that the incoming traffic was successfully accepted by your EC2 instance, but the response, or the outgoing traffic, was rejected by either your security group or network ACL.
<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>
2 123456789010 eni-1235b8ca 110.237.99.166 172.31.17.140 0 0 1 4 336 1432917027 1432917142 ACCEPT OK
2 123456789010 eni-1235b8ca 172.31.17.140 110.237.99.166 0 0 1 4 336 1432917094 1432917142 REJECT OK
Compare IPv4 and IPv6
The following table summarizes the differences between IPv4 and IPv6 in Amazon EC2 and Amazon VPC. For a list of AWS services that support dual-stack configuration (IPv4 and IPv6) and IPv6-only configurations, see Services that support IPv6 / Getting started with IPv6 on AWS for more details.
You can create a custom VPC with both IPV4 and IPV6 support (Dual Support).
- IPV4 CIDR Block: 10.0.0.0/16
- IPV6 CIDR Block: AWS will provide you a /56 IPV6 CIDR Block (You cannot explicitly specify an IP range for IPv6, as this is only provided by Amazom)
Characteristic | IPv4 | IPv6 |
---|---|---|
VPC size | Up to 5 CIDRs from /16 to /28. This quota is adjustable. | Up to 5 CIDRs fixed at /56. This quota is not adjustable. |
Subnet size | From /16 to /28 | Fixed at /64 |
Address selection | You can choose the IPv4 CIDR block for your VPC or you can allocate a CIDR block from Amazon VPC IP Address Manager (IPAM). For more information, see What is IPAM? in theAmazon VPC IPAM User Guide. | You can bring your own IPv6 CIDR block to AWS for your VPC, choose an Amazon-provided IPv6 CIDR block, or you can allocate a CIDR block from Amazon VPC IP AAddress Manager (IPAM). For more information, see What is IPAM? in theAmazon VPC IPAM User Guide. |
Internet access | Requires an internet gateway. | Requires an internet gateway. Supports outbound-only communication using an egress-only internet gateway. |
Elastic IP addresses | Supported. Gives an EC2 instance a permanent, static public IPv4 address. | Not supported. EIPs keep the public IPv4 address of an instance static on instance restart. IPv6 addresses are static by default. |
NAT gateways | Supported. Instances in private subnets can connect to the internet using a public NAT gateway or to resources in other VPCs using a private NAT gateway. | Supported. You can use a NAT gateway with NAT64 to enable instances in IPv6-only subnets to communicate with IPv4-only resources within VPCs, between VPCs, in your on-premises networks, or over the internet. |
DNS names | Instances receive Amazon-provided IPBN or RBN-based DNS names. The DNS name resolves to the DNS records selected for the instance. | Instance receive Amazon-provided IPBN or RBN-based DNS names. The DNS name resolves to the DNS records selected for the instance. |
Wavelength & Carrier gateway
AWS Wavelength embeds AWS compute and storage services within 5G networks, providing mobile edge computing infrastructure for developing, deploying, and scaling ultra-low-latency applications.
Some use cases of wavelength are: Game streaming, live video and event streaming, and machine learning (ML) video inference are examples of emerging interactive applications. To ensure ultra-low latency for end-users and devices connecting via mobile networks, these workloads necessitate computing and storage close to the edge. Furthermore, use cases such as industrial automation, smart cities, IoT, and autonomous vehicles necessitate data processing and retrieval close to the edge in order to meet application performance requirements. AWS Wavelength and Wavelength Zones can help with all of these use cases.
Source: How AWS Wavelength works
Carrier gateways are only available for VPCs that contain subnets in a Wavelength Zone. The carrier gateway provides connectivity (inbounda and outbound traffic) between your Wavelength Zone and the telecommunication carrier, and devices on the telecommunication carrier network.
PrivateLink connectivity between AWS Storage Gateway and Amazon S3
- Create a VPC endpoint for Amazon S3
- Create a file gateway using a VPC endpoint
Source: Connect Amazon S3 File Gateway using AWS PrivateLink for Amazon S3