What you are experiencing with your traceroutes is common. Remember that traceroute uses ICMP packets to send an echo request to each of the routers in the path between the source and destination. Many of these devices are configured not to respond to ICMP packets for security reasons, because ICMP can be used by attackers to disable or attack these systems. But as you said, this does not mean that the path to the destination is unreachable. Imagine you have the following scenario through the Internet:
Here Host1 is sending a traceroute to Host2. Let’s say R4 is configured not to respond to ICMP packets. So traceroute will send an ICMP request to each of the routers in the path using an incremented TTL. (For more info on how traceroute works, take a look at this lesson.) All the routers will respond except for R4, and for that entry you will see the “* * *” responses which is essentially an ICMP timeout.
Even so, R4 will still route packets and thus traceroute will continue to query R5, R6 and will also reach Host2. So connectivity is still achieved.
Now if you are getting timeouts all the way to 30 hops like in your example, this simply means that even the destination host of 22.214.171.124 does not respond to traceroute ICMP packets. This means that traceroute will continue to test connectivity increasing the TTL by 1 every time, but if it never gets a response from the final destination, it will go to the maximum of 30 hops and end there. Note that a host can be configured not to respond to traceroute ICMP packets but to respond to ping ICMP packets. This is why you may be able to ping your destination but not traceroute it…
I hope this has been helpful!