DEV Community: Denise Ignatova

DynamoDB Primary Composite Keys - When you find yourself in a situation requiring you to modify a composite sort key

Denise Ignatova — Wed, 10 Dec 2025 13:51:31 +0000

Hey wonderful readers and knowledge pursuers!
Today I want to talk about DynamoDB and its composite primary and sort keys. I am 100% aware that there is a huge amount of well written articles and on top of that great and verbose documentation for AWS DynamoDB, that I am using every day. But also we all know that there are situation that are not always described in the books and docs.
With all that said, here I am telling a short story about one of these cases.
Once upon a time a team of architects designed a software architecture, created according to a well written and coordinated documentation. But a third party player missed to mention a specific key factor and the blue sky gathered clouds.
OK! Enough mystery tales!
The design included use of DynamoDB and one of the tasks was to create a table in DynamoDB. The design included primary partition composite key and a sort key, and also very smart separation - every data adjacent to the main data object was pushed into the Dynamo table as a separate record, in the code base use Dynamo Toolbox, Schema Validators etc, etc... all goodies available out there.
All done! All set! Start....!
After a while.....
The skipped key factor from the third party, came into a play and was forcing us to change the composite sort key. Changing the sort key programatically in the schema used with Dynamo Toolbox, was a one line easy change. The problem and issue was, that the existing data after we change the sort key would continue to exists with the old sort key and any update operation on the records would fail miserably. We had to find a way to update the sort key on the existing data.
Now! The real story begins....
Obstacles: Primary partition keys and sort keys are immutable in DynamoDB - you can not just run a trivial update and update composite sort key.
Understanding the core components of DynamoDB - Link to AWS documentation
Solution: The solution we worked out was:

Get the items with the old sort key
Delete the items with the old sort key
Re-create the items with the new sort key
Delete and Put must run all in one transaction
Now the question how to implement:
We decided that best is to run one-time script to fix the discrepancy.
There are two options:
create bash script and use AWS CLI commands
or use AWS SDK
We have decided to use AWS SDK for JavaScript v3.
And there we go:
Looking at the process , the first thing to do is to extract the records with the old sort key. You can not query, simply because you do not know the primary key of the affected records, so you need to scan the whole table:

import { DynamoDBClient, ScanCommand } from "@aws-sdk/client-dynamodb"; 
import { DynamoDBDocumentClient } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient();
const ddbDocClient = DynamoDBDocumentClient.from(client)

