Many games on Steam store the game save files in random places around your computer. Sometimes those files are backed up through Steam itself. If they are not then you could lose your save game files if your harddrive dies or even if your save game files get corrupted. To resolve this I started working on a tool to automatically copy save game files to a separate location as a backup. This solution currently supports a folder on your file system and/or AWS S3. It will periodically search your computer for what games on Steam you have installed and copy the save game files it finds to the backup location you select. This will ensure the files are backed up. If a save file gets corrupted and/or lost you can fetch the file from your backup and put it where the game is looking to restore the file.

Problem 🔗

You have EC2 instances and you want to connect to them via AWS Systems Manager instead of using SSH/RDP and all you need is a command line interface. If you search AWS IAM’s managed policies for “SSM”, you will find lots of policies. Which one should you pick for this use case?

Solution 🔗

The basic permissions needed for an EC2 instance to communicate with AWS Systems Manager can be found in the “AmazonSSMManagedInstanceCore” Amazon Managed Policy. If you create an IAM Role and attach this managed policy you will find that you can execution run commands/documents on the server. But you will find you cannot directly connect to the EC2 Instance using Systems Manager in the EC2 Console. This is because this managed policy is missing one permission you need. That is “ec2:DescribeInstances”. I typically attach the “AmazonSSMManagedInstanceCore” managed policy to the role I plan on using and then add an inline policy with following policy doc.

This tool generates One Time Password tokens like Google Authenticator does. It currently only supports time based tokens.

The source code for the application can be found here: https://github.com/Craigspaz/MFA-Manager

Installation 🔗

Prerequisites 🔗

• Python 3
• PIP
• pipenv

1. Clone the repo to your computer
2. Run the command below when in a command prompt/terminal in the directory where the Pipfile was cloned to. This will install the required packages

pipenv install

How to run 🔗

1. Next enter the virtual environment’s shell and then run the main.py file or do it all at once with the command below

The problem 🔗

Sometimes you need to run a automated task that cannot be run in an AWS Lambda function. For example, you may need to synchronize data between two systems and that may take longer than the max 15 minutes lambda functions can run today or you may need to use applications that cannot be run in AWS Lambda. To get around the timeout there are multiple possible solutions.

1. Break the work that needs to be done into chunks and have the function run one chunk of the work at a time
2. Have the lambda function keep track of the time and once it gets close to the timeout have it make note of where it left off and invoke itself again to keep working in the next run.
3. Use a different service/product such as ECS

Pros and Cons of the solutions above 🔗

1. The first solution above has the pro of it all running in an AWS Lambda function but the con of having to break work up into chunks. Sometimes this is easy. Such as if you are paging through results and processing them, you can have the the function invoke itself with the next page of results it needs to process. A problem is this can add complexity as you need to make a recursive function and/or your use case does not easily use.
2. The second solution above has the pro of you do not have to chunkify the task. The con is that you need to keep track of time. This adds lots of complexity.

A Different Solution 🔗

We are going to go with option 3 which is to go with a different solution. The solution is to use AWS Lambda still but just to launch an EC2 Instance. The EC2 Instance can run for an unlimited amount of time and it can also run whatever applications are needed.

If the CloudFront distribution is in the same AWS Account as the Route53 Hosted Zone 🔗

1. Add a new record to the Hosted Zone.
2. Leave the Record Type set to A.
3. Then set the flag to make the record an Alias record.
4. Then in the Routes Traffic To section pick Alias to CloudFront Distribution.
5. Then pick the CloudFront distribution from the list.
6. Click Create Record

If the CloudFront distribution is NOT in the same AWS Account as the Route53 Hosted Zone 🔗

1. Add a new record to the Hosted Zone.
2. Leave the Record Type set to A.
3. Then set the flag to make the record an Alias record.
4. Then in the Routes Traffic To section pick Alias to CloudFront Distribution.
5. Paste in the Domain Name of the CloudFront Distribution
6. Click Create Record

How to prepare the binary files for execution on AWS Lambda 🔗

AWS Lambda runs on the same operating system as the AWS Linux AMI. That operating system is very similar to Centos 7. If you want to run a binary file on AWS Lambda it will need to be compiled to run on the AWS Linux AMI/Centos 7. I recommend doing this on a temporary AWS Linux EC2 instance or a Centos 7 VM/EC2 instance.

Why Build This? 🔗

AWS has NAT Gateways which are easy to set up in just a few clicks. This simplicity comes at a cost. AWS NAT Gateways have a significant cost depending on workload. At the time of writing AWS NAT Gateway cost $0.045 an hour. $0.045 * 730 hours = $32.85 a month. That is the cost of a NAT Gateway doing nothing a month. AWS also charges based on how much data goes through a NAT Gateway. According to their website there is $0.045 fee for data processed by the NAT Gateway. That includes data received by the NAT Gateway. This can result in unexpected high data transfer bills. Data transfer pricing gets very complicated. Having a NAT Gateway can result in you paying data transfer costs for data going through the NAT Gateway and then another cost for that same data to go through an Internet Gateway. Then you need to take into account the return traffic won’t have a Internet Gateway cost but it will have a NAT Gateway data transfer cost. There is also almost no configurability of a NAT Gateway. This is why you may want a NAT Server. This example is a very basic example running on a very small EC2 instance.

Why Build This? 🔗

Cloud Service Providers like AWS have serverless databases like DynamoDB and RDS. The only issue is that DynamoDB is a nosql database and RDS requires you to pick out instance types unless you want to use Aurora. RDS can also add up in costs fast if you provision large instance types for your cluster. It would be nice if there was a pay as you go type of model like how AWS Lambda works. If its not being used, you do not pay anything even if you have lambda functions in your account.