I'll start with describing the architecture of Application Load Balancer:
We have the Application Load Balancer, which contains a list of one or more listeners. Each listener is associated with one specific port and protocol, so that traffic incoming to the load balancer with this port will be handled by this listener. Then, each listener holds a list of rules. A rule specify conditions and actions - basically where to route traffic to. A listener also must have a default action which will be taken if no other condition is met. Usually, this action will be to route traffic to a specific target group.
A target group is a group of either EC2 instances, IP addresses, other Application Load Balancer, or Lambda function.
Furthermore, when you create an Application Load Balancer, it asks you to specify a VPC and list of 2 or more Availability zones, and for each to specify a subnet.
My question now is: Why does AWS asks you to specify this? As far as I understand, the target groups and the registered targets are where you specify the backend of the load balancer, so why do we need to specify the subnets in the ALB configuration?
EDIT
After experimenting, I found that, if I have a EC2 instance running a web server in AZ 3 for example, and now I create a load balancer and selects AZs 1 and 2, then traffic will not reach the web server on AZ 3 until I add another AZ in the load balancer settings.
So if to accurate my question: If this setting of AZs in the load balancer settings means: these are the AZs in which the Load Balancer will send traffic to, in what scenario should I not choose ALL the availability zones there are?
An Application Load Balancer runs on Amazon EC2 infrastructure. Think of it as an Amazon EC2 instance with pre-loaded software, but you don't actually see the EC2 instance in your own account.
Instead, you will see the Network Interfaces where the Load Balancer connects into the network.
Traffic will come into your network through an Internet Gateway then route within the VPC to the Load Balancer. The Load Balancer will then determine a target to receive the traffic, and will send the request via the Network Interface to the resource in the VPC.
When such traffic flows through the VPC, it is subject to normal Security Groups and Network Access Control Lists (NACLs). Private IP addresses will be assigned for each Network Interface used by the Load Balancer.
The Load Balancer instance runs in multiple AZs. If one AZ has a failure, then the Load Balancer instance in the remaining AZ(s) will continue to run. This is why the Load Balancer wants a connection to the VPC in multiple subnets.
Bottom line: While you might normally think of the Load Balancer as a "blackbox service", it is still just some software running on a virtualized computer that needs logical connectivity to the VPC, and it obeys all the rules of networking within the VPC.
why do we need to specify the subnets in the ALB configuration?
Because the load balancer itself requires physical network interfaces, which are created in the subnets you specify (one network interface per subnet).
When you need ALB you must assign an IP address to it. A subnet is nothing more than a range of IP addresses. By placing an ALB inside a subnet, you define which range of IP you desire to be assigned to this resource. Moreover, These subnets allow you to configure different security layers regards the resource inside the subnet for traffic management.
Your target group is located in another subnet with a different range, whereas you can place your ALB in another subnet with a different range.
Related
Are the healthchecks that the target group performs routed from outside the VPC (aka from internet) or are generated and routed internally. I am asking this because I don't know if I should open the port for healthchecks from security group at internet level (0.0.0.0) or VPC level (10.0.0.0/16)
Thanks
Health checks from the target group are always routed internally, inside the VPC. However, instead of allowing requests from (10.0.0.0/16) you should actually allow requests from the security group ID that is assigned to the load balancer.
Target groups are part of Load balancer and behind Load balancer you application layer resides either in form of Ec2 or ECS containers or any other application tier component.
Since public/internet user will be interacting with load balancer hence load balancer will SG will be open which mean allows traffic from anywhere.
And to Application tier i.e ec2 or ecs container the traffic is routed from load balancer only which means only traffic from load balancer should be allowed and to do you need to allow traffic from Sg of load balancer.
I set my load balancer to allow traffic on port 80 to the security group of my EC2 instance, but the load balancer refuses to connect. To do a sanity check, when I allow HTTP traffic from my IP to the load balancer, I'm able to connect seamlessly. I can only access the load balancer from my EC2 instance when I allow all traffic to port 80 on my load balancer. I keep checking back and forth to make sure the security group that the EC2 instance is in is the same as the one that the load balancer should allow, so I know it's not that. What else could be blocking the traffic?
Context: I used a load balancer because I wanted a static address for my EC2 instances to access and I don't want the IP to be dynamic. Basically, behind the load balancer is one coordinator instance that I want to manage jobs for the auto scaling EC2 instances. The load balancer can be internal for the purposes I need it for.
Network traffic between an EC2 instance and a public facing load balancer will go out to the Internet and back, it won't stay within the VPC. Once the request leaves the VPC it loses its association with the source security group, which is why your security group rule isn't working. If the EC2 instance has an Elastic IP address assigned to it, you could try adding that to the load balancer's security group instead.
There is probably a better way to do what you are trying to do without having your EC2 instance access a public load balancer. Perhaps the load balancer could be converted to an internal load balancer? Or maybe there is a better way for this EC2 server to communicate with the resources behind the load balancer directly somehow. You would need to post more information about your system and your desired goal for help with that.
I have two Elastic Beanstalk instances inside the same VPC -- one with public load balancing (internet accessible), one with internal load balancing only.
For extra security, I'd like the internal instance to be completely siloed from the public internet -- no data can enter and no data can exit unless it is through another instance in my VPC.
Is what I am looking for, a "siloed" instance, accomplished by making my load balancer VPC internal only? That is, can that the internal only instance make a request to www.google.com (or another random site) while inside the VPC, or will it not be able to get outside of the VPC? Or alternatively do I need to set outbound security groups to prohibit all traffic not to my other instances.
This is the internal setting I am talking about in Elastic Beanstalk:
Visibility: Internal
Make your load balancer internal if your application serves requests only from connected VPCs. Public load balancers serve requests from the Internet.
As a side note, I have set my security groups so that the only outbound connection is the load balancer and VPC security group. But I am wondering if internal load balancing takes that a step further, regardless of what I set in my outbound rules.
An internal load balancer will/can route traffic to both instances within a Public Subnet or a Private Subnet. Routing traffic via an internal load balancer does not affect or impact the visibility of the instances to or from which the traffic is routed from the load balancer.
I created an internal network load balancer (NLB) to connect to EC2 instances on a private subnet. I want to restrict access to the EC2 instances only from the network load balancer. I used these instructions https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups but it did not work.
Basically, I added the IP address of the network interface of the NLB to the security group with my specific port (eg: 8080 10.4.2.9/32) allowed but that did not work. When i switched to all allow (eg: 8080 0.0.0.0/32) it worked, but i do not want other instances to have access to the ec2 instance.
Any ideas on why this is not working?
Thanks
For what you are trying to accomplish, NLB is the wrong load balancer.
NLB is a layer 4 load balancer. This means that the IP address that you see (at the EC2 instance) is the IP address of the client and not the IP address of the load balancer. With NLB you must allow the client's IP address in your security group.
You want a layer 7 load balancer to implement what you want to do (block other systems in your VPC from accessing your EC2 instances directly). This means ALB or the classic ELB.
If you're using a Network Load Balancer, update the security groups
for your target instances, because Network Load Balancers do not
have associated security groups.
If your target type is an IP, add a rule to your security group to
allow traffic from your load balancer to the target IP.
If your target type is an instance, add a rule to your security group to
allow traffic from your load balancer and clients to the target IP.
You can allow traffic in the EC2 instance security group. As your
instance is in private subnet for that you need to lunch load
balancer in the same region but in public subnet.
Know about your use case first.
Best use cases for Network Load Balancer:
When you need to seamlessly support spiky or high-volume inbound TCP
requests.
When you need to support a static or elastic IP address.
If you are using container services and/or want to support more than one
port on an EC2 instance. NLB is especially well suited to ECS (The
Amazon EC2 Container Service).
security-group-load-balancer
new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second
what-is-a-network-load-balancer
Has someone configured a NLB in the public subnets of your VPC to route traffic to EC2 instances that are in the private subnets?
When using an ELB, a good solution is to create a Security Group for the ELB and then create another SecurityGroup for the private EC2 Instances, allowing incoming traffic from that ELB Security Group, as explained here:
https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
"You can also add a rule on the instance’s security group to allow traffic from the security group assigned to the load balancer. For example, if the security group on the load balancer is sg-1234567a, make the following changes on the security group associated with the private instances"
Since you cannot associate a Security Group to a NLB, how could you accomplish this with the same type of security?
Thanks!
Since you cannot associate a Security Group to a NLB, how could you
accomplish this with the same type of security?
The security aspect does not change.
NLB is a different beast, it not the same as classic Load Balancers. For Classic Load Balancers, from the point of view of your instances, traffic does appear to come from inside the VPC. From outside, traffic goes to a (random and mutating) list of IP addresses, resolved by the DNS record that AWS provides to you.
Network Load Balancers are completely different. From the point of view of your instances, they are completely invisible. If it is an external network load balancer, traffic appears to be coming from instances on the internet directly (even though this is an illusion). Therefore, if you want to talk to everyone on the internet, 0.0.0.0/0 is what you open it to.
This is, in fact, what the documentation says:
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups
Recommended Rules
Inbound Source Port Range Comment
Client IP addresses instance listener Allow traffic from clients on the instance listener port
VPC CIDR health check Allow traffic from the load balancer on the health check port
Client IP addresses is whatever your client IPs are. If they are on the open internet, 0.0.0.0/0 it is. Adding the NLB private IP address, as I saw in other responses, accomplishes nothing. Traffic is not coming from there, as far as the instances are concerned.
On the security angle, nothing changes. Since your instances are in private subnets, traffic cannot flow directly to them, as there is a NAT gateway in the middle. It can only flow from them to the internet (through NAT gateway, then internet gateway). Even if you specify all traffic is allowed from everywhere, traffic still won't come. It will have to come through another way. In your case, that way is the NLB, which has a fixed number of ports it listens to, and only sends traffic to the destination ports on the instances you specify.
If you are moving from classic Load Balancers to NLBs, move the security group rules from the Load Balancer to your instances. Or better yet, since you can have multiple security groups, just add the SG you currently have for the classic LB to the instances(and update any ASGs as needed). Your security posture will be exactly the same. With the added benefit that now your applications won't need things like proxy protocol to figure out where traffic is coming from, it is no longer obfuscated by the load balancer.
That is indeed true as per AWS Documentation :
Network Load Balancers do not have associated security groups.
Therefore, the security groups for your targets must use IP addresses
to allow traffic from the load balancer.
So If you do not want to grant access to the entire VPC CIDR, you can grant access to the private IP addresses used by the load balancer nodes. There is one IP address per load balancer subnet.
On NLB Tab of there is one Network Interface per Load Balancer from there :
On the Details tab for each network interface, copy the address from
Primary private IPv4 IP.
You can use this private IP Address at add it SG of EC2 Instances.
Please Refer to AWS Documentation
Tail your http access logs and you will see there is no changing of source IP address from the network load balancer which means you need to allow 0.0.0.0/0 on the endpoints security group if the internet needs access to your endpoint.
This is only ok if you use a private subnet so be careful if you have this server on a public subnet as this solution would not be advisable. In this case just use an application load balancer. You can still setup the same listener and configure a target group by instance as well. The application load balancer will update the source IP address to it's own private address if you tail the access logs. The advantage of this is you only need to allow https traffic to the app load balancer and then you can accept http for the target group if you like from the load balancer.