const input  = {
    TableName = "your table name",
    FilterExpression: "begins_with(#sk, :sk_portion_you_know)",
    ExpressionAttributeNames: {
        #sk: "sk"
    },
    ExpressionAttributeValues: {
        :sk_portion_you_know: {
          S: "The Portion You know and it is static"
    },

}

const response = await client.send(new ScanCommand(input))

I know , I know, do not panic. Scan is huge, consumes a lot of reads, but done once it is not an overkill.
Here is the pricing from the AWS DynamoDB documentation link to DynamoDB pricing. Briefly (depends on a region) for around 2 million records scan would cost around just over a $1.00.
So far so good.
Anything I am missing ?
Yes! And there it is from AWS documentation link to AWS documentation.

A single Scan operation first reads up to the maximum number of items set (if using the Limit parameter) or a maximum of 1 MB of data and then applies any filtering to the results if a FilterExpression is provided.
With an operation that scans the whole production table, the payload would exceed 1Mb.
So the next important bit, is to implement pagination.
To leverage pagination in DynamoDB you need to add few important params in your input.
ExclusiveStartKey, LastEvaluatedKey, Limit. Ok so lets see how would our input would look like:

const input  = {
    TableName = "your table name",
    FilterExpression: "begins_with(#sk, :sk_portion_you_know)",
    Limit: 100,
    ExpressionAttributeNames: {
        #sk: "sk"
    },
    ExpressionAttributeValues: {
        :sk_portion_you_know: {
          S: "The Portion You know and it is static"
    },
    ExclusiveStartKey: lastEvaluatedKey

}

Now that the input is all set, how we would achieve the pagination.
First lets briefly (it is a complex and a long topic) explain what is a pagination in DynamoDB: Pagination is the process of sending subsequent requests to continue when a previous request is incomplete. A Query or Scan operation in DynamoDB might return results that are incomplete and require subsequent requests to get the entire result set.
The Limit parameter controls the maximum number of items returned per page, optimising throughput and reducing resource consumption. If the value of LastEvaluatedKey is undefined, the initial set of items will be returned according to the specified limit. However, if a valid value is provided, the query will return a set of items beginning from the value of LastEvaluatedKey, which contains the primary key of the last evaluated item.
Examples of how the response from scan is constructed and where the LastEvaluatedKey is placed.
As I love to say this can be implemented in a million and one ways, but simply this could also work:
The main thing to take out is that you need to query/scan till you have a LastEvaluatedKey.
So if you are using typescript like me: you can simply do a do while loop.


do {
    command = await client.send(new ScanCommand(input))
    lastEvaluatedKey = command.LastEvaluateKey
    // update your input's params
    params.lastEvaluatedKey = lastEvaluatedKey
} while (lastEvaluatedKey)

Now your scan will have a pointer from which to start the read for the next bunch of data till there is a data to query/scan - LastEvaluatedKey.
And your input now would look like this:

 const allRecords: Record<string, AttributeValue> = []
 const transactions: Record<string, AttributeValue> = []
const input  = {
    TableName = "your table name",
    FilterExpression: "begins_with(#sk, :sk_portion_you_know)",
    Limit: 100,
    ExpressionAttributeNames: {
        #sk: "sk"
    },
    ExpressionAttributeValues: {
        :sk_portion_you_know: {
          S: "The Portion You know and it is static"
    },
    ExclusiveStartKey: lastEvaluatedKey

}
 let data:ScanCommandOutput
try {
    do {
        data = await client.send(new ScanCommand(input))
        lastEvaluatedKey = data.LastEvaluateKey
        if (data.Items.length) {
            allRecords.push(...data.Items)
        // update your input's params
        params.lastEvaluatedKey = lastEvaluatedKey
    } while (lastEvaluatedKey);

        if (allRecords.length) {
            allRecords.forEach((item) => {
            if (item.sk.S === 'your old key') {
                transactions.push(item)
                }
            })
        }
    } catch(error) {
        throw new Error('Error thrown during scan operation')
    }
  }
}

🚩 There are number of expressions you can use in FilterExpression to filter your search. We had to use begins_with. Link to good examples on how to use different condition expressions
Next lets dive into the last part - deal with changed Composite Sort Key.
We obviously can not updated it in terms of a trivial update, because composite primary keys are immutable as I already mentioned. We will delete and put back the same record with the new sort key. Lets do it!

async function transactWrite(records: Record<string, AttributeValue>[]) {
    records.forEach(async (transaction) => {
    // we are getting the records via ScanCommand marshalled - item: {S: 'field value'} ,
    // the DynamoDBDocumentClient Put uses high level json - {item: value} and to put them we need to unmarshall
    const unmarshalled = unmarshall(transaction);
    const input = {
        ConditionCheck: {
            TableName: tableName,
            ConditionExpression: 'attribute_exists(pk)',
            ExpressionAttributeNames: {
                '#pk': 'pk',
            },
            ExpressionAttributeValues: {
                ':pk': `${unmarshalled.pk}`,
            },
            Key: {
                pk: `${unmarshalled.pk}`,
                sk: `${unmarshalled.sk}`,
            },
            },
            TransactItems: [
            {
                Delete: {
                    TableName: tableName,
                    Key: {
                    pk: `${unmarshalled.pk}`,
                    sk: `${unmarshalled.sk}`,
                    },
                },
            },
            {
                Put: {
                    TableName: tableName,
                    Item: {
                    ...unmarshalled,
                    sk: `The new key to update with put`,
                    },

                },
            },
            ],
        };
    try {
        const response = await docClient.send(new TransactWriteCommand(input));
        console.log('Item transactWrite successfully.', response);
        } catch (error) {
        console.log('Error transactWrite:', error);
    }
  });
}

One very important note here - ScanCommand will return result marshalled like item: {S: 'field value'}. You must unmarshall() the record before using it in Put. Failed to do so , you will end up with Schema Validation Error - ValidationException The provided key element does not match the schema from AWS SDK simply because Put uses high level json schema to validate the input in this manner {"item": "value"}.
Documentation with example about marshalling and unmarshalling your records.
Having Delete and Put in one Transaction adds a confidence, simply because if something goes wrong , the transaction will not be completed and will rollback.
🤓 Little advice:
✅ It is also good to take a few extra steps to make sure you have the data you want to update in a separate file, to extract modified records in another file , so you can compare the changes along side with the same records, but before the transaction. Again there are multiple ways and different precaution steps to take to make sure everything goes smooth and as planned.
It is not the greatest experience, but it happens. Sometimes internal documentation not often enough updated and leading to design holes. Often , but no always when other parties involved, miscommunication is something that could go along, and many other reasons, you name it.
💡 Take off:
The most important as a take off is that - anything is possible, anything could be fixed, there is always a way, and last but not least , as long as you have a great team to support you and back you up 💪 - here is the right place to mention that the smart and great design of DynamoDB made it possible, and the extensive and comprehensive guide of AWS SDK.

🚀 A huge Thank you to AWS DynamoDB team and AWS SDK team. Without the extensive suite of functions from AWS SDK , without the verbose and amazing examples in the documentation for AWS SDK we would have been lost and stuck into a forest of trials and errors.
🌟 Thank you to you my dear reader. Thank you for sticking with me to the end. I hope this could help other people in a similar or same situation.
Let's connect 🤝
LinkedIn
✍ Would love to hear from you ✍

MCP Custom Server Tools + Amazon-Q. How to ...?

Denise Ignatova — Sun, 08 Jun 2025 19:10:55 +0000

Hey fellow reader!
It is me again , the one that always tries to catch the running train.
Once I tasted the power of MCP protocol, I wanted more...
And here it is, short post about how to implement and use MCP tools with Amazon-Q or any other client.
If you have followed my previous post on how to implement MCP custom server this one, you can use the same project and we can get going from there.
Few words on what MCP Server tools are :
There is an excellent documentation MCP protocol tools, and in short, and as a really high overview - Tools as primitives of MCP protocol allow the server to expose executable functionality to clients.
In our case, with a custom server, it would mean that we would be able to ask our LLM client in a natural language to look into our custom server, find the tool and execute it. Wow!
Lets get to work...
We have our MCP custom server exposing resources and connected to Amazon-Q, all what we need to do is to add new capability: tools.
Our tool will be able to generate image file from a flowchart created with mermaid markdown. We will be using mermaid.js API call to generate output image from input mermaid markdown. Mermaid API Usage Cool!

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListResourcesRequestSchema, ListToolsRequestSchema, ReadResourceRequestSchema } from '@modelcontextprotocol/sdk/types.js';
import { dirname } from 'node:path';
import { fileURLToPath } from 'node:url';
import {run} from '@mermaid-js/mermaid-cli';
import fs from 'fs/promises';

const server = new Server({
    name: 'docs-demo',
    version: '1.0.0'
    }, {
        capabilities: {
            resources: {},
            tools: {}
        }
    }
);

Again we will use low-server methods to create our tool. Add this to index.ts

server.setRequestHandler(ListToolsRequestSchema, async () => {
    return {
        tools: [{
            name: 'flow-chart',
            description: 'Display flow chart with mermaid',
            inputSchema: {
                type: 'object',
                properties: {
                   input: {type: 'string'},
                   output: {type: 'string'}
                },
                required: ['input', 'output']
            },
             annotations: {
                title: "Flow chart views",
            }
        },
    ]
}
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
    if (request.params.name === 'flow-chart') {
        const input = request.params.arguments?.input as string;
        const output = request.params.arguments?.output as `${string}.png` | `${string}.md` | `${string}.markdown` | `${string}.svg` | `${string}.pdf`;

        await run(input, output)
        return {
            content: {
                uri: 'file://' + `${output}`,
                type: 'image/png'
            }
        }
    }
    throw new Error('Tool not found');
})

Now we need to check if our client Amazon-Q is connected to our server and would be able to find our server tool.

In the terminal type this after starting the client with q chat:

/tools

you should be able to see this:

Note: for this example we are interested in the flowchart tool.
Now lets ask our client Amazon-Q in a natural language to generate image in a specified directory from a flowchart.md located in our docs folder using our custom MCP server's tool flowchart.
could you generate image file from ./src/docs/flowchart.md in ./src/assets/chart.png using flowchart tool from mcp server.
You should be able to see this:

type t in the terminal to confirm you trust your tool and to allow further actions.
And there we have it:

I am extremely excited about what the future holds.
Thank you for reading. I am beyond grateful for your time and will appreciate your comments and feedback highly.
Can not wait to find out, what awesome tools you have built, using MCP protocol and custom server.
Happy building!

You can wonder through the Git repo as well.

Custom MCP Server + Amazon Q - Powerhouse combination

Denise Ignatova — Fri, 23 May 2025 13:28:12 +0000

Hey fellow reader!
I hope am not too late for the MCP party, and I hope with this short post to add meaningful contribution to the already awesome resources out there.
In short:
I have decided to try out building custom MCP server which exposes as a resource specific documentation and connect it Amazon Q.
I have used typescript sdk Link here.
Lets get started then!

create a directory

mkdir mcp-server

(side note: I am using pnpm, as package manager)

inside the newly created directory run

pnpm init

to generate package.json file. Once it is generated, navigate to it and replace script section with :

script: {
    "build": "tsc && chmod 755 build/index.js"
  }

you are pointing typescript where to store your public endpoint , giving the necessary permission too. After that you would need to create your tsconfig.json.

tsc init

make the needed changes:

outDir: './build'
target: 'es2022'
module: 'NodeNext'

last two would allow top level await to be used.
Install @modelcontextprotocol/sdk.

We will be using low-level server. Examples from the mcp repository : Low-level mcp-server.
We can start.
Create a src directory and inside it create a file called index.ts

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { ListResourcesRequestSchema, ReadResourceRequestSchema } from '@modelcontextprotocol/sdk/types.js';
import * as fs from 'node:fs/promises';
import { dirname } from 'node:path';
import { fileURLToPath } from 'node:url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const server = new Server({
    name: 'docs-demo',
    version: '1.0.0'
    }, {
        capabilities: {
            resources: {},
            tools: {}
        }
    }
);

