DEV Community: Tomasz Łakomy

Quick guide to CSS Grid

Tomasz Łakomy — Wed, 27 Dec 2023 18:29:12 +0000

Grid Container

First, you designate an element as a grid container. This element will hold the grid items (your content). You can do this by setting the element's display property to grid or inline-grid.

.container {
  display: grid;
}

/* Or for an inline grid */
.inline-container {
  display: inline-grid;
}

Defining Rows and Columns

You define the rows and columns in the grid container using grid-template-rows and grid-template-columns.

.container {
  display: grid;
  grid-template-columns: 100px 200px auto;
  grid-template-rows: 50px 100px;
}

Grid Gap

Grid gap is the space between each row and column. Use grid-gap, grid-row-gap, and grid-column-gap.

.container {
  display: grid;
  grid-gap: 10px; /* Space between rows and columns */
}

Placing Items

You can place grid items in specific locations using grid-column-start, grid-column-end, grid-row-start, and grid-row-end.

.item {
  grid-column-start: 1;
  grid-column-end: 3;
  grid-row-start: 2;
  grid-row-end: 4;
}

Shorthand Properties

There are shorthand properties for quicker definitions.

.item {
  grid-column: 1 / 3; /* Start at line 1 and end at line 3 */
  grid-row: 2 / 4;
}

Fractional Units (fr)

The fr unit allows you to distribute available space in fractions.

.container {
  grid-template-columns: 1fr 2fr 1fr; /* 2nd column is twice as wide as the others */
}

Repeat Function

To avoid repetition, use repeat().

.container {
  grid-template-columns: repeat(3, 1fr); /* Creates 3 columns of equal width */
}

auto-fill and auto-fit

auto-fill and auto-fit are used with repeat() to automatically place as many items as possible.

.container {
  grid-template-columns: repeat(auto-fill, minmax(100px, 1fr));
}

Grid Areas

Define areas in your grid and assign items to these areas.

.container {
  grid-template-areas: 
    "header header header"
    "sidebar content content"
    "footer footer footer";
}

.header {
  grid-area: header;
}

Responsive Design

You can create responsive designs by combining CSS Grid with media queries.

.container {
  grid-template-columns: 1fr;
}

@media (min-width: 600px) {
  .container {
    grid-template-columns: 1fr 1fr;
  }
}

Practice

The best way to learn CSS Grid is through practice. Try creating a basic layout with a header, sidebar, main content area, and footer. Experiment with different configurations and see how the elements rearrange themselves.

CloudFront Functions vs. Lambda@Edge: what's the difference?

Tomasz Łakomy — Wed, 22 Nov 2023 11:34:01 +0000

AWS announced CloudFront KeyValueStore yesterday which enhances the capabilities of CloudFront Functions. In case you're not familiar, here's a quick summary of what CloudFront Functions do:

Amazon CloudFront allows you to securely deliver static and dynamic content with low latency and high transfer speeds. With CloudFront Functions, you can perform latency-sensitive customizations for millions of requests per second. For example, you can use CloudFront Functions to modify headers, normalize cache keys, rewrite URLs, or authorize requests.

You may also be familiar with Lambda@Edge which is a similar service that allows you to run Lambda functions at the edge of the AWS network. To quote the AWS docs:

Lambda@Edge is a feature of Amazon CloudFront that lets you run code closer to users of your application, which improves performance and reduces latency. With Lambda@Edge, you don't have to provision or manage infrastructure in multiple locations around the world. You pay only for the compute time you consume - there is no charge when your code is not running.

Reading those two descriptions you may be wondering - what's the difference between those two services? Let's take a look!

