AWS Services You Should Know When Deploying Your Django App
AWS offers a LOT of services.
Seeing the list of AWS services in the console can feel completely overwhelming the first few times. Just reading through the names of all services takes minutes. Finding out what every single one does would need a lot more effort.
And why would you? If you are like most people, there’s only a small subset of services which you really want to know about. Some of them because they are essential, and some because they come in really handy in specific situations.
This article will help you to get an overview of those services, without having to spend lots of research time yourself.
Here’s a hand-picked selection of AWS services which you should know about when deploying Django apps to AWS. Each entry has a link to the AWS service page, and a brief description why they might be relevant.
People often worry about out-of-conrol costs when using cloud services. The “Billing” service can help here. You always want to keep an eye on the costs, keep them under control and react to drastic changes if needed. Here, you can set up billing alerts to be notified in case your spending starts to rise too quickly.
Fine-grained permissions are essential. IAM is one of the core AWS services you should know how to use. When starting out, you are working as the root user of your AWS account. Creating a non-root user is in good taste. If you’re part of a team, want to have roles for parts of your code/infra, or just would like to “do it right”, you’ll want to start to work with non-root users and group-level permissions.
The service AWS offers to configure DNS settings. It’s deeply integrated with other AWS services, you’ll want to use it for your AWS-hosted services for the convenience. If you bought your domain with another registrar, consider pointing it to AWS name servers, and to use Route53 with all of its features.
A service to make it easy to set up a single small server. I haven’t used this much, and have the feeling that it was an attempt of AWS to answer the ease of use other cloud platforms (like Digital Ocean) offer. I don’t think anybody would want to use this in a professional context, but it can be a convenient way to start with AWS. Under the hoods, it’s making use of other AWS services for you. Once again, you’ll probably want to move away from this one pretty quickly, as your requirements become more defined.
The core of AWS when it comes to getting single virtual private servers (VPS) running. This isn’t just about starting instances though. There’s a lot more functionality hiding within: inside of the EC2 menus, you’ll find ways to manage security groups (think of it as an external firewall), load balancing, autoscaling groups and much more. VPC is an essential service to use EC2 properly. Read more on it right below.
Networking is an essential part when working with AWS EC2 and many other services. Before starting machines, you’ll want to make sure that you have a VPC, a subnet layout and routing configured correctly. VPC and EC2 are best buddies.
THE solution when it comes to handling static files. S3 offers “buckets” to store files and make them accessible to other people. In addition, you might want to configure CloudFront to act as a CDN in front of your S3-stored files, and to host your files with https.
EDIT: you don’t have to use S3 if you just want to take care of you Django-site specific static files. As brtt3000 pointed out in the Reddit discussion, you can host your static files without it, but S3 can be useful to handle user uploads.
If you want to have a database for your production setup, it’s a good idea to choose a managed service. RDS makes it possible to set up a PostgreSQL database (or other types) and have AWS take care of the maintenance and routine tasks around it such as backups and updates.
Certificate Manager (ACM)
Amazon offers free SSL certificates through this service for your AWS-hosted workloads. Those certificates integrate with other services, and are a great solution to set up https for your AWS-based apps.
A service for storing secrets securely, and accessing them from running applications. It’s also integrated in the Parameter Store functionality of the Systems Manager service. Read more below.
Systems Manager / Parameter Store
If you want to give your applications access to configuration values (doing it the AWS way), the Parameter Store (part of the Systems Manager) is the service you want to use. It’s a bit hidden inside of the menu, but very handy. In addition, the Secrets Manager is integrated into the parameter store, and is a solid way to handle sensitive secrets for you AWS workloads.
Lambda is a service for running serverless workloads.
When working with Django, Zappa or the serverless framework can be used to package up your app as a single Lambda function. It’s pretty convenient for small projects. You’ll only pay for the execution time your code, which can be near-zero. Beware, there are lots of stories of people who have generated huge bills with serverless services such as Lambda. It’s possible to spend a lot of money by accident if you’re not careful. If you take care and keep the limitations in mind, Lambda can be a great and cost-efficient way to host your apps though!
In addition, Lambda can be seen as code-glue to use in between other AWS services. You can create functions and have them triggered on certain events. This way, you can connect many different AWS services and automate some workflows in a very reliable fashion.
Amazon’s CDN solution. You can have it in front of S3, to deliver your static files quicker. To host the files with https, you can use a certificate generated in the Certificate Manager.
Amazon’s Infrastructure-as-Code service. You can define your infrastructure in form of JSON files, and Cloud Formation makes sure to spin up everything you described, without touching the AWS console. This is also a very good way for setting up different identical environments for your projects with minimal additional effort!
Usually, you don’t want to work with the JSON files themselves, but use something like troposphere (a Python package) for that instead. Alternatively, you can skip CloudFormation altogether and use a tool like Terraform to achieve the same goals.
A monitoring, alert and logging service integrated with AWS. You can set alarms and view metrics here. The nice thing is, that it plays well with most other AWS services. Need to get some observability into your AWS infrastructure? This is the service you want to use.
A managed queueing service. If you don’t want to host your own solution and have messages which absolutely, positively should not be lost, SQS is a great option.
Think of it like Heroku, but made by AWS. To my best knowledge however, Heroku offers a lot more polish, convenience and usability. Not quite Paas, but an “easier” way to deploy your app. For me, this falls in the same category as Lightsail. Behind the scenes, it uses a few other AWS services for you to get the job done. Some people like it a lot, and swear by this. Some grow out of it after hitting certain constraint. It might work for you, and could be a good way to get started. It even could work for you long-term. If in doubt, give it a try!
SES is a service for dealing with emails from your app, and it’s pretty well integrated with Django, as brtt3000 pointed out in the Reddit discussion about this article. I haven’t used it myself, preferring non-AWS services instead, but it sounds like a great option, integrating well with Route53 and taking care of the email busywork for you.
AWS offers lots and lots of services. It can be hard to get an overview, find ones you actually need and make sure you’re not missing something really useful.
This list is meant as a starting point. Don’t worry, you don’t need to know all of them by heart. Instead, treat is as a brief introduction. Pick a few services you actually need at the moment, focus on them and revisit the list later to see if something else might be useful once your requirements have evolved.
I hope this list of hand-picked AWS services has helped you to gain some focus, and maybe to find a few services which you might have been missing. It has gotten quite long so I decided to leave out container-focused services (ECS, ECR, EKS, Fargate) for a later, more focused article around running containers on AWS.