For those of you who need cross-region connectivity, there are a couple of ways to do it:
1) Create an OpenSwan (or OpenVPN, or whatever) tunnel between two endpoints in each region and set them as gateways.
2) Spin up a software VPN (like Vyatta or Sophos UTM) in VPC 1, and use it to connect to a VGW in VPC 2.

Personally I think the second method is better, because it allows you to actually reference IPs on both sides with Security Groups. On the other hand, there are no free software VPNs from a trusted vendor (Vyatta has a community version but they don’t release a build of it on the AWS Marketplace).

To illustrate what I’m talking about WRT the IPs, consider the following setup – let’s assume I want to do DB replication from a master in us-east-1 to a slave in us-west-2:
VPC 1 (us-east-1): 10.0.0.0/16
IPSec gateway 1: 10.0.0.3
DB server 1: 10.0.0.4

VPC 2 (us-west-2): 10.1.0.0/16
IPSec gateway 2: 10.1.0.3
DB server 2: 10.1.0.4

Now, if I set up connectivity between the two IPSec gateways, I can set up the replication from DB server 1 to DB server 2; DB server 1 will connect to 10.1.0.4 and DB server 2 will see that connection as coming from 10.0.0.4. All good.
However, from the perspective of the AWS Security Groups, there are two sets of communications going on that have nothing to do with one another: according to VPC 1, DB server 1 is talking to IPSec gateway 1, which is talking to IPSec gateway 2. According to VPC 2, IPSec gateway 2 is talking to IPSec gateway 1, and IPSec gateway 2 is talking to DB server 2. They’re not able to see the big picture, and unfortunately that means that we can’t create Security Groups to properly set rules – rather than having a rule that says “DB server 2 can be reached by DB server 1″, we need to specify that “DB server 2 can be reached by IPSec gateway 2″. Unfortunately, ANY traffic that’s coming over the gateway will look like it’s coming from IPSec gateway 2, so we’re effectively opening up the DB server to everything in VPC 1 that’s able to use the IPSec gateway.

Nonetheless, setting up a IPSec tunnel between VPCs can be a viable choice for customers looking to save some money or who are uncomfortable leveraging 3rd-party tools in their environment.

Interested in a CFN template to automagically do this for you?  Shoot me an email and let’s talk!

Here’s a cool trick you can do with S3: you can generate a URL with an “expires” timestamp that will only be good until that timestamp.
Although there are a number of potential uses for this, I generally do it instead of emailing attachments; many enterprises still impose ridiculously low limits on their employee email accounts (I’m talking like 100MB total), which can quickly be sucked up by large email attachments.

Right now there’s no way to do this from the CLI, but it’s really easy to do in a Python script.

#!/usr/bin/env python

# Create a time-bombed URL from an S3 object
# Parameters: s3_url [timeout]
# timeout defaults to 1 minute if not specified
# requires the boto module</em>

# 2014 Staunch Technologies, LLC
# See http://www.staunchtech.com/?page_id=53 for licensing information

import sys,re

try:
testArg=re.match('s3:\/\/',sys.argv[1])
except:
print ("usage: " + sys.argv[0] + " s3_object ttl_in_sec")
sys.exit(1)
if not testArg:
print "need a valid s3 object as arg"
sys.exit(1)

try:
sys.argv[2]
expTime=int(sys.argv[2])
except:
expTime=60

(bucket,key)=re.split('/',re.sub('^s3:\/\/','',sys.argv[1]),maxsplit=1)

testKey=re.match('\w',key)
if not testKey:
print ("something wrong with this url - I have a key of: " + key + " - bailing")
sys.exit(1)

from boto.s3.connection import S3Connection
# If you're intending to hardcode your credentials rather than have them as variables then you would replace this line with:
# s3=S3Connection('your_aws_key','your_aws_secret')
s3=S3Connection()
url = s3.generate_url(expTime, 'GET', bucket=bucket, key=key)
print ("Generating URL, good for " + str(expTime) + " seconds")
print (url)

Note that the majority of the script is just validation – the magic actually takes place in the last 5 lines or so.
So, if you run this script with parameters of “s3://your-bucket/objectname 3600″ then it will generate a signed URL to download s3://your-bucket/objectname that’s good for an hour. Note that s3://your-bucket/objectname does NOT have to be public for this to work (in fact, if it were public then we wouldn’t need this script in the first place!)