const docFiles = await fs.readFile('./src/docs/integration.md');
server.setRequestHandler(ListResourcesRequestSchema, async () => {
    return {
        resources:[
            {
            uri: 'file://' + __dirname + '/docs/integration.md',
            name: 'Integration docs',
            mimeType: 'text/plain'
            }
        ]
    }
});

server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
    const uri = request.params.uri;
    if (uri === 'file://' + __dirname + '/docs/integration.md') {
        return {
            contents: [
                {
                    uri,
                    mimeType: 'text/plain',
                    text: docFiles.toString('utf-8')
                }

            ]
        }
    }
    throw new Error('Resource not found');
});


const transposrt = new StdioServerTransport();
console.log('Starting server...');
await server.connect(transposrt)

Create a docs folder in you src folder. There we will add our integration.md file. You would need an assets folder with our diagram. You can download this one!

content of integratiion.md file

# Integration awesome105
### Build a simple flow with AWS SQS , AWS SNS and AWS Lambda

![Diagram](../assets/image.png)

Now we need to install Amazon-q CLI. Here is an excellent tutorial how to install amazon-q on a different os systems.
Link to the tutorial

I have used:

brew install amazon-q

After installation check if it is installed:

q version

Now comes the most important part. To let know amazon-q that there is a mcp-server. Amazon-q will be installed in a directory ~/.aws/amazonq. Get into this directory like this:

