ClayB's picture

Good Morning!

I currently run a Turnkey LAMP Stack server on my network. It hosts a few websites. It's done well for the past 3 years and I hardly ever have to pull up the server to check on it. But we are getting a few more websites and I wonder that I may overstretch its resources.

I'd like to move the server to the cloud (or create a new server in the cloud) to host our websites. Wondering if this is the right avenue to take (TurnkeyHub)?

Does anyone have any info on pricing and how to calculate pricing for the sites/backups we have? Is there any input on whether this is evena  good idea?



Jeremy Davis's picture

First up, I'll warn you that I'm very biased: You should be using the TurnKey Hub! ;)

But on a more serious note, I can't unequivocally say that you would be better off moving your server to the TurnKey Hub. Having said that, depending on your current resource availability and the instance size you run on AWS, at the very least I suspect that your users/customers would benefit from improved network throughput.

If you'd like to share some more specific info about the current resource usage (i.e. CPU, RAM, network, etc) of your server, I'd be more than happy to provide some more specific info. For now though, I'll speak more generically. Hopefully my essay isn't too much for you!

Hub Pricing/Costs

Regarding Hub pricing, you can see the TurnKey Hub subscription plans and their appropriate costs on the public plans and pricing page. Once signed up the Hub, then you can view and change the specific plan(s) you are on from your Hub account plans and billing page.

As for costs, please note that AWS fees may also apply for the AWS resources that you use. I.e. AWS EC2 usage fees for Hub servers, AWS S3 storage fees for TKLBAM backup storage and Route53 charges if you use a custom domain with HubDNS.

AWS Free Tier

Hub users who are new to AWS will most likely be eligible for the AWS Free Tier, so if that fits you, then many things will be free for the first year. There are some limitations, but up to 5GB of TKLBAM should be free and one t2.micro server is free. Having said that, from what you've stated, in your specific scenario I'm not sure that a micro server will cut it. I suspect that a t2.small server may be a better starting point?

AWS EC2 (cloud) instance/server pricing & features

You can find info about the different AWS instance (i.e. server) types here, and specific "on demand" (i.e. pay what you use) pricing info here. "On demand" is suitable for running specific tasks, e.g. we use AWS EC2 instances to build the TurnKey appliance library. For an "always on" webserver, then I'd highly recommend purchasing a reserved instance. It will lock you in for a period of time, but will save you a bucket load! Reserved instances can be purchased directly through the Hub.

Please note that "reserved instances" aren't actually instances (servers), just a billing feature. They are more like a discount coupon for a specific instance size/type in a specific region. If you have a server running that matches the type and region of a "reserved instance" you have purchased then you get the relevant discounted pricing (one "reserved instance" per real instance).

Unless you have requirements above and beyond serving web pages and/or web apps, then one of the t2 instances will likely be what you want. An interesting feature of t2 instance types is the "burstable" vCPU and vCPU credits system.

Note that IMO the AWS site doesn't do a very good job of laying out the different specs and pricing options. You can find a number of 3rd party sites around that do a much better job of that. This one is one of my favourites, although the latest iteration doesn't support filtering yet (just sorting). A quick google also turned up this one which looks like a good way to compare "on demand" and "reserved instance" options.

Also worth of note, is that AWS charge for everything incrementally. You pay separately for your server and server storage. There are also additional charges once you go over a certain amount of network traffic. To get an idea of your real world costs for running servers, you'll need to put some data (or guesses) re different usage criteria into the the AWS usage calculator.

Additional value of TKLBAM in production

Many TKLBAM users involved in website/webapp development and maintenance tell us that they find TKLBAM invaluable in their workflow. A popular workflow is running a local "development" VM, with a remote Hub "production" server. Then using TKLBAM to migrate data between the instances. It's also possible to use the availability of "on demand" instances, to run any last minute checks via an intermediate "staging" instance if you wish. I.e. the "staging" server is only turned on and TKLBAM data migrated to it, as a final test before migrating to "production".

Something you may not be aware of, is that TKLBAM need not be "one backup per server". In a scenario such as yours, it can also be used to backup/migrate individual data sets (i.e. multiple backups) from a single server. For example, each of your users/customers could have their own backup if they wished. This could allow you to migrate different customers to different servers at different times, without affecting any other users. Perhaps food for thought...?!

Contributing to the ongoing sustainability and maintenance of TurnKey

Whilst we love all TurnKey users, paid Hub subscriptions are where we make the majority of our revenue. So being a paid Hub subscriber means that you get to sleep soundly in the knowledge that you (and by extension, your users) are contributing to the ongoing development, maintenance and sustainability of TurnKey. Joy :)

Future Hub development

FYI, at some point in the future, we hope to offer "all-in-one" type Hub plans, which won't require any separate (i.e. AWS) account. We've also always planned to provide support for additional cloud providers, but that will require a fair bit of the Hub backend code to be re-written and we've never really had the spare cycles to work on that. So we're still likely a while away from either of those currently, but thought it worth a mention.

Further questions?

I hope that answers your immediate questions. If you need further info, or have additional questions, please do not hesitate to post more and I will respond ASAP. I try to respond to posts on the forums every day, but it usually at least a few times per week. It's rare that I would go more than a week without responding to a post.

ClayB's picture

Thanks for the essay :)

I've attached (I think, see below) some jpgs of one year of usage concerning our webserver (currently a Turnkey Lamp Stack virtual appliance that backs up to AWS using TKLBAM.

I hope this will provide a more detailed look at our server and allow for more details as to what you would recommend we move to if we make a move to the cloud.

