Latest posts

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2024-07-01 </dd>

In modern cloud architectures, it's essential to secure communication between your resources within a Virtual Private Cloud (VPC) and other AWS services. VPC Endpoints provide a secure and scalable way to connect your VPC to AWS services without traversing the public internet, reducing the risk of data exposure and improving network performance.

This blog post will walk you through a CloudFormation template that creates multiple VPC Endpoints for popular AWS services like Amazon S3, DynamoDB, CloudWatch Logs, and AWS Systems Manager (SSM). We'll also cover the necessary security groups and policies to control access to these endpoints.

#### [The CloudFormation Template](https://github.com/AndrzejKomarnicki/cloudformation_utils/blob/main/vpc-endpoints/vpcendpoints.yaml)

The provided YAML template creates the following resources:

- Gateway VPC Endpoints: For Amazon S3 and DynamoDB, allowing private connectivity from your VPC to these services.

- Interface VPC Endpoints: For CloudWatch Monitoring, CloudWatch Logs, SSM, and SSM Messages, enabling private access to these services from your VPC.

- Security Groups: A default security group for the interface endpoints, and a separate security group for EC2 Instance Connect.

Here's a breakdown of the key sections in the template:

```yaml
Parameters:
 VpcId:
 Type: String
 Description: VPC ID
 VpcCIDR:
 Type: String
 Description: VPC CIDR to associate with VPC Endpoint security group
 SubnetIds:
 Type: List<String>
 Description: Comma-separated list of subnet IDs
 RouteTableIds:
 Type: List<String>
 Description: Comma-separated list of route table IDs
```

The template accepts four parameters: the VPC ID, the VPC CIDR block (optional), a list of subnet IDs, and a list of route table IDs. These parameters allow you to customize the deployment to your specific VPC and network configuration.

```yaml
Resources:
 VPCEndpointSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group
 VpcId: !Ref VpcId
```

This section creates a security group for the interface VPC Endpoints. You can modify the security group rules to control inbound and outbound traffic to these endpoints.

```yaml
S3Endpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - s3:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
```

This resource creates a Gateway VPC Endpoint for Amazon S3. Note the PolicyDocument property, which allows all actions _(s3:\*)_ on all S3 resources _(\*)_. You can modify this policy to restrict access as needed.

The template includes similar resources for creating VPC Endpoints for DynamoDB, CloudWatch Monitoring, CloudWatch Logs, SSM, and SSM Messages.

##### Deploying the Template

To deploy this CloudFormation template, you'll need to provide the required parameters (VPC ID, subnet IDs, and route table IDs) specific to your AWS account and VPC configuration. You can deploy the template using the AWS Management Console, AWS CLI, or AWS CloudFormation APIs.

Once deployed, your VPC will have secure, private connectivity to the specified AWS services, without the need for internet gateways, NAT gateways, or public IP addresses.

#### Conclusion

VPC Endpoints are a powerful tool for securing communication between your VPC resources and AWS services. By using CloudFormation templates like the one provided, you can streamline the deployment of VPC Endpoints across multiple accounts and environments, ensuring consistent and secure network configurations.

Remember to review and customize the security group rules and endpoint policies to align with your organization's security requirements and access controls. Additionally, consider automating the deployment process using CI/CD pipelines or infrastructure-as-code tools for efficient and repeatable infrastructure provisioning.

##### Original Complete Template:

