I've created AWS Lambda in C# using Visual Studio that returns some JSON from the API endpoint. Now I want to run that lambda locally. All the examples use AWS SAM, but they create a new function using the SAM template.
When I run the command sam local start-lambda I get an error saying that the template isn't found. So what is certain is that I need template.yaml, but I'm not sure is there a way to generate this template for existing Lambda?
Any help is appreciated!
Check out the Template Anatomy resource on the AWS documentation.
You might find this example helpful (it's greatly simplified). I use NodeJS for development, but the differences between programming languages when you're creating a SAM Template are trivial. The example is an outline for a simple Lambda function someFunction being invoked by an API Gateway (HTTP) event.
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: My Serverless Application
Parameters:
# Manually define this in AWS IAM for just the services needed.
lambdaExecutionRole:
Description: 'Required. The role used for lambda execution.'
Type: 'String'
Default: 'arn:aws:iam::nnnnnnnnnnnn:role/LambdaExecutionRole'
Globals:
Function:
Runtime: nodejs10.x
# Environment:
# Variables:
# NODE_ENV: test
# DEBUG: myapp:foo
Resources:
performSomeFunction:
Type: 'AWS::Serverless::Function'
Properties:
FunctionName: performSomeFunction
Handler: lambda.someFunction
CodeUri: ./
Description: description of the function being performed
MemorySize: 256
Timeout: 60
Role:
Ref: lambdaExecutionRole
Events:
# API Gateway proxy endpoint.
ProxyApiRoot:
Type: Api
Properties:
Path: '/'
Method: ANY
ProxyApiGreedy:
Type: Api
Properties:
Path: '/{proxy+}'
Method: ANY
As you're getting started with AWS Lambda, one of the big concepts to keep in mind is how your function will be triggered. Functions are triggered by different kinds of events, and there can be many many different types of events. I tend to use API Gateway, Simple Queue Service and CloudWatch Events to trigger mine, but it entirely depends on your use case.
It turned out that you can export Lambda function, and get the generated .yaml template, which was exactly what I needed.
Related
I am using SAM to develop a lambda that is triggered by SNS.
When I am using SAM, it seems I get API GATEWAY associated to the Lambda when I deploy.
It is nice in dev, but not in prod.
How would I develop a Lambda without deploying it attached to an API GATEWAY?
"I was not aware of Lambda runtime API"
Using the Lambda runtime API and the AWS SDKs, as a developer, you can build more flexible Lambda functions with the exact functionality that you want.
For example, you can build Lambda functions that can invoke multiple AWS Services to perform a given use case. For example, from a Lambda function, I want to detect PPE information in images within an Amazon S3 bucket, store the results in an Amazon DynamoDB table, and use the SES service to email the results.
Here are a few end to end tutorials.
For example - here are two JavaScript examples:
Creating and using Lambda functions
Creating scheduled events to execute AWS Lambda functions
Here are some Java runtime examples:
Creating an AWS Lambda function that detects images with Personal Protective Equipment
Creating an Amazon Web Services Lambda function that tags digital assets located in Amazon S3 buckets
Creating an ETL workflow by using AWS Step Functions and the AWS SDK for Java
UPDATE
Once you test your code in an IDE, deploy it and test it from the Lambda console. Once it is successfully invoked, you will see a message like this:
Another option I found, this time within SAM is define the function with a different Event source.
The Lambda will be exposed if it's event source is defined as Api
You can define it as many other things (S3,Sns,Sqs etc)
Here is an example of a function triggered by and http event via api gateway, and the other one, by Sns. The config for SNS is not complete, Check this link for full details https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md
in template.yaml Notice the Events section of each Lambda definition.
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
Properties:
CodeUri: hello-world/
Handler: app.lambdaHandler
Runtime: nodejs14.x
Events:
HelloWorld:
Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
Properties:
Path: /hello
Method: get
BooBooFunction:
Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
Properties:
CodeUri: booboo/
Handler: app.lambdaHandler
Runtime: nodejs14.x
Events:
BooBoo:
Type: Sns # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
How to add an event type as Cloudfront for SAM template for a Lambda function
I have a SAM template where there will be a lambda function and Api gateway as a trigger , Now instead of Api gateway as a Trigger , I need to add an existing CLoudfront Distribution. But I am not finding any such option to do that.
cloudfrontlambda:
Type: AWS::Serverless::Function
Properties:
FunctionName: cloudfrontlambda
Handler: index.handler
Runtime: nodejs8.10
CodeUri: ./Lambda/cloudfrontlambda/
Description: Function is used for validating the id token
MemorySize: 128
Timeout: 30
Role: 'arn:aws:iam::1234567:role/DR_lambda_web_execution'
Events:
--------- ## how to add an Existing cloudfront distribution here
At present there is no event source type for CloudFront distributions within the SAM model [1]. Assuming you are attempting to create an edge lambda function, you will need to attach the function either manually or via the cloudformation template that you used to create the distribution - as it needs to be declared directly against the cloud front distribution. I’ve edited it down for brevity, but for example -
cloudfrontlambda:
Type: AWS::Serverless::Function
Properties:
FunctionName: cloudfrontlambda
Handler: index.handler
Runtime: nodejs8.10
CodeUri: ./Lambda/cloudfrontlambda/
Description: Function is used for validating the id token
MemorySize: 128
Timeout: 30
Role: 'arn:aws:iam::1234567:role/DR_lambda_web_exec’
cloudfrontdistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
CacheBehaviors:
- LambdaFunctionAssociations:
- EventType: string-value
LambdaFunctionARN: !Sub ‘${cloudfrontlambda.Arn}:${cloudfrontlambda.Version}’
E.g.
Note that your lambda function must be deployed in us-east-1 to work in this way. I can confirm that you can deploy a cloud front distribution via a cloudformation template in another region and still reference lambda functions that are deployed to us-east-1.
Also, you must specify the version of the lambda function within the ARN. The AWS::Lambda::Function cloudformation type does not provide this on its own (requiring an additional AWS::Lambda::Version resource), so this may complicate your CloudFront distribution template if it is not already contained with a SAM template.
[1] https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#event-source-object
Short answer, SNS. Long answer, you can't except for SNS.
You can't add an existing CloudFront resource, because that breaks the mold of CF. This took me a while to wrap my head around too, but essentially a CloudFront template can only create/modify resources within itself. It cannot modify resources outside of its stack. Here are a few links supporting this:
https://github.com/awslabs/serverless-application-model/issues/241
https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#s3 (specifically says existing S3 buckets cannot be an event source)
This last link shows that recently they supported importing resources from other stacks, but the resource must first be deleted from its previous stack before it can be used. I'm not sure about your architecture, but I know for mine that would break things very quickly. https://github.com/awslabs/serverless-application-model/issues/249
The work around is to add Custom Resources (lambdas) to alleviate this impediment. In the last link I sent there is an example of an SNS workaround since this limitation does not apply to SNS.
So I'm trying to convert an existing spring boot application to an AWS lambda and using SAM.
I'm trying to use aws-sam-cli to try my lambda locally, however with my SAM setup I am getting: Template does not have any APIs connected to Lambda functions
When I do: sam local start-api
My template.yml:
AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: foo
Resources:
MailFunction:
Type: AWS::Serverless::Function
Properties:
Handler: bar.LambdaHandler::handleRequest
Runtime: java8
CodeUri: target/foo-bar-1.0.jar
Timeout: 300
MemorySize: 1024
Events:
Timer:
Type: Schedule
Properties:
Schedule: rate(1 day)
Any idea what I'm doing wrong? It looks correct as far as I can tell from https://blog.couchbase.com/aws-serverless-lambda-scheduled-events-tweets-couchbase/ + https://docs.aws.amazon.com/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html
You didn't add any API Gateway event to your function. And start-api spawn a local API Gateway.
You need to add at least one Api event to your Events section.
Events:
[...]
Api:
Type: Api
Properties:
Path: /myresource
Method: get
If you just have a Schedule event, try to use generate-event to create such an event.
sam local generate-event schedule ...
and invoke function e.g. sam local invoke function-name -e event_file.json (see)
For Googlers:
Check whether you have an Event with Type: Api
ALSO check whether you have run sam build (very important)
Use the --debug flag so you will know what is going on
As of 2020/7/13, Type: HttpApi does not work with sam local start-api. See issue.
This error message also displays if you are trying to test a websocket API locally. Unfortunately, local testing of websockets is not currently supported - see https://github.com/awslabs/aws-sam-cli/issues/896.
I ran into this error too even when I did have an Api event defined in my SAM template. The problem was that I had a previous template in my .aws-sam/build/ directory which didn't have the Api event defined (from a previous run of sam build). Cleaning out the build directory fixed it.
I am getting this error, but I have function that is working with the HttpApi, it appears that current version of sam does not support HttpApi.
CLI Version
SAM CLI, version 0.52.0
Example Function
FeedsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri:
Description: "Function that handles feeds"
Events:
Handler:
Type: HttpApi
Properties:
ApiId: !Ref FeedsApi
Path: /
Method: get
Handler: api
MemorySize: 1024
Runtime: go1.x
Timeout: 5
Tracing: Active
There is currently an open issue on GitHub for adding support: https://github.com/awslabs/aws-sam-cli/issues/1641
I got this error when I had a whitespace error in my AWS::Serverless::Function definition, specifically Environment needed to be a child of Properties but was on the same level. Correcting the whitespace made this error disappear. Nodejs 10.15.
I'm finding it hard to understand the difference between SAM template and Cloudformation template. I know that SAM template can be used to define Serverless Applications like Lambda, but how does that make it different from Cloudformation template? Is the syntax different? I can still specify the Lambda definitions in cloudformation template. So, my question is why should I care about SAM? Won't knowing about just cloud formation template be sufficient?
From CloudFormation's perspective, SAM is a transform. Meaning: SAM templates are syntactically equivalent, but they allow you to define your serverless app with more brevity. The SAM template eventually gets expanded into full CFN behind the scenes. If you already know CFN, but want to write less YAML code, SAM may be beneficial to you. The idea is to reduce your effort.
SAM templates are a superset of Cloudformation. Any Cloudformation template can be run through SAM unchanged, and it will work. SAM supports all the types available in Cloudformation templates, so you can think of SAM as "CloudFormation++".
However, SAM also gives you additional "transforms" that allow you to define certain concepts succinctly, and SAM will figure out what you mean and fill in the the missing pieces to create a full, expanded, legal Cloudformation template.
Example: For SAM (and Serverless Framework) users, who deal mostly in Lambda functions, one of the more most useful transforms is the Events property on the Lambda function -- SAM will add all the objects needs to access that function through an API path in API Gateway.
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: HelloWorldFunction
Handler: app.lambdaHandler
Runtime: nodejs12.x
Events: # <--- "Events" property is not a real Cloudformation Lambda property
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
The SAM template snippet shown above gets transformed/expanded into several API Gateway objects (a RestApi, a deployment, and a stage). The AWS::Serverless::Function type used in this snippet is not a real Cloudformation type -- you won't find it in the docs. SAM expands it into a Cloudformation template containing a AWS::Lambda::Function object and several different AWS::ApiGateway::* objects that Cloudformation understands.
To give you an idea of how much manual coding this saves you, here's what the expanded version of the above SAM template looks like as a full Cloudformation template:
Resources:
HelloWorldFunctionHelloWorldPermissionProd:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
FunctionName:
Ref: HelloWorldFunction
SourceArn:
Fn::Sub:
- arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/${__Stage__}/GET/hello
- __Stage__: "*"
__ApiId__:
Ref: ServerlessRestApi
HelloWorldFunctionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Action:
- sts:AssumeRole
Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Tags:
- Value: SAM
Key: lambda:createdBy
ServerlessRestApiProdStage:
Type: AWS::ApiGateway::Stage
Properties:
DeploymentId:
Ref: ServerlessRestApiDeployment_NNN
RestApiId:
Ref: ServerlessRestApi
StageName: Prod
ServerlessRestApiDeployment_NNN:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId:
Ref: ServerlessRestApi
Description: 'RestApi deployment id: ???'
StageName: Stage
ServerlessRestApi:
Type: AWS::ApiGateway::RestApi
Properties:
Body:
info:
version: '1.0'
title:
Ref: AWS::StackName
paths:
"/hello":
get:
x-amazon-apigateway-integration:
httpMethod: POST
type: aws_proxy
uri:
Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HelloWorldFunction.Arn}/invocations
responses: {}
swagger: '2.0'
HelloWorldFunction:
Type: AWS::Lambda::Function
Properties:
Code:
S3Bucket: aws-sam-cli-managed-default-samclisourcebucket-???
S3Key: temp/???
Tags:
- Value: SAM
Key: lambda:createdBy
Handler: app.lambdaHandler
Role:
Fn::GetAtt:
- HelloWorldFunctionRole
- Arn
Timeout: 3
Runtime: nodejs12.x
Previously, if you were authoring pure Cloudformation, you would have had to code all this by hand, over and over, for each API Gateway endpoint that you wanted to create. Now, with a SAM template, you define the API as an "Event" property of the Lambda function, and SAM (or Serverless Framework) takes care of the drudgery.
In the old days, when we had to do all this by hand, it totally sucked. But now, everything is glorious again.
Like #Luis Colon said, SAM is a transform. What that means, is that at the top of a SAM Template there is a Transform statement that lets CloudFormation know to run an intrinsic function, Transform, on this SAM template to turn it into a CloudFormation template. So, all SAM Templates will eventually be converted into CF templates, but for the end-user in most cases it is easier to just use the SAM template. For instance, for a simple application with Lambdas triggered by a new API you're creating, the SAM template will let you accomplish this in fewer lines than CloudFormation.
To extend this, the Serverless Framework behaves similarly. Serverless is designed to work across platforms (AWS, Azure, etc.). It's syntax looks very similar to SAM, and it too converts the template into the target platform's (ie. AWS) fuller version of the template (ie. CloudFormation template).
You can imagine SAM as an extended form of CloudFormation. SAM makes Serverless/Lambda deployments easier.
Even CloudFormation can deploy lambda scripts using inline scripts but it has a limitation of 4096 characters and you cannot pack custom dependencies, python libraries.
So to make Lambda/Serverless deployments easy SAM is used. SAM is a CLI tool. You cannot find SAM in AWS Console.
In case of python deployment, sam will read the requirements.txt file build a package, and will deploy the package when you wish to sam deploy
So at the end of the day you can write as much lengthy Lambda Code, use as many libraries you want and even import your custom libraries i.e. complete flexibility.
I'm creating a Nodejs microservice for AWS Lambda. I scaffolded by project using AWS Codestar, and that set me up with a CI/CD pipeline that automatically deploys the lambda function. Nice.
The issue is that every time it deploys the lambda function it must delete and recreate the function, thus deleting any versions or aliases I made.
This means I really can't roll back to other releases. I basically have use git to actually revert the project, push to git, wait for the super-slow AWS Code Pipeline to flow through successfully, and then have it remake the function. To me that sounds like a pretty bad DR strategy, and I would think the right way to rollback should be simple and fast.
Unfortunately, it looks like the CloudFormation section of AWS doesn't offer any help here. When you drill into your stack on the first CloudFormation page it only shows you information about the latest formation that occurred. Dear engineers of AWS CloudFormation: if there was a page for each stack that showed a history of CloudFormation for this stack and an option to rollback to it, that would be really awesome. For now, though, there's not. There's just information about the latest formation that's been clouded. One initially promising option was "Rollback Triggers", but this is actually just something totally different that lets you send a SNS notification if your build doesn't pass.
When I try to change the CodePipeline stage for deploy from CREATE_CHANGE_SET to CREATE_UPDATE I then get this error when it tries to execute:
Action execution failed UpdateStack cannot be used with templates
containing Transforms. (Service: AmazonCloudFormation; Status Code:
400; Error Code: ValidationError; Request ID:
bea5f687-470b-11e8-a616-c791ebf3e8e1)
My template.yml looks like this by the way:
AWSTemplateFormatVersion: 2010-09-09
Transform:
- AWS::Serverless-2016-10-31
- AWS::CodeStar
Parameters:
ProjectId:
Type: String
Description: AWS CodeStar projectID used to associate new resources to team members
Resources:
HelloWorld:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs8.10
Environment:
Variables:
NODE_ENV: staging
Role:
Fn::ImportValue:
!Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]
Events:
GetEvent:
Type: Api
Properties:
Path: /
Method: get
PostEvent:
Type: Api
Properties:
Path: /
Method: post
The only options in the CodePipeline "Deploy" action are these:
It would be really great if someone could help me to see how in AWS you can make Lambda functions with CodePipeline in a way that they are easy and fast to rollback. Thanks!