Managing dev/staging/production on DynamoDB?

Question

We\'re starting to use DynamoDB, and want separate environments for dev/staging/production. We can\'t figure out a natural way to do this---do we just create separate AWS ac

Answer 1

I can't understand why there is'nt a AWS solution for handling DB-versions like production and test in DynamoDB!? Having multiple AWS accounts is a hassle.

It also becomes a big problem to prefix the table names if you get the items by using the c# class attribute [DynamoDBTable("Users")] and fetching the data with DynamoDBContext.Load<User>(userId);

As attributes values can't change during runtime I ended up with this soluting using conditonal compilation symbols and setting constants that can be used as the class attribute value.

public static class DynamoDbTablesConfiguration
{
        #if Debug
            public const string UserTable = "Users_Dev";
        #endif

        #if Release
            public const string UserTable = "Users_Production";
        #endif
}

[DynamoDBTable(DynamoDbTablesConfiguration.UserTable)]
public class User
{
}

Make sure you set the "conditonal compilation symbols" value by right click on project > Properties > Build > "conditonal compilation symbols".

Not a perfect solution but I don't see any other options here if I don't want to create another AWS account.

Answer 2

Amazon now provide a server that you can run locally. You can download it here.

Answer 3

Don't forget Amazon's greatly enhanced IAM for access control. It largely gives you the same benefits of separate accounts. (Separate accounts are still an option if you have want to have different levels of paid support.)

Naming wise, my preference is name.environment.whatever.

Answer 4

I don't see anything that's "above" the tables that can be created for each instance (dev/staging/prod) you have (like a relational database, which have all tables under one DB).

At the application I'm working on, we're using prefixes to the tables.

Answer 5

The standard way to manage this with any amazon products is to create separate accounts and then use consolidated billing so that it doesn't complicate the billing aspect. The thing i like about this is that you don't risk breaking the production code by accidentally running the wrong command. Obviously it doesn't help you if you're logged into the wrong instance but it still helps quite a bit.

Other uses for multiple accounts could be to manage permissions and better testing. Having the accounts separate helps testing because you can reproduce the production account 100% and turn it on and off when you need to test new features. I've talked with amazon premium support about this issue and they've said that this seems to be standard practice for the larger companies. Some of the larger companies have many accounts. At my work here we just have 3 and I find it more useful every day.