Is it correct to use EBS to store a Wordpress in AWS?

Question

Is it correct to use EBS to store a Wordpress in AWS?

Navigation

#1 by (1 votes)
#2 by (0 votes)

0

I need to migrate a site to AWS, this site has a lot of multimedia content (~ 40GB). Is it possible to create an EBS volume (~ 100GB) and mount it to / var / www / html using an EC2 instance (~ 10GB)?

How can I calculate an estimated price for this using the AWS calculator ? I do not understand your Data Transfer parameters (In, Out)

Is there a better way to achieve this and that it is economical?

Is the choice of EBS on S3 correct in this case?

aws

asked by akko 11.08.2017 в 20:06

source

2 answers

Help with vectors and prime numbers Error implementing "OR" in search of datatable

score 1 · Answer 1

Depends on your expected use.

S3 charges you for:

Used space per month (GB / month)
Data transfer (how many enter and leave)
Petitions GET / PUT / POST / LIST etc.

EBS charges you for:

Volume Space
Desired performance (if it exceeds base performance)

For example, from the calculator:

  100GB de datos de S3
+ 10,000 peticiones GET
+ 1,000 peticiones PUT/POST/LIST etc.
+ 100 GB/mes de ingreso de datos
+ 100 GB/mes de egreso de datos
 = 16.83 USD/mes para la region de US-East

On the other hand, on EBS:

100GB de General Purpose SDD (con rendimiento base de 128MB/sec)
= $9.18 USD/mes para la region de US-East

In addition, to the EBS you would have to add the cost of the backup (snapshots) if you are interested.

In my personal opinion, if you are going to use the space to store static, and you do not plan to be manipulating them a lot (deleting, replacing) once created, S3 is a much better option. It already has backups and redundancy, and if you require high performance (throughput) it is likely that at some point you will saturate the IOPS of the SSD unless you pay for it (and then it will be even more expensive.)

You could even reduce the cost of S3 using Reduced Redundancy Storage (if the static ones you have are not absolutely critical and you can consider the option of losing them ... although in reality it is very unlikely: 99.99% vs 99.999999999% )

I hope this helps you make the best decision.

score 0 · Answer 2

How can I calculate an estimated price for this using the AWS calculator? I do not understand your Data Transfer parameters (In, Out)

Indeed, to be able to calculate the price adequately, you must not only know how much it will occupy, it is also necessary to know what the traffic is that your multimedia content supposes.

Is there a better way to achieve this and that it is economical?

No doubt S3 is a cheaper option for several reasons.

As I mention below, it is optimized for web access with high durability and at a very low cost. Although prices vary slightly from one region to another, you can see here a reference for the main persistence layers ( glacier is only for final backups, not for serving content)
If your website has a lot of traffic, it is more than likely that you end up putting a load balancer (Elastic Load Balancer) and consume traffic (at no reduced cost) by this balancer for your static files if it would be long term more expensive than the use of a CDN for this type of content.

Is the choice of EBS on S3 correct in this case?

In cases like yours (serving static content on a website), there is no doubt that what is recommended is to use S3 (or any other CDN service in general) for several reasons that I consider substantiated beyond my opinion:

This designed for this type of access by key (url file) - value (content of the file). Whatever the type of static file: videos, images, css, js, etc, etc.

You will alleviate the load on your web server as all static content (multimedia) will be served from S3 and not from your server. This will make it more robust against peak Access and use

Multiple persistence layers (transparent to you) adapted to the frequency of access (and therefore cheaper).

It has automated rules to make transitions from one persistence layer to another, for example you can determine that the files that have more X months / years, pass to a more economical persistence layer since you know that are going to be less accessed.

High redundancy (transparent for you) and at low cost. You can make backups automatically but S3 already guarantees a durability of 99.999999999% with several internal copies of your data.

Scale undefined and unlimited . Unlike EBS. you will not have to worry about never about if you are going to run out of space or have to resize your solution.

S3 is automatically integrated with other services within the AWS framework. In your case more interesting would be CloudFront , it is a CDN that would allow a much faster access to your static content by having location and chache points all over the planet, unlike S3 (which will remain fixed to the initial region that you decide).

S3 is included in what is called free layer of AWS, so the first 5G of storage, 20,000 get and 2,000 put per month will be free during the first year.

For your specific case there are numerous plugins that are integrated with S3. Here you can see them. I personally, I have used W3 Total Cache with quite good results.

On the other hand EBS is a storage service that could be understood as virtual hard drives , it is more designed to host operating systems, databases, etc.

Although the question is oriented to S3 and EBS I insist on the importance of using a CDN for this purpose and I recommend that you read this article so you can see the existing variety and the importance of using a CDN to serve your static content.