![SST Logo](/assets/images/blog/2023/10/09/00-cover.png)

This week I've had to write CDK code into an existing SST application. I needed to look up the 3x private Subnets for 
a custom VPC (obviously created externally of the SST application as you'd expect), so that I could create an 
Application Load Balancer that would support the application when dealing with its private APIs. What I found was this 
code was working when I ran the `sst build | sst deploy | sst diff` commands against one account, but would fail when targeting
a different account. So imagine it would succeed against a `sandbox` account but would then fail against a `staging` 
account despite both accounts being configured in exactly the same way from the same external Infrastructure as Code.

After a number of hours of tedious checking and comparing, both by looking at the various Subnets configurations 
in the AWS Console and also via the AWS CLI using commands like `aws ec2 describe-subnets` I concluded that everything
was in order and the issue must lay elsewhere. 

### Enter CDK Context. 

I decided there might be something cached by SST that was causing the weird outputs that I was seeing, so I decided to 
try and eliminate this by cloning the repo to another directory. I did this and then tried to execute the `sst build` 
against the same accounts again. 

To my surprise this broke in the same way even when targeting the accounts that had worked previously. I dug into the 
CDK source code to look at the `Vpc.fromLookup()` method in more detail and I found this nice message. 

> Import an existing VPC by querying the AWS environment this stack is deployed to.
> This function only needs to be used to use VPCs not defined in your CDK application. If you are looking to share a VPC 
> between stacks, you can pass the Vpc object between stacks and use it as normal.
> Calling this method will lead to a lookup when the CDK CLI is executed. You can therefore not use any values that 
> will only be available at CloudFormation execution time (i.e., Tokens). The VPC information will be cached in 
> cdk.context.json and the same VPC will be used on future runs. To refresh the lookup, you will have to evict the 
> value from the cache using the cdk context command. See https://docs.aws.amazon.com/cdk/latest/guide/context.html 
> for more information.

At this point I was convinced there must be something going on with the cache and I would just delete the context 
entirely in both copies of my repo. I ran `cdk context --clear` in both directories and tried `sst build` again. 

Now neither would build against any accounts, instead both times I just received an error that I couldn't access 
subnet[2] of undefined. So I decided to try to re-produce in new repo. I created a single stack that did a Vpc Lookup 
and logged out each private Subnet ID to the console.

I was expecting to see 3x results as the private VPC I was referencing contains 3x private Subnets. 

```javascript
// ID of a VPC that has 3x private subnets  
const vpcID = "vpc-???"

const vpc = Vpc.fromLookup(stack, "vpc-lookup", {
    vpcId: vpcID
})

vpc.privateSubnets.map(x => console.log(`Subnet ID: ${x.subnetId}`))
```

To my surprise I saw the following output:

```shell
Subnet ID: p-12345
Subnet ID: p-67890
Subnet ID: subnet-... (real value was returned here)
Subnet ID: subnet-... (real value was returned here)
Subnet ID: subnet-... (real value was returned here)
```

It seems that if you already have a CDK Context (cdk.context.json) that contains the VPC and Subnet information then 
your code will behave as expected and return you the 3x private Subnets and it will log out the IDs. If you don't have 
the CDK Context it seems to just return 2x Subnets with dummy placeholder values.  The problem with this is if your 
code is expecting and depends upon 3x private Subnets then the `sst build` errors before it runs for real to fetch the 
actual values.

We can prove this by doing the following instead.

```javascript
  // Insert the ID of a VPC that has 3x private subnets here
const vpcID = "vpc-???" 

const vpc = Vpc.fromLookup(stack, "vpc-lookup", {
    vpcId: vpcID
})

// With a CDK Context this will print out the Subnet IDs
// for all 3 of my private subnets
// Without a CDK Context this will print out 2x dummy Subnet IDs
// then it will look up the real VPC and print out the 3x REAL Subnet IDs
console.log(`Subnet 1 ID: ${vpc.privateSubnets[0].subnetId}`)
console.log(`Subnet 2 ID: ${vpc.privateSubnets[1].subnetId}`)

// If we include this line then we will get an error because
// the privateSubnets array only contains 2 dummy values,
// and we're trying to reference the third value that would
// only be looked up later
console.log(`Subnet 3 ID: ${vpc.privateSubnets[2].subnetId}`)

// Without trying to access the third private subnet the actual output will be
// Subnet 1 ID: p-12345 // dummy placeholder
// Subnet 2 ID: p-67890 // dummy placeholder
// Subnet 1 ID: subnet-?????? // first real value
// Subnet 2 ID: subnet-?????? // second real value
// Subnet 3 ID: subnet-?????? // third real value
```
As mentioned in the comments, if you comment out that third console.log then the `sst build` will succeed. You will get 
similar output to above where you will see the 2x placeholder values and then the 3x real values afterward.

If you include the third console.log then the `sst build` will error and quit because the code is trying to log out 
a third Subnet ID which doesn't exist in the dummy response. 

If you have a valid CDK Context already with all of your VPC and Subnet data in it, then you will see a single output: 

```shell
Subnet 1 ID: subnet-... (real value was returned here)
Subnet 2 ID: subnet-... (real value was returned here)
Subnet 3 ID: subnet-... (real value was returned here)
```

---
EDIT: ~~Who is to blame here? Is this CDK or is this SST?~~

CDK is at fault here. I have now recreated the problem in a pure CDK [sample project](https://github.com/liam-reilly-info/cdk-context-bug). 
It's unfortunate that my post here tarred SST with this issue, but unfortunately I'm forced to support SST and it's 
built on CDK and CloudFormation. I guess they are always going to suffer for problems beyond their control.

Download the sample code using CDK [here](https://github.com/liam-reilly-info/cdk-context-bug)

Download the sample code using SST & CDK [here](https://github.com/liam-reilly-info/sst-cdk-context-bug)

---
Surely I should be able to look up basic information such as Vpc and
Subnet details? I cannot be expected to always have an CDK Context that happens to contain this information?

It's stuff like this that make me despair and miss Terraform. I've never in my life had to worry about such basic things
as this, and I've been building cloud infrastructure, applications and services for almost a decade at this point.


STILL SST-RUGGLING

Did you enjoy this post?️

You Might Also Like

Idiocracy

GOOGLE I/O - 2023 - KEYNOTE THOUGHTS