cd ~/.aws/amazonq

Now type ls to list everything in this directory - should not have mcp.json. Type in the terminal:

touch mcp.json

copy and paste this and save:

{
  "mcpServers": {
    "docs-demo": {
      "command": "node", // command that will run your index.js
      "args": [
        "/absolute_path/build/index.js"] //absolute path to your index.js
    }
  }
}

Now time to test!
Go back to your terminal and type q chat. You should be able to see this ....

Now lets ask amazon-q to find documentation for our awesome105 integration and explain the diagram associated with it.

And voila...

This is truly amazing! Could you imagine what horizons this feature opens? For me beyond my dreams! Thank you Amazon-q!
Thank you for reading! Please leave a comment and let me know what cool projects you came up with using mcp-server and amazon-q!

AWS SQS and fan-out pattern with Kafka (Confluent).

Denise Ignatova — Wed, 21 May 2025 12:57:47 +0000

Refactoring !!!
Refactoring is inevitable. We face it almost every day. Sometimes we plan for it, sometimes comes as an unscheduled change.

At the beginning of the story, we had a simple, easy flow.
Very trivial workflow:
Publisher will publish a message to AWS SNS Topic , which is subscribed to AWS SQS , then the AWS SQS will send a message to Kafka. So far so good:

with schema matching the structure of the domain product, to push to Kafka. Something along the lines in json format:

JSONSchema (if you are interested to find out more)
JSONSchema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "Product",
  "description": "A product from Acme's catalog",
  "type": "object",
  "properties": {
    "productId": {
      "description": "The unique identifier for a product",
      "type": "integer"
    }
  }
}

In order to satisfy the new business requirements, we came up with a solution involving changing the structure of the schema for our domain event.
Something along the lines: leveraging the oneOf feature to create complex tree like structure:

{
 "$schema": "http://json-schema.org/draft-07/schema#",
 "$id": "TreeNode",
 "type": "object",
 "properties": {
   "value": { "type": "number" },
   "left": {
     "oneOf": [
       { "type": "null" },
       { "$ref": "TreeNode" }
     ]
   },
   "right": {
     "oneOf": [
       { "type": "null" },
       { "$ref": "TreeNode" }
     ]
   }
 },
 "required": ["value", "left", "right"]
}

How the refactoring lead to Fan-out pattern?

It is a well known fact that Kafka Schema Registry have a few compatibility modes and the recommended one is backward compatibility and this is the one we have signed for and it is the default one as well - simply accept new only optional fields, delete fields and do not allow change of type of existing ones. The consumer always read the latest version of the schema and not the version it was produced with. With the huge difference in the schema structure, that was going to be introduced, the crash and the errors were just waiting to happen.

Kafka Schema Registry compatibility modes.

The only solution that could have helped us to maintain the current flat schema and gradually to introduce and accommodate the new event tree-like schema was to use the Fan-out pattern.

In Fan-out messaging scenario, messages are "pushed" to multiple subscribers, which eliminates the need to periodically check or poll for updates and enables parallel asynchronous processing of the message by the subscribers.
We were aiming at that parallel processing scenario, where our AWS SQS is subscribed to two AWS SNS topics, and our AWS SQS queue is attached as a trigger to an AWS Lambda, which pushes messages to these Kafka topics. Then AWS Lambda subscriber reads the Kafka messages from the two separate Kafka topics, and programmatically decides how to consume the messages depend on the message body structure. As a side note - Kafka topic works as a queue.

How would you achieve this?
You would start with AWS AppConfig:

Create a feature flag - either through the AWS Console or with your favorite serverless framework or simply by using AWS CDK.
Create publisher (AWS Lambda).
- Add Logic to your publisher to decide to which topic to publish message depending on the feature flag.
Create AWS SNS topics.
Create two separate Kafka topics.
Create AWS SQS Fifo queue.
- Subscribe the queue to the SNS topics.
Create your producer AWS Lambda.
- Attach the AWS SQS as a trigger.
- Bind to the AWS Lambda your Kafka topics.
- Add logic to your producer to read the message body and decide which one to push to which Kafka topic depending on the message structure.
Create AWS Lambda as Kafka subscriber ( for your Kafka topics ).
- Add event source to your Lambda - the Kafka topics.
- Add logic to your code to read and consume the message body from Kafka topic and decide how to process further depending on the message structure.

Keeping two separate Kafka topics, allowed us to have the current codebase and flow working uninterrupted and at the same time gave us the freedom to test the new schema without causing any problems in production stage.
Once satisfied with the test results we have been able to perform canary deployment and this approach saved us from the headache and worry about the availability of our product.

This is it!
As a side Note: You could skip the creation of the two separate AWS SNS topics and by only leveraging the AWS AppConfig feature flag to switch on and off what type of message to flow trough the SNS topic, and keep only the two Kafka topics (this is a must).

Thank you for reading! I hope you enjoy it and find it useful. Please leave a comment, would love to hear your thoughts.

Recognizing Design Patterns in System Design - Facade pattern, AWS API Gateway and Load Balancer

Denise Ignatova — Fri, 17 Jan 2025 15:43:21 +0000

