Now that we've got our deployment package sorted, we need to deploy it. Like everything else you do in AWS, there are options for deployment as well. Let's start with the most basic: using the Lambda console in the AWS Management Console. Perform the following steps to deploy:

1. First, we're going to update an existing Lambda function called myFunction using a ZIP file as a deployment package.
2. If we click on the drop-down list for the code entry type (shown by the blue arrow in the following screenshot), we can see the upload options that are available:

3. Let's choose Upload a .zip file and pick a .zip file to deploy.
4. When we click Save on the top right, the file will be uploaded and deployed. 

So, what's happening in the background? When you hit the Save button, the file is uploaded through the browser to an Amazon S3 bucket that the Lambda service creates for you. Then, the Lambda service uses that newly uploaded object as a target for deployment and updates the code. The last option in the list – Upload a file from Amazon S3 – simply lets you choose an object that has already been uploaded to S3.

Is the preceding code being overwritten? I hear you asking. Not quite – well, kind of, maybe. Versioning happens. When you create the first Lambda function, it is given the $LATEST version. What you need to do next is click on Actions and then Publish new version. The following screenshot shows where you can find this action: 

This will take whatever is in the $LATEST version and save it as a new version with a numerical value, starting with 1. Think of this as releasing a new major version, with $LATEST being the release candidate. Every new release gets its own Amazon Resource Number (ARN) so that you can manage or invoke it individually. You don't have to make use of this versioning functionality – you can use the $LATEST version forever and keep deploying over the top of it, but here's where it gets cool. 

Aliases. You can arbitrarily add a name or a pointer to a version. These get ARNs as well, so you can invoke a specific version of the function by an alias. Okay; so how would this be useful? Let's look at a real-life use case, that is, the development life cycle of the function itself:

Here, we can see we have created aliases for the various lifecycle stages that the function goes through. The Dev alias is pointing to $LATEST because that holds the most up-to-date code. The Prod alias is pointing to a previous version where the code has been tested and released for production use:

This way, a production release is as simple as updating which version the alias points to. This is useful when all the environments are hosted in the same AWS account. For larger deployments, we may deploy ZIP artifacts across multiple accounts instead. We'll see what that looks like later on.

Here's where it gets even cooler. Let's say that, for the preceding production release, we wanted to mitigate some of the risks of deploying new code in a big-bang approach. Using aliases, we can choose to balance the traffic across two different versions in a weighted manner:

When promoting important-release to Lambda function version 4, we can give it a weighting so that half the traffic goes to the new version and half goes to the other. This way, we can monitor any impact that the new version might have and take action where necessary.

We'll be exploring advanced deployment patterns in more detail and using the Serverless Framework in Chapter 8, CI/CD with the Serverless Framework. For now, we will move on and look at testing, monitoring, and debugging.