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:
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:
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.
Only one concern here when you mind about price: Public Cloud sells in terms of virtual CPUs (basically hyperthreads) with a number of different generations of CPUs.
So, do not consider the: 1 on-prem core = 1 cloud cpu. This is wrong!
At most consider: 1 on-prem hyperthread = 1 cloud cpu. This is almost right!
the 'almost' here is because different generations of CPUs have different per-hyperthread performances.
On the other side consider that very often on-prem specs are oversized. So really assess your power needs before even compare CPUs.
Then online calculators are your friends for rough estimates.
As no-one has mentioned Azure yet here are my two cents in that respect.
In general I would recommend to tear things apart and move them to PaaS services whenever possible. This would prepare your solution for growth and comes with many other benefits, e.g. like built-in backup that you already mentioned, but also scaling and additional security features.
Azure Database for MySQL
This DBaaS solution would cost you around 100 USD. Storage would be cheap (0.69 USD/month = 5 GB * 0.138 USD) and it would include another 5 GB of storage for backup. Additional backup costs may apply if longer backup retention periods are required. For the computational part, a one year reserved instance would cost around 99 USD (general purpose, 2 vCores Intel E5-2673 v4 2.3 GHz)
Azure App Service
Would cost you something between 73 USD - 292 USD dependent on the amount of storage, CPU and RAM your PHP site requires. I would choose at least a Standard tier, as this would allow for auto-scaling and VNet connectivity so that your web app can talk directly to the MySQL DB via service endpoints (data stays on Microsoft backbone, good for latency and security).
Azure CDN
Outbound traffic from zone 1 (North America, Europe, Middle East and Africa) would be (10'000 * 0.081 USD) + (7'000 * 0.075) = 1'335 USD/per month. Plus a monthly fee of around 21 USD for the storage of 250 GB of data in the CDN static zone 1.
Also a storage account would be required (see below). However no charges would apply for the transfer between the storage account and the Azure CDN (Microsoft only, not Akamai/Verizon) in case an object is not at the edge location.
Azure Storage Account
The estimation of this cost factor requires more information, as the monthly price depends on a) the volume of data stored per month b) the quantity and types of operations performed (along with any data transfer costs) c) data redundancy options.
So for an amount of 500 GB of hot block blob storage with the lowest redundancy (LRS) we would have to pay 10.40 USD/month. Now what's missing is the price tag that comes with the operations and data transfers. For more details have a look here: https://azure.microsoft.com/en-us/pricing/details/storage/blobs/
To summarize:
This would result in total charge between 1'579 USD and 1'798 USD per month.
The naive way is to match your current server specs to one of the cloud instance offerrings roughly 1:1 and price that up. E.g. if your server is 4 CPU / 16 GB RAM then in AWS you may look at m5.xlarge that costs $0.192/hr which is ca $140/month. Once you are confident that the instance size is right for your needs you can commit to a 1 or 3 years reserved instance term for up to 60% savings. On top of that you’ll need some disk space at ca $0.10/GB/month and the cost of egress traffic. That’s the easy but potentially more expensive way.
Another option is to rearchitect the website. Store the images in e.g. S3 bucket (much more scalable and cheaper per GB), which means you could probably do with a smaller and cheaper instance since it won’t be overloaded with serving the static images. Likewise you can offload the database to a managed database service (e.g. AWS RDS) or use a NoSQL db like AWS DynamoDB. But all that may require code changes.
If you are happy to rearchitect the website and make use of the cheaper cloud native services you can save a lot. How much? It depends, there is no easy answer until you decide what services you’re going to use.
On the other hand if you just wish to migrate from your colo server like for like to a cloud server that’s very easy to calculate. See above.
Hope that helps :)
I was essentially in the same situation as you but found all the offered virtual services to be extremely confusing and completely unpredictable when it came to calculating costs. So I rented a dedicated server, which guarantees a fixed cost per month for a true CPU and given maximum amount of RAM, disk, and throughput. Predicting your ultimate cost is trivial compared to using the "calculators" offered by the virtual services. Since you're already using a colocated server, which I assume you own, finding an equivalent or greater dedicated server should be straightforward.
$700 sounds very high for your needs, and you should be able to find the capacity and speed you want for far less. I/O is going to be your bottleneck.
At one time or another I have rented dedicated servers from quickpacket, serverhub, and needaserver (because an application required redundant geographically dispersed datacenters). All three vendors were more or less comparable in price, availability, performance, support, etc.
One additional comment to all the other answers:
In determining capacity/CPUs, remember that one of the advantages of cloud services is the ability to scale up as your needs increase. You don't mention your traffic loads or number of sessions, etc., but you can start relatively small and increase capacity as needed, whether that means standing up larger instances or scaling out with more instances.
The biggest cost variable will be your traffic loads, i.e. how much traffic you're serving from your website.
You can benefit on moving to the Google Cloud Platform by moving your static data (which from your description is the majority of the files stored on your server) to GCP buckets and store your static data there.
If you want to calculate how much it will cost you can use pricing page and do the math. Everything depends on how much data will be stored, how much egress traffic you will generate and how much IO operations will be needed.
Or you can just use the official Google Cloud Pricing Calculator and put in all the data you can to get an estimate.
You can also get monthly cost estimes for running GCP VM's while creating new ones - after you put in all the details (how many cores, ram etc) you will see monthly cost. But this is just for running and instance.
You can also get additional commited use discount.
You have, overall, two primary components here:
Note that I'm listing both the PHP-powered web server and the database as one thing here. Moving those to separate cloud services will almost certainly cost you quite a lot in the short term because of the overhead of rearchitecting a large part of the site in a way that's not likely to e trivial.
For the first part, you're down to just total storage space. For most offerings, you're looking at either about 30 USD a month (if you go with block storage accessed by your server), or less than 10 USD per month for object storage (not counting load balancing/edge caching costs, which is likely to be a mostly fixed charge in the 20-200 USD range).
For the second part, look at a service like Vultr Compute Cloud, Digital Ocean Droplets, or AWS Lightsail. They all provide 'traditional' VPS hosting where you get X CPU threads, Y amount of RAM, and Z amount of disk space as one package with a fixed price. With these, you just pick whichever one matches up in terms of processing power with what you're already using and go from there. Pricing on these is usually about 10 USD per CPU core per month, though on the small end there are often lower cost single CPU offerings that have less RAM/storage than the 10 USD offering.
There's one other thing to consider though: network usage. Almost all cloud providers charge in some way for network usage. Typically, you will see one of two approaches:
Most also have some minimum amount of traffic that they will not charge you for (for example, AWS doesn't charge fo the first 5GB/Month of outbound traffic, or Vultr gives you a few TB of bandwidth for free and then pro-rates overages each month per GB).
This particular aspect often gets overlooked because in on-prem and colo setups, you usually pay for whatever bandwidth cap you have, while cloud offerings typically have very high bandwidth caps (many cloud offerings will guarantee 40Gbit speeds at least one way), but you pay per unit of data transferred. Most cases I've heard of people jumping on moving to the cloud and then having to pay a lot more than expected come down to this, so it's something you should make a point to look into thoroughly before making the switch.
It's too soon to worry about scaling because you have better capacity options for less than you're currently paying.
I'm guessing your CPU, memory load, and network input aren't really significant, and the cost of outgoing bandwidth is the only real issue.
I can easily rent a $50/month dedicated server with 50TB/month of I/O that probably can easily handle your current needs. You're currently paying for the equivalent of 14 of those servers!
Switch to a cheaper dedicated server, forget those expensive virtual solutions, and just look into load balancing if your requirements ever outgrow a single server.