In AWS, why is an EC2 behind NAT gateway in private zone said to be safer than one in public subnet?
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.)
amazon-web-services nat domain-controller windows-server-2016
New contributor
add a comment |
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.)
amazon-web-services nat domain-controller windows-server-2016
New contributor
3
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago
add a comment |
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.)
amazon-web-services nat domain-controller windows-server-2016
New contributor
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.)
amazon-web-services nat domain-controller windows-server-2016
amazon-web-services nat domain-controller windows-server-2016
New contributor
New contributor
edited 8 hours ago
Festus Martingale
New contributor
asked 9 hours ago
Festus MartingaleFestus Martingale
1185
1185
New contributor
New contributor
3
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago
add a comment |
3
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago
3
3
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago
add a comment |
3 Answers
3
active
oldest
votes
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 :)
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
add a comment |
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.
add a comment |
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.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Festus Martingale is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f951031%2fin-aws-why-is-an-ec2-behind-nat-gateway-in-private-zone-said-to-be-safer-than-o%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 :)
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
add a comment |
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 :)
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
add a comment |
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 :)
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 :)
answered 5 hours ago
MLuMLu
7,40712040
7,40712040
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
add a comment |
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is not open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even sees the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule?
– Festus Martingale
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
@FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it.
– MLu
4 hours ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced the docs say the NACLs can be hosted at the network edge for increased performance rather than the instance.
– Tim
48 mins ago
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 3 hours ago
John MahowaldJohn Mahowald
6,9531713
6,9531713
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 2 hours ago
JoeJoe
36416
36416
add a comment |
add a comment |
Festus Martingale is a new contributor. Be nice, and check out our Code of Conduct.
Festus Martingale is a new contributor. Be nice, and check out our Code of Conduct.
Festus Martingale is a new contributor. Be nice, and check out our Code of Conduct.
Festus Martingale is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f951031%2fin-aws-why-is-an-ec2-behind-nat-gateway-in-private-zone-said-to-be-safer-than-o%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet.
– ceejayoz
9 hours ago