One Hour to Save the Data

I needed to build a disaster recovery solution. The goal was to get DynamoDB data backed up to a different region on a continuous basis. A one-off export wouldn’t cut it. It had to be reliable and run on its own.

The approach

DDB has an export API that allows customers to move data to an S3 bucket which can be in a different region. While we could have run this manually we needed something that was reliable and continuous. At least as much as possible.

I decided to deploy a lambda that ran at scheduled times. Exports the tables into an S3 bucket. The lambda had to accept a list of tables and a destination. Ideally this solution was repeatable for future applications (which we needed the next day). A config driven approach deployed via a pipeline seemed ideal.

Building it

I created a CDK project and told Kiro to start a spec. I needed a lambda, S3 bucket, IAM roles and a schedule. Some alarming and monitoring would be nice too, but nothing crazy. Oh yeah, and I needed the inputs (table names, buckets) to be created based on a config. That way the CDK stack can be deployed over and over with different parameters.

Writing a spec with Kiro is an iterative approach. It starts out, gets things right and some wrong. You read the spec and make corrections. And when you’re happy you tell it to go implement. Then you check the implementation and most of the time it’s good. Sometimes you tweak in a few spots. The spec took a few minutes to write and so did the implementation. A deployment to preprod to make sure the whole thing worked, a review, and out to production. Total time about 1h, maybe 90 min.

Built for reuse

The config-driven setup meant that pointing it at a different set of tables and buckets took a config edit. That’s why a second region came together the next day in minutes. Same stack, different parameters.

What I did vs. what the AI did

Kiro acted like a personal assistant. It took my thoughts and wrote them into a spec. Organized them (I can be all over the place sometimes), and when I was ready it implemented everything. It confirmed with a successful build.

Kiro didn’t know we needed cross region replication or which tables we needed to save, and it wouldn’t have thought to make the whole thing reusable and configuration driven. All that came from the experience of the human operator. But a human could not have built something this complete this quickly, or at least this one couldn’t have.

One hour

With the help of AI I was able to build something quickly and with minimal issues. Generally those two things are in tension. It was successful because of the help of the friendly ghost (Kiro) and the combined experience building applications and knowing the underlying system.

AI is good at exactly that part, taking a clear brief from an experienced operator and turning it into working infrastructure. Knowing how to use it is the difference.