Fix AWS EC2 Cannot Ping Instance: ICMP & Security Group Rules

To ping an EC2 instance, add one inbound rule to its security group: type Custom ICMP - IPv4, protocol Echo Request, source your own public IP address. That fixes it for most people. Here's what surprises them: ping has no port. You can open every TCP port on the instance, SSH and web traffic included, and ping still fails, because it travels on a different protocol called ICMP. If the rule is already there and ping still hangs, look at the network ACL, the public IP and route, and the operating system's firewall, in that order.

Jake runs a small phone shop, and a few Saturdays ago he shut down his repair-ticket screen for an hour and a half because a ping told him the server was dead. It wasn't. His nephew had rented a small EC2 instance (a virtual computer that Amazon Web Services lets you rent by the hour) to run the shop's stock and repair tracker, and the only rule on its firewall let people in on the web port. The server was healthy the whole time. Ping just had no rule to knock on. Ninety minutes of turned-away walk-ins is a steep price for one missing rule.

Let's define the word before we fix it. Ping is a tiny "are you there?" message. Technically it's an ICMP Echo Request, where ICMP (Internet Control Message Protocol) is the protocol networks use for small status notes rather than real data. The instance answers with an Echo Reply, if the network lets both messages through. Between you and the instance sit four gatekeepers: the security group, the network ACL, the route to the internet, and the operating system's own firewall. This post walks them in that order, then covers the odd cases, the cleanup, and the sixteen questions people ask next.

The one-rule fix: allow ICMP Echo Request in the security group

A security group is a virtual firewall attached to an instance's network interface, which is its virtual network card (AWS calls it an elastic network interface). It decides what traffic may reach the instance. Two facts from AWS's documentation explain a huge share of failed pings. A brand-new security group starts with no inbound rules, so nothing gets in until you add something. And a security group only holds allow rules. You can't write a deny rule in one.

So the cure is an allow rule for the ping message itself. Here's the console route.

1. Open the Amazon EC2 console, choose Instances, and select your instance.
2. Choose Actions, Security, Change security groups. Note the name or ID of every group under Associated security groups, then close the dialog without saving. You need to edit a group that's actually attached, and instances often carry more than one.
3. In the navigation pane, choose Security Groups and select that group.
4. Choose Edit inbound rules (from Actions, or from the Inbound rules tab), then Add rule.
5. For Type, choose Custom ICMP - IPv4. For Protocol, choose Echo Request. There's no port to type, because for ICMP rules the console reuses those fields to hold the message type and code.
6. For Source, choose My IP, which fills in the public IPv4 address of the computer you're using. Or choose Custom and enter a CIDR block, which is a range of addresses written like 203.0.113.0/24.
7. Optionally add a description so the next person knows why the rule exists, then choose Save rules and ping the instance's public IPv4 address again.

