I previously wrote an article about deploying Django applications with AWS Fargate. Before I get into these reasons, here is a little bit of background on how I typically deploy web apps and the motivations for this project.ĭjango is my web framework of choice, and I'm most comfortable working with Django in docker containers.
There are a few different reasons for why I put this project together. This function can access RDS (8) and S3 (4) via a VPC Gateway Endpoint (9), but it cannot access the internet.
APACHE WSGI DJANGO AWS POSTGRESQL CODE
Starting with 5, API Gateway requests are passed to a proxy lambda (6) which calls a Lambda in a VPC that contains our Django code and special Django handler (7).
Route53 and CloudFront (1 and 2), discuessed later on, are optional. There are three cold starts to wait for: the cold start for the proxy Lambda, the cold start for the Django Lambda and the cold start for the Aurora Postgres Serverless database. One other caveat is that there is high latency associated with the initial request. The big caveat is that you can't easily access the internet in Django's request/response cycle without network address translation (NAT) services which add additional costs. The handler for the Django Lambda translates the API Gateway event into a WSGI-compatible request, processes the request and returns the response to the user back through the proxy Lambda.
The main idea is this: web requests are made to API Gateway that calls a Lambda outside of our VPC (proxy Lambda), which then invokes a second lambda (Django Lambda) inside of our VPC so that it can access VPC resources, namely RDS. One way to deploy Django apps to AWS on a budget is to use the Lambda proxy pattern.
0 kommentar(er)
