I was looking for a way to demonstrate deploying EC2 instances into my VPC but was looking for a real world problem to solve while I did it. As it turns out, despite all efforts to insulate them from the insidious lure of gaming (read mom), my kids LOVE Minecraft. I have been into technology for most of my life, and make a living off of my knowledge of it, but I am not a gamer. Until now I have never had the motivation to try setting up a Minecraft server but now that the kids have tasted the forbidden fruit of multiplayer video games they, of course, want to play online with their friends. You can purchase a server online from about 5000 different places and be done with it but it isn't exactly cheap for anything bigger than a Raspberry PI and this is my chance to look cool to my kids by being a hacker (my kids define hacker as anything cool you can do with a computer that involves a terminal window). So, in the spirit of all who enjoy watching people change the gear ratio on a riding lawnmower to make it go 40 mph, I thought I can contribute to my children's delinquency by giving them a variably sized Minecraft server that they can fire up whenever they want AND make a blog post. Given this obvious pressing need, I decided to set the kids up with an automatically deployed Minecraft server using Terraform and AWS. It saves their world in between sessions in an S3 bucket so we can completely tear it down when they are not using it but can start up a new server on demand right where they left off in the game.

Ok, so now that we have an important real world problem to solve, lets list our requirements and plan out an architecture:

This diagram shows our basic architecture and gives us a way to break down our components into distinct stories for implementation.

I'll assume you can handle the implementation of the kids on your own so lets start with the S3 bucket.

Creating an S3 bucket is pretty simple with the the aws_s3_bucket resource in Terraform. We will set ours to be privately accessible, so only our EC2 instance can reach it, and protect it from destruction if it has contents:

Creating the role and permission we need to access it with our EC2 instance is a little harder but not to bad.

From the AWS Docs IAM roles

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

From the AWS Docs Policies and permissions in IAM

You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. AWS supports six types of policies: identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, ACLs, and session policies.

These descriptions explain that a role is an identity and a policy is a set of permissions. Once we associate a role and a policy we can then grant that role to a user, or in our case a service, and we will have given our service permission to do something (read/write to an S3 bucket in this case).

First we define a role with the Terraform aws_iam_role resource for the EC2 instance we plan to create. This will allow the EC2 service to access resources in our account:

Next we need to create a policy with the aws_iam_policy resource that grants permission to do whatever to the specific bucket we create:

Then the policy needs to be attached to the role:

And because we are doing this programmatically via Terraform, we need to create an instance profile that our EC2 instance will use to assume our new role:

Once we have deployed them we can see our role and policy in the console

There's a lot more we could delve into here but this gives us what we need to move on to creating our EC2 instances.

This part is easy too right up to the point it's not. Making the EC2 instances is simple but the pain lies in the scripts that get executed upon creation and the systemd service that is responsible for managing the fetching and storage of our world directory. Once you get them right it's not bad but getting them to work exactly how you want can be tedious.

A lot of stuff comes together in the definition of our public EC2 instance that will run our minecraft server. This image shows the various parts:

The file provisioner gives us a way to move our Minecraft.jar file and the service template we will use to sync our instance with our S3 bucket to our EC2 instance.

The instance profile gives our EC2 instance the permissions it needs to manage our S3 bucket. The part that ties the whole thing together is the user_data attribute which gives us a means to define a script that will execute upon the creation of our EC2 instance.

There is a bunch of stuff going on here but it's all pretty self explanatory:

The next piece of magic is the service template. The two important parts are the ExecStart which tells it to start Minecraft when our server starts and the all important 4th ExecStop that says run the script that will sync your world back to S3 before we unceremoniously deleting this server.

After I watched my 8 year old rage quit Minecraft for life over apparently losing all his diamonds (whatever that means), and then proceed to start playing again in less than 15 minutes, I thought about turning on versioning for my S3 bucket. But then I thought what kind of life lesson would I be teaching him by not letting him suffer the consequences of his actions? So suck it up little one, as survival mode makes abundantly clear, life is hard. But, if you don't subscribe to my baby shark parenting style, know that it is possible to version the files you are syncing back to S3 in case something goes awry and you need to back up to previous version of your world state.

Looking at our Terraform folder the last part that I'm really concerned with is limiting who can get to our server. To do that I define a security group in the ec2_security_group.tf:

We want to avoid leaving our server open to the whole world by setting up ingress rules that have bits like this:

so for our Minecraft server we will limit access to our local IP (you don't need 22 or 80 for Minecraft). The chomp part should put your public ip in the cidr_blocks, if you are running everything local, and you can obviously put an array of whatever IP's you want in there:

Finally, we are ready to deploy this thing and bask in the glory of our creation. My 12 year old is convinced I'd have been done hours ago if I just read some stupid blog entry he found but he's to young to understand why the person who wrote that is clearly an idiot and has no idea how to properly over engineer something.

Assuming you have your VPC

and your S3 bucket deployed

you should have the outputs stored in their respective state files that will allow us to successfully run terraform apply on our terraform_ec2 directory:

The outputs should give us all the connection strings we need to test it.

The public ssh should get you right in to your public instance while the private one should fail from your local machine but work fine from within your public instance ()after you copy a private key to the public instance):

We prove out our connectivity and the success of our Apache install by showing we can ssh into our private instance and curl our simple index file. That proves the NAT gateway we set up in our VPC allowed our private instance to reach out to the internet for its software installs. A quick check in the browser shows we have successfully installed and routed our public Apache instance:

and now we can check our Minecraft server status and see if my latest instance of a server has inherited files from the S3 bucket:

It's up and alive and we can see a big set of files were apparently copied over. If you have any doubts about what happened during startup you can check the logs:

For proof that our sync back to S3 works we can create a file in the /opt/ubuntu/willmc directory and then destroy our instance. If it works we should see our file in S3 (you could also play Minecraft) after our instance is destroyed:

Checking our S3 bucket before we see :

Now gently eradicate our server:

And we can see our shutdown script has done it's job:

My kids have no idea how good they have it.

I hope this post helps someone else look good in front of their kids or at the very least their boss.

I think this example does a pretty good job of touching on a lot of key concepts you will encounter in the real world and shows how you can take advantage of some of the key benefits of the cloud: