6 secure ways to connect AWS resources

Sudhir Kumar
7 min readFeb 5, 2023

How you access AWS resources from on-premises also define your security posture and cloud security principles.

What is the best way to connect securely from on-premises OR local machine.

Few questions to ask yourself :-

  • Are bastion host security groups wide open ?
  • What if SSH RSA pub/priv keypair is leaked OR not rotated AND if key team member leaves your organization ?
  • Do you need centralized SSH logs for auditing purposes ?
  • Can you deploy it as a centralized solution for whole Organization ?
  • Can you apply service control policy/ IAM policy and allow only specific users to get access via session manager.
  • Do you want SSH login notifications based on security events ?

5 ways to connect to AWS resources securely :

  1. Bastion host in public Subnet
  2. Deploy on-premises jumphost and connect via IPSEC from on-premises (over internet OR Directconnect)
  3. Session Manager (CLI and Browser based session)
  4. Access via Serial Console
  5. EC2 Connect
  6. Ec2 instance connect via EIC Endpoint

Bastion host in public Subnet :

If you have no connectivity back to on-premises from cloud (IPSEC or directconnect) and if we would like to access ec2/rds in private subnets from on-premises or local machine.

This is traditional way of connecting and have few caveats:

Cons:

  • Publicly exposed Ec2 instance.
  • Manage ec2 security groups whitelisting.
  • Manage bastion host OS/Update security patches and make sure it’s highly available.
  • Share pem files (public/private keypair) with team members.
  • SSH logging needs to be exported to Cloudwatch/S3 bucket for analysis.

Pros:

  • Easy to setup.
Source — AWS

Deploy on-premises jumphost and connect via IPSEC from on-premises (over internet OR Directconnect)

It’s a good practice to expose certain set of IP addresses from on-premises to cloud over port 22 and have all logs in centralized jumphost.

Pros:

  • Centralized setup with private IP address only.
  • Logging can be enabled for auditing purposes and forward to your local SIEM/logging solution.

Cons:

  • Manage High Availability/OS/Security patches of jump hosts.
  • You have to distribute ssh pem files with team to connect to compute etc.
  • Manage ec2 security groups and allow on-premises jumphost.

Session Manager (CLI and Browser based session)

This is the best and recommended approach to connect to ec2 instances or use local port forwarding to access RDS or other AWS resources.

Pros:

  • No need to distribute SSH RSA pem file to team members.
  • No need to manage ingress security groups. Only egress to port 443 is needed.
  • Logging session logs to Cloudwatch/S3 buckets.
  • Monitoring session activity using AWS EventBridge for notifications.
  • No need to manage additional virtual machines.
  • One click access to managed nodes and browser based sessions also possible.
  • Use IAM temporary credentials for login purposes.
  • You can connect to multiple Operating systems using same tool (Windows/Linux/Mac).

Cons:

  • You need to work on setting up session manager installation in your ec2 nodes and make sure IAM role attached to ec2 instance.
  • Work on IAM or Service control policy to make sure only specific users should have access to ec2 instances.
  • You need to fetch instance ID before login.
aws ec2 describe-instances --filters "Name=tag:Name,Values=test" --query "Reservations[].Instances[].InstanceId"

How-to-install (Steps):

Login to ec2 instance:

# aws ssm start-session - target <instance-ID>

Local Port Forwarding example (Remote port is 443 and local port is 56789):

aws ssm start-session \
— target instance-id \
— document-name AWS-StartPortForwardingSession \
— parameters ‘{“portNumber”:[“443”], “localPortNumber”:[“56789”]}’ — region <region-name>

How-it-works:

Session Manager:

Source — AWS

Port forwarding :

AWS

Access via Serial Console

You can also access ec2 via serial console.

Cons:

  • Only certain ec2 instance types allowed.
  • You need to create system user beforehand as login via serial console is combination of username + password.

EC2 connect

Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). It’s primarily meant for public ec2 instances.

Cons:

  • Does need security groups ingress whitelisting for IP/Port 22.

Pros:

  • You can also connect via browser based sessions.
  • You just need to specify username to connect it.
  • Logs all SSH activities in cloudtrail.

In general, ec2 instances should not be deployed in public subnets with port 22 access (unless there is some edge case/ business use-case).

Ec2 Instance Connect Endpoint

Ec2 Instance connect EIC Endpoint allows you to connect securely to your instances and other VPC resources from the Internet. With EIC Endpoint, you no longer need an IGW in your VPC, a public IP address on your resource, a bastion host, or any agent to connect to your resources.

EIC Endpoint combines identity-based and network-based access controls, providing the isolation, control, and logging needed to meet your organization’s security requirements.

Source: AWS

Creating your EIC Endpoint

  • Only one endpoint is required per VPC.
  • To create or modify an endpoint and connect to a resource, a user must have the required IAM permissions, and any security groups associated with your VPC resources must have a rule to allow connectivity.
  • Refer to the following resources for more details on configuring security groups and sample IAM permissions.

Creating an EIC Endpoint with the AWS CLI

To create an EIC Endpoint with the AWS CLI, run the following command, replacing [SUBNET] with your subnet ID and [SG-ID] with your security group ID:

aws ec2 create-instance-connect-endpoint \
--subnet-id [SUBNET] \
--security-group-id [SG-ID]

After creating an EIC Endpoint using the AWS CLI or Console, and granting the user IAM permission to create a tunnel, a connection can be established.

Connecting to your Linux Instance using SSH

  • With your EIC Endpoint set up in your VPC subnet, you can connect using SSH. Traditionally, access to an EC2 instance using SSH was controlled by key pairs and network access controls.
  • With EIC Endpoint, an additional layer of control is enabled through IAM policy, leading to an enhanced security posture for remote access. We describe two methods to connect via SSH in the following.

One-click command

  • To further reduce the operational burden of creating and rotating SSH keys, you can use the new ec2-instance-connect ssh command from the AWS CLI.
  • With this new command, we generate ephemeral keys for you to connect to your instance. Note that this command requires use of the OpenSSH client and the latest version of the AWS CLI.
  • To use this command and connect, you need IAM permissions as detailed here.

Once configured, you can connect using the new AWS CLI command, shown in the following figure:

Source: AWS

To test connecting to your instance from the AWS CLI, you can run the following command where [INSTANCE] is the instance ID of your EC2 instance:

aws ec2-instance-connect ssh --instance-id <INSTANCE>
  • You can still use long-lived SSH credentials to connect if you must maintain existing workflows ; However, note that dynamic, frequently rotated credentials are generally safer.

Open-tunnel command

  • You can also connect using SSH with standard tooling or using the proxy command. To establish a private tunnel (TCP proxy) to the instance, you must run one AWS CLI command, which you can see in the following figure:
Source : AWS
  • You can run the following command to test connectivity, where [INSTANCE] is the instance ID of your EC2 instance and [SSH-KEY] is the location and name of your SSH key.
ssh ec2-user@[INSTANCE] \
-i [SSH-KEY] \
-o ProxyCommand='aws ec2-instance-connect open-tunnel \
--instance-id %h'

Once we have our EIC Endpoint configured, we can SSH into our EC2 instances without a public IP or IGW using the AWS CLI.

Recommendations

My recommendation is to use Session Manager (CLI and Browser based session) . It’s a safe way to connect resources, ssh tunneling and also without pem keys distribution with authz/authn at AWS SSO level.

Also, you can connect private instances directly (without IPSEC or Directconnect) and enable logs to centralized S3 bucket for auditing purposes.

EIC endpoint is much better approach to access public ec2 instances.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

--

--

Sudhir Kumar

Working as Cloud lead/Architect with security mindset.