I'll be complying with AWS best practise and having e.g. database instances inside a private subnet but I am wondering why this architecture is recommended?
AWS recommend this architecture so that the DBMS is not accessible to the outside world. If you want to patch it, or some other operation and it needs access to the internet, you should provision a NAT gateway in your public subnet. The DBMS instance in the private subnet can then get access to internet through this NAT gateway.
Could the same be achieved via security groups with the DBMS instance in the public subnet? It's worth noting that AWS charge around 40 USD / month for a NAT gateway.
On the DBMS instance you could have a security group rule which allows all outbound traffic but blocks inbound traffic (which I think is the default rule). This rule could be extended to only allow inbound traffic from a specific web server in the public subnet.
Is the answer that instances inside a public subnet automatically get a public IPv4 address? This would be undesirable for my DBMS instance even though it is effectively fire-walled through my security group rules as outlined above.
Thanks for your help in assisting me to understand AWS networking better.
You are right that this is the reference architecture, and you are indeed the not the first person to raise an eyebrow regarding the cost for the NAT Gateway.
It is true that the separation of public and private networks is an additional security layer that can prevent inadvertent exposure of your critical infrastructure to the public internet, but also to less privileged resources in your VPC.
Keep in mind that not every private subnet needs a NAT gateway; this is only necessary if the machines need to initiate traffic to the internet themselves. You could for example have pre-baked, regularily updated AMIs that don’t need the usual yum update at boot or any other such activities, and you might get away without the NAT Gateway.
Also, best practices doesn’t mean that it’s mandatory. For instance, if you deploy via Cloudformation, do regular security and architectural reviews and are sure to have SGs/NACLs/etc. set up properly, you could place the database in a “public” subnet as well. TL;DR: Use your own judgement to assess the tradeoff between security and cost, one way or the other.
Disclaimer: This is not the official position of AWS but my personal perspective.
Related
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.
From a cost optimization perspective, are there any benefits in deploying web servers in private subnets rather than in public subnets? (behind an Internet-facing ALB)
What would be the pros and cons for the two approaches?
Putting your web-servers in private subnets will probably be more expensive (depends on exactly what the servers do) then putting them in public. The reason is that in private subnet they will not have access to the internet nor any AWS services.
Thus if they require the use of some external API or access to some AWS services you will need to use NAT gateway and/or VPC endpoints which are not free (except endpoints to S3 and DynamoDB).
But keeping everything in a public subnet is a security risk and many prefer to keep the servers in private subnets to follow good practices and be more secure then cheap.
Short answer - No
One case where it will be a bit more expensive:
If you need to access public internet from your server, you will need to pay some money for either NAT gateway, or NAT instance. NAT gateway vs NAT instance.
When to use Public subnet
You are not planning on using any ALB, or autoscaling, and would like to attach Elastic IP directly to your single instance.
You would like to have access to the internet from your ec2, and not pay for NAT
When to use Private subnet
If you are planning to use ALB: You should always have 1 entry point to your application, let it be through publicly faced ALB, and don't risk, by allowing direct public access to your service. For ssh or other direct connection, you can setup bastion host
Any service that should not be accessible from the public internet should be better placed in a private subnet and communicate with other services through a private network, which is faster and cheaper, also, when communicating inside vpc, you can set up good security groups.
I am having trouble understanding this image:
Specifically what I want to have is the Global Accelerator attached to every region, with each region having a VPC and Load Balancer. Then in each AZ in a region, have a public and private subnet. The private subnet or database servers will do all the computation and rendering. The public subnet is the Load Balancer (or does the public subnet need to be a set of instances?).
The public subnet also has an Internet Gateway and NAT Gateway attached. The docs say a private subnet can access the internet using a NAT Gateway in the public subnet, but I don't understand why it doesn't just use the Internet Gateway.
I have a route table in the public subnet, and the private subnet. In the public subnet, the route table goes to 0.0.0.0/0 pointing to the internet gateway. In the private subnet, it goes to 0.0.0.0/0 pointing to the NAT gateway.
There are also an Elastic IP associated with the NAT Gateway, presumably so that's what the internet sees when I make a request from a private server.
My question is, what is connected to what? The docs aren't clear enough on a practical example. I would like to have a public subnet, which I think doesn't require having any instances (am I wrong?), only the load balancer. Then the private subnet is the computation/database subnet which does consist of instances which can only connect to the internet through the load balancer connected to the NAT gateway.
I am confused. I have read the docs over and over again but still don't see how this is supposed to be wired up. Any help explaining what is connected to what in this diagram (extending it to include the Global Accelerator) would be greatly appreciated.
Please don't take this the wrong way, but I don't think you really need everything you are saying that you want.
I would recommend that you start with one region and no Global Accelerator. Implement your system and either creating a test platform that can simulate user traffic, or release your system to your customers and monitor it to determine performance.
If you run in multiple regions, you have a problem with where to keep your data -- data might be kept separate in each region, or replicated. This all depends upon your needs. I suggest you start simple, then expand if you need to operate differently.
Global Accelerator does not make sense when using multiple regions, since it is designed to send traffic to one location. Instead, consider Amazon CloudFront to cache data closer to your customers to provide better performance.
If your application runs on multiple web servers, put a Load Balancer in public subnet(s) and everything else in private subnet(s).
Put simply, start simple. Get your application working in the simplest possible way. Then, if you have greater requirements (eg low latency to users), look at adding Amazon CloudFront. Very few applications span multiple regions, so make that choice carefully and have a specific reason for doing so.
When you use AWS Global Accelerator, you can keep your ALB and instance private, without exposing them to the internet.
Such architecture is explained in the recent AWS blog post:
Accessing private Application Load Balancers and EC2 instances through AWS Global Accelerator
In this architecture, internal ALB is used, and there are no public subnets. The only requirements is the pretense of internet gateway in the VPC. It should be noted, that even though there is internet gateway, no routes are configured for the subnets to access the internet:
To avoid internet traffic from inadvertently flowing into a private subnet, we require that an internet gateway is attached to the VPC that contains resources when a client address-preserving accelerator is created.
I came in late but:
One rule is "if it can stay in private subnet then keep it in private subnet". Accessing the internet will always be costlier. When that is done if you must reach the internet then use VPC endpoints (if possible) instead of NATG and IGW. Endpoints are cheaper and make cheaper data transfers.
For Accelerator and Cloudfront, if data cacheing will be a pain for you then use Accelerator, if not, simply put, CloudFront is cheaper and better.
Despite all this, your architecture and use case will always decide your best and cheapest set up.
So the purpose of private subnets in AWS is for its instances to not be directly accessible from the outside world. There are however cases (successfully resisted the 'instances' pun) in which it's useful for the instances to have access to the internet. One such use-case may be to download software updates for example.
The "standard" way to achieve this would be with a NAT gateway and a rule in the routing table pointing all outbound traffic to it (0.0.0.0/0 -> nat-gw).
The thing that puzzles me is this:
Can't we just use a public subnet with a properly configured security group (SG) that denies inbound traffic and allows specific outbound traffic? Since SGs are stateful, they should allow the response to the outbound traffic to go through, just as a NAT gateway would.
I assume I'm just missing something, or that the above configuration is limited in some way that I'm just not seeing. However I can't find an answer to this.
Compliance is one of the primary reasons one may choose to have
private subnets. A lot of companies, especially financial institutions, have strict compliance requirements where there cannot
not be any public access
to the servers. When you create a public subnet, there is a
possibility of assigning a public IP address, which can make any
instance accessible from internet, (again as long as the security
group allows it).
Security Groups are a firewall provided at a logical level by AWS.
Creating a private subnet, ensures that even if an instance belongs
to a Security Group, that allows access to certain ports and
protocols, the server still won't be accessible publicly.
Another reason, you may choose for private subnets is to architect
your infrastructure in a way that all public servers are always in
the DMZ. Only DMZ has access to the internet. Every thing else is in
a private subnet. In the event something goes wrong, access to the
DMZ can be closed and further damage could be prevented.
The simple answer is... you're right!
You can certainly launch everything in a Public Subnet and use Security Groups to control traffic between the instances and to restrict inbound access from the Internet.
People use public & private subnets because this is the way that networks were traditionally designed, when firewalls only existed between subnets. Security Groups are an additional layer of security that works at the Elastic Network Interface, but that's a bit scary and new for many networking professionals (including people who design compliance requirements).
I am trying to evaluate private and public subnets while creating a new VPC.
Is seclusion from inbound traffic from internet the only reason to go ahead with a private subnet? These points also need to be taken into account when considering the private subnet.
NAT Gateway is chargeable - 0.045$/hour and 0.045$ for per GB of data transferred. So there is cost consideration. I would need NAT gateway for pulling code or updates from internet.
I should be able to secure instances in my public subnets by using security groups with different levels of strictness.
When launching an instance I would assign a public ip to only those instances which I want to access from outside the VPC.
I went through this question but it didn't solve my doubts with respect to above points. Any help is appreciated.
From 7 Security Measures to Protect Your Servers:
Isolated Execution Environments
How Do They Enhance Security?
Isolating your processes into individual execution environments
increases your ability to isolate any security problems that may
arise. Similar to how bulkheads and compartments can help contain hull
breaches in ships, separating your individual components can limit the
access that an intruder has to other pieces of your infrastructure.
So, IMHO, do you need private subnets? Depends. In a production environment with public and private services, VPN, databases, etc., yes; but if you have only one server, and you don't want to deal with the configuration of network ACLs, routing, NAT, and so on, maybe a public subnet with your server and a well configured security group could be enough.
To answer your questions:
Use NAT instance (t2.small or m3.medium) instead of NAT gateway. Far cheaper.
Why launch them in public subnet and then tweak the security group if there is no need to accept the incoming internet traffic. There is always a chance to make a mistake in SG rules and allow malicious traffic unintentionally. Even if you want to accept internet traffic, I suggest using a reverse proxy like haproxy
Then launch only those instances in public subnet or use a reverse proxy
The private subnet is an extremely useful feature to protect your instances from DDoS, unauthorized access etc., Do not bypass it for the sake of convenience.