Tag: amazon ec2

Since we began to invest time into developing skills in EC2, we found Elastic IPs to be indispensable in re-hosting applications in the cloud. It’s become clear this is the coolest thing we’ve had a chance to play with in all our cloud providers.

I’ll run a scenario through you:

When we provision on Rackspace instances and DigitalOcean droplets the interfaces on these instances were assigned public IP addresses, and we couldn’t move those around very easily at all.  Potentially support could do it for you  but there would be a particular set of circumstances that would need to be in place for this to be successful, odds are slim to none.

When hosting websites for some users, operations decided it would be practical to deploy services to individually small instances or droplets. This works for some time but when you’re operating 100 instances and your monitoring tools report that utilization on %80 percent of the instances is next to none, you start to consider consolidation of costs since you have alot of unused resources, what’s the sense in maintaining the cost for those resources? The cloud is not about that.

The consolidation of costs is attractive, imagine consolidating 80 different web servers into a 3 node cluster, at a minimum, and this simple operation will reduce your cost multiples. Here is a breakdown.

With 100 instances running 100 websites:

(100 Instances * X Price)  where X is 15.
Total Cost: $1,500 monthly spend.

With 23 instances running 100 websites:

(20 Instances * X Price) + (3 Instances * Y Price) where X is 15, and Y is 100.
Total Cost: $600 monthly spend.

Do the math, it makes sense take on a little risk and your teams operation results can improve dramatically. I’ll talk about the risks that affect us in another post regarding this, but for now let’s focus on the benefits.

Ok, so that seems interesting, how would we go about doing this? Where’s the headache in all this?

DNS.

First and foremost, your headache will be in DNS.  Pointing domains to new IPs is a process that can be smooth and painless or fraught with issues, miscommunications, typos and angry emails.

In the traditional way with Rackspace or DigitalOcean, we’ve had to coordinate changes with clients on their respective Registrar accounts, and there’s the typical 24-72 hours propagation disclaimer we still pass around today even though most ISPs use DNS TTL values of 24 hours or less these days.

In the Amazon Elastic IP world, we’d request 100 IPs, and assign them to any individual web server we wanted to.  If we had 100 t2.medium instances operational, we’d have 100 Elastic IPs attached to them.

Now, when it’s time to consolidate into our 3 node cluster, we have the nifty ability to assign multiple elastic IPs to an instance. Instantly, a DNS problem becomes moot, it’s now something you can handle internally and respond faster.