I have followed this tutorial: https://www.youtube.com/watch?v=o7s-eigrMAI to learn to setup my Load Balancer that connects to Fargate.
I have also followed this answer: AWS Error : None of these Availability Zones contains a healthy target. Requests are being routed to all targets. in AWS
To check if my security groups have been linked properly.
However, after setting it up, when I try to access my load balancer URL, I get a 502 Bad Gateway error.
I have checked on the monitoring tab on my load balancer and I can see that there was a request coming in.
I have 2 security groups:
VPC Security Group (ECS) - sg-05c038a61c8a39401
EC2 Security Group (Load Balancer) - sg-0d50dc5f42650f6b6
What I have done:
Navigated to the Service under my Cluster and clicked on the Security group. This brings me to the VPC Security Group
In the VPC Security group, under the inbound rules, I changed the type to All traffic and source to the EC2 Security Group
Navigate to the EC2 screen and click on Security Group under Network Access
In the EC2 Security Group, under outbound rules, I changed the type to all traffic and destination to the VPC Security Group
My logic is that since the traffic comes into the EC2 Load Balancer, its outbound should be directed to the VPC Security Group
NOTE:
I am able to access the service using the IP address directly
Also, I noticed that my target groups show this error and are constantly draining:
None of these Availability Zones contains a healthy target. Requests
are being routed to all targets.
And after a few minutes, I get this error when I try to access the DNS URL:
503 Service Temporarily Unavailable
Related
A retail website is deployed on a ECS cluster - in a private subnet - behind ELB Application Load Balancer(ALB). What is the best method to ensure that the requests to ECS cluster are coming from ALB only?
A. Configure the inbound rule of ECS security group to accept requests only from ALB security Group.
B. Configure the inbound rule of ECS security group to deny requests from resources other than ALB.
C. Configure the inbound rule of ECS security group to accept requests only from the IP address of the ALB.
D. Create network ACL rules for the private subnet to accept requests only from the IP address of the ALB.
My question is: What's the different between A and C? Why A is right from the Answer? Thanks!
The configuration would be:
A Security Group on the Load Balancer (LB-SG) that allows inbound traffic (eg on port 80/443)
A Security Group on the ECS cluster (ECS-SG) that permits inbound access from LB-SG
By referring to LB-SG, any resource supporting the Load Balancer will be permitted to send traffic to the ECS cluster. There is no need to update configurations when the Load Balancer adds/removes additional AZs or expands to handle additional traffic.
Thus, A would be the most correct answer.
I have configured to use my ip in the security group on ec2 instance. But I am getting 504 gateway timeout error.
When I make it open to world i.e 0.0.0.0/0 then it works well.
I checked for my IP address on the ec2 instance using "who am i" and this is similar to the one in the security group.
Please suggest how to make it work only for my machine.
I have followed the steps mentioned on
possible to whitelist ip for inbound communication to an ec2 instance behind an aws load balancer?
This is how my inbound rule for the security group looks.
All traffic All All 123.201.54.223/32 Dev Security Rule
Security groups will not allow you to make it work on a machine-by-machine basis, only by IPs and security groups, eg if you limit ingress by IP, any other machine using that same IP address (usually on same network/access point etc) will also be allowed in, not just your machine.
If you are using a load balancer, then it is the load balancer that should have access to your instance via its security group, and your access via IP should be controlled in the load balancer's security group, so you should use the settings you have quoted (at least to begin with!) on your LB security group, not your instance security group.
With the instance or group of instances (ie those that are behind the load balancer) in their security groups you want to only allow ingress from the load balancer security group, there's no need to set an IP address ingress (unless you want to allow eg ssh access from specific IP addresses or want them to talk to a database instance).
504 gateway timeout error It's mean your LB not able to communicate with the desired instance and you are able to communicate with LB.
All traffic All All 123.201.54.223/32 Dev Security Rule This will only allow traffic from you IP not Load Balancer IP.
You do not need to mention your IP in the security group of EC2, You have to allow traffic from LB that is 10.0.0.0/16.
HTTP 504: Gateway Timeout
Description: Indicates that the load balancer closed a connection
because a request did not complete within the idle timeout period.
Cause 1: The application takes longer to respond than the configured
idle timeout.
Solution 1: Monitor the HTTPCode_ELB_5XX and Latency metrics. If there
is an increase in these metrics, it could be due to the application
not responding within the idle timeout period. For details about the
requests that are timing out, enable access logs on the load balancer
and review the 504 response codes in the logs that are generated by
Elastic Load Balancing. If necessary, you can increase your capacity
or increase the configured idle timeout so that lengthy operations
(such as uploading a large file) can complete. For more information,
see Configure the Idle Connection Timeout for Your Classic Load
Balancer and How do I troubleshoot Elastic Load Balancing high
latency.
Cause 2: Registered instances closing the connection to Elastic Load
Balancing.
Solution 2: Enable keep-alive settings on your EC2 instances and make
sure that the keep-alive timeout is greater than the idle timeout
settings of your load balancer.
ts-elb-errorcodes-http504
I have recently added a ALB for 2 instances in EC2.
I want to make the ALB and EC2 instances to be private so I added the security group for each services.
What I did is that I added the IP Addresses in HTTPS of the EC2 instances in the ALB sg. vice versa in the EC2 sg.
In Route 53. I made a subdomain to link in the DNS name of ALB.
I tried to test it first using sg that is public and it works fine and can access the EC2 application.
But after I tried to set the sg for both the ALB and EC2.
When I test it, It can't access it.
Where did I go wrong?
A security group can allow traffic from a CIDR range of IP addresses, or from another Security Group. Thus, you should configure the following Security Groups:
ALB-SG: Allow HTTP/S from 0.0.0.0/0 (if you want it open to the world). Associate it with the ALB.
App-SG: Allow HTTP from ALB-SG. Associate it with your EC2 instances (or Auto Scaling group Launch Configuration).
The Application Security Group (App-SG) is thus permitting incoming traffic from the Load Balancer. Or, more specifically, from any resource that is associated with ALB-SG.
Route 53 should have a CNAME record pointing your desired domain name to the DNS Name of the Load Balancer.
I have created a Application Load Balance in Aws.
I have created 2 EC2 and make them a group.
After that I add that group to the ALB with listener 80.
But when the system goes for healthy checks, it gives the error and shows that two registered EC2 are unhealthy.
The error is :
None of these Availability Zones contains a healthy target. Requests
are being routed to all targets.
Availability Zones:
subnet-5691df0f - ap-northeast-1c,
subnet-97ae35e1 - ap-northeast-1a
Please let me know the reason.
AWS Related image
AWS Related image2
I was running into this issue, and also getting a 504 Gateway timeout, and it ended up being this missing rule from the documentation.
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the left navigation, choose Security Groups.
Choose the security group that your container instances use. If you created your container instances by using the Amazon ECS first run wizard, this security group may have the description, ECS Allowed Ports.
Choose the Inbound tab, and then choose Edit.
For Type, choose All traffic.
For Source, choose Custom, and then type the name of your Application Load Balancer security group that you created in Configure Security Groups. This rule allows all traffic from your Application Load Balancer to reach the containers in your tasks that are registered with your load balancer.
Choose Save to finish.
Check if your heath check parameters in target group is properly configured
protocol and port should be pointing to something where response header return 200 ok
screenshot target group settings
also, check if you EC2 heath check is ok or not and the Subnet you added to Alb should have at least 1 Ec2 running any of those subnets,
check the security group also should allow ALB to look for EC2
AwS link 3: https://i.stack.imgur.com/TEOnU.gif]2
AWS Link 4
I encountered a similar issue while learning to setup load balancer for my EC2 instance.
It turns out that under Target Groups:
the "path" under the "Health Check" tab was not registered although it showed the correct value "/".
Therefore I just edited the path value(by clicking the "edit health check") to "/" and saved it again just so that the system can register that value. (you could also try saving it to some other value, say "/health", first and then saving it back to "/")
This seemed to fix my problem.
Hi all I just encountered the same issue and the solution is a setting in the ALB (Application Load Balancer) itself
Make sure the ALB AZ matches your instance AZ here is a screenshot of the setting. I am using us-east-1a and us-eas-1e for my instance. So my ALB setting for AZ should match that, click on the "Edit Subnets" button to edit your AZ on your ALB
Ensure that communication is allowed at security group level between your load balancer and your targets.
From AWS
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html
You must ensure that your load balancer can communicate with registered targets on both the listener port and the health check port [...] you must verify that the security groups associated with the load balancer allow traffic on the new port in both directions.
For example, a simple way to portray the rules you would require if you have a PUBLIC FACING load balancer in security group sg-001 and three EC2 targets in another security group sg-002 is as follows:
Just add new AZs by clicking on the Edit Subnet under the Load Balancer description.
So I set up a proxy server in AWS EC2 (let's say EC2 A) under Elastic Load Balancer with AWS AutoScaling groups... So I have 5 of EC2 : A under this elastic load balancer that has one DNS server endpoint for this proxies.
Through this proxy DNS (e.g. http://myelb.elb.aws.com), I want to send HTTP request from EC2 B.
Then where should I set up the security group?
And what kind of security rules for this program flow?
I tried to add EC2 A to the Elastic Load Balancer but it keeps being OutofService, never got to InService mode.
OutofService indicates that your Elastic Load Balancer is either not ready, or the instances are failing their Health Check. If you point to the little "i" information icon, it will explain why an instance is not InService.
Within your Elastic Load Balancer, take a look at the Health Check tab and confirm that it is configured correctly. It will either be checking a URL (eg /index.htm) or checking a port (eg port 80). If your "A" servers are listening on port 80, the quickest way to pass the health check is to set it to TCP and set the Healthy Threshold to 2 attempts.
Your Security Groups should have these settings:
A Security Group on your Elastic Load Balancer (eg ELB-SG) that allows incoming traffic either from the whole Internet (0.0.0.0/0) or at least from your "EC2 B" instance (specifically, it should allow traffic where the source is the name of a security group associated with your B instance).
A Security Group on your "EC2 A" instances that allows incoming traffic from the security group on your Load Balancer (ELB-SG).
If you are worried that your Security Groups are incorrectly configured, start troubleshooting by opening up access to the entire Internet (0.0.0.0/0) and, once you have confirmed connectivity, progressively reduce access to the above settings.