Revisiting EC2 Connectivity Options

Table of Contents

Introduction

With the recent announcement of EC2 instance connect endpoints, we now have several different ways to connect to Amazon EC2 instances. Depending on your deployment architecture, one or more of these techniques might be suitable as the standard mechanism you & your team use to connect to EC2s when needed.

Let us take this opportunity to review all connectivity options available to us today. Since you’ll need to pick one of these with every new EC2-based application you deploy to AWS, comparing them against each other & knowing each technique’s pros & cons, will serve as a reference in your decision making process.

Note: This article’s focus is on obtaining terminal access to Linux VMs, not HTTP/S, etc. As such, we’re only exploring SSH connectivity options for Linux EC2 instances here, not Windows or Mac.

Public Access

Although not ideal, if you EC2 instances are directly accessible from the public internet, you might choose to open port 22 to the internet & directly SSH to the instance from anywhere in the world.

This is also the least secure option. The only thing standing between your instance & the internet is the instance’s SSH private key, assuming you haven’t enabled password-based logins in your SSH server.

Be prepared to be the target of numerous SSH brute force attacks from around the world if you do choose this option. If you have GuardDuty enabled, it will inform you when such an attack is detected. If you must keep port 22 open, your only option is to block the attacker’s IP in your NACL.

If opening the SSH port is unavoidable for some reason, consider limiting the inbound CIDR range to a set of trusted IPs, like your office CIDR or the SaaS product’s CIDR that needs SSH access to your instances.

Bastion Host

If your EC2 instances are in private subnets, as they should be, bastion hosts, also known as jump boxes, are a very common & relatively secure way of establishing SSH connectivity to your instances.

A bastion host is an EC2 instance that sits in a public subnet in front of the instances in private subnets & acts a single point of connection for all incoming access requests. You SSH into the bastion first & then from the bastion, SSH into the target EC2 instance, as shown below:

PROS:

  • Target EC2s stay private
  • Bastion is the single point of connection, instead of many individual EC2s
  • Only bastion needs to be secured & monitored for internet threats
  • 1-time setup of SSH tunnel via bastion can provide end users transparent access from their local systems to the target EC2s
  • Several popular software support connecting via SSH tunnels, like MySQL workbench
  • A just-in-time access mechanism can be implemented by spinning up the bastion only when needed & shutting it down when not needed

CONS:

  • There’s now this additional EC2 to manage in your environment
  • Bastion could become a bottleneck in some cases
  • You must pay for this additional EC2 instance that hosts no apps but is used only for network access to other EC2s that host apps
  • Bastion must be hardened, patched & kept up-to-date since it’s exposed to the internet
  • Secure storage & distribution of SSH private keys for the bastion is an overhead & a security concern
  • If you use different SSH keys for bastion & backend instances, as you should, novice users might copy the target EC2’s private key onto the bastion to SSH onto them; leaving these keys on the bastion is a major security concern

Secure VPN

Hosting EC2 instances in private subnets & setting up VPN connectivity between the subnets & your workplace is a great way to always have access to your target systems, as if they’re in your local network.

This is ideal for shared workspaces like office buildings where everyone can take advantage of a shared VPN connection & directly SSH to the private IP of an EC2 instance. If needed, VPN can also be setup from an individual engineer’s local machine to private subnets in AWS VPCs.

AWS-Provided Connectivity Options

The options we’ve seen so far are purely network-based, not specific to AWS. They can also be used on-prem to connect to machines in data centers.

The options explored below, are services provided by AWS specifically as a connectivity solution for EC2s.

Systems Manager Session Manager

SSM Session Manager is a very popular & easy to use connectivity mechanism. Simply go to the Systems Manager service console in AWS, switch to the Session Manager section, select an EC2 & connect:

PROS:

  • Ease of use
  • No SSH keys to maintain
  • No need to open SSH port
  • Terminal in your browser!
  • Access history is auditable since user must login to AWS to login to EC2
  • All commands run by the user in an SSM session, can be captured & saved to S3 for security audits

CONS:

  • Only usable via AWS console or AWS CLI
  • SSM agent must be installed & running on the target EC2
  • The EC2 instance profile (IAM role) must grant access to SSM
  • Additional setup might be required like VPC endpoints for SSM in subnets where target EC2 reside

EC2 Instance Connect

EC2 instance connect, although still reliant on network connectivity, is still a better way to access EC2s compared to direct network access like pure SSH. Instead of you providing the SSH key, the Instance Connect API will push a public key to the instance for 60 seconds & then connect you to the instance. However, the instance must still be accessible over the network, with a public IP if over the internet, or via VPN, direct connect, VPC peering, etc if connecting to a private IP.

PROS:

  • SSH access is controlled by IAM policies
  • No SSH keys to manage
  • Connections are auditable via CloudTrail
  • Can be used to securely access bastion hosts
  • Access can be limited to specific EC2 instances, instances with specific tags & Linux users using IAM policy conditions

CONS:

  • EC2 instance connect must be installed on the system: yum install ec2-instance-connect
  • Only works with Amazon Linux & Ubuntu
  • Only IPv4 is supported, not IPv6
  • Instance’s security group must allow inbound SSH from your IP

EC2 Instance Connect Endpoint

You begin by creating an EC2 instance connect endpoint in your VPC:

Once created, this endpoint acts as a private tunnel to your instance. You can then select it when connecting to an instance:

PROS:

  • Connect to private instances without needing direct network access to them
  • 1 EIC endpoint can be used to connect to any instance in any subnet of the VPC
  • All connection attempts are logged to CloudTrail
  • IAM policies can be used to:
    • Allow users to use EIC endpoints to connect to instances
    • Allow connections only from specified source IP ranges

CONS:

  • Relies on an additional piece of virtual infrastructure: the EIC endpoint
  • If endpoint & instance are in different availability zones, cross-zone data transfer charges apply

Conclusion

This article explored several different ways to acquire a terminal session on your Linux EC2 instances. Depending on your use case & architecture, one or more of these can be used as necessary. Certain organizational policies like ‘no SSH keys’ & auditability might automatically mandate the use of one of the advanced AWS-specific ways of connecting to your instances.

About the Author ✍🏻

Harish KM is a Principal DevOps Engineer at QloudX & a top-ranked AWS Ambassador since 2020. 👨🏻‍💻

With over a decade of industry experience as everything from a full-stack engineer to a cloud architect, Harish has built many world-class solutions for clients around the world! 👷🏻‍♂️

With over 20 certifications in cloud (AWS, Azure, GCP), containers (Kubernetes, Docker) & DevOps (Terraform, Ansible, Jenkins), Harish is an expert in a multitude of technologies. 📚

These days, his focus is on the fascinating world of DevOps & how it can transform the way we do things! 🚀

Leave a Reply

Your email address will not be published. Required fields are marked *