Tag: aws

Posted on

New AWS Console with ‘favorites’

I just got prompted to switch to the new AWS Console and found this new feature that I’ve always though would be useful, and now here it it 🙂 You can now flag specific services as your ‘favorites’ and they appear in a ribbon bar across the top of your console and in a widget on the console page. Here’s my 3 ‘favorited’ services in the bar at the top of the console:

If you go to ‘Action’ then ‘Add widgets’ you can also add a favorites section and drag it to a location on your console page:

Here it is at the top of my console page:

Previously we had the ‘Recently visited’ section on the Console, but the items in the list would move around depending which you most recently used. Now with favorites you can pin the services you’re most often using so you can more easily access them.

Posted on

AWS connect-streams api testing locally: issues and workarounds

To initialize the Connect CCP using amazon-connect-streams api in a webpage locally there are several steps to configure. The most likely errors if you haven’t followed all the steps is a X-Frame-Options sameorigin error which you’ll see in your devtools console:

… or a Content Security Policy error if you haven’t added your origin url to Connect’s allowed origins:

Add your origin url to Connect following steps here. If you’re loading from an http server locally, you need to add the full url and port, e.g. https://localhost:8080

Allow cookies: if your default browser settings are to block third-party cookies from different origins, this will prevent the app from loading (you’ll get the same X-Frame-Options error which is confusing). Make sure you allow all the cookies from [your-connect-instance-name].awsapps.com – in the screenshot these should all be allowed:

Posted on

Using Serverless Framework to build and deploy Docker images for AWS Lambdas

AWS Lambdas can be packaged and deployed using a Docker image, described in the docs here.

Serverless Framework makes building and deploying a Docker based Lambda incredibly simple. If you have a simplest Dockerfile like this (from the docs here):

FROM public.ecr.aws/lambda/nodejs:14

# Assumes your function is named "app.js", and there is a package.json file in the app directory 
COPY app.js package.json  ${LAMBDA_TASK_ROOT}

# Install NPM dependencies for function
RUN npm install

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.handler" ]

The handler to be packaged in this image is this simplest hello world function:

exports.handler =  async function(event, context) {
    console.log("EVENT: \n" + JSON.stringify(event, null, 2))
    return "hello!"
  }

To define a Lambda using this image, with Serverless define an ECR section like this to define your image, which will get built using the above Dockerfile in the same folder:

service: lambda-container-1

provider:
  name: aws
  ecr:
    images:
      lambda-container-example:
        path: ./

functions:
  hello:
    image:
      name: lambda-container-example

Run ‘serverless deploy’ and it builds the image, uploads to ECR, and deploys the Lambda all for you.

After deploying, on first test I got this error:

  "errorMessage": "RequestId: 58fe500f-26ee-44ba-b6a9-6079b6ff2896 Error: fork/exec /lambda-entrypoint.sh: exec format error",
  "errorType": "Runtime.InvalidEntrypoint"

The key part of this error is this “exec format error”. I’m building and deploying this from my M1 MacBook Pro, which is Apple’s arm64, not x64.

If we look in the AWS Console for this lambda, on the first page under Image you’ll see the Lambda runtime architecture:

Updating the serverless.yml to include ‘architecture: arm64’, redeploy and now the architecture is arm64:

Invoking with ‘serverless invoke –function hello’ and now it successfully runs!

Proudly powered by WordPress