v1.11.0 Release: Support API IAM Permissions Auth and API Gateway Responses

SAM v1.11.0 Release: SAM now supports two more API Gateway Features - IAM Authorizers and Gateway Responses

IAM Authorizers

AWS SAM previously let you control who can access your Amazon API Gateway APIs with an Amazon Cognito user pool or an API Gateway Lambda Authorizer. Now, you can control access to an API defined in SAM with IAM Permissions. To learn more, see controlling access to APIs using IAM permissions and an example application that uses this feature. Shout out to @horike37 for this contribution! (#827)

Gateway Responses

With this release, you can also define Gateway Responses in your AWS::Serverless::API resources. Amazon API Gateway lets you customize the content of error responses, and you can now define these in SAM. To learn more, see Set up Gateway Responses to Customize Error Responses and an example application that uses this feature. Shout out to @chrisoverzero for this contribution! (#841)

FindInMap support for Serverless::Application

This release also adds support for using FindInMap to specify the ApplicationId and SemanticVersion properties of a Serverless::Application. To learn more, see the docs for FindInMap and Nested Applications. (#856)

# Example application using !FindInMap
  ApplicationFindInMap:
    Type: 'AWS::Serverless::Application'
    Properties:
      Location:
        ApplicationId: !FindInMap
          - ApplicationLocations
          - !Ref 'AWS::Region'
          - ApplicationId
        SemanticVersion: !FindInMap
          - ApplicationLocations
          - !Ref 'AWS::Region'
          - Version 

Change Log:

(#808) Add ReservedConcurrentExecutions to globals
(#858) Fix ElasticsearchHttpPostPolicy resource reference
(#855) Support using AWS::Region in Ref and Sub
(#831 #814 #879) Documentation and examples updates
(#835) Add VersionDescription property to Serverless::Function
(#847) Update ServerlessRepoReadWriteAccessPolicy
(#873 #860 #846 #845) Add additional template validation

SAM v1.10.0: Conditions support!

SAM v1.10.0 Release: Conditions for Serverless resources

You can now define conditions on AWS::Serverless resources. Conditions are statements that let you define the circumstances under which resources get created or configured. With this release, you can conditionally create AWS::Serverless resources. For example, if you deploy your serverless application to multiple environments such as test and prod, you can choose to only deploy specific AWS::Serverless::Functions to your test environment. Conditions on AWS::Serverless resources are also applied to other generated resources (#755), and the swagger definitions generated by SAM on AWS::Serverless::Api resources (#804). Shout out to @Jacco for contributing to this feature! (#653 #707)

Change Log:

Policy Templates

(#620 #686) Add GSIs to DynamoDBReadPolicy and DynamoDBCrudPolicy
(#615) Add DynamoDBReconfigurePolicy
(#426) Add CostExplorerReadOnlyPolicy and OrganizationsListAccountsPolicy
(#556) Add EKSDescribePolicy
(#715) Add SESBulkTemplatedCrudPolicy
(#729) Add FilterLogEventsPolicy
(#625) Add SSMParameterReadPolicy
(#723) Add SESEmailTemplateCrudPolicy
(#769) Add s3:PutObjectAcl to S3CrudPolicy

Other changes

(#464) Add allow_credentials CORS option
(#643) Add support for AccessLogSetting and CanarySetting Serverless::Api properties
(#657) Add support for X-Ray in Serverless::Api
(#786) Add support for MinimumCompressionSize in Serverless::Api
(#682) Add Auth to Serverless::Api globals
(#763) Remove trailing slashes from APIGW permissions
(#648) Add SNS FilterPolicy and an example application
(#690) Add Enabled property to Serverless::Function event sources
(#782) Add support for PermissionsBoundary in Serverless::Function
(#697) Fix boto3 client initialization
(#700) Add PublicAccessBlockConfiguration property to S3 bucket resource
(#705) Make PAY_PER_REQUEST default mode for Serverless::SimpleTable
(#709) Add limited support for resolving intrinsics in Serverless::LayerVersion
(#720) SAM now uses Flake8
(#737) Add example application for S3 Events written in Go
(#604 #632 #644 #741) Updated several example applications

SAM v1.9.0: Lambda Layers and Nested Applications

SAM v1.9.0: Lambda Layers and Nested Applications

Nested Transforms and the AWS::Serverless::Application Resource

You can now assemble and deploy new serverless architectures using nested applications supported by AWS SAM and the AWS Serverless Application Repository.

Nested applications enable you to rapidly build highly sophisticated serverless architectures by reusing and composing authored and maintained services using SAM and the Serverless Application Repository. You can deploy serverless architectures as a set of serverless applications and easily share those architectures privately across teams and organizations or publicly with developers in the open-source community. Using nested applications, you can build more powerful applications, easily manage serverless artifacts, avoid duplicated work, and help ensure consistency and best practices across your teams and organizations.

The new AWS::Serverless::Application transforms into a AWS::CloudFormation::Stack (also known as a nested stack) resource by resolving the Location property to an S3 template URL. SAM users can either provide direct links to a nested template or provide an ApplicationId and SemanticVersion pair from the Serverless Application Repository and SAM will retrieve the template and all its resources for you. This allows developers re-use common application building blocks as well as share and consume them via the Serverless Application Repository.

Learn more in the SAM developer documentation or in the AWS::Serverless::Application specification. We have also included a sample application that uses this feature.

Introducing AWS::Serverless::LayerVersion

Lambda functions in a serverless application typically share common dependencies such as SDKs, frameworks, and runtimes. Lambda Layers are a new type of artifact that can contain arbitrary code and data, and may be referenced by multiple functions at the same time. With layers, you can centrally manage common components across multiple functions enabling better code reuse. You can now use AWS SAM and AWS SAM CLI to locally test, deploy and manage serverless applications that leverage Layers. An AWS::Serverless::LayerVersion transforms into an AWS::Lambda::LayerVersion.

Since an AWS::Lambda::LayerVersion resource is immutable, CloudFormation currently automatically creates a new version and deletes the old version of the Lambda Layer after each update. By default, SAM prevents CloudFormation from deleting old versions by appending a 10-digit SHA (based on all resource parameters) to the logical id of the LayerVersion resource and adding a DeletionPolicy: Retain attribute. This means that any update to the Lambda Layer will result in the creation of a new version, and the old version will still be available for use.

Learn more about Lambda Layers in the Lambda Layers documentation, and in the SAM developer documentation.

Other Updates

#670 Added AWS WorkMail hello world lambda function example
#639 Added link to the new AWS SAM Developer documentation
There were also a few documentation fixes and updates.

Releasing SAM v1.8.0 - API Gateway Authorizers!

What's New in SAM v1.8.0?

Define API Gateway Authorizers in SAM

#546 You can use AWS SAM to easily control who can access your API Gateway APIs with an Amazon Cognito user pool or an API Gateway Lambda Authorizer. An authorizer can be a Lambda authorizer, which is a Lambda function that you provide to control access to your API methods, or it can be an Amazon Cognito user pool, which is a user directory in Amazon Cognito. In SAM, you can define these authorizers as a property of an API, or as a new resource which can be used across multiple APIs.

To get started, check out the specification updates for using the new Authorizer (Auth) parameter within an AWS::Serverless::Api resource or within an API event for an AWS::Serverless::Function. See more examples of how to use Cognito authorizers, Lambda request authorizers, and Lambda token authorizers.

Other Updates

#511 Add dynamodb:DescribeTable to DynamoDBCrudPolicy
#589 Added RekognitionFacesManagementPolicy

Contribute to SAM

Help shape future SAM development! Add your opinions on proposed features and try tackling good first issues. Join the #samdev Slack channel where a growing community of Serverless developers hangs out.

Releasing SAM v1.6.1

What's New in SAM v1.6.1?

NOTE: Although v1.7.0 has since been released, we're posting these release notes retroactively for awareness of v1.6.1 features.

SQS as an Event Source

#451 You can now define an SQS Queue as an event source in your SAM template, and trigger lambda functions by sending messages to an Amazon SQS queue. Check out more information in the documentation as well as in an example application that uses this new feature.

Inline Code

#447 You can now (optionally) write your lambda function code inside of your SAM yaml template. An example of this is included below:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: A hello world lambda function with inline code.
Resources:
  helloworld:
    Type: 'AWS::Serverless::Function'
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10
      MemorySize: 128
      Timeout: 3
      InlineCode: |
        exports.handler = async () => ‘Hello World!'

Thanks to @tylersouthwick, one of our community contributors, for this new feature!

Other updates

#408 Add MobileAnalyticsWriteOnlyAccessPolicy and PinpointEndpointAccessPolicy to Policy Templates
#449 Fix ANY method ARN generation to use a wildcard (*)
#477 Fix references to AWSLambdaSQSQueueExecutionRole
Commit Add SSE to SimpleTable
#397 Add FirehoseWritePolicy and FirehoseCrudPolicy to Policy Templates
#490 #491 Add support for Python3 (AWS internal transform still uses Python2.7 for backwards compatibility)
Also, updates to the documentation and example applications.

Releasing SAM v1.7.0

What's New in SAM v1.7.0?

Default Definition Body Plugin

#541 You can now define explicit AWS::Serverless::API resources without needing to specify a DefinitionBody or DefinitionUri. If you do not specify one of these properties, SAM will generate Swagger for you based on the configuration of your SAM template. This means you can now configure things such as StageName, Cors, and soon Auth without having to manually define the Swagger of your API.

Policy Templates

#453 Added s3:DeleteObject to S3CrudPolicy
#539 Added AWSSecretsManagerGetSecretValuePolicy
#548 Fixed resource scoping in CodePipelineLambdaExecutionPolicy
#571 Added RekognitionDetectOnlyPolicy

Other Improvements

#508 Allow string values in the DependsOn property of S3 buckets (previously only accepted a list of strings)
#574 Expose skill ID for event source validation with Alexa skills
#554 #560 Fixed the sample apps to properly use Policy Templates and re-published these examples to the Serverless Application Repository
#484 Removed JSON schema validation warning

Documentation

This release also contains many documentation updates and fixes. We would like to give a shoutout and a thank you to all of the contributors that have helped us with examples, documentation, and giving us feedback about how we can further improve the SAM experience!

Development and Contributing

As always, we welcome your feedback and ideas of what we can do with SAM as well as your contributions! Join us and a growing community of Serverless developers on our #samdev Slack Channel and continue to engage with SAM through submitting and helping out on issues and pull requests. Check out our Development Guide for more information about how to get started!

🥁 SAM Implementation is now open source!

Spec + Code == Awesomeness

In 2016, we launched SAM and opened up the SAM specification on this Github repo to invite collaborators. We've loved your questions, proposals for new features, enhancements to examples, bug reports, and passionate discussions around developing serverless applications.

Today, we are incredibly excited (💃🕺🍾 🎉) to open source the underlying SAM implementation - the Python code that converts SAM templates to CloudFormation stacks. Now, in addition to proposing changes to the SAM Spec, you can contribute new features and enhancements to all of SAM! You'll find the code under the samtranslator folder and the tests under the tests directory.

Development Process

We invite anyone who is interested in serverless to participate in developing SAM. You can fork the SAM repository, add new event sources, new resources, or any new features that help you build serverless apps faster.

Once you're ready to merge back in, propose changes and solicit feedback by creating a pull request on GitHub. Also, use the #samdev slack channel to communicate and collaborate with the AWS SAM team and fellow SAM developers.

Releases

We will periodically deploy the code from GitHub through CloudFormation. More on this soon.

Getting Started

Clone the repository and read the Development Guide for more information on how to get setup and use this code. The easiest way to run this code is by running the tests.

#samdev Slack

Come hang out with SAM Team and the community developers on #samdev Slack channel and help us develop SAM.

Click on this link to get invited - https://awssamopensource.splashthat.com (https://awssamopensource.splashthat.com/)

CAUTION: Plenty of passionate Python and Serverless developers hangout in this channel. There will be intense, and sometimes heated, discussions around Python, coding, and improving serverless developer experience. If you are looking for a place to chill, this Slack channel is not for you

CloudWatch Logs Trigger

As a part of this release, we have also added support for CloudWatch Logs Trigger. You can easily trigger a Lambda function when log statements are written to CloudWatch.

  LogsFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Handler: index.handler
      Runtime: nodejs6.10
      Events:
        LogsProcessor:
          # This is your Logs trigger
          Type: CloudWatchLogs
          Properties:
            LogGroupName: !Ref CloudWatchLambdaLogsGroup
            FilterPattern: Hello log processor

What's next?

You! 👈 Yeah, you!

Come join the Slack Channel. Collaborate with us to start hacking SAM together. Let's work together to make it really simple for developers to build serverless applications.

Loads of API features, bug fixes and improvements

This one is a big release! So grab a popcorn 🍿 and start reading:

API Features

CORS, yeah CORS!

You can now add CORS to your SAM apps in one line Cors: "'www.example.com'"! This will allow a webpage at "www.example.com" to call your APIs. As a bonus, SAM will automatically create the correct AllowMethods headers to allow only the methods served on each API Path. If you want, you can override other Cors properties by passing a dictionary. Checkout the Spec for full configuration.

CORS is probably the most talked about issue in this Github repo (39 issues mention CORS). We are thrilled to get this out :)

Learn more in this example

Regional Endpoints

If you want to connect the API to your own CloudFront distribution, or want to use it with Lambda@Edge, or just want to API reduce latency, you can now make your APIs Regional by setting EndpointConfiguration: REGIONAL in your API.

Binary Media Types

Send images, pdf, or any binary data through your APIs by adding the following configuration:

BinaryMediaTypes:
  # API Gateway will convert ~1 to / 
  - image~1png
  - image~1gif

Don't forget to set isBase64Encoded: true in your Lambda function response. Checkout this full example for more details

Logging, Metrics, CacheTTL: Any Stage Settings

To add logging or turn on metrics or set the CacheTTL, you can now do that in the MethodSettings property of your SAM template. The value of this property is directly passed through to CloudFormation. So any feature available in CloudFormation MethodSettings property will be available to you in SAM:

    MethodSettings: [{
        # Turn on Info logging
        "LoggingLevel": "INFO",

        # Enable Metrics
        "MetricsEnabled": True,

        # Trace-level Logging
        "DataTraceEnabled": True,

        # On all Paths & methods
        "ResourcePath": "/*",
        "HttpMethod": "*",
    }]

Refer to resources generated by SAM

SAM will generate an API Gateway Stage and API Gateway Deployment for every AWS::Serverless::Api resource. If you want to refer to these properties in an intrinsic function such as Ref or Fn::GetAtt, you can append .Stage and .Deployment suffix to the API's Logical ID. SAM will convert it to the correct Logical ID of the auto-generated Stage or Deployment resource respectively.

• !Ref MyApi.Stage => Ref the Stage generated by SAM
• !Ref MyApi.Deployment => Ref the Deployment resource generated by SAM

This allows you to connect SAM generated resources with other CloudFormation resources. This is super important, especially, if you want to refer to the Deployment resource whose Logical ID keeps changing during every deployment.

Function

Per Function Concurrency

This property allows you to set a concurrency limit to each of your Lambda functions. Use this by adding ReservedConcurrentExecutions property to your Function resource

SimpleTable

TableName, and Tags properties are now available

Bug Fixes

• Managed policy ARNs, and intrinsic functions for managed policies are now supported.
• We will throw an error if invalid value for function policies are specified, instead of passing the value to CloudFormation
• Support Integers in Tags of Serverless::Function
• BucketEncryption property of S3 resource should work now(#275)

New Regions

SAM is now available in all regions that Lambda is available including AWS GovCloud (US) and AWS China (Beijing) Region. Refer to the Region table for all the regions that Lambda is available in.

Documentation Updates 📖

• SAM Internals: Take a look under-the-hood of how SAM generates CloudFormation resources and learn about the naming convention used by SAM
• CloudFormation compatibility - SAM is built on top of CloudFormation, which means you want to be able to use all the cool features CloudFormation offers such as Intrinsic Functions, DependsOn, Conditions etc. SAM's support for CloudFormation features is not 100%. So read this document to understand what works and what does not. If a missing feature is blocking you, then create a Github Issue and let us know!
• FAQs - We have started collecting common questions and answers into a separate document. Thanks to @sgarcez for starting this!

CONTRIBUTORS NEEDED

We are laying the ground work to create a Sphinx based documentation website for SAM. Documentation from the docs folder will be rendered there in a pretty UI. Check it out - https://awslabs.github.io/serverless-application-model/

As you noticed, this website looks bare and empty. We are still in the process of improving the UI, adding more documentation and surfacing relevant information. Our hope is to make this the Go-To destination for all things SAM.

If you are using SAM, and love it, and want to earn some Karma, help us build this website. It is a simple static website created with Sphinx. You can find the source code the website at ./docs/website. There is a Makefile to get you up and running. We are looking for all sorts of help:

• Add more docs (#251)
• Improve README.md to help people get started with SAM easier. Checkout README.md in my fork to get a sense of general direction.
• Improve website UI - Write a new Sphinx theme and write a neat UI

Start Hacking!

👩‍💻👨‍💻 => 🐿

Make your apps more secure - SAM Policy Templates

Just when you thought we were still in an ice cave in Alaska, here is another amazing SAM feature to make your apps very secure:

Introducing Policy Templates

AWS Managed Policies are a simple mechanism to give your Lambda Function permission to access AWS resources. For example, AmazonDynamoDBFullAccess gives permission to access DynamoDB Tables. More precisely, this will give your function access to all DynamoDB APIs against all
DynamoDB tables in all regions. This is excessively permissive when all that your function does is Read & Write values from one table.

SAM provides a tighter and more secure version of AWS Managed Policies called Policy Templates. This are a set of readily availbale policies that can be scoped to a specific resource in the same region where your stack exists. The following example gives your function CRUD access to just one table defined in your stack,

  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      ...
      Policies:

        # Give just CRUD permissions to one table
        - DynamoDBCrudPolicy:
            TableName: !Ref MyTable

      ...

  MyTable:
    Type: AWS::Serverless::SimpleTable

Checkout https://github.com/awslabs/serverless-application-model/blob/master/docs/policy_templates.rst for more information

Lots more to come.. Stay tuned! 📻

Globals, Safe Lambda Deployments, Lambda Versions & Aliases, Local Lambda execution 🐿

What's New?

In the last few months, we moved out of our cozy offices into a ice cave somewhere in Alaska to cut out from the noise and focus on one thing - innovate and deliver some awesome SAM features for you. If this Github page was quiet for a while, this is the reason. To break the silence, here are some amazing features we have just launched:

Safe Lambda Deployments
SAM integrates with AWS CodeDepoy to provide safe, gradual, traffic-shifting deployments for your Lambda functions. You can stop worrying and start pushing code to production with confidence!

MyLambdaFunction:
  Type: AWS::Serverless::Function
  Properties:
     ...
     DeploymentPreference:
       Type: Canary10Percent10Minutes

Read more about Safe Lambda Deployments here

Lambda Versions & Aliases
SAM provides a dead simple way to publish new versions on every code push and use an Alias to point to the latest version. Just add the following property to Serverless::Function resource:

AutoPublishAlias: live

The above property will create a new Alias called live, point all your event sources to the Alias, automatically publish a new Lambda Version every time you push new code, and point the Alias to the latest version. This can be used stand alone but the real power comes when you combine it with DeploymentPreference to do gradual shifting of traffic from your old version to new version, monitoring Alarms, and trigger rollbacks if something goes wrong.

Read more about AutoPublishAlias here

Globals
You can now define all common properties of Serverless Function in one place and let every function inherit it. You can even override some properties or add additional values at the specific function level. The following example enables safe deployments for all your functions and environment variables that are shared with all the functions!

Globals:
  Function:
    Runtime: nodejs6.10
    Timeout: 60
    Environment:
      Variables:    
         DbConnection: mysql://somewhere
     AutoPublishAlias: live
     DeploymentPreference:
       Type: Canary10Percent10Minutes

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Environment:
        Variables:    
          TableName: mytable   

Read more about Globals here

SAM Local CLI
Run Lambda functions locally on your computer by starting with a simple SAM template. This is launched couple of months back but still worth mentioning because it makes your life so much easier.

Installation:

npm install -g aws-sam-local

Checkout https://github.com/awslabs/aws-sam-local for how to use it.

More to come

Actually, this is just a start. We have a lot more features (spoiler alert: API Gateway logging, CORS, more..) coming out real soon

👩‍💻👨‍💻 => 🐿