Prefer the command line? The AWS CLI (Command Line Interface, AWS's text-based tool) version for one address is:

aws ec2 authorize-security-group-ingress --group-id sg-1234567890abcdef0 --ip-permissions 'IpProtocol=icmp,FromPort=8,ToPort=-1,IpRanges=[{CidrIp=203.0.113.25/32}]'

Swap in your own group ID and address. In an ICMP rule, FromPort carries the message type (8 is Echo Request) and ToPort carries the code, where -1 means all codes. The /32 on the end means exactly one address, which is the format AWS requires for a single IPv4 address.

You don't need an outbound rule for the reply. Security groups are stateful, meaning they remember incoming requests and let the matching reply leave regardless of the outbound rules. Plenty of guides tell you to add an Echo Reply rule on the way out. For the instance you're pinging, that's unnecessary.

Jake's first instinct was to pick All ICMP and move on. "Sounds simpler," he said.

Ethan shook his head. "Simpler for about a minute. Echo Request from your own address is the smallest rule that does the job, and small rules are the ones you won't regret next spring."

Why SSH works but ping doesn't: ICMP isn't TCP

In a security group rule, the protocol is the kind of conversation you're allowing. The common ones are TCP (protocol number 6), UDP (17) and ICMP (1). For TCP and UDP you also pick a port, which works like an extension number on an office phone system. ICMP has no ports at all. It's closer to a note slipped under the door asking whether anyone's home.

That's why a rule for port 22, port 80, or even "All TCP" does nothing for ping. Those rules are about TCP. The ICMP rule is a separate line, and it's identified by a message type instead of a port: type 8 for an IPv4 Echo Request, type 128 for an IPv6 Echo Request.

The list of ICMP types in the console also includes Echo Reply, the answer the instance sends back. Choosing that one for your inbound rule is a classic slip. The rule then matches replies, not the requests actually arriving, and ping keeps timing out.

Ethan puts it in shop terms. "Ping is the doorbell. SSH is the key. You can hold the key and still have no doorbell wired up." Nothing is wrong with the instance. The doorbell simply hasn't been connected.

The journey of one ping: four gatekeepers, in order

It helps to picture a single Echo Request traveling from your laptop to the instance and back. It passes four gatekeepers on the way in, and the reply has to get past most of them again on the way out. Once you see the order, the troubleshooting order writes itself.

AWS's own guidance for "Connection timed out" errors lists the same four suspects: the security group, the network ACL, the route to the internet, and the operating system's firewall. The table is the same list with the differences that matter for ping spelled out.

Two things in that table decide most cases. First, the security group is stateful and the network ACL isn't, so a network ACL needs a rule for the reply and the security group doesn't. Second, the security group only allows. If something is denying your ping, it isn't the security group, because a security group can't deny. That single fact saves a lot of staring at the wrong screen.

Jake wanted to know which gatekeeper to blame first. "Start at the one you can change in ten seconds," Ethan said. "That's the security group. If it's not that, work outward."

Quick checks before you touch a single rule

Ethan's habit is to check the boring things first. "Boring things are guilty far more often than clever ones," he says. Like a router that only misbehaves on Sunday nights, an instance can look sick for reasons that have nothing to do with the instance.

Is the instance actually running and healthy?

In the EC2 console, look at the instance's state and its status checks. AWS's own guidance for connection timeouts starts with making sure the instance passes its status checks. A stopped or impaired instance won't answer anything, and no rule change can fix that.

Are you pinging an address that can be reached from where you are?

Every instance has a private IPv4 address, which AWS describes as an address that isn't reachable over the internet. Only instances with a public IPv4 address (or an Elastic IP address, which we'll meet shortly) can be reached from outside. The console shows both on the instance's details.

Here's a small trap. The public address isn't configured inside the instance at all. AWS maps it to the private address using NAT (network address translation, a bit like a PO box that forwards mail to your real home address). That's why ipconfig on Windows or ifconfig on Linux shows only the private one. Read the public address from the console, not from inside the machine.

Also, instances launched into a non-default subnet don't get a public address unless the subnet or the launch settings say so. If yours has none, ping from the internet can't work, whatever your rules say.

Which of these is happening to you? A symptom-by-symptom table

The usual symptom is a ping that hangs, or Windows printing "Request timed out" line after line. From the outside, every cause looks identical. This table sorts them by the extra clues you already have, so you can jump to the right layer instead of reading everything.

The first flow-log row comes straight from a worked example in AWS's VPC documentation, and the single-REJECT row follows the same document's security group example. We unpack both in the section on finding the blocker. If none of the rows fits, that's a clue too: it usually means two layers are misbehaving at once, and fixing one just reveals the next.

Security group traps that survive the fix

Jake added the rule, pinged, and got silence. He started drawing a ten-box flowchart on the back of a receipt. "You're overcomplicating it," Ethan said. "Nine times in ten the rule is there, and it's the rule's edges that bite. Read them slowly."

Your My IP rule points at an address you no longer use

My IP fills in the public IPv4 address of the computer you're using at that moment, as one address. Move to a phone hotspot, switch on a VPN, or go home after working from the office, and the address the internet sees changes. The rule still exists, but it no longer describes you. If ping works from one place and not another, compare the rule's source with the public address of the network you're on today.

You edited a group that isn't the one attached

