I am able to make work the backend service as an instance group - if i enable the "Allow http access" enabled while creating the members in the instance group.
However i want to disable this and make the network work only from the loadbalancer(external ip). However it is not working. The way I did was to define a firewall rule in the subnet where the instance group is there, such that the destination is the network tags defined for the instance group members
settings link as iamge
the source is dfined as the ip of the load balancer as a range.
Create VPC Firewall rules that only allow traffic from the load balancer and health check service.
130.211.0.0/22
35.191.0.0/16
34.96.0.0/20
34.127.192.0/18
References:
Firewall rules
Configuring a firewall rule
Where you looking is fine, you can do it.
The steps are, as I suggested in my comment a little bit more, I will resume them in this list, and let you the link of a qwiklab, you can check the steps there with the code to do it by yourself.
Basically:
Create the instances or instance group with the corresponding healtcheck.
Configure the Load balancer
Set the traffic to the new loadbalancer and build the proxy.
Create HTTPS Load Balancer and send the traffic to the Proxy.
https://www.qwiklabs.com/focuses/12007?catalog_rank=%7B%22rank%22%3A1%2C%22num_filters%22%3A0%2C%22has_search%22%3Atrue%7D&parent=catalog&search_id=15082883
I think that the link is creating instance by instance, but the steps should be the same for an instance group.
Related
I have 2 Elastic Beanstalk environments, "api-server" & "website". Both have a capacity of 1-4 EC2 instances and a load balancer. The load balancer and the instances have both public IP addresses. I want to connect from the "website" to the "api-server" but i can't get it to work without making the "api-server" public. The "api-server" should not be public.
I am connected with a VPN that is allowed HTTP connections to both EB environments and i can confirm that both apps respond.
Both EB environments have 2 security groups, one for the load balancer called "Load Balancer Security Group" and one for the instances called "VPC Security Group". All load balancer and VPC security groups have an outbound rule allowing all traffic on all protocols.
Since i want to connect from the "website" to any of the instances of "api-server" i want to connect to the load balancer and not to any of the instances directly. So i should add an inbound rule to the load balancer group of the "api-server" that allows traffic from the "website"'s instances.
The instances all have the "VPC Security Group" but adding the rule did not give the "website" instances access to the "api-server". I also tried adding the load balancer security group without success. And i also tried the type "All traffic".
I also tried to connect to the "api-server" over different URLs like the load balancer but also no connection possible.
When i add a rule that allows traffic to everywhere, eg. source type "Anywhere-IPv4", i can access the "api-server" from the website. But as i said i don't want the "api-server" public it should be accessible only by the "website".
What also works is adding a rule with the IP address of the current "website" instance, but since they change with deployment of a new version and they are sometimes more or less instances (autoscaled from 1 to 4) its not an option.
So how does it work?
I searched everywhere in the docs but i can't find anything i didn't already tried. What am i missing? This surely shouldn't be so hard?
I appreciate every help!
Edit: Everything is in the same VPC.
So how does it work?
Referencing security groups (SGs) works only withing VPC or peered VPCs. Since you are accessing your second EB over the internet, not within same VPC, you can't reference SGs.
You have to whitelist public IP addresses of your instances. The best way is to put them in private subnet and use NAT gateway. The NAT gives you a single public static IP which you can use in your ingress rule of the second EB environment.
I have been struggling with this problem for 2 days but couldn't get it working.
I have this flow:
external world --> AWS API Gateway ---> VPC Link ---> Network Load Balancer ---> my single EC2 instance
Before introducing the API Gateway, I want to first make sure the Network Load Balancer --> my single EC2 instance part works.
I have set up the EC2 instance correctly. There is a Typescript / ExpressJS api service running on port 3001
I have also set up a Network Load Balancer and a Target Group, the NLB is listening and forwarding requests to port 3001 of the target group (which contains the EC2 instance).
Here is the NLB:
Note that the NLB has a VPC! This raise the question below and I find it so confusing.
listener:
You can see it is forwarding requests to docloud-backend-service, which is described as follows:
You can see that the health check has passed.
I have configured the security group of my EC2 instance with this rule:
1. Allow All protocol traffic on All ports from my VPC
(specified using CIDR notation `171.23.0.0/16`);
Now, when I do curl docloud-backend-xxxxx.elb.ap-northeast-1.amazonaws.com:3001/api/user, the command fails by timeout.
Then, after I add this rule:
2. Allow All protocol traffic on All ports from ANY source (`0.0.0.0/0`);
Now, when I do curl docloud-backend-xxxxx.elb.ap-northeast-1.amazonaws.com:3001/api/user,
the api service gets the request and I can see logs generated in the EC2 instance.
Question:
The second rule opens up the EC2 instance to public, which is dangerous.
I want to limit access to my EC2 instance port 3001 such that only the AWS API Gateway, or the NLB can access it.
The NLB has no security group to be configured. It has a VPC though. If I limit the EC2 instance such that only its own VPC can access it, it should be fine, right?
The first rule does exactly that. Why does it fail?
The NLB has a VPC. Requests go from API Gateway to NLB, then from NLB to EC2 instance. So from the EC2 instance's perspective, the requests come from an entity in the VPC. So the first rule should work, right?
Otherwise why would AWS assign a VPC to the NLB anyways?
Why would I see the VPC on the NLB's description console anyways?
I want to limit access to my EC2 instance port 3001 such that only the AWS API Gateway, or the NLB can access it.
For instance based target groups and for IP based target groups as well we can enable/disable if want to preserve the requester's IP address:
This setting can be found if go to our target group -> Actions -> Edit Target attributes.
What does this mean from the perspective of the Security Group of our application?
If we enable it (which is the default for instance type target groups), the application will see traffic as it is coming directly from the end-client. This means, you we have to enable inbound traffic for 0.0.0.0:3001.
If we disable it, the application will see the source traffic as it was coming from the private IP address of the Network Load Balancer. In this case, we can limit the inbound traffic to the private IP address of the NLB or to the CIDR range of the subnet in which the NLB is placed.
I created an EC2 instance with apache installed on it and allowed HTTP/SSH traffic for my system only. I was able to access Web page using public IP of EC2. Then I configured ALB with same SG, registered same EC2 instance with ALB. Tried to access Web page using DNS name of ALB, got error -504 Gateway Time-out.
Increased time out interval to see if this resolves issue, didn't work. Then I revisited lesson and thought lets allow HTTP traffic to everyone(since it was allowed in lecture) in SG to see if it works and YES, it worked. I again changed SG to allow traffic only for my system and it failed again.
In this configuration, your security group needs to allow traffic from itself -- create rules that allow the appropriate ports, but use the security group sg-xxxx in place of an IP address, as the source. Merely being members of the same security group does not allow two systems to communicate with each other.
A better configuration would be for the balancer to have its own security group, and your instance's group would allow traffic from the balancer's group.
Note also that without the security group configuration being correct, you should also find that the health checks on the balancer are failing.
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.
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.