Making sense of the structure of your code and seeing the big picture has been a goal for every developer ( at least every one I know ), and I am not an exception.
I have been struggling to see from above, to have an overview of the projects I have been working on, and this was affecting my confidence and my productiveness as a developer.
Overwhelmed and certain that I need to go back to the basics, and thanks to the incredible girls from Women Coding Community and their amazing design-patterns course, I started reading again "Head First Design Patterns" by Eric Freeman and Elisabeth Robson - link to the book and consulting with the amazing refactoring guru site link to the site.
Learning and searching for parallels between the existing and well-known design patterns and modern system designs.

One design pattern that is very easy recognizable is Facade pattern.
What do we know about Facade pattern?
Facade pattern is a member of so called Structural patterns. It provides a simple interface for a complex logic. What would that mean? This means that you would have one point of contact in your codebase, that behind the scene distributes the logic to the relevant parts of your project.
Real world example image taken from link to facade pattern

Now the Question, how this Facade pattern relates to a System Design that we know and probably use everyday.(Drum rolls)....

AWS API Gateway:

link AWS API Gateway

An Obvious winner...!
Can you see the similarities in both images?
Can you clearly see the Facade in the illustrated situation?
Did you see how AWS API Gateway offers a simple interface and hides the complexity of handling multiple calls and redirecting them to the relevant consumer?
The diagram shows how AWS API Gateway is used to distribute and handle different API calls by being that one point of a contact.
In this line of thoughts (light-bulb), wait a second..., what about the Load Balancer:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html

It is also an example of providing single entry point of contact( simple interface) , that hides behind a complex logic.

For me this was an eye opener, and realizing that I can re-learn and re-use this knowledge was pivotal moment and breaking change in my understanding of system design and design patterns.
The benefits of using API Gateway and Load Balancer are countless, and this short post is not about this. It is about how to make use of design patterns knowledge to apply effective and optimal decisions while building and designing systems in the modern serverless world.
Seeing the similarities, recognizing the patterns is a powerful capability. Pumped with this knowledge, you would be able to write better code, to architect better design systems.

Thank you for reading!
Excited to read your feedback and comments!

How to Debug your AWS Lambda - SST framework and Powertools

Denise Ignatova — Fri, 17 Jan 2025 11:47:48 +0000

When using serverless framework to build your applications, you depend on the framework's capability to achieve your goals.
One of the main parts of the work process is the ability to debug your code, while you build your logic and in case there are some disruptions in the flow.
When working with AWS Lambda and building your application with SST framework, you can add logs around the logic of your Lambda , but also you need to bare in mind that this constant build up of logs could overwhelm AWS CloudWatch and increase your bills.
While developing there is this amazing Live lambda feature provided by the SST framework which allows you to debug , test and invoke live your AWS Lambda by Postman and whatever endpoint(HTTP, GraphQL) you have chosen.
Once in production and already live, your codebase needs more gentle logging approach. One of the possible solutions is the following:
There are two essentials steps to be completed.

Create custom log method in your code base
Add environment variable to the lambda you are interested to debug

Lets code:
Basically you would have a custom log logic in your codebase, which will be invoked in places.

import { Logger } from '@aws-lambda-powertools/logger';
const logger = new Logger({ serviceName: 'serverless' });

// use logger to create logs at different level 
// example:
// logger.info()
// logger.debug()
// logger.error()
function myDebug (message: string, ...args: unknown[]) { 
const loggerLevel = logger.getLevelName();
if (loggerLevel === 'DEBUG') {
  // log context
  logger.debug(message, context: {context: args});
 }
}

Then in your Lambda Function snippet you would have environment variable POWERTOOLS_LOG_LEVEL with value INFO.

new Function(stack, "MyFunction", {
  handler: "src/lambda.handler",
  timeout: 10,
  environment: {
    POWERTOOLS_LOG_LEVEL: "INFO",
  },
});

Like that, whenever you need to debug you would need to change via the AWS Console (no need of deploy) the value of your POWERTOOLS_LOG_LEVEL environmental variable to DEBUG and voila on a so called live Lambda invocation via SST command sst dev you would run live your AWS Lambda and have beautiful logs on AWS CloudWatch and your terminal from your code base.
To edit the value of your AWS Lambda's environment variable, choose the Configuration tab, on the Lambda Function page, under Environment variables choose Edit. Once you have changed the value choose Save.

Thank you for reading!
Excited to see any feedback!
Have an amazing journey in cloud world!