Security groups attach to network interfaces, and an instance can have more than one group. When several are attached, AWS combines all their rules into one set. So a rule in any attached group counts, and a rule in a group that isn't attached counts for nothing. If two groups have similar names, it's easy to fix the wrong one. That's why the steps at the top begin by listing the associated groups.

The source is another security group, but you pinged the public address

A rule can name another security group as its source instead of an address, which is handy inside a VPC. But AWS's CLI reference notes that traffic is then allowed based on the private IP addresses of the instances in that source group, not their public or Elastic IP addresses. So if instance A's group is the source in instance B's rule, ping B's private address from A. Pinging B's public address won't match.

One related note from AWS: if you route traffic between instances in different subnets through a middlebox appliance (a device in the path that forwards or inspects traffic), a security-group source doesn't let that traffic through. Use each instance's private IP address, or the subnet's CIDR range, as the source instead.

The instance sending the ping has locked-down outbound rules

A new security group comes with one outbound rule that allows everything. If someone deleted it and added narrow outbound rules, the instance sending your ping needs an outbound rule that lets ICMP leave. The instance receiving the ping doesn't need one for its reply, because of the stateful behavior above.

You removed a rule and ping kept working, or the new rule hasn't kicked in

Security groups use connection tracking, which means they keep a short memory of conversations so replies can be recognized. AWS's documentation says ICMP traffic is always tracked. When you change a rule, tracked connections aren't cut immediately; the group keeps allowing packets until the tracked connection times out. AWS points to network ACLs if you need traffic interrupted at once. Rule changes are also described as propagating as quickly as possible, with a small delay possible. So give a change a moment before you call it a failure, and don't be shocked if a ping session already in progress keeps getting answers a little longer than expected.

Ping only fails sometimes on a busy instance

Every instance can track only so many connections at once. AWS says that once the maximum is reached, packets sent or received are dropped because a new connection can't be established. Two network performance metrics report on this: conntrack_allowance_available shows how many tracked connections you still have room for, and conntrack_allowance_exceeded shows whether packets were dropped because the limit was hit. If a busy web server drops the occasional ping while quiet ones never do, watch those two numbers before you blame a rule.

The popular advice that's wrong. Somewhere in a forum, someone says "just allow All traffic from 0.0.0.0/0." That works because it's a far bigger hole than the one you needed, and you'll have to remember to close it. Add the ping rule and leave the rest alone.

Network ACLs: the stateless firewall that eats echo replies

A network ACL (short for network access control list, or NACL) is a second firewall. It guards a whole subnet, which is a slice of your VPC (virtual private cloud, your own private network inside AWS), instead of a single instance. Each subnet is tied to exactly one network ACL. Here's what AWS's documentation says that matters for ping:

• The default network ACL for a VPC allows all inbound and outbound traffic. If nobody ever touched yours, it's probably not the problem.
• A custom network ACL ends with a rule numbered * that denies any packet not matched by a numbered rule above it.
• Rules are numbered 1 to 32766, checked from the lowest number up, and the first match wins, even if a higher-numbered rule says otherwise.
• Network ACLs are stateless. Allow a ping in, and the reply is not automatically allowed out. You need a rule for each direction.
• IPv4 and IPv6 rules are evaluated separately, so an IPv4 rule does nothing for IPv6 pings.
• When you choose ICMP as the protocol, you can allow any or all ICMP types and codes.

AWS's flow-log documentation describes this exact trap. The security group allows inbound ICMP, the network ACL allows it in but not out, and the reply gets dropped. The flow log shows an ACCEPT record for the request and a REJECT record for the reply.

Here's how to look at the network ACL for your instance.

1. In the EC2 console, choose Instances, select your instance, and open the Networking tab.
2. Select the network interface, then choose its network interface ID.
3. On the Details tab, choose the associated subnet ID.
4. On the Network ACL tab, read the inbound rules. Is there an allow rule for ICMP from your address, with a lower number than any deny rule that also matches?
5. Read the outbound rules. Is there a rule allowing ICMP back to your address?
6. If you ping over IPv6, look for the matching IPv6 entries as well.

