Docker containers behind ELB get dynamic ports which are auto registered with ELB so that they can get traffic redirected to them.
In order to make your web servers accessible to ELB you have to open all these ports 1024 - 65535 originating from within your security group.
Is there a way to not to have to open up a security group to a range of port but only to the pots that ELB is using?
Security groups are never modified by AWS as this might cause conflicts and security issues. The only exception would be services such as Elastic Beanstalk. You'd likely have to do what the forum says and allow port ranges.
Per http://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_PortMapping.html
The default ephemeral port range is 49153 to 65535, and this range is used for Docker versions prior to 1.6.0. For Docker version 1.6.0 and later, the Docker daemon tries to read the ephemeral port range from /proc/sys/net/ipv4/ip_local_port_range; if this kernel parameter is unavailable, the default ephemeral port range is used. You should not attempt to specify a host port in the ephemeral port range, because these are reserved for automatic assignment. In general, ports below 32768 are outside of the ephemeral port range.
If you actually care about what ports, you have a few options as far as I can see:
TCP 0-65535 for sg-foo where sg-foo is the security group both the ALB and apps are insg-foo, and put a rule on sg-app (where sg-app is the security group your applications are in) and allow traffic TCP 0-65535 from sg-foo inside sg-app
The EC2 host port that can be allocated as the docker published ports (dynamic ports) are ephemeral port ranges: 49153–65535 and 32768–61000 according to the document.
It looks to me they are over-wrapping (49153-61000?), but it is what the document says. Should be 32768-65535? Please someone explain why.
If dynamic port mapping is set up correctly, then you'll see the registered targets in the target group and the assigned port for the task. You'll also see the task in the registered targets for the following ephemeral port ranges: 49153–65535 and 32768–61000.
For instance, you can see port 32776 is allocated dynamically for a ECS task container.
$ sudo status ecs
ecs start/running, process 3176
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b95c013c6ba *****.dkr.ecr.us-east-2.amazonaws.com/\ecs_monolith_myecs/xyz "node server.js" 3 minutes ago Up 3 minutes 0.0.0.0:32776->3000/tcp ecs_monolith_ABC-1-XYZ-feb4d68dd3d2bfad7500
dbe356e8de8c amazon/amazon-ecs-agent:latest "/agent" 45 minutes ago Up 45 minutes (healthy) ecs-agent
Hence we can open up 49153–65535 and 32768–61000 (or 32768-65535) for incoming traffic from the ELB targat groups which the ECS service is updating for the dynamic port mapping.
For ALB, we can limit the traffic from the SG attached to ALB. But NLB has no SG the reason of which seems to be NLB is not running on EC2, hence no SG and as ALB runs on EC2, hence with SG.
NLB appears in your VPC as an ENI but it actually isn't. It's an extension of a component we have called HyperPlane. Whereas ALB and CLB are running on EC2 instances managed by AWS so they have "real" ENIs attached to them hence being able to use security groups.
NLB have a static IP. However, if the target type of the target group of ELB is instance, then the source IP is preserved as in Target Groups for Your Network Load Balancers.
If you specify targets using an instance ID, the source IP addresses of the clients are preserved and provided to your applications.
If you specify targets by IP address, the source IP addresses are the private IP addresses of the load balancer nodes. If you need the IP addresses of the clients, enable Proxy Protocol and get the client IP addresses from the Proxy Protocol header.
If the network mode of ECS is awsvpc, then we could use IP to make sure the traffic is only from NLB, otherwise, it looks there is no way to limit the source other than using the external client IP range.
In the container instance security group, restrict incoming traffic to a port range of 32768-65535 and the relevant subnet CIDR for your VPC and load balancer (e.g., 10.0.0.0/16).