Hope this proves useful to you!

Well, I know it’s not NY yet, but I’m already making a resolution to blog more.  I am constantly coming into situations where I or a customer asks “how do I…” and I always tell myself I need to write about it, but I never do.  But this year will be different!

So, to start off, a few things I want to start writing about:

• AWS “weak points” and how to work around them (see previous post about NAS)
• Actual HOWTOs, where existing documentation is weak or seemingly incomplete.
• Really cool solutions I (or someone else) came up with.

Hopefully this NY resolution won’t go the way of so many others.

One of the biggest pain points of EC2 is that there is no easy drop-in replacement for a HA NFS server.  In a typical web server setup you would have your content living in a shared location, and hopefully in your production stack that location is redundant.  A simple setup might just be a clustered NFS server, which involves a shared IP and (ideally) a shared disk.  Larger organizations tend to use dedicated NAS solutions like a NetApp or EMC product (or one of many, many other possibilities).

Unfortunately, none of these are easily possible with EC2, and I’m still amazed that Amazon isn’t offering NAS as a service (NaaS?) – it seems the one glaring omission in their comprehensive smorgasbord of products.  So, what are the potential solutions?

1) Fake a HA cluster using DRBD and an elastic IP.

I don’t like this solution for a few reasons: first, I’ve been burned by DRBD too many times in my career.  Every time I’ve implemented it, I’ve found that it _sometimes_ will cause a kernel panic on a node when the partner node fails.  Admittedly, the last time I checked it out was about 5 years ago, but I think I’ll save revisiting it until I have no choice (if that day ever comes).  Second, using the elastic IP solution means that you’re going to be down for roughly the EC2 internal TTL, which could be 10-20 minutes.  That’s not an acceptable amount of downtime for me.

2) Set up dual, replicated (somehow) NFS servers, one per zone, with servers in each zone pointing to their respective NFS server.

There are a couple of problems with this:  first off, you still need a way to replicate everything, but let’s assume for the sake of argument that that’s not an issue for your environment.  You’re still consuming 2x the required disk, and you’re creating a SPOF for each zone.  Overall, not something I like.

IMHO, there’s no good way to replicate your standard NAS setup.  I’ve had lots of discussions with colleagues and with Amazon’s own solutions architects about this, and there’s really no good one-size-fits-all substitute for it.

So, what to do?  Well, unfortunately, the answer is “it depends”.

If you’re just getting started out (i.e. you’re not migrating a NFS-dependent solution to EC2), then you have lots of flexibility.  Here are some examples:

• Store everything in S3 and use s3fs to remotely access it from your web servers.  Unfortunately this can be pretty laggy, especially if you don’t have any sort of caching layer (like a CDN or just a local caching proxy).
• Same as above, but separate static and dynamic content and serve the static content straight from S3.  The separation can be a bit of a pain but it’ll speed things up considerably.  Of course, if you have lots of include files or other objects that are used in generating that dynamic content, then things can still get pretty slow.
• Use S3 as a “source” and periodically sync it to clients, and have clients use local media.  This works great except that it’s tough to manage and using something like s3sync can be very resource-intensive if you’re constantly doing it. This means you’ve got to write a system to manage your deployments.
• Use S3 for your static content and use a source control package for your dynamic content.  This works great, but of course you need to have a solid deployment process, and you’ll have to come up with some creative deployment solutions if you want all your servers to get updated simultaneously.

Of course, for a lot of larger organizations (or those who don’t want to think about separating out their content), you effectively need to come up with a replacement for NFS.  I’ll get into that in another post, but the short answer is gluster.

There are a few labels that I assign to myself: devops guru, devoted husband, musician, etc.  Some words that wouldn’t fit into that category: extrovert, entrepreneur, salesman.  With the advent of Staunch Technologies, I’m trying to add all three of those to my tag list.

So, why on earth would I decide to do this?  Mostly because I see the need, and I know that I can fill it – the problem is getting the word out about myself.  So far I haven’t done much other than try to maintain new connections, revive old ones, and start signing up for meetups.

A few other labels that don’t apply to me: stubborn, proud, closed-minded.  If you have suggestions, I’d love to hear them.

–Nate