Tutorials on Aws Lambda

Serverless computing revolutionizes cloud infrastructure by having developers provision services and define resource demands with code rather than manually configuring hardware from scratch. Designing an application around a serverless architecture and workflow not only saves development time, but also drives down costs for scaling and operation expenses. Cloud computing platforms, such as Amazon Web Services (AWS), offer and maintain a plethora of serverless computing services to automate basic tasks and allow developers to deploy new services quickly. With AWS Lambda, instead of routing all incoming requests to a single server instance that hosts multiple API endpoints, we can distribute these endpoints across many functions. Since each function runs its own container, different functions can be allocated different amounts of memory and CPU power depending on the function's needs. Coupled with spinning up containers only in response to events and keeping them idle during inactivity (not online 24/7 like a traditional server), the savings compound exponentially while still serving end users. Regardless of traffic volume, AWS Lambda automatically creates instances of your function to meet this demand and only charges you for the function's run time and the total number of times it is invoked (per 1 million requests). The fact that AWS manages this entire infrastructure layer (e.g., system patches, security updates, etc.) by itself lets developers focus more on their own infrastructure. AWS Lambda provides runtimes to support various languages, such as Python and Java. There are many open-source libraries and utilities available for developing, deploying and securing serverless applications. For Python applications, Zappa makes the deployment process to a serverless environment simple via several built-in CLI utilities and a zappa_settings.json configuration file. Whether you want to deploy small microservices written with a framework like Flask , or large web applications written with a framework like Django , Zappa handles the deployment the same way without any additional framework-specific configuration. A limitation of Zappa is its inability to scaffold other AWS services/resources, such as RDS database instances (Aurora, PostgreSQL, MySQL, MariaDB, Oracle or SQL Server), during deployment. If your application directly connects to and accesses these AWS services/resources, then we must first provision those services/resources within the AWS Management Console. Below, I'm going to show you how to create an RDS database instance (specifically PostgreSQL) and connect it to a Django application deployed onto a Lambda function. Both the database and Lambda function will be placed within a private subnet of a VPC (virtual private network) to protect them from public Internet access. To get started, clone the following repository to your local machine: This repository's README.md file contains instructions on how to deploy and test a serverless Django application using Docker and Zappa. For Zappa to successfully deploy the Django application to AWS, visit the IAM console and enable the following permission policies: During deployment ( zappa deploy <stage> ), Zappa packages the application, dependencies and virtual environment into a Lambda-compatible archive, which is uploaded to an S3 bucket. Once it sets up the Lambda function, the IAM roles and policies and API Gateway resource, Zappa deletes the archive from the S3 bucket. Using middleware, Zappa turns API Gateway requests into WSGI requests, which can be processed with Python. Once done, Zappa returns the response through the API Gateway. The server is only alive during the execution of the function. If you decide to undo the deployment of the application via the command zappa undeploy <stage> , then Zappa automatically tears down the published API Gateway and Lambda function. Inside of the AWS IAM console, create a new user by clicking the "Add user" button. Name the user serverless-django-admin and enable programmatic access, which means an access key ID and secret access key must be provided to an AWS API, CLI, etc. to interact with AWS services. Under "Attach existing policies directly," check the permission policies mentioned above. Verify the list of permissions and create the user. Copy the access key ID and secret access key and paste them within the .env.* files. Set the environment variable AWS_ACCESS_KEY_ID to the access key ID and AWS_SECRET_ACCESS_KEY to the secret access key. A small network consists of resources connected to one other, such as a Django application connected to a database. Unrestricted access (from the public Internet) to any of these resources leaves them vulnerable to attacks from outside parties. If the database contains any sensitive or personally identifiable information, and this data becomes compromised, then you will be held liable for the data breach! Ideally, the database should have a firewall to filter out all traffic that does not originate from the Django application. A virtual private cloud (VPC) lets you to isolate parts of your network ("subnets") from the public Internet by controlling inbound and outbound traffic via security groups that act as "virtual firewalls." Amazon VPC comes with 65,536 private IP addresses available to be allocated to resources by default, which accounts for both small and large private networks. The network can be divided into subnets, which each groups a subset of the network's resources. Subnets are either private or public. Resources within a private subnets are not accessible from the public Internet. However, they can only access the public Internet under special circumstances. Resources within a public subnets are accessible from and can access the public Internet. To create a VPC, visit the AWS VPC console and click on the "Launch VPC Wizard" button. This opens the VPC wizard, which guides you through the process of creating a VPC step-by-step. The wizard presents four options: Since the Lambda function serving the Django application will be publicly accessible from the public Internet via an invocation URL and the PostgreSQL database will be protected from the public Internet, select the "VPC with Public and Private Subnets" option. The public subnet will host a network address translation (NAT) gateway, which allows resources within a private subnet to be accessed from the public Internet. The private subnet will host our Lambda function and RDS database, and the security group rules of the RDS database will be modified to only accept traffic from other resources within the same network. This way, only the Lambda function is accessible from the public Internet. Let's create these two subnets. The IPv4 CIDR block determines the range of IP addresses available for allocation within a subnet. For the public subnet, set the public subnet's IPv4 CIDR block to 10.0.0.0/21 and the private subnet's IPv4 CIDR block to 10.0.8.0/21 . Each has over two thousand IP addresses, which should be more than sufficient. If you need more IP addresses, then pick different blocks. For the public subnet to be reachable from the public Internet, you must obtain an Elastic IP address , which is a static, public IPv4 address, and associate it to the NAT gateway. To obtain an Elastic IP address, skip to the "Obtaining an Elastic IP Address" section and follow the directions. Copy the allocation ID of the Elastic IP address and come back to the wizard. Paste this ID into the "Elastic IP Allocation ID" field. Note : If you want to keep the private subnet completely isolated from the public Internet (and accessible from a corporate network, etc.), then go back to "Step 1: Select a VPC Configuration" of the wizard and choose the option "VPC with a Private Subnet Only and Hardware VPN Access." Once the VPC is successfully created, you will find the VPC listed under "Your VPCs." Additionally, you will find the VPC's private and public subnets listed under "Subnets." Under "Security Groups," you will find the VPC's default security group. All instances of the Lambda function belong to this security group. When we provision our RDS database, we will need to assign a security group to it, so take note of the security group's ID for later. An Elastic IP address is easy to obtain. Inside of the AWS VPC console, select "Elastic IPs" under the "Virtual Private Cloud" collapsible list in the left sidebar. Click on the "Allocate Elastic IP address" button. Leave the Elastic IP address settings on the default settings, unless you pick a specific network border group , which determines where AWS advertises IP addresses. Click the "Allocate" button to allocate this IP address. Once the Elastic IP address is allocated successfully, copy the allocation ID to associate to the VPC's NAT gateway. Continue on to the second part of this tutorial here , which dives into provisioning an AWS RDS PostgreSQL database and setting its security group rules.

