How can I determine if it is cost-effective to move my site to cloud solution?
I have a large, busy site; it currently runs completely on a dedicated server that I rent each month for ~$700.
It has three parts that I think I could carve off to a cloud solution:
-
Media (image/video) file hosting. Currently I have something like 236 GB of static images, currently all just parked on my server. If I moved these to the cloud I would probably combine with a CDN (to minimize the cost of data transfer out of the cloud service for every image request).
-
Database. Currently running MySQL with about 3 GB of data on my server.
-
Web server. The same server runs nginx serving static files and PHP.
I'm not having any production issues now but I expect my site to double in traffic/server load next year. So I want to think about scalability now.
My question is this: how can I figure out if it would be cost-effective to move any/all of these onto a cloud platform, instead of keeping them on my current server?
(I already know some of the other factors in place: it would be easier to do backups with cloud, I wouldn't have one point of failure like I do now with my single server, etc. But I have no sense of how much more/less it would cost to carve off one of these services. How can I compute that?)
EDIT - thank you all for these amazing answers and comments. A few folks have asked for more info so I'm summarizing all below and adding a little more data:
Data Transfer ("Bandwidth") Used - the site sends ~17 TB outbound data per month (!) and I am planning to double that figure next year (!!). Almost all of this outbound is static media (pics and video clips), so perhaps a CDN would be a good idea, not only for better discoverability but to move the burden of transmitting all that data to the CDN network, so the media storage server doesn't have so much data transfer directly. --EDIT: it seems that CDNs are damn expensive for this much data transfer. So maybe the static media stays on a simple server that gives me a very high bandwidth cap (hello OVH!) and if I can find a cost-effective way to put a CDN in front of it, terrific.
Traffic Not Spiky - my traffic is fairly steady; my goal with moving to a more cloud-based solution is to be able to easily scale up. I.e. my current setup has everything on one hard drive and the drive is 60% full; this infrastructure literally couldn't deal with double the amount of data (and I'm not sure it would have enough computing power to run the web server and DB server at double the traffic, either).
Static Media - As I mentioned above, I have about 236 GB of static media, mostly all images and video clips. This seems like the most obvious (and maybe easiest?) piece to carve off first and put in the cloud.
Database - while the DB runs fine now, I will be having some more complex queries soon and like the idea of something a little more powerful there. So while I don't think my current needs (power and amount of data) dictate that I should move the DB server into the cloud, it's all about being able to scale up.
Busy Hours - I always have at least 1,000 users on the site 24/7, voraciously consuming media. The server is never idle.
Currently Dedicated Server - I misspoke earlier and said it was colo (implying that I owned the hardware). That was wrong. I have a dedicated server (owned by my hosting company) that I rent each month. Not a big distinction but just want to mention.
Update
AWS would charge $3300 a month for 35TB of outbound bandwidth. Five of the largest Lightsail instances would cost a bit over $800 and would include 35GB of traffic. I assume that you can use the instance bandwidth if you use a load balancer. Their CDN pricing would get you to $2300 per month. You'd probably need another server as a web server, so the better part of $1000 a month.
Given your bandwidth needs I would rule out EC2 / CloudFront. You could consider Lightsail and a load balancer, after you verify load balancers effectively use the instance bandwidth. However, staying with a co-lo might be easier, though less flexible.
Previous Post
MLu gave you a good option, but rearchitecting a website can be difficult. Simply moving the image hosting to S3 with CloudFront (or CloudFlare) might be fairly simple and would be cheaper and faster than hosting it yourself.
Basic Suggestion
If you just want a VPS, work out the specs required in terms of CPU / RAM / disk and put it into the AWS Calculator. Ignore the warning to use the new calculator, the new one isn't very good.
LightSail is a cheap way into AWS - bandwidth is especially cheap. You can get 8 cores, 32GB RAM, and 7TB transfer for $160/month, which would cost about $330 for the server plus $600 for bandwidth. Combine a couple of them (or smaller instances) with a $16 Lightsail load balancer you get a lot of power for not a lot of money. Lightsail is a lot simpler than full AWS.
Architecture Suggestion
Your best option for your architecture is like:
- EC2 instance running Nginx / PHP
- AWS RDS for MySQL
- AWS ALB for load balancing
The difficult part here is sizing the resources. You can take a guess based on CPU usage while watching "top" if you like.
RDS
RDS you need to size for your peak load. Say you have a 4 core server now and MySQL looks to be taking two cores at peak then you probably need a two core RDS MySQL server.
To map that to instance type depends on your off-peak usage. T2 / T3 instances give you a fraction of a CPU, with a burst balance to use more sometimes. If you have a lot of time the website isn't busy it can build up CPU credits off-peak, use them on-peak. db.t2.medium gives you two cores and 4GB RAM, db.t3.medium gives you 2 cores, 8GB RAM, and more CPU credits. If the website is fairly busy most of the time you'll need dedicated CPUs, db.m5.large gives you two cores. You can change DB type fairly easily, but there will be some downtime if you don't have a multi-az instance (google that term to learn more).
EC2
EC2 can be more flexible as you can scale the number of instances based on load. You might choose an m5.large (or m5a for AMD, or m6g for ARM) as your base server, with 2 cores and 8GB RAM. Once it hits a threshold, say 60% CPU usage, AWS can spin up as many instances as are required to help cope with load, then take them down when not needed. You don't typically use t2 / t3 instances in load balancer as they can run out of CPU credits which makes things tricky.
Sizing and Price
Once you work out your architecture and sizing you can plug that into an AWS calculator. You'll need RDS instance, EC2 instances, account for egress bandwidth from the server, account for S3 storage of images and image bandwidth, EBS disk space and snapshots for backup, plus space for an AMI image to auto scale from. You probably then want services like Guard Duty to monitor your account (cheap), CloudTrail logs as audit logs which is just the storage price, and other bits and pieces. It can start to add up.
AWS bandwidth can be very expensive. Before you get into the detail of a calculation do a rough guess of maybe a db.m5.large RDS database, a couple of m5.large EC2 instance, 300GB EBS disk, and your outgoing bandwidth. If you use a lot of bandwidth that might cost more than your current co-lo. If most of your bandwidth is static resources an external CDN like CloudFlare can significantly reduce your costs, if you set up caching headers properly. I don't know how much of your 236GB they would cache, but they'd cache all the often used stuff. All of their 100+ data centers will download resources from your server though, so you'll still use a fair bit of bandwidth.
I have deliberately not explained every term I've used. AWS is complex and can be difficult to do well, securely. You'd really want to do some training to understand AWS before you start to use it. Once you understand AWS it's very powerful, but can be time consuming. Or just use Lightsail as mentioned above.
As a rule of thumb, using a cloud is always more expensive than using dedicated servers. As an example, for my private projects I have a fairly beefy server (metal) that costs me 40€ a month that would cost me over a hundred euros a month on AWS.
If you are a business, that is not your real cost calculation though. For my own server, I have to do:
- linux distribution updates
- software updates
- general maintenance
- vpn configuration
- load balancer configuration
- ssl certificates
- possibly mirroring on other continents
- all the other configuration stuff
- ...
As a private person, those things are essentially free. I do them in my spare time and figuring out how to do it can be fun. As a result, I pay 40€ a month for my server and that's the full extent of my expenses.
As a company, all those things cost money. Someone - who is most likely paid - has to do all of that. You might have to hire a server administrator or DevOps, who wants to be paid at least a high 5-figure amount a year, maybe even 6-figure, depending on the location. If you are doing those things yourself, they will take time which you could instead spend on actually developing or promoting your application. Time is money.
The cloud can save you all of that, especially if you use things like containerization, which remove the need to worry about the actual servers and only require you to maintain the actual software you are using.
To say whether it will be cost effective or not requires taking the administrative time into account. You will most likely spend 4-5 times as much money on the cloud infrastructure compared to your dedicated server, and the costs will rise the more users you get. Whether that is more than you would spend on administrating your current infrastructure, either yourself or by hiring a sysadmin, is impossible to say.
As a private person, I would always pick a dedicated server.
As a company, it becomes a difficult calculation, often trending towards the cloud.