Resources in AWS

Introduction

NOTE: This documentation is under construction. Lots more coming.

Once you've got your development environment up and running and you're happy with it, you will eventually want to move everything from your local machine up into AWS so that other people can enjoy it too. This guide will help you to migrate the various pieces into the cloud.

Any time you create new resources in AWS, please be sure to check the pricing for your region and make sure you understand how you will be billed. It's no fun to get a surprise in your bill at the end of the month!

This guide will assume that you already have some familiarity with how to run Cloud Formation templates.

DynamoDB

The database is one of the easiest pieces to move. There is a Cloud Formation template in /cloudformation/dynamodb.yaml with a template for creating a new DynamoDB table with the required indices and attributes for Agony Forge. It is set to be an "On Demand" table, meaning you only get charged per request. If you don't use it, it will be nearly free. The only parameter for the template is the name of the table. You can pick any name you like.

Once you have created the table, you'll need to tell Agony Forge how to access it. In mud.env there are a few variables related to DynamoDB that you'll need to edit.

Variable Name	Description
MUD_DYNAMO_REGION	The region where your DynamoDB table is.
MUD_DYNAMO_ENDPOINT	If you are using DynamoDB in AWS, you can comment this variable out. It's only important if you want to use DynamoDbLocal instead of the real one.
MUD_DYNAMO_TABLE_NAME	The name you picked for your DynamoDB table.
MUD_DYNAMO_GSI1_NAME	This should always be gsi1.
MUD_DYNAMO_GSI2_NAME	This should always be gsi2.

If you are running your MUD from inside AWS, such as in ECS, Kubernetes, or on an EC2 instance, it will already have credentials and an IAM role for gaining access to other AWS resources. It is beyond the scope of this document to explain how to manage IAM roles, but the role your MUD has will need to have permission to read and write to your DynamoDB table.

You can run your MUD locally but still use a DynamoDB table in AWS! The best way to do it would be to create an IAM user that has permission to read and write to your DynamoDB table. Create an "access key" for that user in IAM, and copy the access key ID and Secret into the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables in your mud.env. The advantage of not using DynamoDbLocal is that the database will survive even if you bring the MUD down with docker-compose down, and you won't have to recreate your character every time.