Programming language: Lambda@Edge supports Node.js and Python. CloudFront Functions support JavaScript only. Not really a problem for me personally (I'm a JavaScript developer) but it's worth mentioning.
Execution Location: Lambda@Edge functions are executed in 13 CloudFront Regional Edge Caches, whereas CloudFront Functions are executed in 225+ CloudFront Edge Locations. This means that CloudFront Functions are may be executed closer to the end user, which means lower latency.

Trigger points

CloudFront Functions can be triggered by the following events:

When CloudFront receives a request from a viewer (viewer request)
Before CloudFront returns the response to the viewer (viewer response)

Lambda@Edge function can be triggered when:

CloudFront receives a request from a viewer (viewer request)
Before CloudFront returns the response to the viewer (viewer response)
CloudFront forwards a request to your origin (origin request)
After CloudFront receives the response from the origin and before it caches the object in the response (origin response)

Limits

Maximum execution time: CloudFront Functions need to finish under a millisecond (so if your code is as slow as mine, you should consider using Lambda@Edge). Lambda@Edge functions can run for up to 5 seconds for viewer request and viewer response triggers, and up to 30 seconds for origin request and origin response triggers.
Network access: CloudFront Functions can't access the network. Lambda@Edge functions can access the network.
HTTP manipulation: CloudFront Functions can only manipulate HTTP headers. If you need to remove or replace the body of an HTTP request or response, use Lambda@Edge instead.
Filesystem access: CloudFront Functions don't have access to filesystem (which makes sense, especially given the 1ms limit). Lambda@Edge functions can access the filesystem.
Scale: CloudFront Functions can scale to 10,000,000 requests per second or more. Lambda@Edge functions can scale up to 10,000 requests per second per Region.
Memory: CloudFront Functions have 2MB of memory available. Lambda@Edge functions have 128MB - 3GB of memory available.
Maximum function size: CloudFront Functions need to be tiny - they can't be larger than 10KB. Lambda@Edge functions can be up to 1MB in size (for viewer request and viewer response triggers) and 50MB in size (for origin request and origin response triggers).

Use cases

CloudFront Functions

Cache key normalization – You can transform HTTP request attributes (headers, query strings, cookies, and even the URL path) to create an optimal cache key, which can improve your cache hit ratio.
Header manipulation – You can insert, modify, or delete HTTP headers in the request or response. For example, you can add a True-Client-IP header to every request.
URL redirects or rewrites – You can redirect viewers to other pages based on information in the request, or rewrite all requests from one path to another.
Request authorization – You can validate hashed authorization tokens, such as JSON web tokens (JWT), by inspecting authorization headers or other request metadata.

Lambda@Edge

Functions that take several milliseconds or more to complete.
Functions that require adjustable CPU or memory.
Functions that depend on third-party libraries (including the AWS SDK, for integration with other AWS services).
Functions that require network access to use external services for processing.
Functions that require file system access or access to the body of HTTP requests.

Full Stack TypeScript with AWS Cloud Development Kit v2

Tomasz Łakomy — Wed, 22 Nov 2023 08:56:34 +0000

I've just released my latest course Full Stack TypeScript with AWS Cloud Development Kit course for egghead.io

Really excited about this one, in this course you'll learn how to build full stack applications on AWS with only a single programming language - TypeScript.

That's right - frontend, backend and infrastructure - all provisioned in AWS by nothing more than sheer force of TypeScript (and willpower).

17 lessons, 47 minutes - easily watchable during a lunch break.

If you are a web developer who has never touched AWS - by all means, give this course a shot. In less than an hour we're going to cover:

creating a new CDK app
building and deploying AWS Lambda functions
creating an API Gateway
using DynamoDB
deploying static sites to AWS

And much more!

The best part? We're barely touching the AWS Console - with CDK we get to build cloud infrastructure using familiar programming languages we love (or at least - tolerate).

All you need is a little bit of TypeScript to build full stack applications.

Hope you like it, and have fun learning!

Full Stack TypeScript with AWS Cloud Development Kit course for egghead.io

Overview of AWS Lambda internal extensions

Tomasz Łakomy — Thu, 16 Nov 2023 13:23:07 +0000

Before we start - this blogpost is strongly inspired by excellent AWS Lambda extensions: The deep dive series by Julian Wood.

What are AWS Lambda extensions?

AWS Lambda extensions allow you augement your Lambda functions, for instance to more easily integrate your Lambda functions with your favorite (or the ones you can afford!) third party tools and services for monitoring, observability, security, and governance.

Lambda supports both internal and external extensions, with a number of differences between the two:

External extensions run as an independent process in the execution environment and continue to run after the Lambda function invocation completes. They can be written in any language and can be packaged and deployed as Lambda layers. External exentions can be used to perform tasks such as monitoring, observability, security, and governance. Moreover, they can be used with any Lambda runtime.
Internal extensions run within the runtime, in-process with your code as a separate thread. There are two ways an internal extension is accessed by a function:
- in-process mechanism (such as NODE_OPTIONS)
- a wrapper script that customizes the runtime startup behavior of a Lambda function

Modifying the runtime environment with internal AWS Lambda extensions

Internal extensions allow you to modify the runtime environment of your Lambda functions. This can be done in two ways:

Language-specific environment variables

Lambda supports configuration-only ways to enable code to be pre-loaded during function initialization through the following language-specific environment variables:

JAVA_TOOL_OPTIONS - this environment variable allows you to set additional command-line variables in Lambda. For instance you can specify the initialization of tools, specifically the launching of native or Java programming language agents using the agentlib or javaagent options.
- As an example you can custom garbage collector behavior by setting JAVA_TOOL_OPTIONS to -XX:+UseParallelGC. See AWS docs on JAVA_TOOL_OPTIONS for more details.
NODE_OPTIONS - Lambda supports this environment variable - all available options would be a bit of an overkill for a blogpost, but you can find all of them in Node.js documentation.
- Speaking of documentation - AWS docs say that "On Node.js 10x and above, Lambda supports this environment variable". Which is technically true but as of this writing the lowest available Lambda runtime version of Node.js is Node.js 14. I took the liberty of sending feedback to AWS to update the docs.
- Side note: Node.js 20 Lambda was announced yesterday!
DOTNET_STARTUP_HOOKS - to quote the docs: "on .NET Core 3.1 and above, this environment variable specifies a path to an assembly (dll) that Lambda can use.".

Wrapper scripts

You can create a wrapper script to customize the runtime startup behaviour of your Lambda function which allows you to set configuration parameters that cannot be set through language specific environment variables described above.

Bear in mind that invocations may fail if the wrapper script does not successfully start the runtime process, so tread carefully. Consider not modifying the wrapper script on a Friday.

When you use a wrapper script for your function, Lambda starts the runtime using your script. Lambda sends to your script the path to the interpreter and all of the original arguments for the standard runtime startup.

In order to specify the script set the value of AWS_LAMBDA_EXEC_WRAPPER environment variable to the path of the script. The script must be executable. Here's an example of a wrapper script for Python


  #!/bin/bash

  # the path to the interpreter and all of the originally intended arguments
  args=("$@")

  # the extra options to pass to the interpreter
  extra_args=("-X" "importtime")

  # insert the extra options
  args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")

  # start the runtime with the extra options
  exec "${args[@]}"

BTW, if you'd like to learn more about AWS Lambda environment variables, consider checking out Guide to default AWS Lambda environment variables.

Creating a safe external HTML link - what's the deal with nofollow / noopener / norefferer ?

Tomasz Łakomy — Wed, 08 Nov 2023 07:57:30 +0000

In HTML, when you create a link using the <a> element, you can add various attributes to control the behavior of that link. The rel attribute specifically defines the relationship between the current document and the linked document.

nofollow: This instructs search engines not to follow the link for crawling purposes. It's often used to signal that the site providing the link does not endorse the linked content. This is important for SEO (Search Engine Optimization) because it tells search engines not to pass along ranking credit to the linked page.
noopener: This prevents the new page from being able to access the window.opener property and ensures it runs in a separate process. Without this, the new page can potentially redirect your page to a different URL. It's a security feature, particularly important when target="_blank" is used, which opens the link in a new tab or window.
noreferrer: When a user clicks a link, the browser generally sends an HTTP header called Referer (sic) to the new page, which indicates the URL of the previous page. The noreferrer attribute value prevents the browser from sending this referer header, which enhances privacy by not disclosing the source page's URL. It also has implications similar to noopener with regard to security.

Here’s how you might see these attributes in an <a> tag:

<a href="https://externalwebsite.com" rel="nofollow noopener noreferrer external" target="_blank">Visit External Website</a>

href="https://externalwebsite.com": Specifies the URL of the linked document.
rel="nofollow noopener noreferrer": Specifies the relationship between the current document and the linked one with the terms explained above.
target="_blank": Opens the linked document in a new window or tab.

Use patterns in CloudWatch Logs Insights to investigate production issues faster

Tomasz Łakomy — Mon, 16 Oct 2023 10:50:40 +0000

Browsing through CloudWatch Logs can be a chore, especially when you're debugging a production issue. Having to sift through thousands (if not more!) log lines can be a daunting task, especially when you're not sure what you're looking for.

Let's take an example - suppose we're working on a serverless app that uses DynamoDB as a database. We're seeing some errors in our Lambda functions and we want to see if there's anything in the logs that could help us debug the issue.

Customers reported issues with the logic handled by createUser function so let's see what's going on by running a basic Logs Insights query:



fields @timestamp, @message, @logStream, @log
| sort @timestamp desc
| limit 20

As you can see - by default we're getting all the logs, including START, REPORT and END entries. While they can be useful in some cases, they're not really helpful in our case. Let's narrow down the search by looking only for errors.



fields @timestamp, @message, @logStream, @log
| sort @timestamp desc
| filter @message like /(?i)error/
| limit 20

If you're confused about that /(?i)error/ syntax, you may want to check out Match case-insensitive patterns when using CloudWatch Logs Insights article.

Okay, this is slightly better - we're getting only the logs that contain the word error in them. Since we applied a limit command, we're only getting latest 20 entries, which is a lot to go through (especially at 2am).

When investigating a production issue our goal is to get to the root cause as quickly as possible. We don't want to spend time looking through the logs, we want to find the issue and fix it.

Here's how the new addition to CloudWatch Logs Insights - pattern keyword - can help.

Let's update our query:



fields @timestamp, @message, @logStream, @log
| sort @timestamp desc
| filter @message like /(?i)error/
| pattern @message # this is new!

This is more like it! Instead of getting tons of very similar log lines, CloudWatch managed to uncover patterns in our @message field and group them together.

For instance, a following log entry:



2023-10-16T10:13:50.458Z    b32f908e-c884-4803-b496-33099d173f99    INFO    {
  message: 'Error: cannot create user',
  timestamp: 'Mon, 16 Oct 2023 10:13:50 GMT',
  requestId: '275828cf-9315-4bbd-8de4-a40555be8fb2',
  userId: '10cf0eb6-96fc-4da3-b135-99e193fe6ed9'
}

is turned into the following after applying the pattern keyword:



<*> <*> INFO    {
  message: 'Error: cannot create user',
  timestamp: 'Mon, <*> <*> <*> <*> GMT',
  requestId: <*>,
  userId: <*>
}

As we can see - the pattern keyword is able to identify patterns in our log lines and group them together. This is a huge time saver, especially when you're dealing with a lot of logs. We're no longer seeing unrelevant fields like requestId or userId - we're only seeing the fields that are relevant to us, such as the error message.

With that knowledge we're ready to dig into our codebase and fix the issue.

In the screenshot above you may have noticed other fields such as @ratio, @sampleCount and @severityLabel, let's see what AWS docs have to say about them:

The pattern command produces the following output:

@pattern: A shared text structure that recurs among your log event fields. Fields that vary within a pattern, such as a request ID or timestamp, are represented by <*>. For example, [INFO] Request time: <*> ms is a potential output for the log message [INFO] Request time: 327 ms.

@ratio: The ratio of log events from a selected time period and specified log groups that match an identified pattern. For example, if half of the log events in the selected log groups and time period match the pattern, @ratio returns 0.50

@sampleCount: A count of the number of log events from a selected time period and specified log groups that match an identified pattern.

@severityLabel: The log severity or level, which indicates the type of information contained in a log. For example, Error, Warning, Info, or Debug.

In conclusion: pattern command is something I'm definitely adding to my workflow and my only wish is that it was available sooner. It's a huge time saver and it can help you get to the root cause of the issue much faster.

Match case-insensitive patterns when using CloudWatch Logs Insights

Tomasz Łakomy — Tue, 10 Oct 2023 12:10:58 +0000

👋

I found myself Googling (or rather - ChatGPTing) this one too many times so I decided to write it down.

If you're looking for errors in your CloudWatch Logs you can use CloudWatch Logs Insights to query your logs. One of the most commonly used commands is filter which allows you to filter your logs that match one or more conditions, here's an example:

fields @timestamp, @message
| filter (range>3000 and accountId=123456789012)
| sort @timestamp desc
| limit 20

To be honest I rarely find myself using filter like this, but I often use it to filter logs that match a specific pattern, for example:

fields @timestamp, @message, @logStream, @log
| filter @message like /error/

Note the like keyword here - this is a signal for CloudWatch Logs Insights to treat the pattern as a regular expression. (You can use =~ instead of like if you want, e.g. filter @message =~ /error/ but I personally find it more confusing to read).

There is one problem with this query, suppose that our error log entry looks like this:

console.log({
  message: "Error: cannot create user",
  timestamp: new Date().toUTCString(),
  requestId: faker.random.uuid(),
  userId: faker.random.uuid(),
});

(Obviously don't use faker.random.uuid() in prod, this is just an example).

If we type filter @message like /error/ we won't get any results because the pattern is case-sensitive. To make it case-insensitive we need to add (?i) to the beginning of the pattern, like this:

fields @timestamp, @message, @logStream, @log
| filter @message like /(?i)error/

This will match error, Error, ERROR or even eRroR and we'll get the results we're looking for.

Additional tip:

One more thing - if you want to filter all logs that are not errors (e.g. if you don't want to ruin your weekend), you can use not like syntax, like this:

fields @timestamp, @message, @logStream, @log
| filter @message not like /(?i)error/

Intro to CloudWatch Logs Live Tail

Tomasz Łakomy — Mon, 04 Sep 2023 15:46:21 +0000

AWS has recently introduced a new feature for real-time log analytics: CloudWatch Logs Live Tail.

You can now view your logs interactively in real-time as they’re ingested, which helps you to analyze and resolve issues across your systems and applications.

To access this feature, log in to your AWS account, choose Logs->Live tail, select log groups of interest (up to 10), apply filters as needed and you're good to go.

Sample filters source:

error 404 displays only log events that include both error and 404
?Error ?error displays log events that include either Error or error
-INFO displays all log events that don't include INFO
{ $.eventType = "UpdateTrail" } displays all JSON log events where the value of the event type field is UpdateTrail

Feature overview, as described by AWS:

Real-Time Viewing: See logs interactively as they're ingested. No more waiting.
Rich User Experience: Easily view and detect issues in incoming logs.
Granular Controls: Filter, highlight, pause, and replay logs on-the-go.
Quick Validation: Ideal for DevOps teams, validate processes, configuration changes, and deployment success in real time.

Once you get tired of watching your logs fly in real time, you can either copy or download the logs for further analysis as CSV, JSON or XLSX (for hard core Excel fans out there).

All logs can be filtered based on log group, log stream and custom filter patterns. For instance you can find all ERROR logs in a given log group.

Summary:

Overall I think this is a great addition to the CloudWatch Logs ecosystem. It's a simple feature that can save you a lot of time when debugging issues in your application. Not that I ever have a production outage 😎, but if I did, I'd definitely use this feature to help me resolve it. The only weird bit is the N events/sec screen, in my testing it was not entirely accurate, but then again - my sample UserService is not exactly a production-grade application.

AWS Lambda storage options

Tomasz Łakomy — Wed, 21 Sep 2022 19:46:18 +0000

If you're building a serverless app, you're most likely using AWS Lambda.

Lambda functions are (by design) emphemeral, which means that their execution environments exist briefly when the function is invoked. Which presents an interesting challenge:

What if I need access to storage in my Lambda function?

The seemingly obvious answer to this question is "use a database".

As with most obvious answers, this one is not entirely correct. For instance, storing third-party libraries in DynamoDB would surely be an interesting idea, but not exactly practical.

Good luck storing node_modules in DynamoDB, by the way.

Other potential use cases include machine learning models, image processing, the output of your business-specific compute operation and more.

The goal of this post is to give you an overview of the different storage options available to you when building serverless applications with AWS Lambda, their differences and common use-cases.

Amazon S3

Amazon S3 is a widely popular object storage service, offering high availability and 11 9's of durability. It's a great choice for storing unstructured static assets, such as images, videos, documents, etc.

S3 is a common element of serverless architecture diagrams, to quote AWS docs:

S3 has important event integrations for serverless developers. It has a native integration with Lambda, which allows you to invoke a function in response to an S3 event. This can provide a scalable way to trigger application workflows when objects are created or deleted in S3.

Not only can you invoke a Lambda function whenever an object is placed into an S3 bucket, but you can also both retrieve and send data to/from S3 in your Lambda function invocation. This is often useful because Lambda can be invoked with 6MB payload in a synchronous manner and 256kB in an asynchronous manner. Should you need a larger dataset, you can consider fetching that from S3.

Storing data in S3 has an additional benefit, given how well it integrates with other AWS services. For instance, you can use Amazon Athena to query your S3 data, or Amazon Rekognition to analyze it. Additionally you can use AWS Glue to perform extract, transform, and loan (ETL) operations. To create ad hoc visualizations and business analysis reports, Amazon QuickSight can connect to your S3 buckets and produce interactive dashboards.

Check out S3 FAQ to learn more.

Temporary storage, also known as /tmp

Another interesting storage option available for AWS Lambda functions is its execution environment file system, available at /tmp. There are multiple factors to consider before using /tmp as a storage option:

It has a fixed size of 512MB
Because of the way Lambda is designed, the same execution environment will be reused by multiple invocations to optimize performance
Each new execution environment starts with an empty /tmp directory

In short - /tmp works well for ephemeral storage which should be shared between invocations with an added benefit of fast I/O throughput. As an example you may want to fetch a machine learning model, store it in /tmp and use it in your Lambda function. That way you won't need to fetch it from S3 during every invocation.

Amazon EFS for Lambda

Speaking of file systems - AWS Lambda comes with a support for EFS. Amazon EFS is a fully managed, elastic, shared file system that integrates with other AWS services.

The biggest difference between aforementioned /tmp is that EFS is a durable storage that offers high availability.

You may wonder whether mounting a file system increases the cold start time, according to AWS:

The Lambda service mounts EFS file systems when the execution environment is prepared. This happens in parallel with other initialization operations so typically does not impact cold start latency. If the execution environment is warm from previous invocations, the mount is already prepared. To use EFS, your Lambda function must be in the same VPC as the file system.

Potential use cases for EFS include ingesting/writing large files durably, for instance large zip archives (e.g. machine learning models). Since EFS is a file system, you can append to existing files (unlike S3 where a new version of a whole object gets created).

Lambda layers

Insert Shrek onion quote here

Lambda functions can (and often do) use additional libraries as a part of the deployment package (after all, who can live without node_modules?). Each function can have up to 5 layers, which are counted in the maximum deployment size of 50MB (zipped).

Since layers are not temporary, they are not available in /tmp - instead, they're stored in /opt directory. There's an added benefit of using layers - they can be shared with other AWS accounts (you may want to read about benefits of using multiple AWS accounts).

Using Lambda layers does not incur any additional costs.

Comparing the different data storage options

	Amazon S3	/tmp	Lambda Layers	Amazon EFS
Maximum size	Elastic	512 MB	50 MB (direct upload; larger if from S3).	Elastic
Persistence	Durable	Ephemeral	Durable	Durable
Content	Dynamic	Dynamic	Static	Dynamic
Storage type	Object	File system	Archive	File system
Lambda event source integration	Native	N/A	N/A	N/A
Operations supported	Atomic with versioning	Any file system operation	Immutable	Any file system operation
Object tagging	Y	N	N	N
Object metadata	Y	N	N	N
Pricing model	Storage + requests + data transfer	Included in Lambda	Included in Lambda	Storage + data transfer + throughput
Sharing/permissions model	IAM	Function-only	IAM	IAM + NFS
Source for AWS Glue	Y	N	N	N
Source for Amazon QuickSight	Y	N	N	N
Relative data access speed from Lambda	Fast	Fastest	Fastest	Very fast

Source: https://aws.amazon.com/blogs/compute/choosing-between-aws-lambda-data-storage-options-in-web-apps/

Guide to AWS Lambda Function URLs

Tomasz Łakomy — Tue, 23 Aug 2022 19:43:28 +0000

For the longest time, the go-to way of calling an AWS Lambda function via HTTP(S) was to put an API Gateway in front of it. While this works well (and it's still a required pattern for many, many serverless use cases), sometimes developers wanted to "just call an AWS Lambda function" by sending a network request.

Introducing AWS Lambda Function URLs - a new feature in AWS Lambda that allows you to call a Lambda function without an API Gateway.

What is a Lambda Function URL?

Simply put - it's an URL that you can send a network request to to call a Lambda function. An example URL may look like this:

https://vg7sczk62ycloct63yi3wjpoj40sgkuz.lambda-url.eu-central-1.on.aws/

or, in general:

https://<url-id>.lambda-url.<region>.on.aws/

Lambda function URL can point to either $LATEST or to an user-defined alias. Even though no additional resources are required (e.g. API Gateway or an ALB), function URL is a separate CloudFormation resource which needs to be provisioned separately.

How do I create an AWS Lambda function URL?

You can create an AWS Lambda function URL via:

AWS Management Console (Cloudash team does not recommend so-called ClickOps for production usage, use IaC instead)
AWS CLI
AWS CloudFormation
AWS Serverless Application Model (AWS SAM)
AWS CDK

Could you give me an example?

Sure thing, this is how one might create an AWS Lambda function + and a function url to call it directly using AWS CDK:

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";

export class LambdaUrlStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const myLambda = new cdk.aws_lambda.Function(this, "myLambda", {
      code: cdk.aws_lambda.Code.fromAsset("lambda"),
      handler: "index.handler",
      runtime: cdk.aws_lambda.Runtime.NODEJS_16_X,
    });

    const lambdaUrl = new cdk.aws_lambda.CfnUrl(this, "lambdaUrl", {
      targetFunctionArn: myLambda.functionArn,
      authType: cdk.aws_lambda.FunctionUrlAuthType.NONE,
    });
  }
}

And yes, authType: cdk.aws_lambda.FunctionUrlAuthType.NONE is not exactly secure. Keep reading to learn more:

Security and auth model for Lambda function URLs

Controlling access to Lambda function URLs is performed using the AuthType parameter combined with resource-based policies attached to a particular function.

To quote AWS docs, there are two possible values of AuthType parameter:

AWS_IAM – Lambda uses AWS Identity and Access Management (IAM) to authenticate and authorize requests based on the IAM principal's identity policy and the function's resource-based policy. Choose this option if you want only authenticated IAM users and roles to invoke your function via the function URL.

NONE – Lambda doesn't perform any authentication before invoking your function. However, your function's resource-based policy is always in effect and must grant public access before your function URL can receive requests. Choose this option to allow public, unauthenticated access to your function URL.

`AWS_IAM` auth type

When a Lambda function URL has an AWS_IAM AuthType then whoever needs to invoke this particular Lambda function URL must have the lambda:InvokeFunctionUrl permission for a particular Lambda function.

Note: lambda:InvokeFunctionUrl is different than lambda:InvokeFunction, so you may need to adjust your IAM permissions accordingly when opting in to use this feature.

`NONE` auth type

When a Lambda function URL AuthType is set to NONE then any unauthenticated user with your function URL can invoke your function - proceed with caution. This might be useful whenever you might want to allow public access to your function URL e.g. via a web browser.

Even though the auth type is set to NONE and Lambda does not use IAM to authenticate requests to a function URL, whoever tries to the function needs to have the lambda:InvokeFunctionUrl permissions.

An example function URL invoke policy for all unauthenticated principals:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "lambda:InvokeFunctionUrl",
            "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function",
            "Condition": {
                "StringEquals": {
                    "lambda:FunctionUrlAuthType": "NONE"
                }
            }
        }
    ]
}

Source

When creating a function URL with auth type set to NONE via the AWS Console or AWS SAM, the resource-based policy statement listed above will be automatically created for you. When e.g. using AWS SDK you'd need to create it yourself, example of how one might want to do this below:

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";

export class LambdaUrlStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const myLambda = new cdk.aws_lambda.Function(this, "myLambda", {
      code: cdk.aws_lambda.Code.fromAsset("lambda"),
      handler: "index.handler",
      runtime: cdk.aws_lambda.Runtime.NODEJS_16_X,
    });

    const lambdaUrl = new cdk.aws_lambda.CfnUrl(this, "lambdaUrl", {
      targetFunctionArn: myLambda.functionArn,
      authType: cdk.aws_lambda.FunctionUrlAuthType.NONE,
    });

    const lambdaPermission = new cdk.CfnResource(this, "lambdaPermission", {
      type: "AWS::Lambda::Permission",
      properties: {
        Action: "lambda:InvokeFunctionUrl",
        FunctionName: myLambda.functionArn,
        Principal: "*",
        FunctionUrlAuthType: "NONE",
      },
    });
  }
}

Pricing

Lambda function URLs are included in AWS Lambda's pricing - there are no additional charges for using this feature (and you can save money on not using API Gateway)

Limits

Lambda function URLs share the same limits as AWS Lambda functions:

