Updated 28-Jun-2024
What I learned in migrating from CentOS on Linode to Amazon AMI Linux on EC2.
Note: Amazon Lightsail is probably a better comparison, but it is not available in the region we need it in, so EC2 is required for now.
Update: Lightsail is now available in more regions.
VPS Hosting and Operating System
A change of VPS providers is generally not such a big deal, unless one is dependent on proprietary tools of the previous provider. In the case of Linode, there are some nice graphs, and they have the Linode Shell (Lish) that is handy when things go south. But moving to Amazon is like entering a different galaxy, one that has alien technology. Sure, in the end you've got a web server, an email server, a vpn, etc., but configuration tools and where things go can be a bit of a learning curve.
Linode to AWS
I've been aware of Linode for a decade, but first started seriously kickin the tires in April, 2014. In November, it was time and I began installation, configuration, and testing, with production sites up in early December, 2014. At 2.5 years, this is the approximate time span for moving to a different platform (in terms of my Sysops habits). Actually, though, I have been content with Linode. The precipitating event to migration was a requirement for a location in Canada, and also an unacceptable amount of downtime on a different VPS host located there. Taking a closer look at AWS offerings, and especially getting a better understanding of billing, convinced me this is viable platform for my price/performance needs.
CentOS vs. AMI
Amazon Linux AMI is more or less a fork of RHEL and/or CentOS, depending on whom one reads. The main points are:
- AMI lags a bit behind CentOS, which lags a bit behind Fedora
- AMI may or may not yet have
systemd(as of June 2017 it does not, treat the system as CentOS 6.x) firewalldmay or may not work on AMI, some reports are it does not yet (more on this)systemctldoes not function out of the box, instead useserviceand chkconfig
Firewalling
AWS Security Groups as configured in EC2 are managed in a GUI that is akin to iptables/firewalld.
IP Addressing
Unlike most VPS hosts, public IP addresses are not doled out automatically, at least not permanent ones. For that, one needs to provision an elastic ip address. A small number are available per account per region (5), but there are charges for outbound traffic. Also, it is important not to have elastic ip addresses assigned to unactive instances, as there are additional charges, as well as if multiple elastic ip addresses are assigned to a single instance.
EB vs. EC2 vs. Lambda
There are other options to explore with AWS (just to mention):
- Elastic Beanstalk, which is kind of self-provisioning (but need stateless design)
- Lambda which is a truly serverless environment
- Note that Lambda can now run on IOT as Greengrass Core with Lambda Functions
AWS Billing
It is vital to understand how Amazon bills out various services. Not paying attention can easily mean a lot higher costs, without necessarily more services. Another aspect of billing is the apparent greater efficiency of Amazon Linux AMI on EC2, which means that greater resources are not needed (and as is the case with much of the rest of the hosting universe, those numbers that are provided are not real, due to oversubscription.