I have been trying to set up Elastic Beanstalk so that all instances across multiple availability zones appear externally to have the same static IP address. To do that, I followed the instructions here:
https://aws.amazon.com/premiumsupport/knowledge-center/elastic-beanstalk-static-IP-address/
I also followed the prerequisites here:
https://aws.amazon.com/premiumsupport/knowledge-center/nat-gateway-vpc-private-subnet/
I created a demo environment (PHP) and installed the sample application - just for a proof of concept. Everything works fine as long as I use only a single availability zone (load balancer is in a public subnet and there are two other private subnets for each instance - but all are in the same availability zone). The moment I try to modify Elastic Beanstalk so that some of the instances are in a different availability zone, I have mixed results. Sometimes I am able to get the application to load in my browser, and other times it just times out. I have tried various combinations of enabling / disabling cross zone load balancing, and I get the same results either way.
When I look at the load balancer, all instances show "In Service", and Elastic Beanstalk reports a status of "OK". When I run the VPC Reachability analyzer, it shows that each instances is reachable from the Internet Gateway.
Here is the configuration I have set up:
Availability Zone us-east-1c
Subnet 1 (public): This subnet routes traffic to the Internet Gateway. This is the subnet where the load balancer resides.
Subnet 2 (private): This subnet does not route anything to the Internet Gateway. Instead, it routes all outbound traffic to the NAT (which also resides in the public subnet).
Subnet 3 (private): This subnet is identical to Subnet 2 (uses the same routing table).
Availability Zone us-east-1b
Subnet 4 (private): This subnet is identical to Subnet 2 (uses the same routing table).
Availability Zone us-east-1d
Subnet 5 (private): This subnet is identical to Subnet 2.
So what I am seeing is that as long as I deploy instances only to subnets 2 and 3, everything works fine. As soon as I try to add instances in subnets 4 or 5, that's when the application starts becoming intermittent. Sometimes it works and sometimes it doesn't.
I should also point out that I am trying to load this application in my browser by referencing the URL of the load balancer, and also the auto-generated Elastic Beanstalk URL for the environment. The behavior is the same in both cases.
What am I doing wrong?
I was able to solve this by creating a public subnet in each availability zone and deploying the load balancer to each of those public subnets. After that, everything worked.
Related
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.
OK I'm trying to create an internal Network Load Balancer.
On the console, it says:
Mappings
Select at least two Availability Zones and one subnet per zone.
And at the same time it also says:
Your internal load balancer must have a private subnet.
I have created a new subnet (NLB-subnet, or subnet subnet-084f41a2d64bd25ad, as shown in the picture above) in my VPC, just for the NLB.
When you create a new subnet, you must choose the zone in which your subnet will reside. And you can only choose one in the AWS console. So I did, and I chose ap-northeast-1a.
However, when it asks me to Select at least two Availability Zones and one subnet per zone., I am confused like a 2 year old:
I have selected the AZ ap-northeast-1a for the NLB mapping, and that's where my new subnet resides, no problem.
But then I have to select a second AZ???
The seconds AZ has no subnet just for the NLB, because you can only choose one AZ for the subnet!
What does it want me to do?
Do I have to create a new private subnet in every one of the 3 Availability Zones, just for the NLB?
what? why?
You don't need to place your NLB in two AZs, if you don't want. NLB works fine in a single AZ as well. Only for ALB it is required to have two AZs. From docs:
You enable one or more Availability Zones for your load balancer when you create it. If you enable multiple Availability Zones for your load balancer, this increases the fault tolerance of your applications.
Is there any limit for the number of vpc to be attached to an elastic load balancer in aws. I have created an ELB with one VPC , I wanted to know , whether I can have multiple vpc on the same load balancer?
When setting up an Elastic Load Balancer (ELB) you must specify exactly one VPC. In this VPC you can select one subnet per Availability Zone (AZ).
These settings are needed to assign an IP address to the ELB. When you configure one one subnet then the ELB hat only one IP in this subnet. It is recommended to assign at least two subnets (in different AZs) to the ELB. This way any outage in one AZ does not affect the ELB.
Remember that this configuration is only for input data. Therefore, we handle the question how to connect to the ELB. Configuring output, e.g. where to forward the data by ELB, is another topic.
I see AWS Cloud load balancers in 2 categories:
By Traffic - Internet and Internal LBs
By Use - Application, Network and CLassic LBs
I want to deploy an internal load balancer into one private subnet and ask it to only distribute traffic among the instances in that subnet.
Is that possible?
I know that application LBs must be deployed to 2 subnets. Is there a configuration that allows deployment to only one subnet?
I know that application LBs must be deployed to 2 subnets. Is there a configuration that allows deployment to only one subnet?
Unfortunately, not for ALB.
However, you can use 1 subnet with NLB and CLB.
When setting up an ELB, it would say the following:
You must specify subnets from at least two Availability Zones to increase the availability of your load balancer.
I currently have two VPCs:
WebVPC
public-subnet-us-east-1a
private-subnet-us-east-1b
DatabaseVPC
public-subnet-us-east-1a
private-subnet-us-east-1b
The ELB is only meant for the WebVPC (to serve web traffic). I currently only have one public and one private subnet per VPC, which means I can only provide the ELB with one public subnet from my WebVPC.
Does this mean it is best practice to have at least two public and at least two private subnets?
Your architecture is not Highly Available. It is best practice to replicate services across multiple Availability Zones (AZs) in case there is a failure in one AZ (effectively, if a data center fails).
Also, it is typically best to keep all related services for an application in the same VPC unless you have a particular reason to keep them separate.
Also, security is improved by putting your application in private subnets, with only your load balancer in the public subnets.
Therefore, the recommended architecture would be:
One VPC
A public subnet in AZ-a
A public subnet in AZ-b
A load balancer connected to both public subnets
A private subnet in AZ-a
A private subnet in AZ-b
Your web application running simultaneously in both private subnets (assuming that it can run on multiple Amazon EC2 instances)
Your database running in one of the private subnets, with the ability to fail-over to the other private subnet. Amazon RDS can do this automatically with the Multi-AZ option (additional charges apply).
To learn more about architecting highly scalable solutions, I recommend the ARC201: Scaling Up to Your First 10 Million Users session from the AWS re:Invent conference in 2016 (YouTube, SlideShare, Podcast).
Yes. It is best practice to provide at least two Availability Zones.
If EC2 Instances were launched in Private subnet then load balancer should be launched in Public subnet which should have internet gateway attached to it.
Load Balancer can handle traffic through internet gateway and redirect to Private IPs of EC2 Instances. Only registered EC2 Instances will receive traffic from Load Balancer.
In your case:
You have to launch Database in Private subnet not in Public subnet as per best practice. Both Web tier and database tier can be in same VPC. If you have different environment like Dev, Test and Prod - all should be launch in different VPC. You can use VPC Peering to connect VPCs.
Instead of launching EC2 Instances in Public subnet, it is good to launch in Private subnet. Because, You will be using Load balancer to redirect network traffic to EC2 Instances.