Skip to main content
RapidDev - Software Development Agency
cursor-tutorial

Why Cursor Suggests Outdated Cloud Patterns

Cursor frequently generates AWS CDK v1 patterns including core module imports, deprecated construct APIs, and outdated Stack syntax because its training data contains more v1 examples. By adding project rules that specify CDK v2, referencing your package.json and existing stacks with @file, and prompting with explicit version context, you ensure Cursor generates code using the current aws-cdk-lib unified module and modern construct patterns.

What you'll learn

  • How to create Cursor rules that enforce AWS CDK v2 patterns
  • How to stop Cursor from importing deprecated @aws-cdk/* packages
  • How to use @docs to give Cursor access to current CDK documentation
  • How to prompt Cursor for modern CDK constructs with L2/L3 patterns
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Beginner7 min read10-15 minCursor Free+, AWS CDK v2 projectsMarch 2026RapidDev Engineering Team
TL;DR

Cursor frequently generates AWS CDK v1 patterns including core module imports, deprecated construct APIs, and outdated Stack syntax because its training data contains more v1 examples. By adding project rules that specify CDK v2, referencing your package.json and existing stacks with @file, and prompting with explicit version context, you ensure Cursor generates code using the current aws-cdk-lib unified module and modern construct patterns.

Why Cursor suggests outdated cloud patterns and how to fix it

AWS CDK v1 and v2 have fundamentally different import structures. V1 used separate packages like @aws-cdk/aws-s3 while v2 uses a single aws-cdk-lib package. Cursor's training data contains far more v1 examples, leading it to generate deprecated imports and patterns. This tutorial configures Cursor to always use CDK v2 with current best practices.

Prerequisites

  • Cursor installed with an AWS CDK v2 project
  • aws-cdk-lib and constructs packages installed
  • Basic understanding of AWS CDK stacks and constructs
  • Familiarity with Cursor Chat (Cmd+L) and project rules

Step-by-step guide

1

Create an AWS CDK v2 enforcement rule

Add a project rule that specifies CDK v2 conventions and explicitly bans v1 patterns. The key difference is the import structure: v2 uses aws-cdk-lib as a single package while v1 used dozens of separate @aws-cdk packages.

.cursor/rules/aws-cdk.mdc
1---
2description: Enforce AWS CDK v2 patterns
3globs: "*.ts,**/cdk/**,**/infra/**"
4alwaysApply: true
5---
6
7# AWS CDK v2 Rules
8- Project uses AWS CDK v2 with aws-cdk-lib
9- NEVER import from @aws-cdk/* packages (that is CDK v1)
10- ALWAYS import from 'aws-cdk-lib' and 'aws-cdk-lib/aws-*'
11- ALWAYS import Construct from 'constructs' (not @aws-cdk/core)
12- Use L2 constructs where available, L1 (Cfn*) only when needed
13- Use Stack.of(this) for cross-stack references
14- Use cdk.RemovalPolicy.DESTROY for dev, RETAIN for prod
15- Use cdk.Tags.of() for resource tagging
16
17## Correct Imports:
18```typescript
19import * as cdk from 'aws-cdk-lib';
20import * as s3 from 'aws-cdk-lib/aws-s3';
21import * as lambda from 'aws-cdk-lib/aws-lambda';
22import { Construct } from 'constructs';
23```
24
25## WRONG Imports (CDK v1 NEVER use):
26```typescript
27import * as cdk from '@aws-cdk/core'; // WRONG
28import * as s3 from '@aws-cdk/aws-s3'; // WRONG
29import { Construct } from '@aws-cdk/core'; // WRONG
30```

Expected result: Cursor generates CDK code using aws-cdk-lib imports and v2 patterns instead of deprecated v1 packages.

2

Reference your CDK project for version context

Always reference package.json and an existing stack file when prompting Cursor for CDK code. This gives Cursor concrete proof of your CDK version and existing patterns to follow.

Cmd+L prompt
1@aws-cdk.mdc @package.json @lib/main-stack.ts
2
3Add an S3 bucket to the main stack with these requirements:
41. Versioning enabled
52. Server-side encryption with S3-managed keys
63. Lifecycle rule: move to IA after 30 days, Glacier after 90, delete after 365
74. Block all public access
85. CORS configured for the frontend domain
96. RemovalPolicy.DESTROY for dev environment
10
11Use CDK v2 L2 constructs from aws-cdk-lib/aws-s3.
12Follow the same patterns as existing resources in the stack.

Pro tip: Reference an existing stack file with @file so Cursor matches your constructor signature, naming conventions, and resource organization patterns.

Expected result: Cursor generates an S3 bucket using aws-cdk-lib/aws-s3 with L2 construct methods and proper v2 import structure.

3

Use @docs to reference current CDK API documentation

Add the AWS CDK v2 API reference to Cursor's indexed docs. This gives Cursor access to current construct APIs and prevents it from suggesting deprecated methods. Open Cursor Settings, add the CDK docs URL, and then reference it in prompts.

Cmd+L prompt
1@docs AWS CDK @aws-cdk.mdc
2
3Create a Lambda function with API Gateway integration:
41. Node.js 20 runtime with arm64 architecture
52. API Gateway v2 HTTP API (not REST API)
63. Lambda function URL as an alternative endpoint
74. Environment variables from SSM Parameter Store
85. X-Ray tracing enabled
96. Log retention set to 14 days
10
11Use aws-cdk-lib L2 constructs. Reference the latest CDK v2 API
12for HttpApi and NodejsFunction constructs.

Expected result: Cursor generates Lambda and API Gateway code using current CDK v2 constructs with correct method signatures.

4

Fix v1 imports in existing code with Cmd+K

If Cursor generates v1-style imports despite your rules, select the import block and use Cmd+K to fix them. This is a quick correction that teaches you the exact import mapping between v1 and v2.

Cmd+K prompt
1Convert all CDK v1 imports to CDK v2.
2Replace @aws-cdk/* with aws-cdk-lib/*.
3Replace @aws-cdk/core with aws-cdk-lib.
4Replace Construct from @aws-cdk/core with Construct from constructs.
5Do not change any other code, only the import statements.

Expected result: All imports are converted from @aws-cdk/package to aws-cdk-lib/package format.

5

Generate a complete CDK stack with Composer

Use Composer Agent mode to generate multiple CDK constructs and stack files at once. This approach maintains consistent imports and patterns across all generated infrastructure code.

Cmd+I prompt
1@aws-cdk.mdc @package.json @lib/main-stack.ts
2
3Create a new microservice infrastructure stack with:
41. lib/api-stack.ts API Gateway HTTP API + Lambda functions
52. lib/database-stack.ts DynamoDB table with GSIs
63. lib/monitoring-stack.ts CloudWatch alarms and dashboard
74. lib/constructs/api-lambda.ts reusable L3 construct for Lambda+API
8
9All files must use aws-cdk-lib imports (CDK v2).
10Follow the same Stack constructor pattern as main-stack.ts.
11Use cross-stack references with cdk.CfnOutput and cdk.Fn.importValue.

Expected result: Cursor Agent generates four CDK files with consistent v2 imports, L2 constructs, and cross-stack reference patterns.

Complete working example

.cursor/rules/aws-cdk.mdc
1---
2description: Enforce AWS CDK v2 patterns
3globs: "*.ts,**/cdk/**,**/infra/**,**/lib/**"
4alwaysApply: true
5---
6
7# AWS CDK v2 Rules
8- Project uses AWS CDK v2 with aws-cdk-lib
9- NEVER import from @aws-cdk/* packages (CDK v1 deprecated)
10- ALWAYS import from 'aws-cdk-lib' and 'aws-cdk-lib/aws-*'
11- ALWAYS import Construct from 'constructs' package
12- Use L2 constructs first, L1 (Cfn*) only when L2 lacks a feature
13- Use Stack.of(this) for cross-stack references
14- Use cdk.Tags.of() for consistent resource tagging
15- Use cdk.CfnOutput for exported values
16
17## Correct Import Pattern:
18```typescript
19import * as cdk from 'aws-cdk-lib';
20import * as s3 from 'aws-cdk-lib/aws-s3';
21import * as lambda from 'aws-cdk-lib/aws-lambda';
22import * as apigw from 'aws-cdk-lib/aws-apigatewayv2';
23import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
24import { Construct } from 'constructs';
25```
26
27## Stack Constructor Pattern:
28```typescript
29export class MyStack extends cdk.Stack {
30 constructor(scope: Construct, id: string, props?: cdk.StackProps) {
31 super(scope, id, props);
32 // resources here
33 }
34}
35```
36
37## FORBIDDEN (CDK v1):
38```typescript
39import * as cdk from '@aws-cdk/core'; // NEVER
40import * as s3 from '@aws-cdk/aws-s3'; // NEVER
41```

Common mistakes

Why it's a problem: Not specifying CDK version in rules, getting mixed v1/v2 imports

How to avoid: Add explicit NEVER import from @aws-cdk/* and ALWAYS import from aws-cdk-lib to your rules with examples of both correct and incorrect patterns.

Why it's a problem: Referencing CDK v1 documentation or blog posts in prompts

How to avoid: Always use @docs with the official CDK v2 API reference. Remove v1 code from your project before asking Cursor to extend it.

Why it's a problem: Using L1 (Cfn) constructs when L2 constructs are available

How to avoid: Add to rules: Use L2 constructs first, L1 (Cfn*) only when the L2 construct does not support a specific feature.

Best practices

  • Always reference package.json and an existing stack file when generating CDK code
  • Use @docs with the CDK v2 API reference for up-to-date construct APIs
  • Create reusable L3 constructs for common patterns and reference them with @file
  • Include both correct and incorrect import examples in your rules file
  • Use Cmd+K to quickly fix v1 imports rather than regenerating entire files
  • Keep CDK rules in a separate .mdc file from application code rules
  • Start new Chat sessions if Cursor reverts to v1 patterns mid-conversation

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I need to create an AWS CDK v2 stack with an S3 bucket, Lambda function, API Gateway HTTP API, and DynamoDB table. Use aws-cdk-lib imports (not @aws-cdk packages). Use L2 constructs and TypeScript. Include proper IAM permissions between services.

Cursor Prompt

@aws-cdk.mdc @package.json @lib/main-stack.ts Add a DynamoDB table to the main stack with a partition key, sort key, two GSIs, on-demand billing, point-in-time recovery, and TTL. Use aws-cdk-lib/aws-dynamodb L2 constructs following CDK v2 patterns.

Frequently asked questions

Why does Cursor keep importing from @aws-cdk packages?

CDK v1 had years of widespread adoption and its import patterns dominate Cursor's training data. Explicit rules with both correct and incorrect examples are the most effective fix.

Can Cursor generate CDK for languages other than TypeScript?

Yes. CDK supports Python, Java, C#, and Go. Adjust your rules to specify the language and include language-specific import patterns.

How do I keep Cursor updated on new CDK constructs?

Use @docs to index the CDK v2 API reference. When new constructs are released, Cursor can reference them through the indexed documentation.

Should I use CDK or Terraform with Cursor?

Both work well with Cursor. CDK is better if your team prefers TypeScript. Terraform has broader provider support. Create tool-specific rules regardless of which you choose.

Can Cursor generate CDK tests?

Yes. Prompt Cursor with @file referencing your stack and ask for assertion-based tests using aws-cdk-lib/assertions. Include your test framework (Jest) in the prompt.

Can RapidDev help set up cloud infrastructure?

Yes. RapidDev designs AWS infrastructure using CDK with proper security, monitoring, and cost optimization, and configures Cursor rules for ongoing infrastructure development.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.