The simplest correct pair is one inbound rule allowing ICMP (all types and codes) from your address range and one outbound rule allowing ICMP to the same range. If you insist on being precise, that's Echo Request (type 8) in and Echo Reply (type 0) out. Here's an illustration of a pair that works, using a documentation-style example address:

A subtle version of this trap: the network ACL was built carefully for TCP. It allows SSH in and opens the ephemeral ports going out. Those are the high-numbered temporary ports a client picks for its side of a TCP conversation, and AWS lists ranges such as 1024-65535 for many clients. It all looks right, and SSH works. But none of it helps ICMP, which has no ports at all. So "SSH works, so the network ACL is fine" isn't a valid conclusion for ping.

Public IP, route table, internet gateway: is there even a road?

Firewalls decide who may pass. Routing decides whether there's a road at all. If ping fails from the internet, and the same rules work from inside the VPC, the road is a prime suspect.

The public address itself

Per AWS, an instance in a default VPC gets a public IPv4 address by default, while a non-default subnet has an attribute that decides. An instance in a public subnet without a public IP address isn't reachable from outside its VPC.

The address is also not permanent. AWS releases the automatically assigned public address when the instance is stopped, hibernated or terminated, and assigns a new one on start. It's like a hotel room number: you get one each stay, and you can't assume it's the same as last time. If you ping the old address after a restart, you're knocking on someone else's door. Read the new one from the console.

When you need an address that stays put, use an Elastic IP address, a static public IPv4 address that belongs to your account until you release it. Associating one releases the auto-assigned public address; disassociating it assigns a new auto-assigned one. AWS charges for all public IPv4 addresses, including those on running instances and Elastic IPs, so check the current pricing page before you allocate more than you need.

The route to the internet gateway

A route table is the list of directions for a subnet's traffic. An internet gateway is the door between your VPC and the internet. For a public subnet, the route table needs a route that sends 0.0.0.0/0 (meaning everything not covered elsewhere) to an internet gateway, and that gateway must still exist. AWS's troubleshooting notes call out that someone may have deleted it.

To look: on the instance's Networking tab, select the network interface, then its subnet ID, then open the Route Table tab and check for the default route to an internet gateway.

Instances with more than one network interface

Security groups belong to network interfaces, and AWS says each IP address on an interface is subject to that interface's security groups. So a second network interface can carry a different set of groups than the first, and pinging an address on it follows that interface's rules. AWS also notes an odd case: if an instance has a secondary network interface, it doesn't get a new auto-assigned public IP address after the old one is released. If your instance has extra interfaces and lost its public address after a stop and start, that's a likely reason, and an Elastic IP address is the fix.

Instances that are meant to be private

If the instance sits in a private subnet with no public address, you can't ping it from the internet, and that's by design. From inside the VPC you can ping its private address once the security group allows it. For managing such an instance without a public address, AWS mentions EC2 Instance Connect Endpoint, which lets you connect from the internet without the instance holding a public IPv4 address.

Inside a Linux instance: the kernel setting and the host firewall

Sometimes AWS is wide open and the instance is still deaf. First you need a way in that doesn't depend on ping. SSH is fine if your TCP rule works. If you're locked out, AWS's connection-troubleshooting guidance points to two routes. Session Manager is a feature of AWS Systems Manager that opens a shell for you through an agent on the instance. The instance must be a managed node, its SSM Agent must show Online, and its IAM role (a permission badge attached to the instance) needs the AmazonSSMManagedInstanceCore permissions. The EC2 Serial Console is the other, and AWS says it can help with operating-system and network-configuration problems.

The kernel setting. Linux has a switch that tells the kernel to ignore ping requests entirely. The kernel documentation calls it icmp_echo_ignore_all: if it's set non-zero, the kernel ignores all ICMP echo requests, and the default is 0. You read it with sysctl, a tool that reads and changes kernel settings:

sysctl net.ipv4.icmp_echo_ignore_all

