I’m needing to deploy an api on ecs fargate that uses an internet facing network load balancer. After getting all this setup, the api deployed on ecs, and passing health checks, I’m noticing that I get a timeout error when I try to access the Dns nlb name in the browser. I think this may have to do with the firewall. The nlb doesn’t have a security group I can modify so I’m wondering if I’ve setup the fargate service security group correctly or if there’s anything else I can try. I’ve got 443,8443,80,8080 just to cover a few in that security group.
The nlb setup like the following: tcp 443 listener and then the container is hosted on port 8443. My question is, does the timeout issue sound like this has something to do with the firewall, and if so how do I allow the nlb on the ecs service sec group if that’s what’s needed? As of yet I’m unsure where to set the firewall configs for something like this since the nlb doesn’t have a security group.
I’ve got 443,8443,80,8080 just to cover a few in that security group.
Port 32768 to 61000 shoud open in security group for tasks in fargate to allow NLB access tasks. accroding to this page, if dynamic ports used in NLB and task definition.
Wish this helps
Related
I have an API on AWS ECS, connected with an Application Load Balancer. It has two target groups for blue/green deployment with CodeDeploy. The deployment works, and the targets are healthy, so I assume the app runs, and the ports are configured correctly. The port I use is 3000, and the listener is set to HTTP:3000 as well.
The load balancer is assigned to the default VPC security group, and for testing purposes I set an inbound rule to it that accepts all traffic, and the IP address is 0.0.0.0/0, so in theory it should be accessible for anyone. When I try to call the health check endpoint with {alb_dns}/rest/health (which is tested by the health checker, and it works), I get ECONNREFUSED error. Why can't I access it?
I face an issue in AWS Elastic BeanStalk health checking. I deployed to my NodeJS application to AWS via elastic beanstalk. Then I give permission my elastic load balancer TCP 443 port accessible for only my domain that is routed by Cloudflare. Basically, My elastic load balancer is only accessible by Cloudflare,
Due to the fact that I use Cloudflare, AWS health checks can not be able to access to the endpoint of the load balancer. How can fix this issue? I don't want to open my load balancer TCP 443 port to all world people. I want to open TCP 443 port for the only Cloudflare and, at the same time, I want to use health check of AWS :)
If somebody reads this question in the future, I thought that the health-check is being executed, externally - accessing publicly. But I have just learned that it was not :)). It is being executed directly internally. There is no problem related to Cloudflare or the security group or any other thing!
If there is an error in your ELB regarding this, the problem is probably related to your codebase, not the security group or other configurations.
I have a PHP + Apache application running in ECS with an Application Load Balance sitting in front of it. Everything works fine except when the application makes request to itself and the request times out.
Let's say the URL to reach the application is www.app.com and in PHP I use Guzzle to send requests to www.app.com but that request will always time out.
I suspect it is a networking issue with ALB but I do not know how I can go about fixing it. Any help please?
Thanks.
As you're using ECS I would recommend replacing calls to a public load balancer with a service mesh instead to allow your application to keep all HTTP(S) traffic internal to the network. This will improve both security and performance (latency is reduced). AWS has an existing product that integrates with ECS to allow this functionality named App Mesh/
Alternatively if you want to stick with what you currently have setup you will need to check the following functionality:
If the hosts are ECS hosts are private then they will need to connect outbound by using a NAT Gateway/NAT Instance in the routing table for the 0.0.0.0/0 route. For Fargate this will depend on if the container is public or private.
If the host/container is public it will need the internet gateway added to its route table for the 0.0.0.0/0 route. Even if inbound access from the ALB to the host is private the host will always speak outbound to the internet via an internet gateway.
Ensure that inbound/outbound security groups allow access to either HTTP or HTTPS
We are trying to create an ECS Cluster however we noticed that the internal ECS Agent is unable to register. We unblocked TCP 443 (ACL and SG) however it still did not register. We then proceeded to open up everything All Traffic both TCP and UDP and then the agent was able to register.
We tried to investigate what is being used using FlowLogs but it seems that the agent is using a random port and a different IP each time which makes it almost impossible for us to secure our network due to the agent. We tried and searched a lot for documentation about how and what the ECS Agent needs to run properly to no avail.
What we would like to achieve is to secure our network while allowing the agent to function as needed. Perhaps a better question would be which ports is the ecs-agent trying to use exactly and to which IPs should we allow that traffic to come from/go to?
From just 1 hour the flow log shows IPs from all over the world trying to hit the servers it just doesn't make sense not to prioritize this matter.
The ECS agent needs outgoing internet access to register itself to the cluster.
Here are some steps to try:
Check the security group on the EC2 instances to ensure they're
allowing outbound traffic.
Check your VPC config where the ECS instances are running and ensure they have internet access.
VPC Route Tables to ensure it's routing
destination 0.0.0.0/0 to your Internet Gateway.
Check your ACLs rules and ensure your outbound rules
match your inbound - which has bitten me a few times!
I'm having a hard time figuring out how to set the correct SecurityGroup rules for my LoadBalancer. I have made a diagram to try and illustrate this problem, please take a look at the image below:
I have an internet facing LoadBalancer ("Service A LoadBalancer" in the diagram) that is requested from "inhouse" and from one of our ECS services ("Task B" in the diagram). For the inhouse requests, i can configure a SecurityGroup rule for "Service A LoadBalancer" that allows incoming request to the LoadBalancer on port 80 from the CIDR for our inhouse IP's. No problem there. But for the other ECS service, Task B, how would i go about adding a rule (for "Service A SecurityGroup" in the diagram) that only allows requests from Task B? (or only from tasks in the ECS cluster). Since it is an internet facing loadbalancer, requests are made from public ip of the machine EC2, not the private (as far as i can tell?).
I can obviously make a rule that allow requests on port 80 from 0.0.0.0/0, and that would work, but that's far from being restrictive enough. And since it is an internet facing LoadBalancer, adding a rule that allows requests from the "Cluster SecurityGroup" (in the diagram) will not cut it. I assume it is because the LB cannot infer from which SecurityGroup the request originated, as it is internet-facing - and that this would work if it was an internal LoadBalancer. But i cannot use an internal LoadBalancer, as it is also requested from outside AWS (Inhouse).
Any help would be appriciated.
Thanks
Frederik
We solve this by running separate Internet facing and Internal Load Balancers. You can have multiple ELBs or ALBs (ELBv2) for the same cluster. Assuming your ECS clusters runs on an IP range such as 10.X.X.X you can open 10.X.0.0/16 for internal access on the internal ELB. Just make sure the ECS cluster SG also is open to the ELB. Task B can reach Task A over the internal ELB address assuming you use the DNS of the internal ELB address when making the request. If you hit the IP of a public DNS it will always be a public request.
However, you may want to think long term whether you really need a public ELB at all. Instead of IP restrictions, the next step is usually to run a VPN such as openVPN so you can connect into the VPC and access everything on the private network. We generally only ever run Internet Facing ELBs if we truly want something on the internet such as for external customers.