Resolving connectivity problems to Amazon Web Services (AWS) EC2 instances via SSH/RDP

Stuart ScottAWS Content Director at Cloud Academy
CERTIFIED EXPERT
Published:
Updated:
Hello to you all,

I hear of many people congratulate AWS (Amazon Web Services) on how easy it is to spin up and create new EC2 (Elastic Compute Cloud) instances, but then fail and struggle to connect to them using simple tools such as SSH (Secure Shell) and RDP (Remote Desktop Protocol) and their feelings quickly turn to frustration. 

Depending on your deployment method of your EC2 instances you may need to connect to them to perform additional configuration, install applications or to troubleshoot and incidents that may occur.  Without having a working method of connecting locally to your EC2 instances would prevent you from having full manageability of that host.

This Article has been written to cover the most common configuration problems that prevent connectivity between you and your EC2 instance.
 

Default or Non Default VPC (Virtual Private Cloud)?


Default VPC: Every AWS account comes with a Default VPC already created, this allows users to immediately deploy EC2 instances within this VPC and connect to it.  Simple you may think, and you would be right, many of the AWS networking components have already been set up on your behalf allowing you to connect to your instances with relative ease. However, these same components that are pre-configured take away some of the detailed design that your corporate infrastructure may require.  It comes with a predefined IP CIDR (Classless Inter-Domain Routing) block assigned which might not suit your exact needs, it also has an IGW (internet Gateway) attached which you may not require at that time.  As a result setting up your own VPC from scratch gives a greater granular approach to your infrastructure design

Non Default VPC:  As mentioned above, to create a fully customisable infrastructure environment it is always best to create your own VPC from scratch.  This allows you to create your own IP CIDR Block that you need, your Subnets, your routing tables and Network ACL security etc.

Most users experience connectivity issues when they have set up their own Non Default VPC, therefore this article will focus mainly on this scenario.
 

"I have set up my own Non Default VPC but unable to connect to my instances.... Help!"

When you have your EC2 instances running and you have set up your Key Pairs you will then want to connect to them via SSH or RDP to see what wonders you have created on 'the AWS cloud'.........but your connection times out in one way or another and your attempt fails.  You try and try again, but again and again you experience the same problems.  You are certainly not alone in this scenario and it's usually a simple mis-configuration issue that is easily resolved.