A 1 means the instance is deliberately deaf to ping, and no security group can change that. A related setting, icmp_echo_ignore_broadcasts, only covers pings sent to broadcast or multicast addresses, so it isn't your problem when you ping one address.

The host firewall. Many Linux systems run a software firewall of their own, such as iptables, nftables, firewalld or ufw. Any of them can drop ping requests even when AWS lets them through, and AWS's timeout guidance lists the operating system's firewall as a layer to check. The commands differ by distribution, so use your distribution's documentation to list the rules and look for anything that drops or rejects ICMP echo requests.

Ethan's advice is blunt: "Add one rule that accepts echo requests from your address. Don't switch the whole firewall off just to make a test pass. You'll forget to switch it back on."

Windows Server instances: the firewall rule that answers ping

On a Windows Server instance, the guest firewall is Windows Defender Firewall with Advanced Security. AWS's own documentation says you might need to enable an inbound rule that allows echo requests, for example File and Printer Sharing (Echo Request - ICMPv4-In), or create one. This is the step people miss after fixing the security group.

1. Connect to the instance with Remote Desktop, which needs your security group to allow TCP port 3389.
2. Open Windows Defender Firewall with Advanced Security and choose Inbound Rules.
3. Find File and Printer Sharing (Echo Request - ICMPv4-In) and enable it. If a rule with that name appears more than once, look at which network profile each one covers.

Or use PowerShell (the command-line shell built into Windows). Microsoft's documentation shows that Enable-NetFirewallRule can select rules by display name. Open PowerShell as Administrator and run:

Enable-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)"

Two details can still leave the rule useless. First, profiles: Windows applies rules by network profile (Domain, Private or Public), so a rule enabled only for a profile your instance isn't using does nothing. Second, scope: a rule can be limited to certain remote addresses. Microsoft's PowerShell examples include rules scoped to a specific address or to LocalSubnet, and a rule limited that way won't answer a ping arriving from the internet. Open the rule's properties, check its scope, and make sure it includes the address you ping from.

Find the blocker instead of guessing: flow logs and Reachability Analyzer

Guessing gets old fast. AWS gives you two tools that point at the blocker, and one comes with a limit that surprises people.

VPC Flow Logs record accepted and rejected traffic at the network interface. AWS's example shows ICMP as protocol 1 with ports of 0, and it lays out two patterns: an ACCEPT then a REJECT means the request got in and the reply was dropped by a stateless network ACL, while a single REJECT means the ping was not permitted to reach the instance at all. AWS also provides a Systems Manager runbook named AWSSupport-EnableVPCFlowlogs that switches the logs on for you.

Reachability Analyzer reads your configuration and tells you where a path is blocked. Here's the honest catch: when you create a path, the protocol menu offers TCP or UDP. There's no ICMP choice. So it can't tell you whether your Echo Request rule exists. What it can do is find other blockers, like a missing route, a missing internet gateway, or a network ACL problem, by analyzing a TCP path to the same instance. Follow these steps.

1. Open the Network Manager console and choose Reachability Analyzer, then Create and analyze path.
2. For the source, choose Internet Gateway as the source type and select your VPC's gateway.
3. For the destination, choose Instances and select the instance.
4. For Protocol, choose TCP and use a port you've allowed, such as 22.
5. Choose Create and analyze path. In the results, read Reachability status. If it says Not reachable, expand Explanations and Details to see the blocking component.

A Reachable result for TCP is a good sign for the road, but it doesn't prove ICMP is allowed. Treat it as clearing three suspects (route, gateway, network ACL) while your security group rule stays on you.

Special cases: load balancers, private instances, other networks and IPv6

Pinging a load balancer's name

If your web app sits behind an Application Load Balancer, pinging its DNS name isn't a test of your instance. AWS's documentation says you can open ICMP in the load balancer's security group so it answers ping, but those requests are not forwarded to any instances. A reply tells you the load balancer is there and nothing more. AWS re:Post answers also report that a Network Load Balancer doesn't respond to ICMP echo requests at all. A quick TCP or HTTP check against the listener port tests what your customers actually use.

Pinging out from a private instance

