Using Terraform to setup a VPC with two EC2s in private subnets. The setup needs to SSH to the EC2s to install package updates from the Internet and install the application software. To do this there is an IGW and a NAT-GW in a public subnet. Both EC2s can access the Internet at this point as both private subnets are routing to the NAT-GW. Terraform and SSH to the private subnets is done via Client VPN.
One of the EC2s is going to host a web service so a Classic mode Load Balancer is added and configured to target the web server EC2. Using Classic mode because I can't find a way to make Terraform build Application mode LBs. The Load Balancer requires the instance to be using a subnet that routes to the IGW, so it is changed from routing to the NAT-GW, to the IGW. At this point, the Load Balancer comes online with the EC2 responding and public Internet can access the web service using the DNS supplied End Point for the LB.
But now the web server EC2 can no longer access the Internet itself. I can't curl google.com or get package updates.
I would like to find a way to let the EC2 access the Internet from behind the LB and not use CloudFront at this time.
I would like to keep the EC2 in a private subnet because a public subnet causes the EC2 to have a public IP address, and I don't want that.
Looking for a way to make LB work without switching subnets, as that would make the EC web service unavailable when doing updates.
Not wanting any iptables or firewalld tricks. I would really like an AWS solution that is disto agnostic.
A few points/clarifications about the problems you're facing:
Instances on a public subnet do not need a NAT Gateway. They can initiate outbound requests to the internet via IGW. NGW is for allowing outbound IPv4 connections from instances in private subnets.
The load balancer itself needs to be on a public subnet. The instances that the LB will route to do not. They can be in the same subnet or different subnets, public or private, as long as traffic is allowed through security groups.
You can create instances without a public IP, on a public subnet. However, they won't be able to receive or send traffic to the internet.
Terraform supports ALBs. The resource is aws_lb with load_balancer_type set to "application" (this is the default option).
That said, the public-private configuration you want is entirely possible.
Your ALB and NAT Gateway need to be on the public subnet, and EC2 instances on the private subnet.
The private subnet's route table needs to have a route to the NGW, to facilitate outbound connections.
EC2 instances' security group needs to allow traffic from the ALB's security group.
It sounds like you got steps 1 and 2 working, so the connection from ALB to EC2 is what you have to work on. See the documentation page here as well - https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
I'm not completely familiar with the load balancers in AWS. So, the idea is to set up a VPC with a public subnet and a private subnet. The instances and the ASG for the front-end will be in the public subnet, and the instances and the ASG for the backend will be in the private subnet. My question is which load balancer should I place between the front-end and the backend, and is it supposed to go in the public or the private subnet?
Any help is appreciated.
Hello I recommend you to use S3 + CloudFront for your web if its react app ( html,JS...) you can earn a lot with S3 + Cloudfront to have a serveless web hosting high scalable, and security also !!!
Regarding the back end part, the best practice is to put an ELB in your public subnet wich redirect traffic api to your back-end to a target group ASG in your private subnet.
You can add a certificate https ACM to your Alb to perform the transit security.
and the traffic from your ALB and instances ASG is in the http (port 80)
Finally the query will come from the client device wich whill get the app from cloudfront/S3 and perform a call to your ELB in public wichi redirect to your instances in private subnet.
I have an EKS cluster with worker nodes in private subnet. The worker nodes can access internet via the nat gateway. I have a Route53 hosted zone record routing traffic (alias) to a load balancer.
When I try to access the url (route53 record) from a pod within the EKS cluster, it times out. I tried allowing the worker nodes security group in the inbound rules of the load balancer security group but it does not work. Only thing that works is if I allow the public IP of the nat gateway in the inbound rules of the load balancer security group.
I am sure this setup is very common. My question is, is the solution of allowing the nat gateway public ip in the inbound rules of the LB SG the correct way or is there a better cleaner way to allow the access?
based on what you have described here, it seems like you have a internet facing load balancer and trying to access it from the pod. In this case, the traffic needs to go out to internet(through nat gateway) and come back to the load balancer, that is why it only works when you add the public IP of nat gateway to load balancer's SG.
Now, in terms of the solution, it depends on what you are trying to do here:
if you only need to consume the service inside the cluster, you can use DNS name created for that service inside the cluster. in this case the traffic will stay inside the cluster. you can read more here
if you need to make the service available to other clusters but same VPC, you can use a private load balancer and add the security group of worker nodes to the load balancer SG.
if the service needs to be exposed to internet, then your solution works but you have to open the SG of the public load balancer to all public IPs accessing the service.
I need to design a cross-region cross-VPC architecture and i am not sure how i can restrict access to my resources
The requirement is that i need to run my web app in one region and my database in an another region.
Both the servers are inside private subnets. The web app has an auto scaling group and load balancer attached. The database server in the other region should only be accessible from this web app. I cannot use ip based restrictions as the IP of load balancer changes with time. What other option do i have?
The IP address of your Load Balancer is irrelevant because the Load Balancer is only used for incoming connections to your web server.
First, I should point out that having your database remote from your application is a poor architectural decision, which will slow down your application. Please reconsider it if possible!
You have not provided much information, so I will make the following assumptions:
VPC in Region A contains:
A Load Balancer in a public subnet
Web servers in a private subnet
VPC in Region B contains:
A database in a private subnet
In this situation, you wish to communicate between two private subnets in different VPCs that reside in different regions. For this, you could consider creating a private VPN connection via Amazon EC2 instances located in the public subnets of each VPC. This would use a software VPN such as OpenVPN or OpenSwan.
You should also consider how to achieve a High Availability option for this solution. A well-architected VPC would have your web servers deployed across multiple Availability Zones in Region A, with your database preferably in a multi-AZ configuration in Region B (assuming that you are using Amazon RDS). You should similarly design your VPN solution to be highly-available in case of failure.
An alternative is to put a NAT Server in the public subnet of the VPC in Region A and configure the private Route Table to send traffic through the NAT Server. This means that traffic going from the web servers to the Internet would all come from the public IP address associate with the NAT Server (not the Load Balancer).
However, the database is in a private subnet, so the traffic cannot be directly routed to the database so this is only half a solution. It would then either require the database to be in a public subnet (with a Security Group that only accepts connections from the NAT Server) or some type of proxy server in the public subnet that would forward traffic to the database. This would become way too complex compared to the Software VPN option.
I'm putting the instances behind the aws loadbalancer, I have configured the routable and attached the IGW to it, created the loadbalancer and added this instance to the aws loadbalancer every things work well, the endpoint URL of the AWS loadbalancer able to load the HTTP pages
Now i have removed the IGW from the route table and tested it again, the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
A subnet without a default route pointing to the igw-xxxxxxxx Internet Gateway object is, by definition, a private subnet. If you remove the igw from a public subnet, you now have a private subnet.
Placing an Internet-facing load balancer (ELB) in such a private subnet is incorrect.
It sounds as though you are making a commonly-made -- but incorrect -- assumption that the ELB should be configured in the same subnets as the instances behind it. This is also incorrect.
Provision the ELB in public subnets, without regard to the subnets the instances behind it were placed in.
In summary:
Internet-facing ELB requires a public subnet for placement.
NAT instance requires a public subnet for placement.
The instances that use these services (NAT and ELB) belong in different -- private -- subnets, different subnets than the ELB and NAT instances.
ELB and NAT can be placed together in the same subnets, or separately, as long as the subnets are public (have the IGW as their default route) and are in the same availability zones.
I believe you cannot do anything without the IGW attached to the routing table where the subnet is attached to.
Another way to do this is to spin off a NAT instance(can be found in AWS marketplace) in the public subnet, add it to your private route table where your original instance is on (0.0.0.0/0 - instanceid) all the traffic will be routed through the NAT instance.
Here mainly we have to see two things, provided subnet for the elasticloadbalancer is public or private.
Every VPC should have one IGW to connect to the public, every trafic should go through the IGW only. If VPC connected to the IGW, IGW distribute internet to the all instance which are in that VPC, if route table changed to the particular rt, internet traffic can send to only that instance. Here in ELB instance is in service because both are in the same VPC and can communicate each other means checks the status. This IGW will work main role when we are using the NAT.
Always we provide ip range for the IGW or rt as 0.0.0.0/0, it represents as public.
The following link will explain more : http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
This small explanation might be helpful for someone.
Let me cover your two questions
the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
This is the default behaviour of load balancer , since internally load balancer and your instance may be in the same VPC so they are able to communicate that is why loadbalancer is showing inService status.
Second question Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
You need IGW if you want to access any resources especially EC2 , Loadbalancer from internet. however if you put your load balancer in private subnet it means IGW is not associated with the subnet having loadbalancer in it and hence this load balancer is not accessible outside your VPC that is reason that you were not able to load your page.
NAT instance is usually used when you want your private subnet instances should be able to initiate request over internet and has nothing to do with normal load balancing setup unless and untill you want dont want to install any updates from internet to your instance.
You are trying to access webpage publicly and removing the route entry IGW from the loadbalncer subnet.
The Subnet without IGW will become Private, Hence you can't access it.
First, a subnet with route table that route traffic via the internet gateway (IGW) is a public subnet. An IGW is required because the subnets created in AWS VPC are internal IPs and as internal IPs are not routable via the internet, traffic to and fro EC2 instances that belongs to an internal IP needs a way to complete these request. This is where an IGW comes into play. The IGW allows your EC2 instance to make outbound request to the internet and allows other user/client to make inbound request to your ec2 instance.
A public subnet are group of IPs (called subnets) in your VPC that allows internet traffic to and fro your ec2 instance. A subnet without an Internet gateway is a private subnet. As you already guess no traffic is allowed in or out.
That said, instances in VPC which are in Private subnet still need to initiate an outbound request to the internet to download software or perform update. In this case you have to create and attach a NAT gateway or NAT instance to the private subnet. NAT Gateway and NAT instance only allow outbound traffic to the internet but not the the other way round. In some cases you might want your production EC2 to be in the private subnet and ELB in public subnet for security reason.
ELB usually belong to the public subnet so it reachable from the internet as is your case as well.
TO answer some of your question - when you deleted the IGW from the route table, your ELB automatically becomes a private subnet as such your web page stops loading.
Also, you could still see the ec2 instance behind the ELB as InService even when you deleted the IGW because the ELB and EC2 instance can communicate via the internal IP as they are in same network or VPC.
The ELB needs a route to the internet in order to send you the response over internet.. As simple as that.
Configure your ELB in public subnet, regardless of where your instances are present.
Basically there are two types of load balancers.
1)Internal
2) External
Internal load balancers are those which are launched in a private subnet which will be accessible only internally by the instances on same vpc of the internal elb
External load balancers are which are accessible over the internet which should be launched in a subnet which has internet gateway attached to it and which has route table configured properly to route the requests.
If you attach an internet gateway to a subnet it becomes a public subnet.Also if you create a load-balancer which you need to be accessible from internet it should be a External load balancer and aws will not allow it launch in a private subnet.The instances are showing in service because its communicating internally using private ip-address.