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.
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.
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:
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
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
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:
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
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, 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.
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
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
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:
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
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
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! 🚀
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.