```yaml
AWSTemplateFormatVersion: 2010-09-09
Description: Create Gateway VPC Endpoints for S3 and DynamoDB. Interface VPC Endpoints for CloudWatch Monitoring/Logs, EC2 Instance Connect and SSM with a default SG.
Parameters:
 VpcId:
 Type: String
 Description: VPC ID
 VpcCIDR:
 Type: String
 Description: VPC CIDR to associate with VPC Endpoint security group (if not provided 0.0.0.0/0 will be used instead)
 SubnetIds:
 Type: List<String>
 Description: Comma separated list of subnet IDs
 RouteTableIds:
 Type: List<String>
 Description: Comma separated list of route table IDs
Conditions:
 HasVpcCIDR: !Not
 - !Equals
 - ""
 - !Ref VpcCIDR
Resources:
 VPCEndpointSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group
 VpcId: !Ref VpcId
 VPCEndpointSecurityGroupIngress:
 Type: AWS::EC2::SecurityGroupIngress
 Properties:
 GroupId: !Ref VPCEndpointSecurityGroup
 FromPort: 443
 ToPort: 443
 IpProtocol: tcp
 SourceSecurityGroupId: !Ref VPCEndpointSecurityGroup
 VPCEndpointSecurityGroupIngress2:
 Type: AWS::EC2::SecurityGroupIngress
 Properties:
 GroupId: !Ref VPCEndpointSecurityGroup
 FromPort: 443
 ToPort: 443
 IpProtocol: tcp
 CidrIp: !If
 - HasVpcCIDR
 - !Ref VpcCIDR
 - "0.0.0.0/0"
 S3Endpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - s3:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
 DynamoDbEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - dynamodb:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.dynamodb"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
 CloudWatchEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - logs:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.logs"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 MonitoringEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - cloudwatch:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.monitoring"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 SsmEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - ssm:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 SsmMessagesEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - ssmmessages:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 VPCEndpointEC2ICSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group for EC2 Instance Connect
 VpcId: !Ref VpcId
 VPCEndpointEC2ICSecurityGroupEgress:
 Type: AWS::EC2::SecurityGroupEgress
 Properties:
 GroupId: !Ref VPCEndpointEC2ICSecurityGroup
 FromPort: 22
 ToPort: 22
 IpProtocol: tcp
 DestinationSecurityGroupId: !Ref VPCEndpointEC2ICSecurityGroup
 VPCEndpointEC2ICSecurityGroupEgress2:
 Type: AWS::EC2::SecurityGroupEgress
 Properties:
 GroupId: !Ref VPCEndpointEC2ICSecurityGroup
 FromPort: 22
 ToPort: 22
 IpProtocol: tcp
 CidrIp: !If
 - HasVpcCIDR
 - !Ref VpcCIDR
 - "0.0.0.0/0"
 EC2InstanceConnectEndpoint:
 Type: AWS::EC2::InstanceConnectEndpoint
 UpdateReplacePolicy: "Delete"
 Properties:
 SubnetId: !Select
 - 0
 - !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointEC2ICSecurityGroup.GroupId
 PreserveClientIp: false
```

VPC Endpoints on-demand with CloudFormation

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-11-02 </dd>

Cloud Development Kit for Kubernetes (**cdk8s**) is a software development framework for defining Kubernetes applications and reusable abstractions using familiar programming languages and rich object-oriented APIs. cdk8s generates pure Kubernetes YAML - you can use cdk8s to define applications for any Kubernetes cluster running anywhere.

Recently the cdk8s team has expanded the capabilities of the "cdk8s import" command, simplifying the process to incorporate Helm charts. Providing a Helm Chart URL to the "cdk8s import" command will auto-generate a custom type-safe construct for you that represents the Helm Chart in question.

Let's start by initializing a new cdk8s project in an empty directory:

```bash
mkdir cdk8simporthelm && cd cdk8simporthelm
```

```bash
cdk8s init typescript-app
```

You should see the following basic structure of a cdk8s application with the _constructs_ and _cdk8s_ libraries:

```typescript
import { Construct } from 'constructs';
import { App, Chart, ChartProps } from 'cdk8s';

export class MyChart extends Chart {
 constructor(scope: Construct, id: string, props: ChartProps = { }) {
 super(scope, id, props);

 // define resources here

 }
}

const app = new App();
new MyChart(app, 'cdk8simporthelm');
app.synth();
});
```

Now let's go ahead and import the Bitnami Redis chart:

```bash
cdk8s import helm:https://charts.bitnami.com/bitnami/redis@18.2.0
```