6 MB response and request payload size
Default 1,000 up to tens of thousands TPS
15-minute timeout

In short - there is no additional cost, no additional timeout and payload limits when choosing to use Lambda function URLs.

Check out the official AWS docs to learn more.

So, what's the difference between Function URLs and API Gateway? Are Function URLs objectively better?

Not exactly, there's always a tradeoff.

Feature	API Gateway REST APIs	Function URLs
HTTPS	Yes	Yes
Payload limit	6 MB (with AWS Lambda)	6 MB
Max timeout	29 seconds	Up to 15 minutes
SDK generation	Yes	No
Cost	from $3.50/million for first 333 million	Free
AWS WAF	Yes	No
Usage plans	Yes	No
Request/response validation and transformation	Yes	No

Source - AWS Summit SF 2022 - Best practices for building interactive applications with AWS Lambda (CON302)

Function URLs have a greatly extended timeout (up to 15 minutes) compared to API Gateway + Lambda, with the tradeoff of highly reduced security/usage limits capabilities.

To quote Announcing AWS Lambda Function URLs blogpost:

Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching. [...] It is also the simplest way to invoke your Lambda functions during research and development without leaving the Lambda console or integrating additional services.

Use API Gateway to take advantage of capabilities like JWT/custom authorizers, request/response validation and transformation, usage plans, built-in AWS WAF support, and so on.

