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.
Related
I created 2 private subnets PRIVATEA and PRIVATEB in a custom VPC. These subnets are in different availability zones. Added an EC2 instance in PRIVATEA. The instance already has an ENI eth0 attached to it. Next I created an ENI in the other PRIVATEB subnet and attached it to EC2 instance in PRIVATEB subnet. The setup is successful. Basically I followed a blog tutorial for this setup. It said that secondary interface will allow traffic for another group i.e. Management.
But I am not able to relate any use case with it. Could anyone please explain when do we use such a setup ? Is this the correct question to ask in this forum here ?
Thanks
An Elastic Network Interface (ENI) is a virtual network card that connects an Amazon EC2 instance to a subnet in an Amazon VPC. In fact, ENIs are also used by Amazon RDS databases, AWS Lambda functions, Amazon Redshift databases and any other resource that connects to a VPC.
Additional ENIs can be attached to an Amazon EC2 instance. These extra ENIs can be attached to different subnets in the same Availability Zone. The operating system can then route traffic out to different ENIs.
Security Groups are actually associated with ENIs (not instances). Thus, different ENIs can have different rules about traffic that goes in/out of an instance.
An example for using multiple ENIs is to create a DMZ, which acts as a perimeter through which traffic must pass. For example:
Internet --> DMZ --> App Server
In this scenario, all traffic must pass through the DMZ, where traffic is typically inspected before being passed onto the server. This can be implemented by using multiple ENIs, where one ENI connects to a public subnet to receive traffic and another ENI connects to a private subnet to send traffic. The Network ACLs on the subnets can be configured to disallow traffic passing between the subnets, so that the only way traffic can flow from the public subnet to the private subnet is via the DMZ instance, since it is connected to both subnets.
Another use-case is software that attaches a license to a MAC address. Some software products do this because MAC addresses are (meant to be) unique across all networking devices (although some devices allow it to be changed). Thus, they register their software under the MAC address attached to a secondary ENI. If that instance needs to be replaced, the secondary ENI can be moved to another instance without the MAC address changing.
Just starting to move our first application to AWS. We have one public subnet (web servers) and two private subnets (for our app instances and databases). My query is where should we put our log management (greylog) and monitoring instances. Should we put them into our app instances subnet or create another private subnet?
Yes you can use the same app subnet, but it is good to have separate subnet for separate services since it will helpful for scenarios like while debugging we can easily classify that requests coming from a particular CIDR range belongs to app subnet or monitoring subnet and we can also have the flexibility of blocking traffic through ACL which applies at subnet level.
You can very well place the logging/monitoring servers in the one the existing private subnets as long as you have rightly sized the subnet CIDR block with enough IP addresses.
Refer this documentation for VPC/Subnet sizing
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4
I wish to implement my website in AWS virtual private cloud (VPC) with the following requirement:
The web tier will use an Auto Scaling group across multiple Availability Zones (AZs).
The database will use Multi-AZ RDS MySQL and should not be publicly accessible.
What is the minimal number of subnets required?
I assume one subnet = one AZ. Having said that, I will be needing 2 subnets for the RDS instance and one for my web tier which might have to sit in the public subnets? so total 3 minimal?
You have two options:
Do everything in Public Subnets, using Security Groups to protect your database, or
Use Public & Private Subnets
If both options, you would need:
An Amazon VPC
An Internet Gateway (which connects the VPC to the Internet)
An Elastic Load Balancer
An Auto Scaling group of Amazon EC2 instances running your web tier
An Amazon RDS Multi-AZ database -- you have indicated a preference for MySQL
Also, you would create three security groups:
A Load Balancer security group, permitting inbound traffic from the Internet (0.0.0.0/0) for HTTP (port 80) and presumably HTTPS (port 443)
A Web Tier security group, permitting inbound traffic from the Load Balancer security group on the same ports
A Database security group, permitting inbound traffic from the Web Tier security group on port 3306 (MySQL)
Option 1: Do everything in public subnets
In this option, you can put all services inside a Public Subnet (which is defined as a subnet connected to the Internet via an Internet Gateway).
You wish to implement a multi-AZ solution, so you will need one subnet per AZ. If you choose to use two AZs, this means you will need two subnets. (You could choose to use more than two AZs/subnets, if they are available in your region.)
Deploy your Load Balancer in both subnets. Create your Auto Scaling group to use both subnets. Create an Amazon RDS DB Subnet Group across both subnets for use by the multi-AZ database and launch the database into that DB Subnet Group.
The security groups will ensure that only the Load Balancer is exposed to the Internet. Nothing else will be publicly accessible.
Option 2: Use Public & Private Subnets
Some people prefer using Private Subnets to ensure resources are not exposed to the Internet. This is mostly to remain compatible with traditional on-premises architecture that does not have the concept of a Security Group.
This option would involve:
A Public Subnet in each AZ: Put your Load Balancer in these subnets
A Private Subnet in each AZ: Put your Web Tier Auto Scaling group and your database in these subnets (defined via the DB Subnet Group)
Use the same Security Groups as option 1
But if you put 3 subnet in different AZ as you said that is better for security and accessibility from web-server.
There is no requirement for 3 subnet.
If you put 2 subnet in different AZ and 1 is public and 1 is private that is also able to communicate with each other because of in 1 VPC multi-pal instance can calumniate with each other and different.
But if you put 3 subnet in different AZ as you said that is better for security and accessibility from web-server.
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 was setting up an environment using Elastic Beanstalk and I wanted the hosts to be apart of the default VPC for my account. I didn't really understand what the options meant. See the below image for an example:
Associate Public IP Address - How does this differ from the ELB visibility?
Subnets for ELB and EC2 - What do these do? The set-up wizard requires at least one box is selected. During my setup I selected all of the boxes.
VPC Security Group - How does this differ from the security group of the EC2 hosts. I use the security groups to SSH onto the hosts. Why does the VPC need a security group?
If selected, the ELB will be created with a public IP address associated to it (or the EC2 instance will if you select single instance instead of load balanced during the setup). Visibility is just for ACLs, and won't actually give it a publically accessible IP.
In a common VPC setup, you'll have both public and private subnets with a NAT in between them. Things in the public subnet can usually access the Internet and private subnet. Private subnet can usually just access the local subnet. In a load balanced EB environment, you'd typically place the ELB in the public subnet and the EC2 instance(s) in the private subnet.
VPC security groups are for your resources (anything in your VPC). They're just prefixed with the term VPC so as to distinguish between VPC security groups and legacy EC2 security groups (for EC2 instances that are not part of any VPC). The option in the UI only affects the EC2 resources in your VPC though I believe...not the ELB.