Category Archives: Lambda

Adding a Custom Domain Name – AWS SAM

Hi everyone,

It’s been a long time but I’m messing around with AWS SAM again. I’m currently converting into an AWS SAM application. As part of this I needed to add a custom domain. Unfortunately, the doco on how to do this isn’t great so I’m going to share what ended up working for me just in case it helps someone else.

To start, these are the resources that you’ll need in your template.yaml:


    Type: AWS::CertificateManager::Certificate
      DomainName: !Sub api-${Stage}
      ValidationMethod: DNS

    Type: AWS::Serverless::Api
      StageName: !Ref Stage
      # Allows to call these APIs
      # SAM will automatically add AllowMethods with a list of methods for this API
      Cors: "''"
      EndpointConfiguration: REGIONAL
        DomainName: !Sub api-${Stage}
        CertificateArn: !Ref ApiCertificate
          HostedZoneName: "" # NOTE: The period at the end is required

You’ll also need to make sure your reference the gateway from your function:

  # This lambda function handles is used to test endpoint availability.
    Type: AWS::Serverless::Function
      Handler: src/handlers/get-ping.getPingHandler
      Runtime: nodejs14.x
        - x86_64
      MemorySize: 128
      Timeout: 30
          Type: Api
            Path: /ping2 # NOTE: AWS overrides the ping command.
            Method: GET
              Ref: ApiGatewayApi # NOTE: Make sure you have this referencing correctly.
      Description: Responds with 'Pong' if successful.

Now when you run AWS deploy it will continue as usual until it gets to the stage of creating your certificate:

Here it is looking for a specific DNS entry in order to confirm that you own the domain. You’ll need to go into Route53 (or whichever other DNS provider you’re using) and add a CNAME entry with the specified details:

Note that your name and value contents should come from the output of the ApiCertificate job (highlighted in the screenshot above).

Once that’s done you’ll need to wait about sixty seconds for the DNS records to propagate within AWS. You should then be able to access your api using the new domain:

Thanks to the follow github post for the pointers in the right direction:

aws sam No hosted zones named found

Note that if you get the error above when trying to deploy please ensure that you’ve added the trailing “.” to your Route53 HostedZoneName in the api-gateway in your template.yaml:

        DomainName: !Sub api-${Stage}
        CertificateArn: !Ref ApiCertificate
          HostedZoneName: "" # NOTE: The period at the end is required

Access to fetch from origin has been blocked by CORS policy – AWS SAM Local

Hi everyone,

I’ve been using AWS SAM local lately and ran into a bit of an issue with CORS. It took a looong time to find a solution that worked for all of my local scenarios so hopefully this will be able to help someone else out.

Access to fetch at '' from origin 'http://localhost:3001' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

The error above is fairly typical when working with APIs. The request will work from tools such as postman and fiddler but browsers will block it. These are a few good links that explain why CORS is necessary:

As for the solution, add the following to your template.yml:

    Type: AWS::Serverless::Function
      Handler: functions/generic/cors.getPreflightHandler
      Runtime: nodejs8.10
          Type: Api
            Path: /pages
            Method: options
            RestApiId: !Ref XXXApi
              Authorizer: NONE

If you haven’t already defined your api in your template.yml file there is a default/omitted one created for you. There are a few examples on the AWS github:

The next thing to do is to create a handler for the options request:

/* Handles retrieving a specific page */
exports.getPreflightHandler = async (event, context, callback) => {
    callback(null, { body: {} }, headers: { 'content-type': 'application/json', 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Headers': 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token', 'Access-Control-Allow-Methods': 'OPTIONS,GET,POST,PUT,PATCH,DELETE', 'Access-Control-Allow-Credentials': true }, statusCode: 200 })

I’ve moved all mine out to some helper methods but the above should be enough to get it working for you. Hopefully the AWS team will have a simpler solution soon but if you run into any issues in the meantime please let me know!

Overriding Global Variables – AWS SAM Local

Hi everyone,

Today I’ve added local overrides to the global variables in my template.yml file. This was pretty finicky – a lot of conflicting suggestions out there unfortunately. These are the settings that ended up working for me.


    "Parameters": {
        "RDS_HOSTNAME_TEST": ""


          Type: String
          Default: 'DEFAULT'

aws sam local command:

sam local start-api --env-vars "local-env-var-overrides.json"


exports.createTrapHandler = async (event, context, callback) => {

	try {

        console.log("RDS_HOSTNAME_TEST: " + process.env.RDS_HOSTNAME_TEST)
        // Outputs:

This link ended up being pretty useful:

Get User Id in Lambda node.js

Hi everyone,

A quick post on where to find the user id (sub) in a lambda requested that has been authenticated with a congito authorizer.

You’ll be able to find everything you need in the event object under requestContext > authorizer > claims:

exports.viewContextHandler = async (event, context, callback) => {

"requestContext": {
    "resourceId": "XXXXX",
    "authorizer": {
        "claims": {
            "at_hash": "XXXXX",
            "sub": "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX",
            "aud": "XXXXX12341234512345XXXXX",
            "email_verified": "true",
            "token_use": "id",
            "auth_time": "1547371205",
            "iss": "",
            "cognito:username": "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX",
            "exp": "Sun Jan 13 10:20:05 UTC 2019",
            "iat": "Sun Jan 13 09:20:05 UTC 2019",
            "email": "XXXXX@XXXXX.XXXXX"

Parsing DynamoDB Items – AWS Lambda with Node.js

Hi everyone,

A quick post on how to parse DynamoDB items into something more readable when using lambda with Node.js:



    CatBreedId: { S: '17acbc81-2b4a-462b-be87-bcc49580b1ae'},
    Name: { S: 'Cat #1'}



    "CatBreedId": "17acbc81-2b4a-462b-be87-bcc49580b1ae",
    "Name": "Cat #1"

Official doco is here:

Thanks to the following stackoverflow post for the info:

AWS 2_ContinuousDeliveryPipeline Tutorial – Error: no test specified

Hi everyone,

I ran into the following error while completing an AWS tutorial:

C:UsersChris-PCsourcereposUniApiuni-apitest>npm test

> uni-api-test@1.0.0 test C:UsersChris-PCsourcereposUniApiuni-api
> echo ‘Error: no test specified’

‘Error: no test specified’

The solution was to add the following line to my package.json file:

“scripts”: {“test”: “mocha”}

Now when running npm test I get the expected test output:

4 passing (24ms)
1 failing

1) Reading Unicorns
errors on missing unicorn data:

AssertionError [ERR_ASSERTION]: 500 == 404
+ expected – actual


at lambda.lambda_handler (testread.spec.js:77:20)
at appread.js:20:10
at Object.get (testread.spec.js:34:33)
at Object.exports.lambda_handler (appread.js:18:13)
at Context. (testread.spec.js:65:16)

npm ERR! Test failed. See above for more details.

Thanks to this link for the answer:

An error occurred (UnrecognizedClientException) when calling the CreateFunction operation: The security token included in the request is invalid.

Hi everyone,

I ran into the following error today while attempting to create a Lambda function using the CLI:

An error occurred (UnrecognizedClientException) when calling the CreateFunction operation: The security token included in the request is invalid.

The first thing to check is that your aws config is setup correctly. For me this is under

If that looks fine, double check that the associated user has the correct rights by viewing the IAM page in the server console:

Finally, ensure that the user has programmatic access and that the keys match those in your config.