For even more details... the server itself does nothing but serve websites. We currently have 8 sites in total. Five (5) of the sites are WordPress sites. Two (2) of them are Joomla sites. The last one is a very old site running CodeIgniter PHP Code.

There's is always a possiblilty that we add more sites over time. We are a Local Government, Non-Profit that servers the community and could potentially host sites for different cities or communities in our area.

You can probably tell from the jpgs, but the sites don't typically see too much traffic. No ecommerce or anything like that. Mostly informational sites concerning the local community.

On that note... I have no idea what caused the spike in early June but it has since been brought back to normal.

Based off of this information, which direction would you point us as far as moving the server to Turnkey Hub? 

Jeremy Davis's picture

Ok, ready for another essay...?!

Looking at the graphs you've posted, it looks like over the last year, your server has been using very few resources and the traffic is also pretty low. If you remove the last month or so, I'd say that a micro may well be enough for your purposes. With the last month or so usage though, I'm not so sure.

The spike in CPU usage over the last month or 2 may be worth looking into further. On face value, it appears that your VM may be topping out on the CPU resources it has been allocated (the top of the graph looks flat suggesting that it's hitting the limit of available CPU resources).

Unless that corresponds with some known specific additional workload(s) that have been running, it may be signs of an issue. I guess there is also the possibility that some other VM running on the same hardware is interfering with the validity of your results? Either way, if I were you, I'd be keen to understand why the massive and consistent increase in CPU load.

Does it have a single (v)CPU or does it have multiple? (I'm guessing just one). Assuming that the recent increase in load can be explained, then I'd be inclined to add an additional (v)CPU (if possible) and see if you can drop the average usage down to a reasonable level.

I say that because as I noted, the t2 family of AWS instances have "burstable" vCPU performance and have a "CPU credits" system. Essentially what that means is that while your server is running below it's specified limit (t2.micro is 10%, t2.small is 20%, t2.medium is 20% x 2 vCPUs) then your server accrues "CPU credits" (up to a maximum balance). When it runs above that limit, it uses your accrued "CPU credits". If/when your credits reach zero, your server vCPU is throttled.

FWIW, in the previous t1 instance family, the throttling was instantaneous and savage. If a t1 server was throttled while under significant load, it would create a vicious circle where the only way to recover the server was to reboot. AWS have improved the way the throttling works in the t2 family of instances, via throttling that ramps up more slowly ("CPU degrades gracefully over a 15 minute window") so isn't quite so savage. So long as a t2 server generally runs under low load, even if it does hit the absolute limit and get throttled, it will likely recover without manual intervention. Although it will still have a significant impact on user experience if it gets throttled too often. You can monitor this via CPU credit monitoring.

Another really important thing to know would be how much RAM your server has allocated. The RAM graph appears to be in percentage used, rather than volume used. t2.micro has 1GB, t2.small has 2GB and t2.medium has 4GB.

At the end of the day though, the only way you will know for sure if using the Hub and AWS will work for you, would be to do some real world tests. I suggest that you get clarity on what sort of ongoing running costs budget you have to work with. That will give you the upper limit of how far you can go. I'd also ensure that you have something of an agreed budget to do some further explorations and real world tests (including your time).

Once you know where you stand financially, then either do some rough "back of the envelope" figures, and/or plug some numbers into the AWS calculator. Then you will have some ideas about your absolute upper limits. Personally, I'd be inclined to give yourself 10% headroom on your budget (just in case). I would then start exploring below that limit with an "on demand" instance. E.g. if your long term budget can afford a one year "reserved" t2.medium; start by spinning up a t2.small "on demand" Hub instance.

Whilst "on demand" pricing will cost you a fair bit more in the short term, you can back out at any time without ongoing costs. Once you are happy with the performance, you can purchase a reserved instance to bring your running costs down. In your scenario, I'd personally recommend a 1-year "reserved" instance. A 3 year "reserved" instance will save you more, but you will be locked in for 3 years, so won't have the flexibility of changing server size if your load changes. Obviously that will depend on your anticipated usage though. Perhaps a 3 year reserved instance makes more sense?

So long as you go with "on demand" pricing during your "exploratory" stage, worst case scenario, you can back out entirely and nothing is really lost (other than your time and the relatively small amount of money spent on AWS and the Hub). If you purchase a paid Hub plan and decide to cancel prior to the month ending, please feel free to get in touch via support for a pro-rata refund (changes between paid plans automatically make pro-rata adjustments, but cancelling back to free doesn't).

One other thing that occurs to me, is that it may be worth considering splitting the workload between your existing server and a small (or even micro) Hub instance. It may be possible to extend the life of your current local VM by moving just part of it's workload to the Hub?

Sorry that I still can't give you any really specific advice, but really, real world tests are the only way that you can be completely sure of how things will work.

A final point to keep in mind is that AWS servers are commonly targeted by hackers. That should not generally be a huge concern, but it's worth keeping in mind. PLEASE make sure that you set really good passwords! Particularly for your Linux root user account (i.e. SSH password) as there are bots that constantly scan AWS servers trying to log in via brute force attack via SSH. Best practice is to disable SSH password login and only use SSH key-pairs for authentication via SSH. It's probably also worth considering running SSH on a different port (it defaults to 22). Although please don't change the port and think that would protect you if you have a crappy password! "Security by obscurity" (e.g. using non-default ports or non default usernames) can add a layer of additional difficulty for hackers, but should NEVER be used instead of proper security measures (such as setting a good password and disabling SSH password login). I should probably do a blog post on that sometime soon!

Good luck with it all!

Jeremy Davis's picture

When I posted the other day about "one of my favourite" 3rd party AWS price comparison sites, I actually got confused. This is my favourite one! And the one I intended to link to! Apologies about that.

Add new comment