Linode vs. Amazon EC2, revisited
After my dedicated in-house server (hosted at my employer's server room) went offline after a string of local power outages in October last year, I had to get some of the services (mail, etc) migrated from this server quickly. I already have 3 Linode servers, two in Dallas, and one in London, but due to storage space limitations, I found that Amazon EC2 had the "best" option at the time. My server had about 1.5TB storage space total, spread across 3 data drives, and probably had half of this in-use. Since most of this was already backup data, I could limit myself to a 200 GB instance with Amazon, just to get the basic services running again.
Mind you, this server was something I built from individual components back in 2005, and since that time, I had "only" upgraded with more disk space, and reinstalled Linux once (about half-way through the lifetime). Back in October, it simply would not power on properly; I could see power lights on the motherboard, but it didn't boot up, not even with the motherboard startup screen.
Fortunately, I had about weekly backups of most websites, DNS zone files, Apache configurations, copied to one of my Linodes (which were kept for 2 weeks at a time), so I could at least have a baseline of services going.
Since then, this EC2 instance had been running somewhat fine, until I got an e-mail from Amazon on Friday last week. A quick extract of that e-mail (specific account details left out):
> We have important news about your account. EC2 has detected degradation of the underlying hardware hosting one or more of your Amazon EC2 instances in the eu-west-1 region. Due to this degradation, your instance(s) could already be unreachable. Running instances will be stopped or terminated after 12:00AM UTC on 2015-06-06.
[…]
How does this affect you?
If your instance’s root device is an instance store volume, the instance will be terminated after the specified retirement date. When the instance is terminated, all data stored on the instance store will be deleted and can’t be recovered. Depending on the nature of the hardware degradation, you may be able to connect to your instance and migrate any data from instance store volumes. Unfortunately, in the case of disk failure the instance store data cannot be recovered.
If your instance's root device is an EBS volume, the instance will be stopped after the retirement date, and you can start it again at any time.
In either case, since EC2 instance store volumes are physically attached to the host computer, any data on these volumes will be lost when the instance is stopped or terminated.
In essence, since the underlying hardware for my EC2 instance's storage volume got degraded, I'm forced to manually create a new instance, migrate all data to the new instance, and more or less start over. And with only the "Basic Support" included with my AWS account, I don't get access to technical support.
If hardware is degraded with Linode, I would've been notified about this as well, and be offered to fully migrate my whole server to new hardware. And as part of this process, I can choose an earlier migration time, or be automatically migrated at a certain cut-off point. In addition, the whole Linode migration process is fully automatic, so I'd only have to verify that the server has fully restarted. My server would've been out of contact for only an hour or two - just enough time to shut down, move over all data, and reboot.
The notification with details from Amazon only made me exclaim a few choice NSFW words, since it would involve a lot of extra work, which wouldn't happen if this was with Linode.
Let's compare just the stats, though, shall we?
Amazon EC2:
* Linux t2.micro (1 vCPU, 1 GB RAM) in region eu-west-1 (Ireland)
200 GB EBS volume
Data transfer comes in addition, but for the sake of comparison, let's guesstimate 100 GB per month
Elastic IP address (required for reverse DNS and increased e-mail sending limits, and to get out of Amazon's "dynamic IP address pool")
Included Basic Support (Account, Billing, Service limit increases - no technical support included)
Cost: around $37 per month (source: AWS Simple Monthly Calculator)</list>
Linode:
* Linux 2048 (2 vCPU, 2 GB RAM), any region (closest would be London)
48 GB storage
3 TB data transfer included, pooled together with other Linodes in the account
Reverse DNS included
Great support included (first response usually within 15-30 minutes of creating a support ticket), account-technical support included
Cost: $20 per month</list>
Sure, I get less storage with Linode, but everything else is fantastic, and much better than Amazon. Even if I reduce EBS storage with Amazon to 50 GB, I end up at a monthly cost of a little over $20, which will vary with data transfer (increasing calculated data transfer to 1 TB/month will bring that monthly total up to about $29).
And, after checking current storage usage on my EC2 instance, I see about 14 GB in use, so with these issues, Amazon is really making their case for NOT using them anymore.
I still plan on using them for CDN (CloudFront and S3), but I'm seriously considering moving everything in my EC2 instance over to Linode (I have less than 1 week to decide which direction I'll take). If this is something that will happen each time hardware is degraded, I cannot be expected to reconfigure a whole new virtual server and move over data just for that. I've used this particular EC2 instance for about 7 months, and already, they're serving me this crap.
To summarize: Linode scores huge on this. Linode would never put me through this. They're "man" enough to take full responsibility for their hardware, and help me move over to new hardware with as little downtime and effort as possible.
7 Replies
Linode is great, I use Linode, blah blah blah, but lets not throw stones at AWS for poor judgement on your part?
- Les
And, I am using an EBS volume as the root storage for my EC2 instance, but basically saying "our hardware was degraded, your EC2 instance (virtual server) is screwed" is just dodging responsibility as a service provider.
Back then (October last year), I was in a rush, I didn't have time to properly determine the amount of storage space I would end up using after everything I needed was back in place, which is why I went for AWS, since Linode didn't have enough storage. Had I known that I wouldn't use as much storage space, I would've gone for Linode in the first place, and avoid this type of problem.
"* If your instance's root device is an EBS volume, the instance will be stopped after the retirement date, and you can start it again at any time."
You can reboot whenever to move off the bad hardware, or you can reboot at the listed date.
- Les
> What do you need to do?
If you can still access the instance, we recommend the following:
If your instance's root device is an instance store volume, launch a replacement instance from your most recent AMI and migrate all available data to the replacement instance, or migrate your data to an EBS volume, which you can back up with a snapshot.
If your instance's root device is an EBS volume, you can replace the instance by creating an AMI of your instance, and launching a new instance from the AMI. For more information please see Amazon Machine Images (
) in the EC2 User Guide. In case of difficulties stopping your EBS-backed instance, please see the Instance FAQ ( http://docs.aws.amazon.com/AWSEC2/lates … /AMIs.html">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html http://aws.amazon.com/instance-help/#ebs-stuck-stopping ).If you've registered the instance in EC2 Classic with a load balancer, the load balancer will not be able to route traffic to your instance if you stop and start it, due to the new IP address associated to the instance. You must deregister the instance from the load balancer after stopping the instance, and then re-register it after starting the instance. In EC2 VPC, the IP address does not change, but the abovementioned deregister and register actions will speed up the time that it takes for the load balancer to recognize the instance. For more information, see De-Registering and Registering Amazon EC2 Instances (
) in the Elastic Load Balancing Developer Guide. http://docs.aws.amazon.com/ElasticLoadB … ances.html">http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/USDeRegReg_Instances.html
So, do I just reboot at any time? Do I have to wait for the EC2 instance to automatically stop first, and then start it again? Or do I have to go through the process of creating a new EC2 replacement instance, based off an AMI I create from the already-running server/instance?
@akerl:
You can reboot whenever to move off the bad hardware, or you can reboot at the listed date.
Are you saying this from experience, or just based off the information I quoted from the notification mail?
- Les
> The good new is that I have looked over your account and I see that you have an EC2 Instance that's root device is EBS backed and scheduled for retirement. This means you can save the data on your Instance! Although I can't really give you much tech support here through Customer Service, I did find some good information that I think will help.
There are two different steps you can take to save the data on your instance.
1. Start and Stop your instance: Wait for the scheduled retirement date - when the instance is stopped - or stop the instance yourself before the retirement date. You can start the instance again at any time. For more information about stopping and starting your instance, and what to expect when your instance is stopped, such as the effect on public, private and Elastic IP addresses associated with your instance, please see the documentation here:
http://docs.aws.amazon.com/AWSEC2/lates … Start.html">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html 2. Also, you can create an EBS-backed AMI from your instance, and launch a replacement instance. For more information, see Creating an Amazon EBS-Backed Linux AMI, here:
http://docs.aws.amazon.com/AWSEC2/lates … i-ebs.html">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html All of the documentation on EC2 Instances that have been scheduled for retirement, can be found here:
which is part of our comprehensive documentation database. http://docs.aws.amazon.com/AWSEC2/lates … nt-working">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html#instance-retirement-working
I just wish that they linked directly to these guides in their initial notification, rather than providing somewhat-confusing information that I originally received.
It's back up now, but I'll still strongly consider switching this one over to Linode unless I manage to get ahold of new dedicated hardware soon…