Moving back to our **main.ts** file we can now import the new Redis module that was generated in the previous step:

```typescript
import { Construct } from "constructs";
import { App, Chart, ChartProps } from "cdk8s";
import { Redis, RedisArchitecture } from "./imports/redis";

export class MyChart extends Chart {
 constructor(scope: Construct, id: string, props: ChartProps = {}) {
 super(scope, id, props);

 new Redis(this, "Redis", {
 values: {
 architecture: RedisArchitecture.REPLICATION, // <------- type safe property
 },
 });
 }
}

const app = new App();
new MyChart(app, "cdk8simporthelm");
app.synth();
```

After we're done adding anything else we need in addition to what's above, let's synthesize the k8s YAML manifest:

```bash
cdk8s synth
```

You should now have your manifest generated in the **dist** subfolder and you can run kubectl apply as you would with any other manifest.

![redisdeployment](/images/cdk8sredisdeploy.png "redisdeployment")

You can find the source code repo for this blog post here: https://github.com/smallfriesdigital/cdk8s-helm-import

To access more info about Values Schema, Additional Values, Globals and Dependencies visit https://cdk8s.io/docs/latest/cli/import/#helm-charts

Use the new cdk8s import function to generate code for existing Kubernetes Helm Charts

Generate a custom type-safe Helm Chart construct with cdk8s

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-04-17 </dd>

With the rising popularity of Function URLs, which are dedicated HTTP(S) endpoints for your Lambda function, we can avoid many of the complexities, costs and limitations associated with Amazon API Gateway. The downside is we also lose some of the nice features of an API Gateway that we get out of the box, one key feature being API routing based on method and path of an http event. This is where Middy, a Node.js middleware engine for AWS Lambda really comes in handy.

In particular, we can achieve nested http routing within our Lambdas by leveraging Middy's [http-router](https://middy.js.org/docs/routers/http-router) handler. Let's start by cloning the starter project repo:

```bash
git clone https://github.com/AndrzejKomarnicki/awscdk-nodejsfunction-middy
```

Next let's install the npm packages and run some AWS CDK CLI commands from the root working directory of our cloned repo.

```bash
npm install
cdk synth && cdk diff
```

By default AWS CDK CLI will check your environment variables for your AWS creds and region first, if not found it will default back to your AWS credentials and config files. You can of course also specify the AWS CLI profile of choice. For more info on how to setup environments for your Stack instance head over to https://docs.aws.amazon.com/cdk/v2/guide/environments.html.

Anyway, if everything checks out let's proceed to deploy the Stack as part of our CDK app:

```bash
cdk deploy
```

After deployment, you should see output similar to below:

![functionurl](/images/functionurl-blog2.png "functionurl")

Next let's dive into the Lambda function source code before we test the endpoints... 
Open up **index.ts** from _/services/node-lambda/_

```javascript
import middy from "@middy/core";
import jsonBodyParser from "@middy/http-json-body-parser";
import httpErrorHandler from "@middy/http-error-handler";
import httpSecurityHeaders from "@middy/http-security-headers";
import httpRouterHandler from "@middy/http-router";
import { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";
import { Logger, injectLambdaContext } from "@aws-lambda-powertools/logger";

const logger = new Logger({
 logLevel: "INFO",
 serviceName: "middy-example-api",
});

async function getHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(`Hello from ${event.rawPath}`),
 };
}

async function postHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(event.body),
 };
}

// routes served by httpRouterHandler middleware
// you can add more nested handlers for routes (method and path) as needed
const routes = [
 {
 method: "GET",
 path: "/user/{id}",
 handler: getHandler,
 },
 {
 method: "POST",
 path: "/user",
 handler: postHandler,
 },
];

export const handler = middy()
 .use(jsonBodyParser())
 .use(httpSecurityHeaders())
 .use(httpErrorHandler())
 .use(injectLambdaContext(logger)) // Change to (logger, { logEvent: true }) to log the incoming event
 .handler(httpRouterHandler(routes));
```

