我想提到一些ISP引起的罕见问题。我偶尔也会用BSNL。这是一个奇怪的问题，它占用了你日常生活中的几个小时。在这种情况下，人们可能会提出与ISP或更换ISP的问题。

Amazon实例可以从浏览器访问(所有开放端口) 控制台无法ping通 SSH / Telnet也不能正常使用。

当ping两个系统时，默认启用SSH(如果您通过putty或终端连接)。为了允许ping，我为每个实例(入站)添加了安全组。

您必须编辑EC2实例所属的Security Group并允许访问(或者创建一个新的Security Group并将该实例添加到其中)。

默认情况下，一切都被拒绝。您需要添加到安全组的例外取决于您需要向internet提供的服务。

如果它是一个web服务器，你需要允许访问端口80为0.0.0.0/0(这意味着任何IP地址)。

要允许ping实例，您需要启用ICMP通信。

AWS Web控制台在相关下拉列表中提供了一些最常用的选项。

那些刚接触aws ec2并希望从SSH、browser、Ping从系统访问实例的人，那么下面是这些的入站规则

安全组中的自定义ICMP规则不是它所需要的，至少对我来说是这样。 但下面的规则是可行的:

Type: All ICMP 
Protocol: TCP
Port range: 0 - 65535
Source: Anywhere - 0.0.0.0/0

完成此操作后，您将能够ping其他实例。你会看到如下内容:

PING 10.0.0.15 (10.0.0.15): 56 data bytes
64 bytes from 10.0.0.14: icmp_seq=1 ttl=64 time=3.9 ms
64 bytes from 10.0.0.14: icmp_seq=2 ttl=64 time=3.9 ms
64 bytes from 10.0.0.14: icmp_seq=3 ttl=64 time=10.6 ms
64 bytes from 10.0.0.14: icmp_seq=4 ttl=64 time=40.6 ms
64 bytes from 10.0.0.14: icmp_seq=5 ttl=64 time=3.8 ms
64 bytes from 10.0.0.14: icmp_seq=6 ttl=64 time=5.3 ms
64 bytes from 10.0.0.14: icmp_seq=7 ttl=64 time=6.5 ms
64 bytes from 10.0.0.14: icmp_seq=8 ttl=64 time=3.5 ms
64 bytes from 10.0.0.14: icmp_seq=9 ttl=64 time=21.0 ms
64 bytes from 10.0.0.14: icmp_seq=10 ttl=64 time=3.5 ms
64 bytes from 10.0.0.14: icmp_seq=11 ttl=64 time=3.5 ms
64 bytes from 10.0.0.14: icmp_seq=12 ttl=64 time=59.7 ms
64 bytes from 10.0.0.14: icmp_seq=13 ttl=64 time=3.5 ms
64 bytes from 10.0.0.14: icmp_seq=14 ttl=64 time=3.5 ms
64 bytes from 10.0.0.14: icmp_seq=15 ttl=64 time=4.8 ms
64 bytes from 10.0.0.14: icmp_seq=16 ttl=64 time=3.1 ms
64 bytes from 10.0.0.14: icmp_seq=17 ttl=64 time=3.1 ms
64 bytes from 10.0.0.14: icmp_seq=18 ttl=64 time=3.0 ms
64 bytes from 10.0.0.14: icmp_seq=19 ttl=64 time=3.1 ms

--- 10.0.0.14 ping statistics ---
20 packets transmitted, 19 packets received, 5% packet loss
round-trip min/avg/max = 3.0/9.9/59.7 ms

´s。

我有一个更深层次的问题——我已经创建了VPC、子网和适当的安全组，但忽略了添加Internet网关并将其与子网关联。因为这是我的第一个谷歌结果“不能ping ec2”，我把这个信息贴在这里，以防它被证明对别人有用(或将来我自己)。