Notes on: Linux Academy: AWS CSAA: 9) Advanced Networking: Network Connectivity Troubleshooting

Just a place to put some notes on the “AWS Certified Solutions Architect - Associate (New!)” course from https://linuxacademy.com

Common Issues


EC2 Troubleshooting:

Connectivity issues to an EC2 instance
- Correct ports on the security group may not be open

Cannot attach an EBS volume to an EC2 instance
- EBS volumes must live in the same availability zone as the EC2 instance they are attached to
- You can create a snapshot from the volume and launch the volume in the correct availability zone

Cannot launch additional instances
- You have probably reached the EC2 limit and need to contact AWS to increase the limit

Unable to download package updates
- The EC2 instance may not have a public/Elastic IP address, and/or does not belong to a public subnet

Applications seeming to slow down on T2 micro instances
- T2 micro instances utilize CPU credits (for “burstable” processing), so chances are your application is using too much processing power and needs a larger instance or different instance type

AMI unavailable in other regions
- AMI’s are only available in the regions that they are created
- An AMI can be copied to another region but will receive a new AMI id

“Capacity error” when attempting to launch an instance in a placement group
- Start and stop all the instances in the placement group (AWS tries to locate them as close as possible)

VPC Troubleshooting:

New EC2 instances are not automatically being assigned a public IP address
- Modify the Auto-Assign Public IP setting on the subnet

NAT Gateway is configured but instances inside a private subnet still cannot download packages
- Need to add 0.0.0.0/0 route to the NAT gateway on the route table for private subnets

Traffic is not making it to the instances even though security group rules are correct
- Check the Network Access Control Lists to ensure the proper ports from the proper sources are open (also check your IGW and route table settings)

Error when attempting to attach multiple internet gateways to a VPC
- Only one internet gateway can be attached to a VPC at any given time

Error when attempting to attach multiple Virtual Private gateways to a VPC
- Only one Virtual Private Gateway can be attached to a VPC at any given time

VPC Security group (for EC2 instances) does not have enough rules for the required application
- Assign the EC2 instance to multiple security groups

Cannot SSH/communicate with resources inside of a private subnet
- Either you have not setup a VPN, or you have not connected to an EC2 instance (Bastion host) within the VPC to launch a connection from

Successful site-to-site VPN connection but unable to access extended resources
- Need to add on-premise routes to the Virtual Private Gateway route table

Failure to create a VPC peering connection between two VPC’s in different regions
- Peering connections can only be created between two VPC’s in the same region

ELB Troubleshooting:

Load balancing is not occurring between instances in multiple availability zones
- Make sure “Enable Cross-Zone load balancing” has been selected

Instances are healthy but are not registering as healthy with the ELB
- Check configuration for the “health check” to make sure you have selected the proper ring protocol, ping port, and ping path

The ELB is configured to listen on port 80, but traffic is not making it to the instances that belong to the ELB
- You may have mistaken the “Listeners” for the security group. Listeners are not the same as the security group rules, port 80 needs to be open on the security group that the ELB is using.

Access logs on web servers show IP address of the ELB not the source traffic
- Enable Access Logs to Amazon S3 (found under “attributes”)

Unable to add instances from a specific subnet to the ELB
- Most likely the subnet that the instance lives in has not been added to the ELBs configuration

Auto Scaling Troubleshooting:

An Auto Scaled instance continues to start and stop (or create/terminate) in short intervals
- The scale-up and scale-down thresholds may be too close to each other. Either raise the scale-up threshold or lower the scale-down threshold.

Auto Scaling does not occur even though scaling policies are configured correctly
- The “max” number of instances set in the auto scaling group may have been reached

Quiz: Connectivity Troubleshooting Quiz

T: You cannot peer two VPCs that are located in different AWS regions.

T: NACLs are the security layer for a subnet (not security groups.)

Q: You have just provisioned a fleet of EC2 instances and realized that none of them have a public IP address. What settings would need to be changed for the next fleet of instances to be created with public IP addresses?
A: Modify the auto-assign public IP setting on the subnet.
E: The auto assigning of IP addresses resides in the settings of the SUBNET you are provisioning the instances in. By default, new subnets have auto-assign IP addresses disabled.

Q: You have an application currently running on five EC2 instances as part of an Auto Scaling group. For the past 30 minutes all five instances have been running at 100% CPU Utilization; however, the Auto Scaling group has not added any more instances to the group. What is a likely cause?
A1: The Auto Scaling group's MAX size is set at five
A2: You already have 20 on-demand instances running
E: The number of instances in an Auto Scaling group cannot exceed its set MAX limit, regardless of scale-up policies. Also, unless you request an increase from AWS, you cannot have more than 20 on-demand instances running at one time.

T: There can be many reasons why you cannot download software packages besides the instance being provisioned in a private subnet. For example, creating an instance without a public IP address or not having the proper ports open on the security group can cause issues downloading software.

Q: You are using a T2 instance type and are starting to notice that most of the time your application is running very slow. What would be an appropriate course of action?
A: Move the application to a large instance type.
E: T2 instance types rely on "burstable" CPU credits for processing power. If your application is constantly using all the CPU credits, then you may experience slow downs when you run out of credits. The solution to this would be to move the application to an instance running a large instance type.

Q: You are running an analysis on traffic that is accessing your web application. However, you notice that the IP address for every visitor is the IP address of the Elastic Load Balancer. How should fix this problem so that the logs reflect the IP address of the originating host?
A: Enable access logs on the ELB and store them in an S3 bucket.

Q: You have an ELB distributing traffic a fleet of EC2 instances inside your VPC, evenly spread across two Availability Zones. However, you realize that only half of the instances are actually receiving traffic. What is the most likely cause of this problem?
A: Cross-zone load balancing has not been enabled.
E: Cross-zone load balancing must be enabled for it to serve traffic evenly to all instances in all associated Availability Zone.

Q: If you have an EBS volume in Availability Zone us-east-1d and you want to attach it to an EC2 instance in Availability Zone us-east-1a, what procedure should you follow?
A: Create a snapshot of the volume in us-east-1d, then create a new volume from the snapshot, choosing to place it in us-east-1a. Attach the new volume to the instance.
E: EBS volumes cannot be used across Availability Zones; however, since snapshots are stored in S3, new volumes can be created from a snapshot and placed into any Availability Zone.

T: A VPC can only have one IGW attached to it at a time.

Comments