I'm going to show you how to set up your Django app to respond to S3 events on AWS Lambda. The tool we're using to get Django running on AWS Lambda is Zappa . Follow along to see how responding to events works with this setup. ... When running your Django app on AWS Lambda using Zappa, it's easy to send and receive events from other AWS services . Zappa lets you get events from: Let's configure our Django with Zappa project to detect when new files are uploaded to an S3 bucket. You'll need a Django project configured with Zappa. You can create a Django project, then follow the guide for adding Zappa to your Django setup . Once your project is set up properly, log into the AWS console and create an S3 bucket with a unique name. The bucket won't need public access for this tutorial since we'll upload files directly using the AWS console. Once the bucket is ready, click on 'Properties' and record the Amazon Resource Name (ARN) for the bucket. At the root of your project, create a new file called aws_events.py . In this file, we'll add the handler function that will accept all our S3 events. When AWS invokes your function, two objects are passed in: the event object and the context object. The context object contains metadata about the invocation, function, and execution environment. The S3 event contains: Here's the code to accept the event: Our event handler code above prints out the event information and exits. Finally, we need to tell Zappa to register our event handler function with AWS so that AWS can start sending events. Add the following to the project's zappa_settings.json file: With all the changes saved, go ahead and push these changes to the cloud. In order to see the event details that our code prints out, let's activate the Zappa console log. You can do this by running: This gets Zappa to show you what your Django project is printing. Leave it up and running and remember you can exit anytime by pressing Ctrl-C . Head back over to your AWS console and find your S3 bucket page. Under the Objects tab, find the upload button. Go ahead and upload a file. Any file will do, but it's best to send a smaller one for expediency. After a few seconds, you should see in the terminal window the full event information from S3. It should look something like the following: A few things to note here. The filename is testfile.jpg and the bucket name is newline-upload-bucket . Of course, your file and bucket will be named differently. Also note the formatting is a little wonky, but still readable. You can try uploading a few more files. Maybe try two or three at once. You'll see each upload handled by your Django project as independent events. At this point, we have many options. Maybe your app will create a thumbnail if an image was uploaded. Or scan a document for keywords. Alternatively, your app might send an email to the client that uploaded the file confirming the receipt of the file. To dive in even more into setting up your Python apps to run serverless on AWS Lambda, check out our latest course, The newline Guide to Serverless Django with Zappa.