A client needed a prototype server that was low cost, had potential to scale, and whose management could easily be transferred. We needed a single linux-based server that we could turn on and off for security and to control cost. Amazon’s EC2 service fit the bill well, so we set up an account and I got started on implementation.
A few of us at Avalon Consulting, LLC had already used EC2 for a couple other clients. It seemed easy enough and I was eager to get my hands dirty and see how this service really worked. I thought this would be a simple procedure, but like any project we hit bumps in the road that made it more of a challenge than expected.
The first thing I did was create the instance, being sure to select the proper options so that billing was credited properly. This is when I hit the first issue: all data was destroyed if the instance was stopped. After much research I found that I had to create an instance from an Elastic Block Store (EBS) Image. Once I created the instance I needed to attach a separate EBS volume and figure out how to mount (attach) it to the instance.
Having resolved those issues, I hit my second issue: the DNS name assigned to the instance changed every time it was stopped and started. Since we were using this internally, we were hoping to avoid having to give it a proper domain name and just use the name EC2 assigned it. The solution to this was to get an Elastic IP address. Once EC2 assigned us an IP address, we found a domain and changed its appropriate entries to point to our new site.
This doesn’t sound like too much of an effort, but two things made it difficult. First, documentation is not easy to find or follow. There was many references available, but bringing everything together for what I thought was a basic implementation required understanding a lot of the system as a whole. For example, they provide a Getting Started Guide, Developer Guide and User Guide among others. Although there is a good amount of information, some chapters in one guide I would have expected to be in another, so every time I go back a refer to them I have to fish through each one to find what I’m looking for. Buried in one of them is a link to the PDF that I needed to create an instance based on an EBS volume.
The second difficulty was cost. The model EC2 and most cloud-type services offer are based on what services used and at what quantity. Estimating a monthly cost is not very straight-forward. Some of the costs to consider:
- The instance(s) themselves
- Bandwidth used
- An EBS volume
- I/O access to an EBS volume
- Number of API calls to the account
- Static IP address
Some of these items are not a simple cost model. For example, there is no cost to assign an IP address, but if it is unused, such as when an instance is not running, there is a small cost per hour. The cost of an instance depends on the number and type of CPUs and RAM available for the instance. Hourly costs can be reduced by purchasing a “reserved instance.”
So what did I learn from this experience? I learned the basics for establishing an EC2 presence. I also learned that an administrator’s job is not going away any time soon. One of my coworkers had no experience with cloud services and asked how one would troubleshoot application issues. His assumption was since this was in the cloud, a lot of administration had been relinquished to technology. Setting up an EC2 system and reading the documentation assumes a certain level of proficiency with network and system administration.
Overall this was a good experience. The learning curve was a little slow, mostly due to documentation. Estimating costs is not an exact science. But EC2 and other cloud services have a lot to offer, and can offload hardware and data center woes while allowing the customer full control over their systems.