DEV Community: Steven Leung

I Stopped My AI From Making Up AWS Answers With One Command

Steven Leung — Sat, 01 Aug 2026 07:34:07 +0000

The Problem

AWS announces changes continuously, any reader here would be familiar with that, and with the AWS News Blog.

Imagine you're a developer in July 2026 asked to work with Amazon S3 Files, which went generally available during April 2026.

Your AI assistant has a knowledge cutoff: a fixed date after which the model stops receiving new training data. Past that date, it's completely unaware of new product releases, feature launches, or documentation changes. Time is of the essence and you can't exactly pause until the next model ships.

AI assistants have made it easy to skip the manual grind of reading docs and researching things yourself, right up until the assistant's knowledge runs out of date. So what do you do when it doesn't know about the thing you need it to know about?

The Solution

Enter the AWS Knowledge Model Context Protocol (MCP) Server, an open-source tool from AWS Labs (AWS's official open source GitHub organisation) that connects AI models directly to authoritative, up-to-date AWS documentation.

It lets AI clients like Claude and Copilot pull real-time AWS information without waiting on a model update: current documentation, blog posts, What's New announcements, and Well-Architected guidance, all fetched live rather than recalled from training data.

What is MCP, for the uninitiated

The Model Context Protocol (MCP) is the standard AI tools use to talk to external tools and knowledge sources. AWS Knowledge is a remote MCP server, hosted by AWS, that puts AWS-specific material in front of the model in a format it can use.

You'd be forgiven for thinking this sounds like RAG (Retrieval-Augmented Generation). MCP enables RAG, but it isn't RAG itself, and RAG doesn't need MCP either. People were doing RAG long before MCP existed. MCP is the connector standard; RAG is the "look something up, then answer using what you found" pattern. MCP just happens to be a common way of wiring that pattern up.

What it gives the model

The server exposes a handful of tools the AI can call directly:

search_documentation: keyword search across all AWS documentation
read_documentation: fetches a specific documentation page, converted to markdown
recommend: suggests related documentation pages for a given URL
list_regions: lists all AWS regions and their identifiers
get_regional_availability: checks which regions support a given service, feature, SDK API, or CloudFormation resource
retrieve_skill: pulls down a domain-specific "agent skill", a packaged set of workflows and best practices for a more involved AWS task

That last one is worth a quick note: skills aren't new actions bolted onto the model, they're structured guidance the model reads and follows, the same way it would follow a detailed how-to doc, just retrieved on demand instead of baked into the prompt.

The important details

Client-server pattern: your AI tool is the client, AWS Knowledge is the server.
No AWS account required: it's public and unauthenticated.
Free to use: no cost, which makes everything easier.
Rate limited: it's a shared public service, so standard limits apply.

A quick note on privacy

Worth knowing what actually leaves your machine here: just your query text (e.g. "does Lambda support S3 Files yet") plus your IP address, going to a public AWS endpoint, the same exposure as searching the AWS docs site yourself. Nothing from your codebase, credentials, or AWS account goes with it, this server only answers questions, it doesn't read your project or touch your infrastructure. AWS states that telemetry from this server isn't used for model training, and since there's no authentication step, there's nothing tying a query back to your identity beyond standard request logs.

One rule of thumb regardless: fine for general AWS knowledge lookups, not the place to paste anything client-specific or commercially sensitive as part of a query.

See it in action

Once it's wired in, the difference shows up the moment you ask about anything recent. Try something like:

"Is Amazon S3 Files generally available yet, and which regions support it?"

Without AWS Knowledge connected, most models will either hedge ("I'm not aware of this service" or "as of my knowledge cutoff, this doesn't exist") or, worse, guess. With it connected, the assistant calls search_documentation, finds the GA announcement, and answers with the actual launch date and region list, sourced from the live docs rather than a guess.

That's the whole pitch in one prompt: the model goes and checks, instead of you doing it in a second tab.

How to install it

Claude Code

The claude mcp add command is specific to Claude Code's CLI, but AWS Knowledge itself is just a standard MCP server, so the same URL works in any MCP-compatible client. Only the registration step changes.

claude mcp add --transport http aws-knowledge https://knowledge-mcp.global.api.aws

If you want it available across a whole project, and checked into git so the rest of the team gets it too, add --scope project instead of leaving it at the personal default:

claude mcp add --scope project --transport http aws-knowledge https://knowledge-mcp.global.api.aws

Verify it worked:

claude mcp list
claude mcp get aws-knowledge

list shows connection status at a glance, get shows the full config and whether it's reachable right now.

VS Code, Visual Studio, JetBrains, and other Copilot IDEs

These all share a similar mcp.json config shape. The root key is servers, not mcpServers, that's the detail that trips people up if they're copying config from Claude or Cursor.

{
  "servers": {
    "aws-knowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

Since AWS Knowledge is public and needs no authentication, that's the whole config, no tokens or headers required. Where you put it and how you open it differs by IDE:

VS Code: open the Command Palette and run MCP: Open User Configuration for something that applies everywhere, or create .vscode/mcp.json in a repo to scope it to that project and commit it for the team.

Verify it worked: run MCP: List Servers from the Command Palette, select aws-knowledge, and check its status. If it's erroring, choose "Show Output" to see the actual server log. In Copilot Chat (Agent mode), click the tools icon to see the live list of available MCP tools and confirm aws-knowledge is in it.

JetBrains (IntelliJ, WebStorm, PyCharm, etc.): click the GitHub Copilot icon, then Edit Settings, then Model Context Protocol, then Configure, which opens the same mcp.json.

Verify it worked: open Copilot Chat in Agent mode and click the tools icon at the bottom of the chat window. This opens the live tool list, confirm the AWS Knowledge tools show up there. If they don't appear right after saving, try reopening the chat window rather than assuming it's misconfigured, that's the most common false negative.

Visual Studio (2022, version 17.14.9+): create an .mcp.json file in your solution directory or %USERPROFILE%, using the same config shown above.

Verify it worked: after saving, Visual Studio shows a CodeLens prompt above the server entry, click it to connect. Then open Copilot Chat in Agent mode and use the tool picker to confirm aws-knowledge's tools are listed. Since this server needs no auth, it should connect straight away with no credential prompt.

Claude Desktop

This one works differently. Claude Desktop doesn't pick up remote HTTP servers from a config file at all, claude_desktop_config.json is for local servers only. Remote servers go through the UI:

Open Settings, then Connectors (Organization integrations, if you're on a Team or Enterprise plan).
Add a custom connector.
Paste in https://knowledge-mcp.global.api.aws as the server URL.
Confirm. The tools are available from your next chat.

No OAuth step here either, since the server doesn't require authentication.

Verify it worked: open the Connectors panel again and confirm aws-knowledge shows as connected with its tools listed, or just ask it something time-sensitive in a new chat and see whether it searches before answering.

If it won't connect

This is a public, high-traffic endpoint, so occasionally the issue is on AWS's end rather than your config. There's a known case where the server has briefly returned connection errors during initialisation across every client at once. If aws-knowledge looks correctly configured but won't connect, it's worth trying again a few minutes later before assuming your JSON is wrong.

Prefer to keep it local?

If you'd rather not depend on a remote, AWS-hosted server, for offline work or a stricter environment, AWS also publishes awslabs.aws-documentation-mcp-server, a locally run equivalent with overlapping search and read tools, installed via uvx instead of a URL. Same idea, runs on your machine instead of AWS's.

One thing worth watching

Every MCP server you connect adds to the list of tools your assistant has to consider on each turn. Adding AWS Knowledge is low-cost since it's just a handful of tools, but it's worth treating "add every MCP server that looks useful" as the wrong instinct. Add what you'll actually reach for, not everything available.

Final thoughts

This is low effort for high value, for only a bit of setup. One command, or one small JSON block, and you're done.

After trying it out, I'd call this a must for every developer working with AWS, and it left me wondering how I'd gone so long without it.

It cuts down the hallucinations by giving the model something current to check itself against, instead of relying purely on training data that's already going stale by the time you're reading this.

The bigger win for me, honestly, is staying in one place. No more jumping between the IDE (or terminal) and a browser tab full of AWS docs. That context switch between "coding" and "reading documentation" is a small tax we pay dozens of times a day, and it adds up. With this wired in, your AI assistant can just go check for itself, and you stay exactly where you were working.

What's the most recent AWS feature your AI assistant got completely wrong?

Drop it below, I want to see how bad the gap actually is.

If you'd like to connect or keep the conversation going, find me on LinkedIn.

More information

I Stopped My AI From Making Up AWS Answers With One Command

Steven Leung — Sat, 01 Aug 2026 07:31:02 +0000

The Problem

AWS announces changes continuously, any reader here would be familiar with that, and with the AWS News Blog.

Imagine you're a developer in July 2026 asked to work with Amazon S3 Files, which went generally available during April 2026.

The Solution

What is MCP, for the uninitiated

What it gives the model

The server exposes a handful of tools the AI can call directly:

search_documentation: keyword search across all AWS documentation
read_documentation: fetches a specific documentation page, converted to markdown
recommend: suggests related documentation pages for a given URL
list_regions: lists all AWS regions and their identifiers
get_regional_availability: checks which regions support a given service, feature, SDK API, or CloudFormation resource
retrieve_skill: pulls down a domain-specific "agent skill", a packaged set of workflows and best practices for a more involved AWS task

The important details

Client-server pattern: your AI tool is the client, AWS Knowledge is the server.
No AWS account required: it's public and unauthenticated.
Free to use: no cost, which makes everything easier.
Rate limited: it's a shared public service, so standard limits apply.

A quick note on privacy

One rule of thumb regardless: fine for general AWS knowledge lookups, not the place to paste anything client-specific or commercially sensitive as part of a query.

See it in action

Once it's wired in, the difference shows up the moment you ask about anything recent. Try something like:

"Is Amazon S3 Files generally available yet, and which regions support it?"

That's the whole pitch in one prompt: the model goes and checks, instead of you doing it in a second tab.

How to install it

Claude Code

claude mcp add --transport http aws-knowledge https://knowledge-mcp.global.api.aws

If you want it available across a whole project, and checked into git so the rest of the team gets it too, add --scope project instead of leaving it at the personal default:

claude mcp add --scope project --transport http aws-knowledge https://knowledge-mcp.global.api.aws

Verify it worked:

claude mcp list
claude mcp get aws-knowledge

list shows connection status at a glance, get shows the full config and whether it's reachable right now.

VS Code, Visual Studio, JetBrains, and other Copilot IDEs

These all share a similar mcp.json config shape. The root key is servers, not mcpServers, that's the detail that trips people up if they're copying config from Claude or Cursor.

{
  "servers": {
    "aws-knowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

Since AWS Knowledge is public and needs no authentication, that's the whole config, no tokens or headers required. Where you put it and how you open it differs by IDE:

Verify it worked: run MCP: List Servers from the Command Palette, select aws-knowledge, and check its status. If it's erroring, choose "Show Output" to see the actual server log. In Copilot Chat (Agent mode), click the tools icon to see the live list of available MCP tools and confirm aws-knowledge is in it.

JetBrains (IntelliJ, WebStorm, PyCharm, etc.): click the GitHub Copilot icon, then Edit Settings, then Model Context Protocol, then Configure, which opens the same mcp.json.

Verify it worked: open Copilot Chat in Agent mode and click the tools icon at the bottom of the chat window. This opens the live tool list, confirm the AWS Knowledge tools show up there. If they don't appear right after saving, try reopening the chat window rather than assuming it's misconfigured, that's the most common false negative.

Visual Studio (2022, version 17.14.9+): create an .mcp.json file in your solution directory or %USERPROFILE%, using the same config shown above.

Verify it worked: after saving, Visual Studio shows a CodeLens prompt above the server entry, click it to connect. Then open Copilot Chat in Agent mode and use the tool picker to confirm aws-knowledge's tools are listed. Since this server needs no auth, it should connect straight away with no credential prompt.

Claude Desktop

This one works differently. Claude Desktop doesn't pick up remote HTTP servers from a config file at all, claude_desktop_config.json is for local servers only. Remote servers go through the UI:

Open Settings, then Connectors (Organization integrations, if you're on a Team or Enterprise plan).
Add a custom connector.
Paste in https://knowledge-mcp.global.api.aws as the server URL.
Confirm. The tools are available from your next chat.

No OAuth step here either, since the server doesn't require authentication.

If it won't connect

Prefer to keep it local?

One thing worth watching

Final thoughts

This is low effort for high value, for only a bit of setup. One command, or one small JSON block, and you're done.

After trying it out, I'd call this a must for every developer working with AWS, and it left me wondering how I'd gone so long without it.

It cuts down the hallucinations by giving the model something current to check itself against, instead of relying purely on training data that's already going stale by the time you're reading this.

What's the most recent AWS feature your AI assistant got completely wrong?

Drop it below, I want to see how bad the gap actually is.

If you'd like to connect or keep the conversation going, find me on LinkedIn.

More information

💿 The Death of the Disc: Why Sony's 2028 Digital Monopolisation Was Inevitable

Steven Leung — Sat, 04 Jul 2026 09:49:23 +0000

Sony shared an announcement with the console market: physical disc production for all PlayStation games will completely stop in January 2028.

You can read the official announcement on the PlayStation Blog.

From a pure engineering perspective, modern internet infrastructure has rendered physical distribution redundant. We no longer need plastic circles to transport megabytes.

The gamer community response isn't about data transfer speeds. It is over true digital ownership, consumer rights, and software preservation.

In this article, we break down the details, look at the history leading to this moment and explore why console makers would pursue this direction.

🔍 The Announcement Break Down

The 2028 Deadline: The mandate strictly applies to new games launching after January 1, 2028.
Legacy Back Catalog: Discs pressed before this date will still function (assuming future hardware maintains optical drive compatibility).
"Code-in-a-Box" Retail: Stores will still sell physical cases on shelves, but they will contain a paper download voucher instead of a disc. I am no sustanability poster boy, seems wasteful to preserve retail shelf presence.

🛑 The Illusion of Ownership: "Buying" vs. "Renting"

When you hit "Buy" on a digital storefront, you aren't purchasing a game. You are purchasing a conditional license to stream or download it—a long-term rental agreement that can be unilaterally altered or revoked.

No Secondary Market: Players completely lose the ability to resell, trade, or lend games to friends.
Monopoly Pricing: Eliminating discs removes competitive pricing from retailers like GameStop, JB Hi-Fi, or Amazon, leaving users locked to a single proprietary storefront.
Delisting Vulnerability: If a publisher loses IP rights, the software vanishes instantly.

🎮 Case Study: My Close Call with Digital Erasure

Look no further than Star Trek: Resurgence for proof of how fragile digital stores are.

In April 2026, the publishers suddenly lost their IP distribution rights. Within hours, the game was entirely scrubbed from Steam, Xbox, PlayStation, and Nintendo stores. If you didn't already own it digitally, you could no longer buy it.

Because I bought the physical disc version, I completely bypassed this corporate licensing disaster. My access remains entirely uninterrupted.

🔄 The Masterful Irony of Microsoft & Sony

Microsoft pioneered the digital-first console concept, but they got burned doing it.

2013: Xbox One reveal tries digital-first ➡️ Sony mocks them ➡️ Microsoft backtracks.
2020: Xbox normalises discless consoles via the budget-friendly Xbox Series S.
2028: Sony takes the plunge, absorbs the primary backlash, and clears the path.

The roles have completely reversed. Sony is now absorbing the community anger, inadvertently clearing a safe path for Microsoft's rumoured next-gen console (Project Helix) to go entirely digital without taking the primary marketing hit.

💰 The Financial Play: Why the Disc Drive Had to Die

Consoles are astronomically expensive loss-leaders. Removing the optical drive is a calculated strategy to reclaim profit margins.

1. The 30% Platform Tax

Physical retail margins are incredibly fragmented. Digital distribution completely rewires the math:

Fee Breakdown	Physical Retail Split	Digital Storefront Split
Retailer Margin	20% – 25%	0%
Logistics & Pressing	\$8 – \$12 per unit	Near \$0
Console Maker Cut	~20% licensing fee	Flat 30% Platform Tax

Moving 100% of software sales into a proprietary ecosystem instantly doubles the console maker's profit margin.

2. Killing the Used Game Economy

Publishers despise the second-hand market. If a single disc is resold five times, five separate gamers play it, but the console makers only profit off the very first sale. Going 100% digital forces every single player to purchase an isolated, distinct license.

3. Discs are Modern Engineering Bottlenecks

Let's be real: physical discs are already just glorified plastic download tokens.

Read-Speed Limitations: Optical drives are too slow to stream modern assets, forcing consoles to copy the entire disc to an ultra-fast internal SSD anyway.
Day-One Dependencies: Massive day-one patches mean the data stamped onto the physical disc is usually obsolete before it even reaches store shelves.
Hardware Failure Points: Removing mechanical laser drives removes a major hardware failure point while freeing up physical chassis real estate for better cooling solutions.

4. Subsidising Next-Gen Hardware

With the explosion of AI infrastructure driving up silicon costs and heavy reliance on global chip foundries, next-gen components are getting more expensive to build.

Since hardware is traditionally sold at a loss to get consoles into living rooms, removing the optical drive allows console makers to claw back R&D costs on the box itself, ensuring 100% of future software revenue flows straight back to them.

⚖️ Other Considerations?

While the loss of consumer rights is valid, the transition isn't entirely black and white. Looking at the broader industry ecosystem reveals other winners and losers.

The Real Winners: Indie Developers & Security

Levelling the Playing Field: Physical distribution has historically been a gatekeeper. Smaller indie developers could never afford the millions required for global shipping and retail slotting fees. A 100% digital landscape guarantees a two-person team sits right next to a AAA giant on the dashboard.
Anti-Piracy & Leaks: Moving entirely to encrypted digital licensing drastically reduces day-one software piracy, disc theft, and street-date breaches by rogue retailers.

The Real Losers: Regional Gamers & Consumer Wallets

The "Digital Divide": High-speed internet is a luxury. For gamers in rural areas or countries with strict data caps, downloading a 150GB game is a massive barrier. Removing discs completely exiles these communities.
The Storage Tax: With games growing in size, players will face a secondary hardware tax. They will be forced to purchase expensive SSD upgrades just to hold their digital-only libraries.

🏁 Conclusion

The removal of the physical disc is financial engineering. Sony and Microsoft are transitioning from console makers into app store rulers, mirroring the highly profitable App Store blueprints laid out by Apple.

For the console makers, the math is simple:

Removing the physical retail supply chain instantly increases software margins.
Removing the second-hand market recoups lost revenue.
Removing mechanical disc drives cuts hardware manufacturing costs.

But for the gamer, this transition does come with a non financial price. Gamers are relinquishing true ownership, consumer rights, and long-term software preservation on the altar of business model evolution. Moving forward, games are no longer physical assets we own; they are software we rent.

🗣️ Let's Discuss

As developers, engineers, and tech enthusiasts, how do you view this shift?

Will the indie discovery boom outweigh the loss of consumer ownership?
From a business standpoint, is a 100% digital monopoly the only sustainable way to fund next-gen hardware?
How should the industry solve the looming digital preservation?

Drop your perspective in the comments below! 👇

The Myth of ‘Just Connect Lambda to RDS’

Steven Leung — Sun, 04 Jan 2026 12:09:56 +0000

You and I often see blogs about “connecting your Lambda to RDS is as simple as”...

Often will see blogs on internet with:

Connect your lambda to same VPC as RDS
Ensure VPC Security Groups correctly configured

This one‑liner manner, the reality is connecting Lambda to RDS is more to it then that, this orchestration is one of the more trickier parts within AWS serverless architecture.

I really dislike this oversimplification as it hides a lot of detail the real engineering challenges. In this blog I hope to offer more substantive deep dive and aim to provide reliably repeatable instructions.

CDK great for blogs and teaching

It would not be infrastructure blog without talking about CDK.
CDK very effective tool for conveying cloud infrastructure concepts in blogs.

Code-first approach: Infrastructure is defined using familiar programming languages, making it easier for developers to understand and follow, easy to convey concepts.
Readable and maintainable: Readers grasp concepts quickly.
Reusable: Code examples can be reused and extended.
Immediate feedback: Developers can test examples locally and possibly iterate, ideal for tutorials.

All Up Front

Tutorials tend to introduce larger concepts in small pieces then sewn together at the end

That approach is effective for teaching to beginners because it reduces mental overload and builds confidence.

However this blog is aimed at experienced AWS practitioners who only interested in the RDS/Lambda recipe.

So here, we will do the opposite, introducing the full solution first and then breaking it down into smaller pieces

This tutorial does assume working knowledge of CDK on reader's part.
The source code for this article can be found at Github

export class DatabaseConstruct extends Construct {
    private lambda: lambda.IFunction;

    const stackName = cdk.Stack.of(this).stackName;
    const instanceIdentifier = `${stackName}-rds-instance`;
    const vpcName = `${stackName}-vpc`;
    const lambdaSgName = `${stackName}-lambda-sg`;
    const rdsSgName = `${stackName}-rds-sg`;
    const secretName = `${stackName}-rds-secret`;

    constructor(scope: Construct, id: string) {
        super(scope, id);

    this.vpc = new ec2.Vpc(this, `${stackName}Vpc`, {
                subnetConfiguration: [
                    {
                        name: "Isolated",
                        subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
                        cidrMask: 24,
                    },
                ],
                natGateways: 0, // No NAT Gateway
                maxAzs: 2,
                vpcName
            });

    // Security group for Lambda
    this.lambdaSg = new ec2.SecurityGroup(this, `${stackName}LambdaSecurityGroup`, {
                vpc: this.vpc,
                description: "Lambda security group",
                securityGroupName: lambdaSgName,
                allowAllOutbound: false // Do NOT allow all outbound traffic
            });

    // Security group for RDS
    this.rdsSg = new ec2.SecurityGroup(this, `${stackName}RdsSecurityGroup`, {
                vpc: this.vpc,
                description: "RDS security group",
                securityGroupName: rdsSgName,
                allowAllOutbound: false // Do NOT allow all outbound traffic
            });

    this.rdsInstance = new rds.DatabaseInstance(this, `${stackName}RdsInstance`, {
                engine: rds.DatabaseInstanceEngine.postgres({version: rds.PostgresEngineVersion.VER_17_4}),
                vpc: this.vpc,
                instanceType: ec2.InstanceType.of(ec2.InstanceClass.T4G, ec2.InstanceSize.MICRO),
                credentials: rds.Credentials.fromGeneratedSecret('postgres', {secretName}),
                multiAz: false,
                allocatedStorage: 20,
                maxAllocatedStorage: 100,
                publiclyAccessible: false, //Do NOT make RDS publiclyAccessible.
                vpcSubnets: {subnetType: ec2.SubnetType.PRIVATE_ISOLATED},
                removalPolicy: cdk.RemovalPolicy.SNAPSHOT,
                deletionProtection: false,
                securityGroups: [this.rdsSg],
                instanceIdentifier,
                storageEncrypted: true,
            });

    this.dbSecret = (this.rdsInstance as rds.DatabaseInstance)?.secret;

    // Add this after VPC creation
    this.vpc.addInterfaceEndpoint('SecretsManagerEndpoint', {
                service: ec2.InterfaceVpcEndpointAwsService.SECRETS_MANAGER,
            });

    this.rdsSg.addIngressRule(this.lambdaSg, ec2.Port.tcp(5432), "Allow Lambda to access RDS");
    this.lambdaSg.addEgressRule(
                ec2.Peer.anyIpv4(),
                ec2.Port.tcp(443),
                "Allow outbound HTTPS to Secrets Manager"
            );
    this.lambdaSg.addEgressRule(this.rdsSg, ec2.Port.tcp(5432), "Allow outbound access to RDS");

    // Get the subnet used by RDS
    // Prevents Cross Zone Data Transfer Charges
    // After VPC creation, select the isolated subnets for RDS
    const rdsSubnets = this.vpc.selectSubnets({subnetType: ec2.SubnetType.PRIVATE_ISOLATED});
        const rdsSubnet = rdsSubnets.subnets[0];

    const role = new iam.Role(this, `${stackName}LambdaExecutionRole`, {
                assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
                description: "Role for Lambda functions to access RDS and Secrets Manager",
                roleName: `${stackName}LambdaExecutionRole`,
                managedPolicies: [
                    iam.ManagedPolicy.fromAwsManagedPolicyName("service-role/AWSLambdaBasicExecutionRole"),
                    iam.ManagedPolicy.fromAwsManagedPolicyName("service-role/AWSLambdaVPCAccessExecutionRole"),
                ],

                inlinePolicies: {
                    // Allow Lambda to access RDS and Secrets Manager
                    LambdaRdsSecretsManagerPolicy: new iam.PolicyDocument({
                        statements: [
                            new iam.PolicyStatement({
                                effect: iam.Effect.ALLOW,
                                actions: ["secretsmanager:GetSecretValue"],
                                resources: [stage != 'prod'
                                    ? `arn:aws:secretsmanager:ap-southeast-2:${cdk.Stack.of(this).account}:secret:${secretName}*`
                                    : this.dbSecret!.secretFullArn ?? ''
                                ],
                            }),
                            new iam.PolicyStatement({
                                effect: iam.Effect.ALLOW,
                                actions: ["secretsmanager:ListSecrets"],
                                resources: ["*"],
                            }),
                        ],
                    }),
                },
            }
        );

    // Lambda function in VPC
    this.lambda = this.createLamba({
            stackName,
            functionName: "Lambda",
            code: "/dist/",
            description: "Lambda function",
            role,
            rdsSubnet,
            timeout: Duration.seconds(29),
        });

    }
}

Sanity Check

Once successfully deployed and before proceeding, you can use AWS CloudShell to connect to your RDS instance.
CloudShell provides a browser-based terminal with AWS
CLI and common tools pre-installed.

You can connect to your RDS database using the psql command for PostgreSQL or mysql for MySQL, as long as:

The RDS instance is publicly accessible or accessible from the CloudShell VPC.
The security group of your RDS instance allows inbound connections from the CloudShell IP range.
Example for PostgreSQL:

psql --host=<RDS-endpoint> --port=5432 --username=<username> --dbname=<database>

Caveats and Nuances

Because of the simple one line "Just connect your lambda to RDS". A lot of nuances are overlooked. Here I've done the research so you don't have to.

The full solution available above, I won't go over every line of code. I do want to highlight certain lines that would serve as gotcha moments.

1. Be wary of CDK Defaults

// Create VPC
this.vpc = new ec2.Vpc(this, `${stackName}Vpc`, {
subnetConfiguration: [
{
                        name: "Isolated",
                        subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
                        cidrMask: 24,
},
],
natGateways: 0, // No NAT Gateway
maxAzs: 2,
vpcName
});

          this.lambdaSg = new ec2.SecurityGroup(this, `${stackName}LambdaSecurityGroup`, {
                vpc: this.vpc,
                ...
                allowAllOutbound: false // Do NOT allow all outbound traffic
            });

            // Security group for RDS
            this.rdsSg = new ec2.SecurityGroup(this, `${stackName}RdsSecurityGroup`, {
                vpc: this.vpc, 
                ...
                allowAllOutbound: false // Do NOT allow all outbound traffic
            });

You need to be explicit in CDK as when you do not, CDK will assume defaults. Important you become familiar with CDK defaults/fallbacks.

One example when not specified CDK will create VPCs with public subnets and NAT gateways as fallback.

VPC security groups are also created with allowing all outbound by default which is not what we want in this scenario.

Besides being explicit in code is good habit for developers to form as it makes your code more readable to other developers.

2. RDS A pain to instantiate

If we honest, whether it's CDK, Cloudformation or Clickops. Instatitating an instance of RDS can be painful if you get wrong. Not easy to correct. Once created, some settings are not a case of edit and clicking "save changes".

 this.rdsInstance = new rds.DatabaseInstance(this, `${stackName}RdsInstance`, {
engine: rds.DatabaseInstanceEngine.postgres({version: rds.PostgresEngineVersion.VER_17_4}),
                vpc: this.vpc,
                instanceType: ec2.InstanceType.of(ec2.InstanceClass.T4G, ec2.InstanceSize.MICRO),
                credentials: rds.Credentials.fromGeneratedSecret('postgres', {secretName}),
                multiAz: false,
                allocatedStorage: 20,
                maxAllocatedStorage: 100,
                publiclyAccessible: false, //Do NOT make RDS publiclyAccessible.
                vpcSubnets: {subnetType: ec2.SubnetType.PRIVATE_ISOLATED},
                removalPolicy: cdk.RemovalPolicy.SNAPSHOT,
                deletionProtection: false,
                securityGroups: [this.rdsSg],
                instanceIdentifier,
                storageEncrypted: true,
});

RDS resource is not easily editable once created making exploration and experimentation difficult.
RDS instances take long time to stand down, delete and reinstantiate.

Properties to look out for:

multiAz: For development purposes, do not need multiple AZs. Not to mention costly. Prod deployments would be another conversation.
instanceType: For our development purposes, use free tier of RDS, Micro T4 instance to keep costs low.
publiclyAccessible: we do not want this or any DB instance to be publicly available on the internet.
vpcSubnets: Part our security, we need to specify that RDS exists in private subnet with no access to internet.
removalPolicy/deletionProtection: For development purposes, these properties make easier to tear down and redo.
storageEncrypted: Enables database encryption, good practice for data at rest to be encrypted. Should DB be created without encryption, challenging to enable later as afterthought, so better to enable at time of DB creation.

3. AWS Secrets still needs to be allowed accessed

Security practice is to simply provide AWS Secret Name as lambda environmental variable, and lambda logic would retrieve database connection string from AWS Secrets using secret name

Remember this VPC is tightly locked down to internal access only with no external access allowed. We have also disabled NAT gateways.

As such our VPC will need to allow Lambda to access to AWS Secrets using VPC Interface(s).

this.vpc.addInterfaceEndpoint('SecretsManagerEndpoint', {
                service: ec2.InterfaceVpcEndpointAwsService.SECRETS_MANAGER,
            });

...

this.lambdaSg.addEgressRule(
                ec2.Peer.anyIpv4(),
                ec2.Port.tcp(443),
                "Allow outbound HTTPS to Secrets Manager"
            );

4. Reduce Data Transfer Fees

const rdsSubnets = this.vpc.selectSubnets({subnetType: ec2.SubnetType.PRIVATE_ISOLATED});
const rdsSubnet = rdsSubnets.subnets[0];

...

this.lambda = this.createLamba({
            stackName,
            functionName: "Lambda",
            code: "/dist/",
            description: "Lambda function",
            role,
            rdsSubnet,
            timeout: Duration.seconds(29),
        });

When your Lambda function and RDS instance are in different Availability Zones (AZs) within the same AWS Region.

AWS does charge for data transferred between those AZs. This is called "cross-AZ data transfer" and is billed per GB.
Key points:

Data transfer between AZs in the same region is not free.
If Lambda and RDS are in different AZs, every query result or data exchange incurs cross-AZ charges.

This line of code ensures both lambda and RDS are in the same AZ helping to avoid cross zone charges.

5. Lambda Execution Roles IAM Policy

const role = new iam.Role(this, `${stackName}${stage}LambdaExecutionRole`, {
                assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
                description: "Role for Lambda functions to access RDS and Secrets Manager",
                roleName: `${stackName}${stage}LambdaExecutionRole`,
                managedPolicies: [
                    iam.ManagedPolicy.fromAwsManagedPolicyName("service-role/AWSLambdaBasicExecutionRole"),
                    iam.ManagedPolicy.fromAwsManagedPolicyName("service-role/AWSLambdaVPCAccessExecutionRole"),
                ],


            }
        );

Your lambda needs the AWSLambdaVPCAccessExecutionRole policy because your Lambda function runs inside a VPC. This policy grants permissions for Lambda to manage network interfaces (ENIs) inside your VPC, which are required for your function to access resources like RDS, private subnets and so on.

Without this policy, Lambda will not be able to create or manage the necessary network interfaces, and your lambda function will fail to start in a VPC.

6. Imported Resources from other instances of CDK stack

If your solution followed traditional CI/CD using stages dev, uat and prod.

CDK would create RDS instances for each stage which could get costly.
To reduce cost, you could import resources created from one stage into another.

this.vpc = Vpc.fromLookup(this, `${stackName}Vpc`, {vpcName});

this.lambdaSg = SecurityGroup.fromLookupByName(this, `${stackName}LambdaSecurityGroup`, lambdaSgName, this.vpc);

this.rdsSg = SecurityGroup.fromLookupByName(this, `${stackName}RdsSecurityGroup`, rdsSgName, this.vpc);

this.rdsInstance = rds.DatabaseInstance.fromLookup(this, `${stackName}ProdRdsImport`, {
                instanceIdentifier,
            });

this.dbSecret = secretsmanager.Secret.fromSecretNameV2(this, `${stackName}RdsSecret`, secretName);

Once this.dbSecret is imported, we can access access secretFullArn property aka this.dbSecret!.secretFullArn

Incorrect, secretFullArn is only available for secrets instantiated using new constructor style. When you import a secret using fromSecretNameV2, limited to properties like secretArn and secretName are available, the secretFullArn will not be available.

Workaround: Provide this.dbSecret!.secretName as environmental variable to your lambda and the logic within your lambda will resolve secret name to secret arn, hence why secretsmanager:ListSecrets action with "*" resources was provided as IAM policy within LambdaExecutionRole

Conclusion

Connecting a Lambda function to RDS is never a one line exercise, and treating as such sets developers up for pain later. The real work resides with Infrastructure as code: networking, security, and the subtle properties AWS services that only become obvious when exploring and experimenting.

My goal in this blog was to move past the one‑liner advice and give you a repeatable approach you can rely on.

Also encourage you to take the time to explore and understand all moving parts.

About Myself

I am a Senior Software Engineer with Australia's national IT consultancy Versent, I hope to be known for my AWS expertise, holding multiple AWS certifications and being recognised as an AWS Community Builder.

With several decades of software engineering experience, I have delivered full‑stack, integration, and cloud‑native solutions across major enterprise clients in energy, health, and education.

I aim not only to bring technical capability, also community spirit by being involved with local tech events and conferences.

More Info

Check out my Linked In, feel free to follow me
Click here to browse plenty of more articles from the AWS Builders