Learn more in Lambda function URLs documentation.

Guide to default AWS Lambda environment variables

Tomasz Łakomy — Mon, 06 Jun 2022 19:34:43 +0000

AWS Lambda runtimes set a number of default environment variables during initialization of every serverless function.

The following variables are reserved and cannot be set in your function configuration:

_HANDLER - The location of a functions's handler.
_X_AMZN_TRACE_ID - X-Ray tracing header
AWS_REGION - The region the function is running in (we all know it's us-east-1).
AWS_EXECUTION_ENV - The AWS Lambda runtime identifier. Examples: AWS_Lambda_nodejs14.x, AWS_Lambda_java8.
AWS_LAMBDA_FUNCTION_NAME - The name of the function (which is either "hello world" or IaC randomly generated one, there's no between).
AWS_LAMBDA_FUNCTION_MEMORY_SIZE - The amount of memory allocated to the function (e.g. 1024MB).
AWS_LAMBDA_FUNCTION_VERSION - The version of the function (e.g. $LATEST).
AWS_LAMBDA_INITIALIZATION_TYPE - The initialization type of the function, can be either on-demand or provisioned-concurrency.
AWS_LAMBDA_LOG_GROUP_NAME - The name of the CloudWatch log group.
AWS_LAMBDA_LOG_STREAM_NAME - The name of the CloudWatch stream.
AWS_ACCESS_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN - The access keys obtained from the function's execution role. Be careful with those, read SAS-7: Insecure Application Secrets Storage for guidance. This post on Security for AWS Lambda Serverless Applications is also a good place to start.
AWS_LAMBDA_RUNTIME_API - The host and port of the AWS Lambda runtime API, example: 127.0.0.1:9001
LAMBDA_TASK_ROOT - The path to your Lambda function code
LAMBDA_RUNTIME_DIR - The path to runtime libraries
TZ - The timezone information, e.g. :UTC'

In addition to that, AWS Lambda runtime sets additional variables that are not reserved and can be extended in your function configuration:

LANG - The language of your function's runtime, e.g. en_US.UTF-8
PATH - The execution path, e.g. /var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/bin
LD_LIBRARY_PATH - The system library path, e.g. /var/lang/lib:/lib64: /usr/lib64:/var/runtime: /var/runtime/lib:/var/task:/var/task/lib:/opt/lib
AWS_XRAY_CONTEXT_MISSING - Quoting the docs: "For X-Ray tracing, Lambda sets this to LOG_ERROR to avoid throwing runtime errors from the X-Ray SDK."
AWS_XRAY_DAEMON_ADDRESS - The IP address and port of the X-Ray daemon.

There are also a few runtime-specific environment variables:

NODE_PATH - A node.js env variable, containing node.js library path, e.g. /opt/nodejs/node14/node_modules: /opt/nodejs/node_modules: /var/runtime/node_modules:/var/runtime:/var/task
PYTHONPATH - The Python library path
GEM_PATH - The Ruby library path
AWS_LAMBDA_DOTNET_PREJIT - Quoting the docs: "For the .NET 3.1 runtime, set this variable to enable or disable .NET 3.1 specific runtime optimizations. Values include always, never, and provisioned-concurrency."

Stay on top of your logs. ⚡️

Introducing Cloudash, a desktop app for monitoring your serverless services performance, invocations, errors and more.

Did a production incident happen last week? Or 20 seconds ago? With Cloudash you can search, filter and browse your serverless logs and metrics effortlessly.

Benefits of multi-account strategy on AWS

Tomasz Łakomy — Mon, 23 May 2022 19:30:42 +0000

One of major benefits of adopting AWS Cloud in your organization is the ease of creating and destroying resources in your account. Entire production environments consisting of multiple resources can be deployed (e.g. using AWS CDK), tested and destroyed should a need arise.

As the company grows, so do the number of resources it requires. This can be a challenge for the team as it needs to be able to manage and deploy all the resources in a single account. AWS customers want the ability to build, move fast, iterate while maintaining the best security practices.

When multiple teams work with a single AWS account, ownership boundaries become blurred, cost optimization and visibility become a challenge, and the blast radius for potential security incidents becomes ever larger.

As such, a recommended approach by AWS is to set up a multi-account AWS environment. There are number of benefits to this approach, including (but not limited to):

Cost optimization

An AWS account is the default cost allocation unit. As such, having multiple teams working with a single account can make cost optimization challenging (unless you're exceptionally good at managing tags for all resources provisioned in that account).

Having a bill shared by all teams rise by 20% month-by-month can trigger a long investigation into the root cause of the cost issue, which can be a costly process (bear in mind that developer's time is expensive, quite often more costly than the cost of an AWS environment they operate in)

Using multiple accounts (e.g. one account per team) massively improves the visibility of costs caused by each team's activity (if TeamX AWS bill rises by 20% it maaaay be that super large EC2 instance they forgot to shut down).

On the other hand - having greater visibility into the costs of each team can help avoid TeamA spending time on improving the performance of a single Lambda function by 20% (and saving $5.50 per month) when the real problem is a huge TeamB's NAT Gateway bill. In addition to that - having better visibility into their costs can help technical teams make better decisions about their architecture and deployment strategies.

Grouping workloads based business needs and ownership

Developers usually need a development environment to test their code in, a staging environment (to pretend that it's production) and a production environment (to actually deploy the code to the delight of their customers).

While setting up those environments in a single AWS account is possible (although challenging), a better solution is to split those workloads by environment and by team.

Given two teams (TeamX and TeamY) that maintain two separate products (ProductX and ProductY), you may want to consider a following AWS account split:

ProductXDevAccount (owned by TeamX)
ProductXStagingAccount (owned by TeamX)
ProductXProdAccount (owned by TeamX)
ProductYDevAccount (owned by TeamY)
ProductYStagingAccount (owned by TeamY)
ProductYProdAccount (owned by TeamY)

Following this approach allows you to specify necessary guardrails (governance rules for security, operations, and compliance) to each of those accounts.

As an example, while developers should be able to do more or less whatever they want (within limits, obviously) in a development account, they shouldn't be able to casually delete a DynamoDB table in a production account (nor should they have read/write access to its data, depending on data compliance requirements).

Applying security controls per environment

To continue the above example, you may want to apply security controls to each of those accounts. Maintaining different security policies for development/staging/prod environments in a single account is challenging and error-prone (a small mixup of IAM policies can have drastic consequences for your business). Having separate accounts with clearly defined roles (since e.g. development account should never be used for serving production traffic) helps with establishing proper security controls.

Minimising blast radius

Speaking of security, what happens when you do have a security incident? As Dr. Werner Vogels says:

Everything breaks, all the time

Security incidents are never fun, but if they do happen - it's better to have one environment of one service affected than your entire tech stack (if you were to run everything in a single account). AWS accounts are security boundaries provided by AWS, for instance if a development account is compromised, the production database is safe (as it's stored in a completely different account and as such - much, much harder to access by the attacker).

Limits allocation

AWS Service Quotas (a.k.a. limits) are set up on per account basis. Separating workloads into different accounts gives each account a well-defined, individual quota.

As an example, by default you can create up to 100 S3 buckets in an AWS account. With multiple teams working with a single account, this limit can quickly be exceeded and no new buckets can be created (side note: it's possible to raise an account bucket limit to a maximum of 1,000 buckets). Using multiple AWS accounts in your organization can help you mitigate those limitations.

In addition to that, because Service Quotas and request rate limits are allocated for each account, having a multi-account strategy can allow you to e.g. raise AWS Lambda Concurrent Executions limit only in production account (e.g. before Black Friday) while keeping it at the default in development and staging accounts to avoid unnecessary costs.

Promoting innovation and agility

Apart from staging/production environments, you may want to consider deploying creating other types of accounts for developers to use. To quote AWS documentation:

Sandbox accounts are typically disconnected from your enterprise services and do not provide access to your internal data, but offer the greatest freedom for experimentation.

Development accounts typically provide limited access to your enterprise services and development data, but can more readily support day-to-day experimentation with your enterprise approved AWS services, formal development, and early testing work.

If your tech organization is going through a cloud transformation, it's definitely better for engineers to experiment with new services and technologies in their own sandbox accounts (as opposed to your production environment). This way, you can test out new features and see how they work before deploying them to production.

If you'd like to learn more about best pracitices for AWS Multi-Account strategy, consult the Organizing Your AWS Environment Using Multiple Accounts whitepaper.

Stay on top of your logs. ⚡️

Introducing Cloudash, a desktop app for monitoring your serverless services performance, invocations, errors and more.

Did a production incident happen last week? Or 20 seconds ago? With Cloudash you can search, filter and browse your serverless logs and metrics effortlessly.

Search for whatever you want, whenever you want. Cloudash comes with built-in filtering capabilities enabling to get to the bottom of your problems faster than ever before.

Get started here.

DEV Community: Tomasz Łakomy

Quick guide to CSS Grid

Grid Container

Defining Rows and Columns

Grid Gap

Placing Items

Shorthand Properties

Fractional Units (fr)

Repeat Function

auto-fill and auto-fit

Grid Areas

Responsive Design

Practice

CloudFront Functions vs. Lambda@Edge: what's the difference?

Trigger points

Limits

Use cases

CloudFront Functions

Lambda@Edge

Full Stack TypeScript with AWS Cloud Development Kit v2

Overview of AWS Lambda internal extensions

What are AWS Lambda extensions?

Modifying the runtime environment with internal AWS Lambda extensions

Language-specific environment variables

Wrapper scripts

Creating a safe external HTML link - what's the deal with nofollow / noopener / norefferer ?

Use patterns in CloudWatch Logs Insights to investigate production issues faster

Match case-insensitive patterns when using CloudWatch Logs Insights

Intro to CloudWatch Logs Live Tail

AWS Lambda storage options

What if I need access to storage in my Lambda function?

Amazon S3

Temporary storage, also known as /tmp

Amazon EFS for Lambda

Lambda layers

Comparing the different data storage options

Guide to AWS Lambda Function URLs

What is a Lambda Function URL?

How do I create an AWS Lambda function URL?

Could you give me an example?

Security and auth model for Lambda function URLs

AWS_IAM auth type

NONE auth type

Pricing

Limits

So, what's the difference between Function URLs and API Gateway? Are Function URLs objectively better?

Guide to default AWS Lambda environment variables

Stay on top of your logs. ⚡️

Benefits of multi-account strategy on AWS

Cost optimization

Grouping workloads based business needs and ownership

Applying security controls per environment

Minimising blast radius

Limits allocation

Promoting innovation and agility

Stay on top of your logs. ⚡️

`AWS_IAM` auth type

`NONE` auth type