SAM v1.13.2 Patch Release: Redeploy API GW when OpenApiVersion flag is added (bug fix)

This patch release fixes a bug where the API GW would not redeploy if you added OpenApiVersion in certain cases. The fix takes into account the OpenApiVersion flag when calculating the hash to determine if the API has changed and needs to be redeployed.

Changelog
(#1056)(#1061) Redeploy api if OpenApiVersion changes.

SAM v1.13.1 Patch Release

SAM v1.13.1 Patch Release: Binary Media Types bug fix

This patch release fixes a bug with Binary Media Types introduced in 1.13.0 and reported in issue #1036. SAM wasn't converting the encoding of the Binary Media Types from *~1* to */* before adding them to the swagger document, which resulted in the corruption of some APIs that use Binary Media Types in SAM. This was fixed in #1043

Changelog

(#1043) Fix Binary Media Types regression

SAM v1.13.0 Release

SAM v1.13.0 Release: OpenApi 3 Support and Request Models Support

OpenApi 3.0 support and Stage "stage" fix

We have now added support for OpenApi 3.0 in SAM. This is an opt-in feature that can be enabled by using the OpenApiVersion property for an AWS::Serverless::Api. This property is supported at both the resource and global levels of the template.

Globals:
  Api:
    OpenApiVersion: '3.0.1'

Resources:
  ImplicitApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: s3://sam-demo-bucket/member_portal.zip
      Handler: index.gethtml
      Runtime: nodejs8.10
      Events:
        GetHtml:
          Type: Api
          Properties:
            Path: /
            Method: get

If you opt into this flag, SAM also fixes the issue where a stage named "stage" was created by default. #191

API Request Models Support

This feature adds support for listing Models in the Api resource and defining a model to be used in the Api event source. Previously, the only way to do this was to manually write the swagger file. This now makes it much simpler to define the models, and special callout to community member @beck3905 for adding this feature.

Resources:
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Models:
        User:
          type: object
          required:
            - grant_type
            - username
            - password
          properties:
            grant_type:
              type: string
            username:
              type: string
            password:
              type: string
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      CodeUri: src/
      Events:
        GetApi:
          Type: Api
          Properties:
            Path: /post
            Method: POST
            RestApiId:
              Ref: MyApi
            RequestModel:
              Model: User
              Required: true

Change Log:

1. (#932)(#949)(#990) OpenApi 3.0 support and stage stage bug fix
2. (#948) API Request Models Support by @beck3905
3. (#958) Fix CORS options method when DefaultAuthorizer is used
4. (#954) Fix API Binary Media Types update issue
5. (#946)(#973) Bug fixes
6. (#962)(#961)(#960)(#963)(#979) version bumps in dependencies
7. (#950)(#968)(#982) Additions to docs and examples

SAM v1.12.0 Release

SAM v1.12.0 Release: Reference custom Lambda CodeDeploy configurations

Reference Custom Lambda CodeDeploy Configurations

Previously in SAM, you could configure CodeDeploy to enable gradual code deployments for your AWS Lambda functions. Now, you can reference existing custom CodeDeploy configurations in the DeploymentPreference property of an AWS::Serverless::Function. Thank you @Buffer0x7cd for contributing this feature! (#848)

To learn more about implementing gradual Lambda deployments using CodeDeploy, see this blog post. To learn more about how to create a custom Lambda CodeDeploy configuration, see the AWS Documentation.

# Example using a custom CodeDeploy configuration
Resources:
  MyFunction:
    Type: 'AWS::Serverless::Function'
    Properties:
      CodeUri: s3://sam-demo-bucket/demo.zip
      Handler: index.handler
      Runtime: python3.6
      AutoPublishAlias: live
      DeploymentPreference:
        Type: MyCustomDeploymentConfiguration  # Name of CodeDeploy configuration

Change Log:

(#904) Add StepFunctionsExecutionPolicy
(#908 #913) Bug fixes by @jadhavmanoj
(#918 #966) Additional bug fixes
(#888) Run cfn-lint on test outputs
(#605 #883 #886 #887) Example app updates
(#899 #902 #905 #909 #919) Documentation updates

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!