When a private instance pings the internet through a NAT gateway, the checks flip. AWS's NAT gateway troubleshooting lists the public subnet's route to an internet gateway, the private subnet's route to the NAT gateway, and security groups and network ACLs that allow the outbound traffic. It also reminds you that your security group rules must allow you to ping other resources.

Between VPCs, over a VPN, or from your office network

The same layers apply, just with private addresses. The rule's source has to include the address the ping comes from, so use a CIDR block that covers your office or the other VPC. The network ACLs need both directions open. Routing matters in both directions too: AWS's Reachability Analyzer documentation includes a finding where a missing route for the response leg means the network might drop the response traffic.

IPv6

To use ping6 against an instance's IPv6 address, AWS says to add an inbound ICMPv6 rule, such as All ICMP - IPv6 (protocol 58). An ICMPv6 Echo Request is type 128. Sources for IPv6 look like ::/0 for anywhere, and network ACLs treat IPv6 separately from IPv4, so both need attention if your VPC has both.

Automate it: put the ping rule where it can't be forgotten

If you rebuild instances often, clicking through the console every time is how the rule gets forgotten. Two documented approaches keep it in writing.

In an infrastructure template

AWS CloudFormation, the service that builds AWS resources from a written template, documents the exact shape. To allow ping requests, add the ICMP protocol type and specify 8 (echo request) for the ICMP type and either 0 or -1 (all) for the ICMP code. In the ingress section of the security group, that means these properties: IpProtocol: icmp, FromPort: 8, ToPort: -1, and a CidrIp set to the address or range you trust. It's the same rule as the console version, with the type and code in the port fields.

With the CLI, including cleanup

The CLI command from the first section adds the rule. AWS documents the matching removal too: revoke-security-group-ingress takes a security group ID and a rule ID. Each rule gets a unique ID when you create it, and you can use that ID with the API or CLI to modify or delete it. Give your ping rule a clear description, note its ID, and you can remove it in one command when the troubleshooting is over.

Jake liked that. "So the rule can be written down instead of living in someone's head?" Ethan grinned. "That's the whole idea. Heads forget. Templates don't."

There's an adjacent task you'll probably need next: reaching the instance to manage it. AWS warns that rules for SSH (port 22) or RDP (port 3389) should authorize only the specific address or range that needs access, and that choosing Anywhere allows every address on that protocol. Give those rules the same care as the ping rule.

Is it safe to leave ping open, and what not to block

Ping is a small thing, but it's still an open door. AWS's guidance is that it's a best practice to authorize only the specific IP address ranges that need access. For ping, that usually means one address (your own) or your office's range. Opening it to the whole internet lets anyone confirm that your address answers. It's not a catastrophe, but it isn't necessary either.

There's a flip side. Don't block all ICMP everywhere out of habit. Some ICMP messages have a job beyond ping. The maximum transmission unit (MTU) is the largest packet that can cross a connection, and all EC2 instance types support 1500. Path MTU Discovery (PMTUD) is how two machines work out the smallest MTU along their path. A device that receives a packet that's too big replies with an ICMP message, which for IPv4 is Destination Unreachable: Fragmentation Needed (type 3, code 4), and for IPv6 is Packet Too Big (type 2). Without those messages, oversized packets can be dropped.

AWS recommends allowing inbound ICMP to support Path MTU Discovery, and its documentation adds that ICMP can be blocked even when a security group allows it, such as when a network ACL entry denies ICMP to the subnet. That's the reason to avoid writing a blanket deny-all-ICMP rule in a network ACL. Ethan's take: "Allow what you need, from who you need, and leave the clever deny rules to people with a very good reason."

One more piece of honest advice. Ping is a weak health check. A reply shows the network path and the operating system answered. It says nothing about whether your app works, and some AWS services won't answer it at all. If you're monitoring a server, point the check at the port your app really uses. AWS's own connection tracking documentation uses netcat, a small tool that opens a connection to a chosen port, in its examples, and any TCP-level tool serves the same purpose.

When nothing works: the ladder from cheapest to most drastic

