5 ms·

EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Writing to EFS however means that you

EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Writing to EFS however means that you can just treat your EC2 instance as a stateless front-end server that can be swapped out whenever needed. Couple that with an autoscaling group and when the instance inevitably dies, it'll automatically come back up on a new host. I don't have an ops team so I prefer AWS to be responsible for stuff like this wherever possible.

dannyw 6y ago
I have a Wordpress blog that has been continuously up, barring two host server migrations (~3 hours), since 2004. It is powered by a Linode. I have literally never needed to manage the server unless I was actively working on something, like changing the theme. People overcomplicate things these days. You could spend X hours creating some autoscaling, autorecovering setup; but for 99% of projects, it'd maybe encounter an outage that requires your intervention, once a decade.
- brodouevencode 6y ago
  Fair, but how many customers do you serve? The example provided was enterprise level. TBH I would have not chosen Wordpress as the application of choice but the architecture is what would be recommended for an enterprise solution. Too many people are getting hung up on it being WP. AMZN doesn't care what the application is and has no vested interest (that I'm aware of) in WP. EDIT: clarity
hanoz 6y ago
>EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Where a long enough timeline is 700 years (before you're more likely than not to have suffered a full or partial failure).
dpedu 6y ago
> EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Taking regular snapshots decreases the chance of an EBS drive failing.
liveoneggs 6y ago
EFS is intolerably slow and keeping your php files on it is a bad idea. It's a little more complex but using packagist to install everyy except locally and then put wp-content/uploads/ on EFS works okay. fs-cache/cachefilesd helps.

dannyw 6y ago

I have a Wordpress blog that has been continuously up, barring two host server migrations (~3 hours), since 2004. It is powered by a Linode. I have literally never needed to manage the server unless I was actively working on something, like changing the theme. People overcomplicate things these days. You could spend X hours creating some autoscaling, autorecovering setup; but for 99% of projects, it'd maybe encounter an outage that requires your intervention, once a decade.

brodouevencode 6y ago
Fair, but how many customers do you serve? The example provided was enterprise level. TBH I would have not chosen Wordpress as the application of choice but the architecture is what would be recommended for an enterprise solution. Too many people are getting hung up on it being WP. AMZN doesn't care what the application is and has no vested interest (that I'm aware of) in WP. EDIT: clarity

hanoz 6y ago

>EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Where a long enough timeline is 700 years (before you're more likely than not to have suffered a full or partial failure).

dpedu 6y ago

> EBS volumes have a ~99.9% reliability rating so on a long enough timeline you're going to need to restore from snapshots. Taking regular snapshots decreases the chance of an EBS drive failing.

liveoneggs 6y ago

EFS is intolerably slow and keeping your php files on it is a bad idea. It's a little more complex but using packagist to install everyy except locally and then put wp-content/uploads/ on EFS works okay. fs-cache/cachefilesd helps.