TIL: You can import existing resources into CDK stacks using the `fromLookup` method.

In our ongoing migration from a legacy Terraform-managed AWS environment to AWS CDK, a significant hurdle was always the state migration. The prospect of a "big bang" cutover, where we would need to recreate all foundational VPCs, security groups, and RDS instances from scratch, was a major project risk. Recently, I discovered a method within the CDK that elegantly sidesteps this issue for a large class of resources: the static `fromLookup` methods available on many L2 constructs.

The core concept is that CDK can perform a real-time lookup of existing AWS resources during the synthesis phase, using the AWS SDK. This allows you to import these resources into your CDK application's logical model without ever needing to manage their state or risk recreating them. It's a powerful tool for incremental adoption, where you can start writing new infrastructure in CDK while having it seamlessly reference the old, manually created or Terraform-managed infrastructure.

The typical pattern involves using the `fromLookup` method on a construct class. Here is a practical example for importing an existing VPC and an RDS database instance:

```typescript
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as rds from 'aws-cdk-lib/aws-rds';

// Look up an existing VPC by its tags or ID.
// CDK will perform a DescribeVpcs call during synthesis.
const existingVpc = ec2.Vpc.fromLookup(this, 'ImportedVpc', {
vpcId: 'vpc-12345678', // You can specify ID, or rely on tags
// isDefault: true // Alternatively, look up the default VPC
});

// Look up an existing RDS instance by its instance identifier.
const existingDatabase = rds.DatabaseInstance.fromLookup(this, 'ImportedDb', {
instanceIdentifier: 'legacy-production-db',
});

// Now, you can use these in your new CDK constructs.
new ec2.Instance(this, 'NewAppServer', {
vpc: existingVpc,
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM),
machineImage: ec2.MachineImage.latestAmazonLinux2(),
// Security group referencing the imported Vpc is straightforward.
});
```

It is crucial to understand the operational mechanics and limitations:
* **Synthesis-Time Operation:** The lookup happens when you run `cdk synth`. The resolved physical IDs are stored in the generated CloudFormation template as plain parameters or embedded strings. This means the CloudFormation stack itself has no special "import" operation; it simply references the already-existing resource.
* **Read-Only Reference:** CDK treats these looked-up resources as immutable, read-only references. You cannot modify their core properties (like CIDR block for a VPC) through CDK. Any changes must be made via the original provisioning tool or manually, after which a subsequent `cdk synth` will pick up the new attributes.
* **Tag-Based Discovery:** For resources like VPCs, using tags (e.g., `tags: { 'Environment': 'Production' }`) is often more robust than hardcoding IDs, as it aligns with how many teams already manage their resources.

For our team, this approach has transformed the migration strategy. We are now able to decompose the monolithic Terraform state by layers, starting with the application-layer resources (Lambdas, ECS services, API Gateways) that we can now define in CDK while they safely depend on the looked-up network and data layers. The primary effort shifts from risky state manipulation to refactoring infrastructure definitions into TypeScript, which brings immediate benefits in terms of type safety, reusable constructs, and developer experience. While not a complete solution for every resource (some may require a formal CloudFormation import), `fromLookup` has proven to be an indispensable tool for a controlled, low-risk IaC migration.