Some problems are like a printer that hates Mondays: every layer looks fine, and it still misbehaves. Work down this list in order. Each rung is cheaper and less disruptive than the one after it.

1. Confirm the basics. The instance is running, its status checks pass, and you're pinging its current public IPv4 address.
2. Re-read the security group. The group is attached to the instance's network interface, the type is Custom ICMP - IPv4 with Echo Request (or All ICMP), and the source matches the network you're on right now.
3. Re-read the network ACL. ICMP is allowed in and out, no lower-numbered deny catches it first, and the IPv6 entries exist if you use IPv6.
4. Check the road. The subnet's route table has a default route to an internet gateway that still exists, and the instance has a public address.
5. Look inside the operating system. Use Session Manager or the EC2 Serial Console to check the Linux kernel setting and host firewall, or the Windows echo request rule and its scope.
6. Turn on evidence. Switch on VPC Flow Logs and read the ACCEPT and REJECT records, and run Reachability Analyzer on a TCP path to clear the route, gateway and network ACL.
7. Use a control. Launch a small test instance in the same subnet with the same security group and see whether ping works between them. It costs some instance time, so delete it afterward.

Now the limits, stated plainly. This post can't see your account, so it can't tell you which layer is the culprit. If you don't have permission to change security groups or network ACLs, you'll need someone who does, because AWS's security group instructions note the required IAM permissions. And if the instance belongs to another team's account, none of this is yours to edit. In that case, take the symptom table and your flow-log evidence to the owner. If you've been through the whole ladder and something still refuses to answer, contact AWS Support with what you've collected.

Back to Jake and his Saturday. When his monitor said "down" again the following week, he didn't close the screen. He opened the EC2 console, read the public address, and checked the security group's inbound rules. Ethan just nodded. "That's the whole trick. Look for the missing doorbell before you declare the building empty."

After it works: tidy up so the fix doesn't become the next problem

Ping replies are on your screen. Before you close the tab, spend two minutes on the boring part, because a fix that lives forever with no owner is how a forgotten rule becomes a surprise.

• Narrow anything you widened. If you used All ICMP or Anywhere to get unstuck, replace it with Echo Request from your own address.
• Name the rule. A short description saying why it exists lets the next person delete it without fear.
• Remember the address problem. If the rule uses My IP, it will stop matching when your public address changes. Decide whether that's acceptable or whether a range is better.
• Leave the other layers alone. Don't leave the Windows firewall off, and don't leave a broad network ACL rule in place just because it made testing easier.
• Consider not needing ping at all. If what you really want is to know your app is alive, point your monitoring at the app's port.

Ethan's last word on it is short. "A good fix is one you can explain in a sentence and undo in a minute."

Frequently asked questions about pinging EC2 instances

Why can't I ping my EC2 instance even though SSH works?

SSH uses TCP port 22, while ping uses ICMP, and a security group treats them as separate protocols. A rule for port 22 does nothing for ping. Add an inbound rule of type Custom ICMP - IPv4 with protocol Echo Request and your own address as the source. If that rule exists and ping still fails, check the subnet's network ACL, then the firewall inside the operating system.

Which security group rule do I need to allow ping on EC2?

One inbound rule: type Custom ICMP - IPv4, protocol Echo Request, source your public IP address or a CIDR block you trust. All ICMP - IPv4 also works but allows every ICMP message type. For IPv6 pings you need an ICMPv6 rule instead. No port number is involved, because ICMP does not use ports.

Do I need an outbound rule for the ping reply?

No. Security groups are stateful, which means a reply to allowed inbound traffic can leave the instance regardless of outbound rules. Network ACLs are different. They are stateless, so if the subnet uses a custom network ACL, its outbound rules must allow the reply too. The instance that sends a ping does need outbound ICMP allowed if its outbound rules were restricted.

Should I choose Echo Request or Echo Reply in the ICMP rule?

Choose Echo Request for an inbound rule on the instance you want to ping. Echo Request is ICMP type 8 for IPv4. The Echo Reply is the answer the instance sends back, and the security group allows that automatically. Choosing Echo Reply for the inbound rule is a common slip that leaves ping timing out.

