Introduction
AWS announced in July 2023 that it would charge all Public IPv4 addresses beginning February 1, 2024.
Until now, AWS only charged Public IPv4 addresses when they were unassigned, and some people think it's terrible that AWS is trying to gain more money ...
But other people like us think that's not a big deal and is an excellent opportunity to save IPv4 addresses.
We have a big problem with IPv4 Addresses; when DARPA (Defense Advanced Research Projects Agency) wrote the protocol in 1981, nobody thought that 4.294.967.296 IPs would be exhausted on the feature.
At that time, personal computers were rare, the Web didn't exist, and nobody could imagine the idea of smartphones.
In 2011, IANA (Internet Assigned Numbers Authority) assigned the last IPv4 address blocks. If you need an IPv4 address, you will buy it from anyone with an IPv4 address without using it, which creates a lot of problems for any company that needs an IPv4.
At the end of 1995, the Internet Engineering Task Force (IETF) started to write a new protocol (IPv6) because they knew at that moment that IPv4 addresses would be exhausted in a few years. Internet was in early adoption (Few people use it).
The adoption of IPv6 is too slow. Many Telecommunications Companies use IPv6, and we, as users of them, use IPv6. Still, many companies that publish services on the Internet don't use it because it is a hard change to implement quickly.
That's the reason for this change. We need to use fewer IPv4 addresses; if AWS doesn't charge, we will continue using many IPv4 addresses.
And the big questions that you may be asking:
- How many IPv4 addresses are we using on AWS?
- How much will AWS charge me?
- How can we save IPv4 easily without using IPv6?
How to list the IPv4 Space in use
Some time ago, AWS released a tool for listing, analyzing, and auditing the public IPv4 space being used. This tool is called Amazon VPC IP Address Management (IPAM).
Before deepening dive into this topic, we must differentiate four types of public IPv4 addresses in AWS:
EC2 public IP addresses:
Public IPv4 addresses are taken from an Amazon pool and are only associated with the EC2 instances. When stopping, hibernating, or terminating the instance, the IP gets released back to the pool, and you cannot reuse it.Elastic IP addresses:
Public IPv4 addresses that can be allocated to your account. They can be associated and disassociated from instances as required. They are allocated until you choose to release them (from the account & not the service)Service-managed public IPv4 addresses
AWS internet-faced-managed services deployed in your account:
Elastic Load Balancers, NAT Gateways, AWS Global Accelerator, AWS Site-to-Site VPN...BYOIP addresses
AWS will not charge you for bringing your own IP Space
These IPs can be used in pools to assign to your EC2 instances or NAT Gateways.
Having this in our mind, it is time to use the Amazon VPC IPAM to check the public IPv4 space that is in use and its resources.
- Log in to your AWS account.
- Search for Amazon VPC IP Address Manager in the search bar.
- Click on “Create IPAM”
- Select the marked options:
Notes:
- The Free Tier will perform the checks on your organization for public IPv4 usage
- The Advanced Tier will check on your organization for both public and private IP addresses, at a cost
- You can add a name tag or a description to it - optional
- Click on “Add All Regions” to perform a report on our global infrastructure
- Click on “Create IPAM.”
After some minutes, you will be able to see a report with all the IPv4s your organization is using under the Public IP Insights menu:
For each IPv4 in use, AWS will bill $0.005 per hour; this means 0.005 x 8760 hours in a year = $43.8 per year for each IPv4
If you have 10 IPs in use, you will pay $438 for this IP space.
If you have 100… it will sum to $4380
If you have 1000… well... add another 0
How can I reduce the IPv4 usage?
To use a Load Balancer
Using a Load Balancer to expose our application is an AWS Best practice and reduces the number of Public IPs; instead of using one IP for every EC2, we will use one IP per subnet where the ALB is deployed.
Advantages:
- You improve your availability because the ALB is working on a high availability setup.
- You strengthen your scalability using Auto Scaling groups as a target of Load Balancer.
- You can offload SSL using certificates on Load Balancer.
- Your security can be better using WAF rules.
- You can use HTTP or HTTPS ports using ALB or any TCP ports using NLB.
Disadvantages:
- Cost (Not too much, but add cost to your solution)
To use a Load Balancer doing a reverse proxy
Using a Load Balancer to expose our application is an AWS Best practice and reduces the number of Public IPs; instead of using one IP for every EC2, we will use one IP per subnet where the ALB is deployed.
What happens if we deploy a lot of Load Balancers with few servers? That is a problem because we are wasting a lot of IPs (and Load Balancers)
Since 2017, AWS has supported using an Application Load Balancer like a reverse proxy. This is a remarkable improvement because we can use one load balancer for multiple target groups depending on the host header with your requested URL.
With this feature, you can use only a load balancer for your entire application.
But what happens with the encryption? We need to use multiple certificates, one per URL.
You could use the same DNS zone and a wildcard. Still, it is not a very good idea, and security teams don't like wildcard certificates (Exist some security issues with wildcard certificates …)
But we can use another cool ALB feature like SNI (Server Name Indicator) that permits using multiple certificates for different DNS names in the same ALB.
Advantages
- Reduce the number of Public IPs used by our applications
- We Reduce the number of ALBs used by our applications.
- We are saving costs because fewer ALBs and public IPs mean fewer costs for us.
- We Centralize the management of ALBs.
Disadvantages
- We Create a dependency on other teams. If we have multiple stacks to manage every application, we create a dependency with the stack that contains the centralized ALB.
- It could be a problem using WAF because WAF rules are the same for all applications, and some rules must be more specific.
- The solution only works on a multi-account deployment. ALB can send requests to target groups in the same account but not to target groups in other accounts. ALB permits sending requests to other accounts' IPs (If private connectivity exists), but that does not allow elasticity. We can use a reverse proxy server mount on an EC2, but it is not a managed solution and creates more operational overhead.
To use a Bastion
Using a Bastion host is a typical solution to access your cloud servers; instead of adding a public IP address to any server that we manage, we create a Bastion Host with a public IP and log into this Bastion Host using SSH or RDP (Depending on our Bastion Hosts OS). From this bastion, we can jump to our EC2 or RDS.
That is a secure way to access your resources because we can limit the scope of our security group by adding only the public IPs we use from our corporate network or individual public IPs from our internet connection.
From our Bastion Host, we can access any EC2, RDS, ECS, EKS, etc.
We only need to add our Bastion Host security group or IP to the security groups for the instances we need access.
We can access our VPC, but we can also access other VPCs if we implement VPC peering or deploy a Transit Gateway topology.
These interconnections between VPCs allow us to centralize our Bastion host and reduce and simplify our management infrastructure.
That method is easy to use; Bastion Host is something usual on on-prem; we can use different access keys, different OS users, log access, etc.
Also, if we need a more secure way to access, we can use a Client VPN instead of connecting directly to our Bastion Hosts using SSH or RDP.
Advantages
- We reduce the number of Public IPs used for managing instances.
- We improved security because we had fewer entrance points to our servers.
- We need to maintain fewer instances for management.
- Baston Host is a familiar topology for IT infrastructure.
- We can log access to the Bastion host and audit the activity.
Disadvantages
- We need an EC2 for management.
- We must manage and audit security groups to limit access to our Bastion Host.
- We can have considerable exposure to our infrastructure if someone gains access to our Bastion Host.
- We can receive SSH brute force attacks and must protect ourselves from them.
To use the Session Manager
AWS Systems Manager Session Manager (SSM) is a way to access our EC2 like an SSH but without SSH and with many benefits of AWS security out of the box.
To use the AWS Systems Manager Session Manager, we need to accomplish some tasks:
- We need to have the SSM agents installed on our instances (If we use an AMI from AWS, the agent is installed by default).
- The Instance needs access to the SSM endpoint using a NAT Gateway or deploying an AWS private endpoint.
- We need to add an Instance profile with permissions to SSM to permit the EC2 to execute some API calls to SSM services.
- We need permission to use SSM on our IAM user or IAM role.
We can follow AWS Documentation to configure.
This access method permits one to log on to an instance without using SSH and use our IAM credentials.
That's very useful because we can use the IAM Identity Center and centralize access to our systems using our IdP credentials instead of Linux Local credentials.
Also, if we use IAM Identity Center or IAM Roles, we are using temporary security credentials that significantly improve our security. Those credentials rotate very often (they are only active for a few hours or less if we choose). If someone stole these credentials, they would be revoked automatically when the token expires, and we can also revoke the credentials immediately.
If we use Windows servers, we can use AWS Systems Manager Fleet Manager, which uses a similar system but for RDP connections.
Also, we can use a mixture using SSM with a private Bastion Host.
That is the same method as if we are using a Bastion Host but without exposure to our Bastion Host on the Internet.
However, SSM is unusable for some people because they need to use X11 on remote servers or upload files using SCP or their terminal instead of the AWS console or AWS CLI.
But we are lucky; SSM has a feature named Port Forwarding that permits us to create a tunnel from our computer to the Bastion Hosts and connect to other servers directly. It is like an SSH tunnel and is very powerful. We can access our RDS servers or private websites without publishing them. We can also forward X11 and use the remote displays.
Advantages
- We don't need to use Public IPs
- We use IAM credentials with temporary credentials instead of Linux credentials or SSH keys.
- We can use our IdP credentials to log on to EC2 instances.
- We use an HTTPs encrypted connection encrypted by AWS.
- We don't expose servers on the internet.
- We can audit logs and actions.
- We can explore logs on Cloudwatch and create metrics and alarms.
- We can revoke credentials automatically.
- We can use the port forwarding feature to create secure tunnels
- The solution doesn't have any cost; SSM is free.
Disadvantages
- We must use AWS CLI or AWS console to connect to servers.
- The method is more complex and needs to be more familiar to users.
- We need to install agents and create Instance profiles.
To use private EC2 Instance connect
The service EC2 instance connect allows you to connect to your public/private EC2 instances by establishing an SSH session through the browser. The Instance Connect API will publish a one-time use SSH public key to the EC2 instance metadata, which will remain for 60 seconds.
If the instance has the EC2 instance connect installed, an SSH daemon will pull the public key information from the instance metadata for authentication in this timeframe.
The SSH connection will be established using the one-time use private key that the Instance Connect API generated at the time of the request.
IAM backs the service; no user who doesn´t have access to this service will be allowed to connect. For more information on how the service works, follow the user guide.
Initially, the EC2 instance connect was meant to connect to EC2 instances with a public IP address. In June of 2023, AWS released an update on this service, allowing users to connect to the EC2 instances with Private IP through the internet.
To perform this task, create an EC2 instance Connect Endpoint in a private subnet in your VPC. This endpoint acts as a private tunnel connecting from the internet to your private instances. You can connect to different subnets inside the VPC using the same endpoint.
(If you connect to an instance in a different AZ from the Endpoint, some charges may apply)
Here, you can find a how-to guide on connecting using the EIC Endpoint to a private IPv4 instance.
Advantages
- You can connect to your instances from the internet without an internet gateway.
- The access for creating and using the EC2 Instance connect endpoints can be restricted/granted through IAM policies and permissions.
- Improve the security by having a centralized access control to EC2 instances and removing the need to manage the SSH keys.
- Removes the need for a Bastion host.
- CloudTrail tracks all the events.
Disadvantages
- It does not support IPv6 addresses.
To Migrate to IPv6
Since 2011, AWS has been promoting IPv6; every year, AWS has been adding and adapting more services to use this technology.
Networking compatibility modes supported by AWS:
- IPv4-only mode: Your resources can communicate over IPv4; if they communicate with IPv6, it will require an interoperability layer.
- IPv6-only mode: Your resources can communicate over IPv6; if they communicate with IPv6, it will require an interoperability layer.
- Dual-stack mode: Your resources can communicate over IPv4 and IPv6.
Under this article, you will find the list of services that can use IPv6.
For more information on how to design an IPv6 network, follow the Best Practices runbook
Advantages
- Reduce costs by stopping using IPv4
- Eliminates the need for translation mechanisms (NAT), removing performance overheads of translations, simplifying the routing of packets
- IPv6 adds more security, using IPsec as a standard
Disadvantages
- Not all the services support IPv6
- An architecture analysis should be done before implementing/adapting anything.
Top comments (0)