Vryjdfkk

I've been running four servers on AWS for a few years. It's for a hobby project. All servers live in the same subnet in the same VPC.

To simplify the management of accounts and permissions, I've decided to use Active Directory. This means installing domain controller(s). Documentation indicates that to use AWS domain controller services, the domain controllers must be in a private subnet of the VPC. Continuing my research into private subnets, a term unfamiliar to me, I learned that EC2s in the private subnet must be behind a NAT gateway -- or at least that's a strong recommendation.

The recommendation to put domain controllers in a private subnet behind a NAT gateway is apparently based on the security benefits provided. This leads to my question: What exactly are those security benefits?

Here's why I ask...

My existing four servers each have a private IP and a routable ("elastic") IP but the firewall prevents anyone from connecting on the latter, unless I create a security rule that allows it. Why would this be any different for domain controllers? I understand that DCs will only be used by servers on my network, and never by random outside parties on the Internet, but wouldn't that simply be the default state of affairs unless I create an inbound security rule to the contrary? What's the point of segregating these DCs on an isolated subnet with their own NAT gateway? It seems to be adding complexity with no real upside. Well, presumably there is an upside and I just don't know what it is, thus my question.

(I'm a hobbyest, not a professional, so if you feel that this question is more suitable for SuperUser, I'll delete and repost there. I just figured since it was server-related this site might be more appropriate.)

If an instance has a Public / Elastic IP I can directly target it with an attack. Maybe you left some unneeded ports open in the Security Group that I can exploit.

If it doesn’t have a Public / Elastic IP it’s close to invisible to the Internet and I can’t directly target it from outside.

Think of a house - if it’s got door directly on the street your house security depends on the door lock. However if it’s in a section behind a solid wall it’s much harder to even get to the door and try to break the lock. Even if you by mistake leave the door unlocked you should still be pretty secure.

So yes, if everything works as expected then the security of public and private subnets should be similar. But mistakes happen and having your resources in Private subnet gives you an extra layer of protection in such times.

Hope that helps :)

In addition to the network considerations, think about service isolation. AD DS + DNS + File Server ideally are the only roles on domain controller hosts. Probably don't want a public web server on the same box as the credentials to your network.

You can make the directory someone else's problem by using a hosted directory service. At the cost of less flexibility and learning opportunity.

Secure networks are possible with a private or public IP. The difference is personal preference of how obvious you want to make the isolation.

Let's look at "private subnet" and "behind a NAT gateway" independently.

Separating an admin subnet from a public facing network subnet makes the boundary between the security zones obvious. At a glance, an IP is either internal or external. You can add AWS network ACLs or a third party firewall between them. (On top of security groups which are associated to instances, not subnets.)

NAT gateway doesn't really add security. Incoming connections are not allowed, but that's also doable with security groups.

NAT does conserve IPv4 addresses. Or, IPv6 with a egress-only Internet gateway uses zero IPv4 addresses.

It's not more secure assuming the firewall rules were created correctly and you only have one server. The reason why you would want a private IP range is because it allows communication between multiple servers to happen securely. Take for example a web server and domain controller. You would want the web server to be able to securely communicate with the domain controller over a private network and you would also want to allow outside access to port 80/443. To accomplish this, would simply port forward port 80 and 443 directly to the www server. This configuration would protect the domain controller traffic by not exposing it to the public network.