This post may apply to you if you want to reduce infrastructure expenses. Though, I bet everyone identifies with that.

But how about this: you're paying for a marketing website/some CMS server, and you are not actively doing anything with it (and really don't plan to). You should be thinking about infrastructure expenses because you're essentially throwing money away paying for resources that just flat out are not needed.

But... how do I host my website, you may ask, and not spend such money on servers?

Well, there's this wonderful concept called serverless applications. They come in many different shapes and forms. Various cloud providers, especially AWS, have offerings specifically for serverless applications. AWS has, to name a few, Lambda, DynamoDB, Aurora Serverless, SQS, and S3.

S3, specifically, is the answer for the marketing site use case. If you have a Wordpress site you are not making any edits to, there are a variety of free plugins that can take your Wordpress site and convert it into straight HTML/CSS instead of PHP. You'd take all those files and put them onto an S3 bucket set up for static website hosting.

After that, you would set up a Cloudfront distribution to point to the bucket, using the SSL Certificate/domain of your choosing. Then change DNS, and you're done.

If you use AWS's calculator, you can approximate how much this would cost monthly versus your server/database setup. Part of the cost reduction is that you're paying only for resources you're directly using or requesting. With S3, you pay a little bit for the storage itself, and the rest of it is request-based. Pay for what is actually used rather than having to pay perpetually for something despite it being requested or not.

The plus side to this is also that you don't have to worry about maintaining and monitoring your server (which is a monthly cost/worry in and of itself). It's less headache/worry all around when the website is on S3/Cloudfront hosted serverlessly.

Both the pay-for-use and maintenance points apply to databases as well, which I alluded to in my Amazon Aurora Serverless post. You could reduce costs by switching to AWS's Serverless offering if you couldn't go fully static with your website but needed the variable scaling for your database. You don't have to pay for the high tier, and you don't have to worry about the site going down if you're on the low tier. A nice... happy... medium.

S3 for static websites and serverless Aurora are the "easy" switches to make to reduce spend month-to-month. There are other, bigger jumps that could be done to go fully serverless: converting an application to be serverless and hosted on AWS Lambda, swapping to use SQS from some other queuing system (perhaps paying for Redis/Memcached to store queue), and so on. It's a paradigm shift... sometimes made easier by the tooling provided by AWS, and sometimes still requiring you to rethink your application architecture. If you're contemplating rebuilding or building a new application, definitely seriously think serverless—you may save money in the long term by doing so. You can move away from server management and let someone else deal with it and just think about the code.

However, something to keep in mind: this does not remove the need for a "DevOps" or Sys-admin role entirely, nor the costs associated with it. Instead of managing servers, you're managing cloud providers and infrastructure-as-code codebases such as Terraform. The type of work being done is different, but work still has to happen. The cost savings are in the actual resources and some management, but you still need to have a management framework for it. Overall there may be less work and it could be structured differently, but the role is still needed.

What serverless is really offering, instead of eliminating the DevOps/Sys Admin role, is the pay-per-usage aspect... which sells itself.