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.
Related
My VPC is in eu-west-2. I have two subnets for an RDS instance, split across two different availability zones for reasons of high availability: eu-west-2a and eu-west-2b. I also have a Redshift cluster in its own subnet in eu-west-2c.
With this configuration, I have successfully configured an AWS Client VPN endpoint so that I can access RDS and Redshift from my local machine when connected to a VPN client with the appropriate configuration.
While following the same principles of using subnets for specific services, I would like my EC2 instances to live in private subnets that are also only accessible over a VPN connection. However, one of the limitations of the Client VPN service is:
You cannot associate multiple subnets from the same Availability Zone with a Client VPN endpoint.
This implies that I would need to create a separate endpoint for connecting to my private EC2 subnet—which feels like complete overkill for my modest networking architecture!
Is there a workaround?
By default, a subnet can reach the other subnets.
This means that you won't need to do anything. This will work out of the box. If not, check the route tables and see if there is a route from your VPN subnet to your private subnet.
When you associate the first subnet with the Client VPN endpoint, the following happens:
The state of the Client VPN endpoint changes to available. Clients can now establish a VPN connection, but they cannot access any resources in the VPC until you add the authorization rules.
The local route of the VPC is automatically added to the Client VPN endpoint route table. (This local route allows you to communicate with every subnet within the VPC that the subnet is in.)
The VPC's default security group is automatically applied for the Client VPN endpoint.
See documentation for details.
Question
Can we make a route table which has both igw-id (Internet gateway ID) and vgw-id (VPN gateway ID)? If we can't/shouldn't do it, why?
Example
10.0.0.0/16 --> Local
172.16.0.0/12 --> vgw-id
0.0.0.0/0 --> igw-id
Reference
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario3.html
(I mainly refer to "Overview" section and "Alternate routing" section.)
Explanation
This webpage above shows the scenario where one VPC has one public subnet, one private subnet and one VPN gateway. In this example, the VPN gateway is always accessed from instances in the private subnet (meaning its route table doesn't have the record "igw-id"). I wonder why one route table doesn't have both "igw-id" and "vgw-id".
Yes, we can have both igw and vgw. In fact, the example above would be a perfect for a public subnet which can connect to your corporate network through direct connect or site-to-site VPN, and also have internet access and be accessible from the internet.
Now, weather you would want this or not, it is an architectural decision. In the example scenario given by AWS, they try to segregate subnets by having a public subnet (with the igw) which can contain services accessible from the internet and a private subnet for other backend services (exmaple: databases). These backend services can be accessed from the corporate network using a site-to-site VPN, this is why the subnet has the vgw.
Yes, you can have a route table with the 3 routes you specified. However, bear in mind that with a route 0.0.0.0/0 --> igw-id, hosts on the internet can initiate connections with the instances in that subnet. Typically, you would want to secure the instances in a subnet that you allow a route to your on-premise network, and not expose it to the internet. If these instances require to connect to the internet, AWS recommends NAT devices for your VPC.
While it's technically possible, the main reason not to do that is due to a concept called network segmentation. It basically follows a "defense in depth" approach that network layers should be separated in a "public" and a "private" part (more zones are also often used like third tier for data storage and a fourth for infra used to manage the other three tiers).
Since your public subnet is directly exposed to the internet, it'most likely to be breached when you misconfigure something. If you would have routes in your public subnet to your VPN gateway, a single breach enables an attacker to attack your on-prem environment as well.
This is why its best practice to add one or two network tiers to your architecture. Even when the public tier is compromised, they still need to get into an instance in the private tier before they can attack your on prem environment.
It's recommended that your public subnet only contains an elastic load balancer or similar when possible. Its a pretty good way to reduce the attack surface of your application servers (less chance that you expose an unwanted port etc.).
A nice guide on this can be found here. It doenst include vpns, but you can condisider them part of the app layer.
So I have just setup an application load balancer but I need a static IP to whitelist my database connection, I found Global Accelerator can do the job so I have set it up and assigned it to the ALB. All showing fine in the console but when I ping my domain (www.example.com), I don't see either of the 2 static IP's assigned... and when I whitelist both IP's my application still cannot connect.
Am I doing something wrong?
Edit: My database is Mongo DB hosted on the Atlas Cloud. In my staging environment I have secured the connection to a single server instance using that servers IP address. Now I'm moving to a production environment with a load balancer, I'm not quite sure how I would achieve the same result, since I have multiple EC2 instances which can be created/destroyed via autoscaling. My thinking is that I need to whitelist the load balancer IP address rather than individual instances.
I am assuming that your architecture is:
Domain name pointing to an Application Load Balancer in AWS
Load Balancer points to an Auto Scaling group of Amazon EC2 instances
The EC2 instances point to your MongoDB database hosted on the Atlas Cloud
You want an static IP address so that the database can permit access from the Amazon EC2 instances
While incoming traffic to the EC2 instances goes through the Load Balancer, please note that the connection from an EC2 instance to the database is a separate outbound connection that is established to the database. This traffic does not go through the Load Balancer. The only traffic coming 'out' of a Load Balancer is the response to requests that came 'in'.
The typical way to implement this architecture is:
Load Balancer in public subnets
Auto-Scaled Amazon EC2 instances in private subnets
A NAT Gateway in the public subnet(s)
This way, the instances in the private subnets can access the Internet via the NAT Gateway, yet they are fully isolated from traffic coming in from the Internet. It has the additional benefit that the NAT Gateway has a static IP address. All traffic going through the NAT Gateway to the Internet will 'appear' to be coming from this IP address.
For fault tolerance, it is recommended to put a NAT Gateway in at least two Availability Zones. Each will have its own static IP address.
Oh, and you could consider moving your database to Amazon DocumentDB (with MongoDB Compatibility), which would reduce latency between the application servers and the database.
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.
This has probably been answered elsewhere but I can't seem to find it!
I have a number of AWS EC2 instances that I am using as part of a project being built and I am now looking into securing the setup a bit. I want to lock down access to some of the ports.
For example I want to have one of the instances act as a database server (hosting mysql). I want this to be closed to public access but open to access from my other EC2 instances on their private IP's.
I also use the AWS auto-scaler to add/remove instances as required and need these to be able to access the DB server without having to manually add its IP to a list.
Similarly if possible I want to lock down some instances so that they can only accept traffic from an AWS Load Balancer. So port 80 is open on the instance but only for traffic coming from the Load Balancer.
I've looked at specifying the IP's using CIDR notation but can't seem to get it working. From the look of the private IP's being assigned to my instances the first two octets remain the same and the last two vary. But opening it to all instances with the same first two octets doesn't seem that secure either?!
Thanks
What you want to do is all pretty standard stuff, and is extensively documented in the AWS VPC documentation for Virtual Private Clouds. If your EC2 instances are not running in a VPC, they should be.
The link below should help, it seems to be your scenario:
Scenario 2: VPC with Public and Private Subnets (NAT)
The configuration for this scenario includes a VPC with a public
subnet and private subnet, and a network address translation (NAT)
instance in the public subnet. A NAT instance enables instances in the
private subnet to initiate outbound traffic to the Internet. We
recommend this scenario if you want to run a public-facing web
application, while maintaining back-end servers that aren't publicly
accessible. A common example is a multi-tier website, with the web
servers in a public subnet and the database servers in a private
subnet. You can set up security and routing so that the web servers
can communicate with the database servers.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html