有4情景AWS VPC配置。但是，让我们看看这两个：

There are 4 scenarios in AWS VPC configure. But let's look at these two:

方案1有1个公用子网。

Scenario 1 has 1 public subnet.

方案2有1个公共子网和1个私人子网。

Scenario 2 has 1 public subnet and 1 private subnet.

由于公共子网推出可能没有EIP（除非它是分配的）任何情况下，并不意味着它已经不是从互联网寻址？那么，为什么会出现需要专用子网？

Since any instance launched in public subnet might not have EIP (unless it's assigned), doesn't it mean that it is already not addressable from the Internet? Then why is there a need for private subnet?

长短期问题，究竟是私人和公共子网之间的区别是什么？

Long question short, what exactly are the differences between private and public subnets?

推荐答案

要理解之间的区别私，并在亚马逊VPC公共子网需要一般的IP路由和网络地址转换（NAT）如何工作的理解，以及它是如何，他们是专门在VPC实现的。

To understand the distinction between "private" and "public" subnets in Amazon VPC requires an understanding of how IP routing and network address translation (NAT) work in general, and how it they are specifically implemented in VPC.

在VPC公共和私人子网之间的本质差异是由什么该子网的默认路由是定义在VPC的路由表。。

这个配置，进而，指示使用，或者不使用，公共IP地址上的特定子网实例的有效性。

This configuration, in turn, dictates the validity of using, or not using, public IP addresses on instances on that particular subnet.

每个子网都只有一个默认路由，它可以是两件事情只有一个：

Each subnet has exactly one default route, which can be only one of two things:

Internet网关没有做任何网络地址转换，这样的实例，不需要一个公网IP地址无法连接的向外的互联网 - 做事如下载软件更新，或访问其他AWS资源像S3和SQS - 如果它的VPC子网的默认路由是互联网网关对象。所以，如果你是一个公子网中的实例，那么你的需要的为了做一个显著许多事情的服务器通常需要做一个公网IP地址。

The Internet Gateway does not do any network address translation, so an instance without a public IP address cannot connect outward to the Internet -- to do things like downloading software updates, or accessing other AWS resources like S3 and SQS -- if the default route on its VPC subnet is the Internet Gateway object. So, if you are an instance on a "public" subnet, then you need a public IP address in order to do a significant number of things that servers commonly need to do.

对于只有一个私有IP地址的情况下，还有的出站访问互联网的替代方法。这就是网络地址转换和NAT实例进来了。

For instances with only a private IP address, there's an alternate way of outbound access to the Internet. This is where Network Address Translation and a NAT instance come in.

在一个私人子网的计算机可以访问Internet，因为在一个私人子网中的缺省路由的没有的VPC的Internet网关的对象 - 这是一个配置为NAT实例的EC2实例。

The machines on a private subnet can access the Internet because the default route on a private subnet is not the VPC "Internet Gateway" object -- it is an EC2 instance configured as a NAT instance.

一个NAT实例是一个公共子网有公网IP，和具体的配置实例。还有的AMI是pre建要做到这一点，或者你可以建立自己的。

A NAT instance is an instance on a public subnet with a public IP, and specific configuration. There are AMIs that are pre-built to do this, or your can build your own.

在私有地址的机器发送流量向外，交通被发送，由VPC，到NAT实例，它取代了数据包的源IP地址（专用设备的私有IP地址）与自己的公网IP​​地址，将流量发送到互联网，接受响应数据包，将它们转发回源机器的私有地址。 （这也可能重写源端口，并且在任何情况下，它会记住的映射，所以它知道哪些内部计算机应接收响应数据包）。通过NAT实例不允许任何意外入站流量达到私人情况下，除非它被专门配置为这样做。

When the private-addressed machines send traffic outward, the traffic is sent, by VPC, to the NAT instance, which replaces the source IP address on the packet (the private machine's private IP address) with its own public IP address, sends the traffic out to the Internet, accepts the response packets, and forwards them back to the private address of the originating machine. (It may also rewrite the source port, and in any case, it remembers the mappings so it knows which internal machine should receive the response packets). A NAT instance does not allow any "unexpected" inbound traffic to reach the private instances, unless it's been specifically configured to do so.

因此​​，从专用子网访问外部网络资源时，该流量通过NAT的实例，并似乎已起源于NAT实例的公网IP​​地址的目的......所以响应通信回来了NAT实例。无论是分配到NAT实例，也没有分配给私有实例安全组的安全组需要配置允许这个响应流量，因为安全组是有状态的。他们意识到响应流量相关的会话内部发起，因此被自动允许。突发流量是，当然，否认除非安全组被配置为允许它

Thus, when accessing external Internet resource from a private subnet, the traffic traverses the NAT instance, and appears to the destination to have originated from the public IP address of the NAT instance... so the response traffic comes back to the NAT instance. Neither the security group assigned to the NAT instance nor the security group assigned to the private instance need to be configured to "allow" this response traffic, because security groups are stateful. They realize the response traffic is correlated to sessions originated internally, so it is automatically allowed. Unexpected traffic is, of course, denied unless the security group is configured to permit it.

与传统的IP路由，你的默认网关是在你的同一个子网中，它工作在VPC的方式是不同的：对于任何给定的私人子网中的NAT实例总是不同的子网，并且其他子网始终是一个公开子网，因为NAT实例需要有一个公共的外部IP，和它的默认网关是VPC因特网网关对象。

Unlike conventional IP routing, where your default gateway is on your same subnet, the way it works in VPC is different: the NAT instance for any given private subnet is always on a different subnet, and that other subnet is always a public subnet, because the NAT instance needs to have a public external IP, and its default gateway has to be the VPC "Internet Gateway" object.

同样...你不能与专用子网公网IP部署的一个实例。它不工作，因为在一个私人子网的默认路由（定义）一个NAT实例（执行NAT上的通信），而不是互联网网关对象（不）。来自Internet的入站流量将达到实例的公网IP​​，但答复将尽力航线向外通过NAT实例，要么丢弃信息流（因为它会答复的组成，连接它不知道，所以他们倒是被视为无效）或将改写答复通信使用自己的公网IP​​地址，这是行不通的，因为外来不会接受的答复是来自比另外一个IP地址，他们试图以启动通信

Similarly... you cannot deploy an instance with a public IP on a private subnet. It doesn't work, because the default route on a private subnet is (by definition) a NAT instance (which performs NAT on the traffic), and not the Internet Gateway object (which doesn't). Inbound traffic from the Internet would hit the public IP of the instance, but the replies would try to route outward through the NAT instance, which would either drop the traffic (since it would be composed of replies to connections it's not aware of, so they'd be deemed invalid) or would rewrite the reply traffic to use its own public IP address, which wouldn't work since the external origin would not accept replies that came from an IP address other than the one they were trying to initiate communications with.

在本质上，那么，私与公名称是不是真正的从互联网访问或交通不便。它们是有关种地址将被分配给该子网上，这是因为需要翻译相关实例 - 或避免平移 - 这些IP地址为因特网的相互作用。

In essence, then, the "private" and "public" designations are not really about accessibility or inaccessibility from the Internet. They are about the kinds of addresses that will be assigned to the instances on that subnet, which is relevant because of the need to translate -- or avoid translating -- those IP addresses for Internet interactions.

由于VPC有来自全国VPC子网的所有其他VPC子网隐路，默认路由并不能起到内部VPC流量的作用。实例具有私有IP地址将连接到，从自己的私有IP地址，而不是从自己的公共IP地址（如果有的话）在VPC其他私有IP地址...只要目的地址是另一个私有地址内VPC。

Since VPC has implicit routes from all VPC subnets to all other VPC subnets, the default route does not play a role in internal VPC traffic. Instances with private IP addresses will connect to other private IP addresses in the VPC "from" their private IP address, not "from" their public IP address (if they have one)... as long as the destination address is another private address within the VPC.

如果具有私有IP地址的情况下从来没有在任何情况下，需要发起出站互联网流量，那么他们在技术上可以部署在公共的子网，仍然还是无法访问从互联网上......但在这样的的结构，这是不可能的他们发起朝向因特网，它包括连接与其他AWS基础设施服务，再次，像S3或SQS输出流量。

If your instances with private IP addresses never, under any circumstances, need to originate outbound Internet traffic, then they technically could be deployed on a "public" subnet and would still still be inaccessible from the Internet... but under such a configuration, it is impossible for them to originate outbound traffic towards the Internet, which includes connections with other AWS infrastructure services, again, like S3 or SQS.