How to deploy an app to AWS: App automation and optimization

Hey there. Welcome to the fifth and final installment in our series on successfully deploying an app to AWS with the least effort. In previous weeks, we've focused on:

• Getting started
• Preventive measures
• Securing your app
• AWS Route 53 and DNS

This week, we'll discuss things you need to worry about now that you've released, plus optimizing your app.

Ok, so you've released your app. Congrats! However, we both know your work doesn't end here. You should continue improving your app, both on the end-user side and the back end. 

Here's our list of minimum must-dos for app maintenance and optimization so you can spend more time on features that delight your users.

Automated build and deployment

You may not agree with this first one. I get it. A lot of people think they can get away without it, and to some extent, they're right. But what they fail to take into consideration is the sheer amount of time devops automation will save them.

Consider: When you first release an app, the number of critical fixes and critical features needed is at its highest. Your very first users will require significant changes to the product. Thus, it's incredibly helpful to have an automated build and deploy system that consistently builds correctly. 

There are a lot of options out there for this, such as Jenkins and CircleCI, but AWS has a build and deployment automation tool built-in. For the sake of time, I’d stick with that tool: AWS CodePipeline.

AWS CodePipeline is a CI/CD service that enables you to provide continuous delivery in an automated fashion.

It includes:

• CodeCommit (a git repository)
• CodeBuild (build tool)
• CodeDeploy (deployment tool)
• CodePipeline (ties all the tools together; adds steps, approvals, staging, etc.)

On top of all that, you can also integrate any of your existing tools with CodePipeline.

AWS cost management vs. availability

There are a lot of pitfalls here if we're going for the bare minimum. You're going to be drawn to adding a bunch of resources in multiple AWS availability zones and maybe even regions. You'll be tempted to use the costliest tools to get the job done because they seem better. Skip spending time on this in favor of better protecting your data (which we’ll discuss below).

Stay strong and avoid these siren calls until you have more users or a more established app. Right now, your (few) users aren’t expecting perfection. Save that for later.

• You don't need high availability, so don't launch more resources than you need. 
• You don't need hot backups, so don't make big database clusters. 
• You're not sure what instance sizes you'll need, so don't buy any reservations that last longer than three months. (I've been guilty of this one myself.)
• You don't need all the cost classes in CloudFront. You probably don't even need CloudFront. Ignore CDN for now.

In this section, we're staying on theme: right now, less is more. It's natural to gravitate toward more availability on AWS, but at this phase, it's unnecessary and ultimately a waste of resources.

Disaster prevention and recovery

One area where you can't skimp is safeguarding customer data. You can lose servers, databases, and active traffic—a pain, but ultimately not catastrophic. But losing customer data will cost you customers.

So it's a good idea to have a backup plan. Take a look at every place you're storing data and make an AWS disaster recovery strategy. Here are some ideas.

S3

• Replicate your data across regions.
• Consider restricting deletes in IAM or S3 configuration.
• Implement S3 object versioning.

EC2 instances and EBS volumes

• Only put data on EBS volumes. EC2 instances do come with a little bit of memory, but if you get rid of the instance, you lose everything on it.
• Create snapshots as required.
• But first, make sure you pause all writes, flush data to disk, sync file system, and lock the file system. Only then create your snapshot. Failure to take any of those measures may result in an unrecoverable snapshot.
• Use EBS snapshot lifecycles to manage backups.

RDS

• Configure your snapshots.

DynamoDB

• Configure backups.

SQS and Kinesis

• Keep messages long enough to catch up.
• Consider streaming to S3 as a failsafe.

Everything else

• Read the documentation for every service you're using.
• Configure backups.

This all feels like no-brainer information, but it's all too easy to let it slip until something goes wrong. Take the time to prevent that from happening.

Configuration management

There are a ton of tools available to help you manage configuration: Terraform, Chef, Puppet, SaltStack, Ansible, CloudFormation, etc. That said, they all take forever to set up—much longer than if you just did the work yourself. Plus, each of them has a wicked learning curve. You don't need to set them up for your stage, so don't mess with them yet. 

Here's all you really need to do: Set up another repo (or just use your dev one) for notes, install scripts, etc., so you have a backup in case things go south. 

For every type of server (database, Kubernetes, etc.), have the following: 

• AMI
• IAM role/permissions
• Security group, subnet
• Instance type and size
• Launch script or copy/paste commands to run for configuration, programs, etc.

For every Lambda:

• Language and version
• Environment variables

For every other service:

• Critical configuration
• Versions
• Permissions

Basically what you want at the end of this is a way for someone else to reproduce the environment if they need to. Only record the things that matter, and keep them up to date: If you change a script, configuration, or value, update your repo. If you need a new resource, refer to the repo.

Monitoring

Hearing that you're down from an end-user has to be one of the worst feelings ever. Ideally, if something is going to go wrong, you want to know about it first. 

There are a bunch of services out there that will monitor different aspects of your infrastructure. CloudWatch is AWS’s proprietary monitoring tool, so if you don't want to spend time looking into other tools, stick with that.

You can set up custom alerts in CloudWatch for pretty much anything you want. For now, focus on what’s most critical and expand your coverage as you go.