logo
Connecting to Your Remote Instances Without a Public IPv4 Address

Connecting to Your Remote Instances Without a Public IPv4 Address

A cost-effective strategy to optimize AWS bills

Published Feb 8, 2024
Given the AWS announcement on the imposition of charges on public IPv4 addresses starting February 1, 2024 and acknowledging the widespread use of these addresses for connecting to remote instances, this article aims to elucidate an alternative method for connectivity that doesn’t require a public IPv4 address.

  1. Bastion Hosts
  2. The Usual Approach
  3. Challenges using a Bastion Host
  4. EC2 Instance Connect Endpoint
  5. Conclusion

Before going any further it’s essential to provide an explanation about bastion hosts, commonly known as jump hosts, jump boxes, or jump servers.
Bastion hosts are strategically positioned and intentionally designed and configured servers, named by analogy to the bastion, a military fortification.
They are intended to resist attacks, functioning as intermediaries between an organization’s internal network and an external network, typically the internet.
The primary purpose of a bastion host is to provide secure access to internal resources, especially in environments where direct access to internal servers is restricted for security reasons.

For many years, when trying to connect to an Amazon Elastic Compute Cloud (Amazon EC2) instance within a Amazon Virtual Private Cloud (Amazon VPC) over the Internet, users will typically connect first to a bastion host with a public IP address set up over an Internet Gateway (IGW) in their VPC, and then use port forwarding to reach their destination via SSH (Secure Shell), or Remote Desktop Protocol (RDP).

Using a bastion host introduces several challenges and considerations, despite its benefits in enhancing security:
  1. Complex Configuration: Properly configuring and maintaining a bastion host can be complex, involving setting up secure authentication mechanisms, managing firewall rules, and ensuring proper logging and monitoring.
  2. Single Point of Failure: If configured as a single entry point for external access, any failure or compromise of the bastion host can disrupt or potentially compromise access to internal resources.
  3. Security Risks: If not configured securely, the bastion host itself can become a target for attacks. Security vulnerabilities, misconfigurations, and/or weak authentication on them can pose significant risks.
  4. Maintenance Overhead: Regular maintenance and updates are crucial for the security of the bastion host. Ensuring that security patches are applied promptly without disrupting the services it provides requires careful planning.
  5. User Training: Users need to be trained on the proper procedures for connecting through the bastion host. Misuse or lack of understanding can lead to security incidents or connectivity issues.
  6. Logging and Monitoring: Setting up effective logging and monitoring systems for the bastion host is essential. Analyzing logs, detecting unusual activities, and responding to security incidents require dedicated resources and expertise.
  7. Scalability: As an organization grows, scaling the bastion host solution to accommodate increased user access may require adjustments to the infrastructure and architecture.
  8. Network Latency: The additional hop through the bastion host can introduce network latency, affecting the responsiveness of remote connections, especially for real-time or bandwidth-sensitive applications.
  9. Compliance Considerations: Organizations subject to specific compliance standards may face challenges in ensuring that the bastion host solution meets the required regulatory requirements.
  10. Dynamic Environments: In dynamic environments where IP addresses or configurations frequently change, maintaining up-to-date access controls and configurations for the bastion host can be challenging.
  11. Costs: The deployment and maintenance of a bastion host may involve additional costs in terms of infrastructure, security tools, and ongoing management.
On June 27, 2019, AWS introduced Amazon EC2 Instance Connect, but there is still a need of a public IP address to be able to use it.

On June 14, 2023, AWS launched Amazon EC2 Instance Connect (EIC) Endpoint, a new feature that allows users to connect securely to their instances from the Internet.
With EIC Endpoint, you no longer need an Internet Gateway (IGW) in your VPC, a public IP address on your resource, a bastion host, or any agent to connect to your resources.
As an additional benefit, the organizational administrator is freed from the operational burden of maintaining and updating bastion hosts for connectivity, and I bet they will be very happy to know about that. 😃🙌
EIC Endpoint, an identity-aware TCP proxy, works with the AWS Management Console and AWS Command Line Interface (AWS CLI). Furthermore, you can continue using your favorite tools, such as PuTTY and OpenSSH.

Effective February 1, 2024, AWS will initiate charges for public IPv4 addresses. To optimize your AWS expenses, consider leveraging the Amazon EC2 Instance Connect (EIC) Endpoint where there is no longer a requirement for an Internet Gateway (IGW) in your Virtual Private Cloud (VPC), a public IP address on your resource, a bastion host, or any intermediary agent for connecting to your remote resources.
And stay tuned for my upcoming article where I will explore the detailed steps on setting up this streamlined approach for connecting to remote resources using the Amazon EC2 Instance Connect (EIC) Endpoint.
If you enjoyed this article and found it helpful, please don’t forget to leave a heart ❤**, comment** 💬**, clap** 👏🏻**, and share** ➦ it to show your support.
Also, don’t forget to connect and follow me for more articles. Thank you!