If you are trying to connect to your EC2 instance from a source outside of AWS then check the following elements of your configuration:
 
  1. Check your internal Firewall - If you are trying to connect from inside of your corporate network you will most likely be passing through your internal firewall which may block ports 22 (SSH) and 3389 (RDP).  Speak with your internal network administrator to ensure your traffic is allowed out to your destination and also the returned traffic allowed back in to you
  2. Do you have an IGW (Internet Gateway) attached to your VPC? - If you don't have an IGW set up and attached to your VPC then you will not have any way for traffic to leave your AWS environment out onto the public internet and back to you.  (For details on how to check your IGW see "How To" section below)
  3. Do you have a route to the outside world from the subnet of the destination EC2 instance? - Once you have an IGW associated with your VPC you need to ensure you have the correct routing set up.  A route within each Subnet that you need to make publically accessible needs to point to the outside world via the IGW, for example 0.0.0.0/0 via your IGW.  (For details on how to check your route tables, see "How To" section below)
  4. Do you have the right Security Group Access applied to your instance? - Security Groups control access at an Instance level.  The correct ports need to be allowed to pass within your security group that is associated to your instance allowing either SSH (Port 22) or RDP (Port 3389) from a valid source address.  (For details on how to check your security Group see "How To" section below)
  5. Do you have the correct ports open on the NACL (Network Access Control List) associated with the subnet? - NACLs control access at the Network Level.  You need to ensure that the inbound and outbound NACL allow ports 22 or 3389 to pass through.  (For details on how to check your NACL configuration please see "How To" section below
  6. Has the instance got a Public IP address? - For an instance to be reachable from outside of AWS you need to ensure it has a public IP address.  This can either be dynamically assigned by AWS during the EC2 instance creation; however this address may change on reboot.  Alternatively you can apply a fixed Public IP address called an EIP (Elastic IP address).  (For details on how to check the Public IP address see "How To" section below)
  7. Are your instance resources peaking? - At times your instance may peak at 100% CPU utilisation, this can cause connection errors when there are not enough resources available to allow and manage the connection.  Check your CloudWatch metrics as you may need to resize your instance to a larger instance or troubleshoot why you have 100% CPU.  (For details on how to check your instance resources see "How To" section below)
  8. Has your instance passed its Status Checks? - Ensure your instance has passed it Status Checks on boot to ensure no underlying issues were detected that may prevent connectivity problems.  If you have failed Status checks, stop and restart your instance as in many cases this can be down to a hardware fault at an AWS level.  By stopping and restarting (not rebooting) your instance will likely spin up on a different physical host resolving any hardware errors previously experienced.  (For details on how to check the Status see "How To" section below)
 

 

How To:


Covering points (2) - (8) above


(2) Check your IGW

  1. Open up the AWS Console
  2. Select VPC from the Services List
  3. Select Internet Gateways from the list.  This will show the IGWs that you have set up within your AWS account.  There will most likely be one already there that is used for the Default VPC (unless you have previously removed this), this will NOT be attached to your Non Default VPC and so you must attach another IGW to your VPC
  4. By selecting the IGW listed you can check to see what VPC it is associated with in the Summary section at the bottom of the screen
  5. If you do not have an IGW associated to your Non Default VPC you must either create a new IGW and associate it to your VPC or associate an IGW in your list that has a Status of Detached
Creating a new IGW
  1. Click Create Internet Gateway
  2. Give your IGW a meaningful name
  3. Click Yes, Create
  4. Your IGW will now appear in the list with a State of Detached
Associate a Detached IGW to your VPC
  1. Select the IGW
  2. Right mouse click and select Attach to VPC
  3. Select your Non Default VPC
  4. Click Yes, Attach
Further information on IGWs can be found here

(3) Check your routing table

  1. Open up the AWS Console
  2. Select EC2 from the Service list
  3. Select the instance you are trying to connect to
  4. Within the Description pane at the bottom of the screen make note of the Subnet ID
  5. Select VPC from the AWS Service list
  6. Select Subnets
  7. Select the Subnet you made a note of in step 4
  8. Click on Route Table
  9. There needs to be a route within this table pointing to the outside world via your IGW.  If this does not exist then you need to add this route
Adding a route to the Route Table for the IGW
  1. Click on the Route Table ID of the Route Table
  2. Select the Route Table
  3. Click Edit
  4. Click Add Route In the Destination section add 0.0.0.0/0
  5. In the Target section enter your IGW ID, it will pick up any IGWs you have automatically when you select the field
  6. Click Save
Further information on AWS route tables can be found here

(4) Check your Security Groups are set up correctly

  1. Open up the AWS Console
  2. Select EC2 from the Service List
  3. Select your instance your are trying to connect to
  4. Within the Description pane at the bottom of the screen click on the Security Group that is associated with your instance
  5. Select the Security Group
  6. Click on Inbound
  7. Under Type there needs to be either SSH or RDP respectively allowing access from a source range or specific IP from the device you are trying to connect from
  8. If SSH or RDP does not exist you must add a rule allowing this port through
Adding a rule to the Security Group
  1. Click Edit
  2. Click Add Rule
  3. In the dropdown list under Type select either SSH or RDP
  4. In the Source box add your source IP/Range as required.  This is where you are trying to connect from
  5. Click Save
Further information on Security Groups can be found here

(5) Check your Network ACLs

  1. Open up the AWS Console
  2. Select EC2 from the Service list
  3. Select the instance you are trying to connect to
  4. Within the Description pane at the bottom of the screen make note of the Subnet ID
  5. Select VPC from the AWS Service list
  6. Select Subnets
  7. Select the Subnet you made a note of in step 4
  8. Click on Network ACL
  9. Select the ID of the Network ACL
  10. Select the NACL
  11. Click Inbound Rules
  12. Looking at the rules you need to ensure that there is a rule that either explicitly allows Ports 22 or 3389 as Allowed or where these ports fall under a wider rule such as All Traffic with Any Protocol and Any Range and not explicitly Denied
  13. The same checks need to be applied for the Outbound Rules
  14. If there isn't a rule allowing this access you must add a new rule
Adding a rule to a Network ACL
  1. Click Edit
  2. Add a Rule Number (it's a good idea to increment these rules by a base of 5 to allow for further rules to be added in-between others at a later date as these rules are carried out in number order)
  3. Under Type select either SSH or RDP
  4. In the Source box add your source IP/Range as required.  This is where you are trying to connect from
  5. Select Allow under Allow/Deny
  6. Click Save
  7. Perform the same steps for the Outbound Rules
Further information on Network ACLs can be found here

(6) Check the Public IP Address

  1. Open up the AWS Console
  2. Select EC2 from the Service list
  3. Select the instance you are trying to connect to
  4. Within the Description pane at the bottom of the screen check to see if there is a Public IP Address assigned
  5. If it does not have a Public IP address you can assign an EIP (Elastic IP address)
Allocating an EIP
  1. Select EC2 from the Service list
  2. Under Network & Security select Elastic IPs
  3. Select Allocate New Address
Further information on EIP's can be found here

(7) Check your CloudWatch Metrics for you instance

  1. Open up the AWS Console
  2. Select EC2 from the Service list
  3. Select the instance you are trying to connect to
  4. Select the Monitoring tab at the bottom of the screen
  5. This will show you the current CloudWatch metrics running on your instance.  By default these metrics are collected automatically every 5 minutes, unless you have chosen to use Detailed Monitoring which will provide results every minute (there are additional costs involved for Detailed Monitoring).
  6. Check the different graphs for any anomalies that might be peaking exceptionally high and appear unusual to your baselined history.  Having the CPU Utilisation at 100% can prevent you from connecting to your device over SSH/RDP
  7. You might need a larger instance if your instance does not have enough Compute power to process your workload, or there maybe software issues on your instance causes the CPU leak
Further information on CloudWatch Metrics can be found here

(8) Check Status Checks of your instance

  1. Open up the AWS Console
  2. Select EC2 from the Service list
  3. Select the instance you are trying to connect to
  4. Check the Status Checks column to see if 2/2 have passed
  5. Further information on Status Checks can be found by selecting Status Checks tab at the bottom of the screen
  6. If the System Status Check has failed then it's most likely due to an underlying hardware fault and the best course of action is to stop the instance and restart it again as this will in most cases cause the instance to spin up on a different physical host.  If the Instance Status Check has failed then it could be an operating System configuration problem, however the first course of action would be to simply reboot the instance as this resolves many of these problems
Further information on Status Checks can be found here

If you are trying to connect to your EC2 instance from another EC instance inside of AWS then check the following elements of your configuration:
 
  1. Do you have the right Security Group Access applied to your instance? - The correct ports need to be configured within your security group that is associated to your instance allowing either SSH (Port 22) or RDP (Port 3389) from a valid source address. 
  2. Do you have the correct ports open on the NACL (Network Access Control List) associated with the subnet? - Security Groups control access at the instance level; NACLs control access at the Network Level.  You need to ensure that the inbound and outbound NACL allow ports 22 or 3389 through. 
  3. Are you using the Internal IP Address? - When connecting to instances from another instance you typically need to use the internal IP address instead of the external IP address
  4. Are your instance resources peaking? - At times your instance may peak at 100% CPU utilisation, this can cause connection errors as there are not enough resources available to allow and set up the connection.  Check your CloudWatch metrics as you may need to resize your instance to a larger instance or troubleshoot why you have 100% CPU.
  5. Has your instance passed its Status Checks? - Ensure your instance has passed it Status Checks on boot to ensure no underlying issues were detected that may prevent connectivity problems.  If you have failed Status checks, stop and restart your instance as in many cases this can be down to a hardware fault at an AWS level.  By stopping and restarting (not rebooting) your instance will likely spin up on a different physical host resolving any hardware errors previously experienced.
 

I hope the above information has been useful to you in resolving any connectivity problems you may have experienced on your EC2 instances within AWS,

By no means are the above the ONLY reasons you may have trouble connecting to your instances, however they are some of the most common reasons why people have issues connecting and is always a good place to start your troubleshooting.   

Thank you for taking the time to read my article, if you have any feedback please do leave a comment below.

If you liked this article or found it helpful please click the 'Good Article' button at the bottom of this article, it would be very much appreciated.
    
I look forward to your comments and suggstions.

Stuart Scott - (LinkedIn)
AWS-Logo.jpg-AWS Certified Solutions Architect
-AWS Accredited Technical Professional
-AWS Accredited Business Professional
-AWS Accredited TCO and Cloud Economics

 
3
7,480 Views
Stuart ScottAWS Content Director at Cloud Academy
CERTIFIED EXPERT

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.