<p>Short answer: Yes, you should expect any IaaS, PaaS, SaaS platform to have issues from time to time.</p>
<p>There's no bullet-proof system.  Sometimes the vendor has issues with the underlying hardware that can affect your server/container.  My first step if I think AWS is having a hardware/virtualization issue is stop and start the instance.  This moves your instance to a different AWS server.  You should rarely need to do this though.</p>
<p>What you can do is monitor and alert on metrics that would indicate your service/server is not responding.  In your example, Network traffic (bytes in) below a certain threshold for a certain period of time could indicate an issue.</p>
<p>To further protect the availability of your site you can (depending on your use case) create a second (or multiple) instance and use an application or network load balancer to check host health and send traffic accordingly. (ALB/NLB).</p>
<p>Bottom line, you should always expect issues (whether using a cloud provider or your own hardware) and build monitors to alert when an issue may be present and take appropriate actions.</p>
<p><strong>References</strong><br />
<a href="https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html" rel="nofollow noreferrer">AWS High Availability White Paper</a></p>

CC BY-SA 4.0
2022-02-07T20:28:08.853Z
Doesn't that mean that generally I should start with at least 2 EC2 instances?
x-yuri
CC BY-SA 4.0
2022-02-08T13:31:03.967Z
@x-yuri Yes, depending on your use case.  I've added use of LB's into the answer and linked an AWS white paper on HA.
kenlukas
CC BY-SA 4.0
2022-02-07T16:23:15.810Z
2022-02-08T13:29:52.083Z
2022-02-08T13:29:52.083Z
kenlukas
<p>I recently had an <a href="https://serverfault.com/questions/1090498/downtime-on-an-ec2-instance">issue</a> with an EC2 instance. Briefly, the site was unavailable for 2 hours, a peak of CPU usage for no apparent reason, network traffic dropped close to 0, docker containers restarted, issues with the clock. The fault might have been not on their side, but...</p>
<p><strong>Do you expect</strong> that EC2 instances might occasionally act up? After all, they seem to <a href="https://aws.amazon.com/compute/sla/" rel="nofollow noreferrer">sort of guarantee</a> no more than 0.5% downtime (3.6 hours per month?). Which means there might be downtime.</p>
<p>What do you do to avoid that? In my case I don't even know if that counts towards downtime, because technically the server was running, but network traffic was close to 0. And I'm not sure, but it seems their health/status checks didn't notice anything unusual (how do I check?)</p>
<p><strong>UPD</strong> Most likely the physical server where it was running failed and the instance migrated to another server. Because there's the following line in the log:</p>
<blockquote>
<p>Jan 12 21:31:29 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: Forward time jump detected!</p>
</blockquote>

<amazon-ec2>
Should I expect EC2 instances to act up?
x-yuri
# Should I expect EC2 instances to act up?

(Asked by: username_0 on 2022-01-19)

I recently had an [issue](https://serverfault.com/questions/1090498/downtime-on-an-ec2-instance) with an EC2 instance. Briefly, the site was unavailable for 2 hours, a peak of CPU usage for no apparent reason, network traffic dropped close to 0, docker containers restarted, issues with the clock. The fault might have been not on their side, but...

**Do you expect** that EC2 instances might occasionally act up? After all, they seem to [sort of guarantee](https://aws.amazon.com/compute/sla/) no more than 0.5% downtime (3.6 hours per month?). Which means there might be downtime.

What do you do to avoid that? In my case I don't even know if that counts towards downtime, because technically the server was running, but network traffic was close to 0. And I'm not sure, but it seems their health/status checks didn't notice anything unusual (how do I check?)

**UPD** Most likely the physical server where it was running failed and the instance migrated to another server. Because there's the following line in the log:

> Jan 12 21:31:29 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: Forward time jump detected!

**Tags:** amazon-ec2


---

## 1 answers

### Answer by username_1 on 2022-02-07. Score: 2 | Accepted answer

Short answer: Yes, you should expect any IaaS, PaaS, SaaS platform to have issues from time to time.

There's no bullet-proof system. Sometimes the vendor has issues with the underlying hardware that can affect your server/container. My first step if I think AWS is having a hardware/virtualization issue is stop and start the instance. This moves your instance to a different AWS server. You should rarely need to do this though.

What you can do is monitor and alert on metrics that would indicate your service/server is not responding. In your example, Network traffic (bytes in) below a certain threshold for a certain period of time could indicate an issue.

To further protect the availability of your site you can (depending on your use case) create a second (or multiple) instance and use an application or network load balancer to check host health and send traffic accordingly. (ALB/NLB).

Bottom line, you should always expect issues (whether using a cloud provider or your own hardware) and build monitors to alert when an issue may be present and take appropriate actions.

**References**  
[AWS High Availability White Paper](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html)

> **Comments:**
> **username_0**: Doesn't that mean that generally I should start with at least 2 EC2 instances?  
> **username_1**: @username_0 Yes, depending on your use case.  I've added use of LB's into the answer and linked an AWS white paper on HA.  

---