Is it safe to allow ping from anywhere (0.0.0.0/0)?

It is not dangerous by itself, but AWS advises authorizing only the specific address ranges that need access, and a single address is easy to enter with My IP. Allowing everyone means anyone can confirm your address answers. Ping from your own address, and remember that some ICMP messages help with path MTU discovery before you block ICMP broadly.

Why does ping work from another instance but not from my laptop?

Inside a VPC, traffic uses private addresses and may be allowed by a rule that names the VPC range or another security group. From your laptop, the traffic arrives from your public address, so the rule's source must include it, the instance needs a public IPv4 address, and the subnet needs a route to an internet gateway. Also check the network ACL.

Can I ping the private IP address of an EC2 instance from the internet?

No. AWS describes a private IPv4 address as one that is not reachable over the internet. From your laptop, ping the public IPv4 address or Elastic IP address. To reach a private address you need to be inside the VPC or connected through a VPN or Direct Connect, and the rules must still allow ICMP.

Why did ping stop working after I stopped and started my instance?

AWS releases the automatically assigned public IPv4 address when an instance is stopped and assigns a new one when it starts. The old address you were pinging is back in the pool. Read the new public address from the console, or use an Elastic IP address if you need one that stays the same.

How do network ACLs affect ping to an EC2 instance?

A network ACL filters traffic at the subnet level and is stateless. The default one allows everything. A custom one ends with a deny rule, so ICMP must be allowed both inbound and outbound, and lower-numbered rules win. If the request is allowed in but the reply is not allowed out, ping fails, and flow logs show an accepted request followed by a rejected reply.

How do I allow ping on a Windows Server EC2 instance?

After adding the security group rule, enable the Windows Defender Firewall inbound rule named File and Printer Sharing (Echo Request - ICMPv4-In), or create an equivalent rule. In an administrator PowerShell window you can run Enable-NetFirewallRule with that display name. Also open the rule's scope settings to make sure it covers the addresses you ping from.

How do I check whether a Linux instance is ignoring ping?

From a session on the instance, run sysctl net.ipv4.icmp_echo_ignore_all. The kernel documentation says a nonzero value makes Linux ignore all ICMP echo requests, and the default is 0. Also review the host firewall, such as iptables, nftables, firewalld or ufw, because a rule there can drop echo requests even when AWS allows them.

How can I ping an EC2 instance over IPv6?

Use the ping6 command against the instance's IPv6 address, and add an inbound security group rule for ICMPv6, such as All ICMP - IPv6, which is protocol 58, or a custom rule with type 128 for Echo Request. Network ACL rules for IPv6 are evaluated separately from IPv4 rules, so check those too.

Can I ping an Application Load Balancer or Network Load Balancer?

An Application Load Balancer can answer ping if you open ICMP in its security group, but AWS notes those requests are not forwarded to your instances, so a reply says nothing about them. AWS re:Post answers report that a Network Load Balancer does not respond to ICMP echo requests. Use a TCP or HTTP check against the listener port instead.

How long does a security group change take to apply?

AWS says rule changes are propagated as quickly as possible, but a small delay might occur. Existing tracked connections are not cut immediately when you change a rule, so an already-running ping may behave oddly for a while. Wait briefly, then start a fresh test.

How do I troubleshoot ping if I can't log in to the instance?

Work from outside. Read the security group, network ACL, route table and public IP in the console. Turn on VPC Flow Logs to see accepted and rejected traffic, and run Reachability Analyzer, remembering it offers TCP and UDP rather than ICMP. If Session Manager or the EC2 Serial Console is set up, they can get you inside without SSH.

Is ping a good way to monitor whether my server is up?

Not on its own. A ping reply shows the network path and operating system answered, but not that your application works, and some AWS services do not answer ping at all. A TCP or HTTP check against the port your app uses tests what your customers actually use. Keep ping as one signal, not the only one.

Revision note. Written September 2026. If you've been staring at "Request timed out" for an hour, take a breath: it's almost always one small missing rule, and you're closer to the fix than it feels.