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

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

检查你的安全组

2-check Internet网关

3-检查路由表

默认情况下，EC2由AWS安全组(EC2和VPC中的服务)保护。缺省情况下，安全组不允许任何包含ping的ICMP请求。允许:

Goto: AWS EC2实例 定位:绑定到该实例的安全组(可以有多个安全组) 检查:协议(ICMP)端口入站规则(0 - 65535)如果不存在，您可以添加它，并允许它在指定的源IP或另一个安全组上使用。

安全组使您能够控制到实例的流量，包括可以到达实例的流量类型。

1. Check the Security Groups (Enabled the PORTS to be OPEN)
2. Check the correct VPC 
3. Attached the correct Subnet 
4. AWS EC2 to be in Public Subnet 
5. Enable Internet Gateway 

打开AWS EC2中的端口，检查此链接正式的AWS链接

安全组中的自定义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中打开，可能是您的内部网络正在阻止该IP到ping或在您的防火墙中阻止ping包。