Running A Small Web Site In AWS

I moved from a bare-metal 1&1 server to AWS a few years ago, and it was an excellent decision. Generally, I now have more control over…
Photo by UX Indonesia on Unsplash

Running A Small Web Site In AWS

I moved from a bare-metal 1&1 server to AWS a few years ago, and it was an excellent decision. Generally, I now have more control over running my site, and things like moving disks around and backing up are so much easier (and often less expensive). I can also easily scale up and scale down.

My Web site has now grown within AWS over the past few years, and I now have around 1.5 million users per year, and with over 36 million requests per year (and growing each day, as more people get into cybersecurity and want to learn more). So, over time, I learnt a few things about reducing costs, and saving time, and I have a few tips here.

Overall, I receive many requests to put advertisements on my site, but have rejected each one, as I want to keep it free to use, and support free access to education. Also, I do not have a team of Cloud engineers, and it’s just me administrating the site. The costs of running the site, are thus mine.

Scripting

While you can do most things in the GUI that AWS provides, the real power of AWS lies in the CLI (Command Line Interface), and where commands can be remotely run. I tend to use T3 instances, and often have to ramp up the performance of my Web site for lab requirements. For this, it is fairly easy to stop and instance, and then change the instance type — in this case to t3.medium — and the restart:

aws ec2 stop-instances --instance-ids i-012345678
aws ec2 wait instance-stopped --instance-ids i-012345678
aws ec2 modify-instance-attribute --instance-id i-012345678 --instance-type "{\"Value\": \"t3.medium\"}"
aws ec2 start-instances --instance-ids i-012345678

Normally, this can take less than a minute to execute, and so the downtime is not that long. If we need a reboot, it’s then just:

aws ec2 reboot-instances --instance-ids i-012345678

AWS supports these CLI commands on most operating systems, including Mac OS and Windows.

Upgrading VMs

If you want to migrate your system from one operating system to another, such as from Windows 2008 to Windows 2019, it is probably better to do a manual upgrade, and where you install the operating system, and carefully add the services and data. I have found that the tools to do automatic migration in AWS and also from Microsoft are poor at doing this migration, and it is often costly in your time and in costs. A fresh install from an AMI is sometimes the best way to go. Then you know your core starting point and can add new services.

VM instance type

Your EC2 costs often boil down to the cost of running an instance, and the volume/snapshots. For me, the compute cost is around the same as the disk costs. With EC2 instance types, the cost model again is fairly simple, and where an update from t3.medium ($0.0418 per hour) to t3.large ($0.0835 per hour), will add around 4GB memory, will double your EC2 instance costs per month. In most cases, it’s a doubling of costs on an upgrade from the next instance up:

Thus, t3.medium for a day will $1 per day, and $30 per month (if the month has 30 days, fof course). A move to t3.large will double this cost. Windows servers have a higher hourly cost than Linux ones. So, monitor usage, and find a good balance of CPU cores and memory.

Volumes and Snapshots

The usage of volumes and snapshots are fundamental to the overall cost of running AWS, and it's a fairly simple costing model. Volumes cost twice as much as snapshots. With a volume, you can add a disk to a running server, where a snapshot is a backup of a volume and would need to be converted back into a volume to month onto a disk. You either pay $0.10 per GB per month for a volume, or $0.05 per GB per month for a snapshot. Thus a 250GB volume will cost $25 per month for a volume and $12.50 for a snapshot.

So, if you are not using a volume, perhaps make a snapshot of it, and delete the volume. It is easy to recover the volume from the snapshot at a later time. A snapshot costs half of the price of a volume. Remember to make sure the snapshot is in place before you delete the volume.

Snapshots

Snapshots are great for backups and in restoring from a previous instance. Again, you pay-as-you-go, and you only pay for the data that has changed since a previous snapshot. So, if you have a 250GB disk, and only 10GB has changed since the last snapshot, you only pay for the difference. But, it’s easy to do too many of these snapshots, so sometimes it’s best to delete a few intermediate ones, and to define major snapshot points where you consolidate into a new full snapshot, and then create an incremental one from there. Snapshot cost half as much as volumes, but the costs can mount up if you have a few volumes.

Volume sizes

You pay-as-you-go and disk storage can be a significant part of the monthly bill, so it is often best to trim the disk sizes to save costs. A 500GB volume is likely to cost $50 per month, but 100 GB one reduces this to $10. In most cases, you can grow a volume at a later time, but it is probably best just to find an optimal disk size to allow for new services to be added.

Cloudflare

I can’t recommend Cloudflare highly enough for buffering a Web site. For one it allows for a caching of the content, so that content can be sourced from Cloudflare rather than from the AWS host site. It also allows for bots and malicious activity to be checked for, and, hopefully, blocked. While corporate sites will probably use smart firewalls for these types of services, for a small site, Cloudflare is free to use (within limits), and should give good support for firewall rules.

Lambda

The setup of lambda code is fairly easy in AWS, and can significantly reduce costs of running code in servers. Think carefully about things that can be scripted, and consider moving some code away from servers and into AWS Lambda code. The Python examples are particularly easy to copy-and-paste from standard examples, and then modify. AWS is generally good with their documentation.

Conclusions

If you run a corporate AWS infrastructure, you probably run lots of automated tools and run load balancing. But, if you run your own Web site, it probably helps to simply think about your setup, and learn to have a good balance of costs against backup and performance. For costs, I just think about a baseline cost that settles down, and any upgrade just doubles that for a given period of time.

But the power of the public cloud is almost endless, but watch those costs.