ELB(Elastic load balancer) can be used to make some compute instances(EC2) sitting in public subnet, public facing(to Internet), by assigning a public IP to ELB, where clients can talk to ELB.
Case 1
EC2 instances(having only private IP) in public subnet, receive http requests via ELB.
In case 1, How does EC2 instance respond back to client? Is it via ELB?
Case 2
EC2 instances(having both private IP & public) in public subnet receive http requests via ELB.
here, it says: "When you receive incoming traffic through the load balancer, the responses will go out the same way."
In case 2, How does EC2 instance respond back to clients? Does EC2 instance sent directly from the public IP address of your instance out to the Internet?
CASE 1
How does EC2 instance respond back to client? Is it via ELB?
Yes. A request coming thru the ELB will be forwarded to the EC2, and the EC2 response will go back thru the ELB and forwarded to the client. So yes, the ELB is playing its role in both directions.
CASE 2
In case 2, how does EC2 instance respond back to clients? Does EC2 instance sent directly from the public IP address of your instance out to the Internet?
If the request comes via the ELB, then the instance will send its response to the ELB, which will then forward to the client. In other words, requests coming thru the ELB always get their response thru the ELB:
CLIENT <-> ELB <-> EC2
In the referenced post (link), the person wrote:
When you receive incoming traffic through the load balancer, the responses will go out the same way. However, traffic that is originating from your instance will not pass through the load balancer. Instead, it is sent directly from the public IP address of your instance out to the Internet. The ELB is not involved in that scenario.
It's talking about traffic that is originated (initiated) by your EC2. Example: apt-get update will fetch a bunch of HTTP servers. This traffic won't pass the ELB. If you haven't changed the default VPC and route tables, the traffic will traverse the Internet Gateway (IGW) and go to the internet.
Related
I have an AWS infrastructure as follow:
EC2-WS01
EC2-WS02
Load balancer
These machines run the same code. In front of these machines is there a Load Balancer that distribute the load. So the clients point to the load balancer that forward the requests. One of the services of my app is a webhook service that send to an external server, protected by a firewall, some information every 15 minutes. We had to setup the firewall accepting the request from the two EC2 IP Address. I want to know if is possible make sure that regardless of the instances I have, when I make a request, it is always made by the same ip
Is possible to do that with an Elastic IP or what else?
Your architecture would need to be:
Load Balancer in a public subnet
Amazon EC2 instances in private subnet(s)
A NAT Gateway or NAT Instance in a public subnet, with an Elastic IP address
A Route Table on the private subnet(s) that sends Internet-bound traffic via the NAT Gateway/NAT Instance
The traffic from the Amazon EC2 instances will "come from" the public Elastic IP address associated with the NAT Gateway/NAT Instance.
I was wondering if someone could answer the question for me?
My understanding right now is:
Client makes request and packets first hit the route table for the public subnet
Route table routes the packets to the ELB
ELB routes packets to NAT Gateway
NAT Gateway routes packets to route table for private subnet
Private route table routes packets to one of the three nodes
Is this correct? Also are there any resources to understand the packet flow?
There are some notable problems with your description.
Classic ELBs do not route packets.
They work at either layer 4 (TCP mode) or layer 7 (HTTP mode) and in both cases they copy payload from one TCP connection (browser to ELB) to another TCP connection (ELB to instance) and back. This is why the instance sees the IP address of the balancer rather than the IP address of the browser. IP packets are below layer 4.
NAT Gateways are not used at all in handling ELB traffic.
NAT Gateways are for outbound connections, which means connections originated inside your VPC to destinations outside. This does not include reply traffic from the ELB. Without a NAT Gateway, the traffic through the ELB works the same as always, but the instances on the private subnet have no way of establishing outbound connections -- to talk to third party APIs, to set their clock to external time servers, to download software updates, or to communicate with any AWS service that doesn't have a VPC endpoint configured, such as S3, DynamoDB, etc.
The route tables are mostly irrelevant, because the only route that is actually used is the default route on the public subnet(s) where the ELB itself is located. This route allows the reply traffic to return from the ELB to the external client via the Internet Gateway. Everything else uses the implicit local routing that is built into VPC and not configurable -- traffic inbound from the client is implicltly routed to the ELB, and traffic between ELB and the instances is implicitly routed in both directions as well, because the source and destination IP addresses are internal private addresses of the ELB and the instances. The ELB and the instances communicate directly, not using any gateway device (such as a NAT Gateway).
For each connection needed, the ELB specifically selects one healthy instance and creates a connection to it. When the balancer is in TCP mode, there is a 1:1 relationship between client connections and instance connections. When the balancer is in HTTP mode, there are typically fewer instance connections than client connections, because the ELB will only establish as many connections to the instances as are needed based on traffic, and client connections tend to spend a significant amount of time doing nothing, between page loads.
I configured an internet facing ALB in AWS with two listeners (80 and 443) and the target groups are in private network (10.0.1.0/24). When http/https request are sent by ALB to the target group in 10.0.1.0 network, how the request is sent back to ALB? ALB has a public IP, and the target group do not have a route to internet. I can configure a NAT gateway and setup a route 0.0.0.0/0 to use the NAT gateway. But the web response will go all the way to internet and then comeback to ALB. Highly undesirable. I can't put these instances in public facing subnet either.
Can some one help how this can be done? I thought of VPC endpoint, and configured one with the load balancer (I used ELB, as I couldn't find ALB endpoint service). Now, the endpoint shows it has an IP in the 10.0.1.0 subnet. However, I don't know how this will work. Can someone suggest what's to be done. Thanks.
Not sure exactly what your question here is. But giving you a simple explanation of how AWS ELB works.
In both AWS Classic Load Balancers and Application Load Balancers, two connections are involved:
A connection between client (browser, etc) and ELB
A connection between ELB and backend target instances (webservers)
When creating an Internet facing ELB, you are given the option of selecting two subnets. These subnets should be public subnets which have a route to an Internet Gateway. The ELB will launch at least one ELB node in each of these subnets. Clients on the Internet will be able to connect to these ELB nodes using their public IPs through the IGW.
Once the ELB receives the request from the client, it forwards the request to its backend targets. This communication uses the PRIVATE IPs of the ELB nodes and the target instances. Therefore, even if the instances are in the private subnet, the ELB will still be able to forward requests to them because the connection is over private IPs which uses the 'local' route in the route tables. The response from the target then goes to the ELB over private IP, and is then forwarded to the client over public IP.
Client <--public IP--> ELB <--private IP--> Targets
The connection between client and ELB is over public IP, the connection between ELB and webservers is over private IPs which does not need a route to an IGW or NAT.
Don't worry about NAT Gateways for your private subnets. Just make sure the subnets you choose when creating the ELB are public and have a route to an internet gateway.
I have an application running in an EC2 instance in a private subnet (to add extra security), receiving traffic directly from an internet-facing NLB that is associated to the public subnet.
I have also configured a NAT Gateway in the public subnet so that the private EC2 instance can download whatever needed from the Internet.
I have just come out to the next conclusion:
If I request from the Internet: http://index.html
The private EC2 Instance uses the NAT Gateway to send back the HTTP response, and therefore you are charged for that NAT processing.
https://aws.amazon.com/vpc/pricing/
"Data processing charges apply for each Gigabyte processed through the NAT gateway regardless of the traffic’s source or destination"
The Route Table associated to the Private Subnet (where the web/app server is located) has { - local ; 0.0.0.0/0 - NATGateway} If I remove the 0.0.0.0/0 entry, then the HTTP requests to the server do not work. And if I remove the NAT Gateway I get the same issue.
Additionally, when I have the NAT Gateway and the route table to use it from the Private Subnet, I can also see traffic in the monitoring tab of the NAT Gateway when I do a simple HTTP request from the Internet - http:///index.html
Has someone faced the same issue? Is my understanding correct?
Is there any workaround to avoid this? I can just think of the following:
Move the application to a Web Tier (in a public subnet) so that the EC2 Instance has a public IP and therefore it does not need the NAT Gateway to respond to every HTTP request
Create a Web Tier in addition to the Application Tier, so that all traffic goes from the NLB <-> Web Tier <-> App Tier
Create a NAT Instance instead of a NAT Gateway so that you are not charged for that NAT processing.
Thanks!
So, it turns out there is an strange behaviour (bug?) in NLB that requires a default route to something for return traffic to work.
Scenario:
NLB in Public Subnet
NLB Target Group pointing to an instance in a Private Subnet
Sending traffic to the NLB will not give a response.
Add:
NAT Gateway
Add a route in the Private Route Table to point to the NAT Gateway
This works.
However, it doesn't actually use the NAT Gateway!
Instead of adding a NAT Gateway, you can instead create a default route to another instance, for example:
0.0.0.0/0 -> another instance
Then, connecting to the NLB works!
Behind the scenes, the VPC network detects that traffic coming out of the instance is in response to a request that came via the NLB, and traffic will be routed out the NLB.
HOWEVER, it only works if there is a valid default route in the route table. The route isn't used -- the network overrides it, so it doesn't matter what it points to. However, it must point to a valid resource. It doesn't work if it points to an ENI that isn't attached to anything. In my tests, it also doesn't seem to work if you point it back to the same instance. But, I pointed it to another instance and it worked just fine.
AWS Support agrees that this is not the best behaviour, but it's how things have to be configured for the moment.
Bottom line: It does not require a NAT Gateway. It just needs a valid default route that will be ignored when routing return traffic.
I have ETL servers in a private subnet in my VPC on AWS. These ETL servers are locked down with specific outbound rules per approved outbound IP addresses. I have a service these ETL tools need to communicate with outside the VPC using TLS1.2/443 that uses a DNS name and not an IP address. Let's say "account.service.com". For this reason, it was suggested I consider using an elastic load balancer in the public subnet as a proxy.
If I send requests to the ELB private IP address from the ETL instance, how do I tell the ELB to send those requests on to "account.service.com"?
Essentially, I want the ELB to work as a tunneling proxy, since I can't specify "account.service.com" in my outbound security group rules in the private subnet.
This is not possible.
Elastic Load Balancers can only send traffic to Amazon EC2 instances, and those instances need to be in the same VPC as the Load Balancer.
You would need to use some other technology (eg Squid proxy) in your Public Subnet to send traffic to a non-EC2 destination.