As you can tell we import **httpRouterHandler** from **@middy/http-router**, and we define two async node.js functions - _getHandler()_ and _postHandler()_, which are referenced by the routes object as part of its handler property depending on http path and method in the http event.

Of course you can re-organize these nested Lambda handlers to be exported as modules instead of having everything in one monolithic index.ts file, this only serves as a starting point for demonstration purposes.

Let's proceed to test our endpoints with the different paths and methods we defined. You can go back to the outputs generated by "CDK deploy" and test against both the _Function URL_ and _CloudFront URL_.

```json
GET method on /user/{userid}
```

![getmethod](/images/getmethod-blog2.png "getmethod")

```json
POST method on /user
```

![postmethod](/images/postmethod-blog2.png "postmethod")

Using AWS CDK with TypeScript to deploy and manage AWS Lambda functions that support nested HTTP routes served through function URL and CloudFront

Nested API routes with Node.js AWS Lambda Function URL, Middy HTTP router and AWS CDK

![service](/images/headshot.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-03-26 </dd>

HashiCorp announced the general availability of Terraform CDK back in August 2022, and since then we've seen the arrival of several enhancements and new pre-built providers-many available through the [Construct Hub](https://constructs.dev "Construct Hub"). The beauty of CDKTF is that you can generate the code bindings for virtually any existing Terraform provider by simply using the cdktf cli and you can use the existing Terraform registry to look up a provider's resource and argument reference.

The source code for this series can be found here: https://github.com/smallfriesdigital/cdktf-mongodbatlas-gcp.

Let's dive head first into initializng a new cdktf project within our working dir that uses the GCP provider:

```bash
cdktf init --template=typescript --local --providers="google@~>4.0"
```

Next let's add the pre-built MongoDB Atlas provider:

```bash
cdktf provider add mongodb/mongodbatlas
```

OK, so now let's update _MyStack_ in **main.ts** with the following CDKTF TypeScript code:

```javascript
import { Construct } from "constructs";
import { App, TerraformStack, TerraformVariable } from "cdktf";
import { MongodbatlasProvider } from "@cdktf/provider-mongodbatlas/lib/provider";
import { Project } from "@cdktf/provider-mongodbatlas/lib/project";
import { Cluster } from "@cdktf/provider-mongodbatlas/lib/cluster";

class MyStack extends TerraformStack {
 constructor(scope: Construct, id: string) {
 super(scope, id);

 // define secure environment variables (won't end up in cdk.tf.json)
 const publicKey = new TerraformVariable(this, "publicKey", {
 type: "string",
 description: "MongoDB Atlas Org Public Key",
 sensitive: true,
 });

 const privateKey = new TerraformVariable(this, "privateKey", {
 type: "string",
 description: "MongoDB Atlas Org Private Key",
 sensitive: true,
 });

 const orgId = new TerraformVariable(this, "orgId", {
 type: "string",
 description: "MongoDB Atlas Org ID",
 sensitive: true,
 });

 // satisfy all the Atlas requirements before instantiating new cluster
 new MongodbatlasProvider(this, "Atlas", {
 publicKey: publicKey.value, // secret set via environment variable TF_VAR_publicKey
 privateKey: privateKey.value, // secret set via environment variable TF_VAR_privateKey
 });

 const atlasProject = new Project(this, "newProject", {
 name: "CDKTFProject1",
 orgId: orgId.value, // set via environment variable TF_VAR_orgId
 });

 // create cluster resource
 new Cluster(this, "newCluster1", {
 projectId: atlasProject.id,
 name: "atlasClusterCDK",
 clusterType: "REPLICASET",
 cloudBackup: false,
 mongoDbMajorVersion: "5.0",
 providerName: "TENANT",
 backingProviderName: "GCP",
 providerInstanceSizeName: "M0",
 providerRegionName: "CENTRAL_US",

 replicationSpecs: [
 {
 numShards: 1,
 regionsConfig: [
 {
 electableNodes: 3,
 priority: 7,
 readOnlyNodes: 0,
 regionName: "CENTRAL_US",
 },
 ],
 },
 ],
 });
 }
}

const app = new App();
new MyStack(app, "cdktf-gcp-mongodbatlas");
app.synth();
```

In this case we're using the free tier **_M0 Sandbox_** cluster, which is only recommended for development or testing purposes and doesn't support backups. Also keep in mind we are referencing the **_Atlas Region_** associated with the respective **_Google Cloud Region_**, not the GCP region name directly.
 You can read more about that here: (https://www.mongodb.com/docs/atlas/reference/google-gcp/#std-label-google-gcp)

> **CDKTF Best Practices for handling secrets:** use the TerraformVariable construct, Terraform uses the values in TerraformVariable directly at execution time, so CDKTF does not write them to the synthesized cdktf.json file. To pass a Terraform variable through environment variables, name the environment variable **TF_VAR_NAME** - 'NAME' being a placeholder for your variable name.

##### Environment variables that need to be set in the execution environment:

- TF_VAR_publicKey
- TF_VAR_privateKey
- TF_VAR_orgId

You can now feel free to run **cdktf plan** and **cdktf deploy** in order to get the base setup going, or instead choose to do it at the end once we wrap up all the other resource additions.

Let's go back and update the existing Cluster resource by assigning it to a constant in **main.ts**, then adding the admin database user to that cluster.

```javascript
// create cluster resource
const atlasCluster = new Cluster(this, "newCluster1", {
 projectId: atlasProject.id,
 name: "atlasClusterCDK",
 clusterType: "REPLICASET",
 cloudBackup: false,
 mongoDbMajorVersion: "5.0",
 providerName: "TENANT",
 backingProviderName: "GCP",
 providerInstanceSizeName: "M0",
 providerRegionName: "CENTRAL_US",

 replicationSpecs: [
 {
 numShards: 1,
 regionsConfig: [
 {
 electableNodes: 3,
 priority: 7,
 readOnlyNodes: 0,
 regionName: "CENTRAL_US",
 },
 ],
 },
 ],
});

const adminPassword = new TerraformVariable(this, "adminPassword", {
 type: "string",
 description: "MongoDB Atlas Cluster DB Admin",
 sensitive: true,
});

// add admin user to cluster
new DatabaseUser(this, "adminUser", {
 username: "cdktf-adminuser",
 password: adminPassword.value, // secret set via environment variable TF_VAR_adminPassword
 projectId: atlasProject.id,
 authDatabaseName: "admin",
 roles: [
 {
 roleName: "readAnyDatabase",
 databaseName: "admin",
 },
 ],
 scopes: [
 {
 name: atlasCluster.name,
 type: "CLUSTER",
 },
 ],
});
```

##### Environment variables that need to be set in the execution environment:

- TF_VAR_adminPassword

Finally, let's add the remaining network access piece to our stack in **main.ts**:

```javascript
const userNetwork = new TerraformVariable(this, "userNetwork", {
 type: "string",
 description: "MongoDB Atlas Project IP access",
 sensitive: false,
});

new ProjectIpAccessList(this, "projectnetworkAccess", {
 projectId: atlasProject.id,
 cidrBlock: userNetwork.value, // secret set via environment variable TF_VAR_userNetwork
});
```

Last but not least, define the one remaining env variable with your network CIDR.

##### Environment variables that need to be set in the execution environment:

- TF_VAR_userNetwork

```bash
cdktf plan
cdktf deploy
```

And voila! We are now ready to start developing against our MongoDB Atlas cluster from our machine. Bon coding.

An example of how to leverage Cloud Development Kit for Terraform with TypeScript to deploy a MongoDB Atlas cluster on GCP

Latest posts

VPC Endpoints on-demand with CloudFormation

Generate a custom type-safe Helm Chart construct with cdk8s

Nested API routes with Node.js AWS Lambda Function URL, Middy HTTP router and AWS CDK

Deploy a MongoDB Atlas cluster on GCP with CDKTF using TypeScript