Custom GitHub Action workflows with projen


# CDK Websocket Server

In this demo, we see how to build a simple WebSocket server using Amazon Elastic Container Service with Fargate. This demo also includes an [Amazon CloudFront Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html), [Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/), and [Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html). This will allow the server to scale up as needed while using TLS to secure the communication.

![Overview](/images/blog/WebSocketOverview.png)

## ECS Fargate

## Docker Build

```Dockerfile
FROM --platform=linux/arm64 node:20
WORKDIR /usr/src/app
COPY . .
RUN yarn && yarn build
EXPOSE 8080
CMD [ "node", "dist/server.js" ]
```

The Docker build is a simple Typescript based server that runs on NodeJS. This Dockerfile will copy the contents of the source directory and use `tsc` to transpile the Typescript file into Javascript before running.

### Cluster and Auto Scaling Group

First we will create the cluster that our container will run in.

```typescript
this.cluster = new Cluster(this, 'Cluster', {
  vpc: props.vpc,
  clusterName: 'websocket-service',
});

const autoScalingGroup = new AutoScalingGroup(this, 'AutoScalingGroup', {
  vpc: props.vpc,
  instanceType: new InstanceType('m6i.large'),
  machineImage: EcsOptimizedImage.amazonLinux2(),
  desiredCapacity: 1,
});

autoScalingGroup.role.addManagedPolicy(
  ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
);

const capacityProvider = new AsgCapacityProvider(this, 'capacityProvider', {
  autoScalingGroup: autoScalingGroup,
});

this.cluster.addAsgCapacityProvider(capacityProvider);
```

This cluster is running in a newly created VPC and includes an Auto Scaling Group.

### Fargate Task Definition

Next, we will create a Fargate container that will run our WebSocket Server. This will consist of several configurations that need to work together.

```typescript
const webSocketTask = new FargateTaskDefinition(
  this,
  'WebSocketTaskDefinition',
  {
    memoryLimitMiB: 2048,
    cpu: 1024,
    runtimePlatform: {
      operatingSystemFamily: OperatingSystemFamily.LINUX,
      cpuArchitecture: CpuArchitecture.ARM64,
    },
    taskRole: websocketServiceRole,
  },
);
```

Here we are setting up the basics of our compute. This Task will use `ARM64` compute. All components must be configured to use the same type of compute.

### Fargate Container

Next we will set up our container.

```typescript
webSocketTask.addContainer('WebSocketContainer', {
  image: ContainerImage.fromAsset('src/resources/containerImage'),
  containerName: 'websocket-service',
  portMappings: [{ containerPort: 8080, hostPort: 8080 }],
  logging: LogDrivers.awsLogs({
    streamPrefix: 'websocket-service',
  }),
  healthCheck: {
    command: ['CMD-SHELL', 'curl -f http://localhost:8080/health'],
    interval: Duration.seconds(30),
    timeout: Duration.seconds(30),
  },
  environment: {},
});
```

There are several key components here.

#### Port Mappings

In this example, we are using port `8080` on the container and host. Later we will see how to map the public facing port to this port.

#### Health Check

This container is also configured to perform periodic health checks to verify the container is running correctly. In this example, we are running a `curl` on the server.

### Fargate Service

Finally, we will create the Service using the previously created Task.

```typescript
const websocketService = new FargateService(this, 'WebSocketService', {
  cluster: this.cluster,
  taskDefinition: webSocketTask,
  assignPublicIp: true,
  desiredCount: 1,
  vpcSubnets: { subnetType: SubnetType.PUBLIC },
  securityGroups: [webSocketServiceSecurityGroup],
  enableExecuteCommand: true,
});
```

With the Fargate created, we can tie this to an Application Load Balancer.

#### Security Group

To ensure that only the Application Load Balancer can make requests to the Fargate container, we will attach a Security Group to the Fargate Service and allow the Application Load Balancer Security Group access to it.

```typescript
const albSecurityGroup = new SecurityGroup(this, 'ALBSecurityGroup', {
  vpc: props.vpc,
  description: 'Security Group for ALB',
  allowAllOutbound: true,
});

webSocketServiceSecurityGroup.connections.allowFrom(
  new Connections({
    securityGroups: [albSecurityGroup],
  }),
  Port.tcp(8080),
  'allow traffic on port 8080 from the ALB security group',
);
```

## Application Load Balancer

```typescript
this.applicationLoadBalancer = new ApplicationLoadBalancer(
  this,
  'ApplicationLoadBalancer',
  {
    vpc: this.vpc,
    internetFacing: true,
  },
);
```

The Application Load Balancer is created and associated with the VPC.

### Target Group

```typescript
const webSocketTargetGroup = new ApplicationTargetGroup(
  this,
  'webSocketTargetGroup',
  {
    vpc: props.vpc,
    port: 8080,
    protocol: ApplicationProtocol.HTTP,
    targets: [websocketService],
    healthCheck: {
      path: '/',
      protocol: Protocol.HTTP,
      port: '8080',
    },
  },
);
```

First, we will create a Target Group. This is where traffic will be sent. Here we can see port `8080` as the port to send traffic to on the container. This corresponds to the port exposed on the Fargate container. This Target Group will forward requests to the Fargate Service. This Application Load Balancer also includes a health check. This health check is different from the previously created health check as the Application Load Balancer is initiating this check rather than the container itself.

### Listener

```typescript
const webSocketListener = props.applicationLoadBalancer.addListener(
  'webSocketListener',
  {
    port: 80,
    protocol: ApplicationProtocol.HTTP,
    open: true,
    defaultAction: ListenerAction.fixedResponse(403),
  },
);

webSocketListener.addAction('ForwardFromCloudFront', {
  conditions: [
    ListenerCondition.httpHeader(props.customHeader, [props.randomString]),
  ],
  action: ListenerAction.forward([webSocketTargetGroup]),
  priority: 1,
});
```

Next we will create a Listener. Here we can see the listener is listening on port `80`. This is where we made the conversion from port `80` to port `8080`. We are using Protocol `HTTP`. The server will upgrade this HTTP request to WebSocket when it is received.

### Actions

To [restrict access to the Application Load Balancer](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) we will be adding a unique header to the CloudFront Distribution and a corresponding condition on the Application Load Balancer.

We do that here by creating a default action that responds with a `403`. This means that the Application Load Balancer will reject any request unless it includes a specific Header and Value. In this case, the Application Load Balancer will forward the request to the `webSocketTargetGroup`. We will be adding this Header and Value on the Origin of the CloudFront Distribution in the next step.

Note that the Application Load Balancer is using `HTTP` and not `HTTPS`. We will be enforcing `HTTPS` at the Cloudfront Distribution layer. Be only allowing traffic to our Application Load Balancer from our CloudFront Distribution, we can enforce `HTTPS` be used from the Client. This allows us to create a secure connection without a owning a domain that can be used to generate the certificate.

## Cloudfront Distribution

Finally, we will create our CloudFront Distribution. This will be used to provide TLS to our Application Load Balancer.

```typescript
const defaultOrigin = new LoadBalancerV2Origin(props.applicationLoadBalancer, {
  httpPort: 80,
  protocolPolicy: OriginProtocolPolicy.HTTP_ONLY,
  originId: 'defaultOrigin',
});

this.distribution = new Distribution(this, 'Distribution', {
  defaultBehavior: {
    origin: defaultOrigin,
    viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY,
    cachePolicy: CachePolicy.CACHING_DISABLED,
    allowedMethods: AllowedMethods.ALLOW_ALL,
    originRequestPolicy: OriginRequestPolicy.ALL_VIEWER,
  },
  defaultRootObject: 'index.html',
  priceClass: PriceClass.PRICE_CLASS_100,
  logBucket: distributionLoggingBucket,
  enableLogging: true,
});
```

Here we are creating a CloudFront Distribution that only accepts HTTPS. This will create a certificate that is used by the Distribution. This Distribution will send that traffic to our Application Load Balancer on port `80`.

### Custom Header

In order to provide the security outlined above using Custom Headers and Values, we must add those Headers and Values to the Origination. Unfortunately, that feature does not existing natively in CDK. Therefore, we will use a Custom Resource to add the Headers and Values.

```typescript
new CustomResource(this, 'customHeaderCustomResource', {
  serviceToken: customHeaderCustomResourceProvider.serviceToken,
  properties: {
    DistributionId: this.distribution.distributionId,
    Origins: [
      {
        OriginId: 'defaultOrigin',
        CustomHeaders: [
          {
            HeaderName: props.customHeader,
            HeaderValue: props.randomString,
          },
        ],
      },
    ],
  },
});
```

Using the previously created Distribution, we will pass the information to our Custom Resource that will be added to the Distribution.

### Custom Resource

```typescript
const updatedOrigins = Distribution.DistributionConfig!.Origins!.Items!.map(
  (origin: any) => {
    const matchedOrigin = Origins.find((o: any) => o.OriginId === origin.Id);
    if (matchedOrigin) {
      return {
        ...origin,
        CustomHeaders: {
          Quantity: matchedOrigin.CustomHeaders.length,
          Items: matchedOrigin.CustomHeaders.map((header: any) => ({
            HeaderName: header.HeaderName,
            HeaderValue: header.HeaderValue,
          })),
        },
      };
    }
    return origin;
  },
);
```

Within the Custom Resource, we will `GetDistributionConfiguration` and match up the origin with the desired Header and Value. Using this updated configuration, we will `UpdateDistributionConfiguration`. Now, when a request is made to our CloudFront Distribution, it will add this Header and Value to the request to the Application Load Balancer. This, in turn, will forward the request to our Fargate Service.

## Results

We have now created an auto-scaling, load-balanced application that is secured with `HTTPS` using a CloudFront Distribution. This will allow you to build a secure WebSocket server that will automatically adapt to your traffic needs.

## Deployment

To deploy this demo, simply run:

```bash
yarn launch
```

## Removal

This demo does include services that can accumulate costs, so be sure to remove when not needed. To delete:

```
yarn cdk destroy
```

You may have to manually delete the Auto Scaling Group if it is not able to automatically delete.

## Repo

https://github.com/schuettc/cdk-websocket-server


This demo will show how to build and deploy a Fargate WebSocket server.  This application will automatically scale and use TLS to secure the connection.

Building and Deploying a WebSocket server with Fargate and CDK


![Overview](/images/blog/KDSReader.png)

In this demo, we see how to build a React based Websocket reader to get information from a Kinesis Data Stream to a client in real-time. This can be useful for viewing the contents of a Kinesis Data Stream.

## Components

### Websocket API

This demo uses an [Amazon API Gateway using WebSockets](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html). Three routes are configured in this API Gateway: $connect, $disconnect, and $default. Connect and Disconnect are used to control connections to the API Gateway. These requests are passed to the Lambda function and stored in the DynamoDB.

```typescript
this.webSocketApi = new WebSocketApi(this, 'webSocketApi', {});

this.webSocketApi.addRoute('$connect', {
  integration: new WebSocketLambdaIntegration(
    'ConnectIntegration',
    this.lambdaHandler,
  ),
});
this.webSocketApi.addRoute('$disconnect', {
  integration: new WebSocketLambdaIntegration(
    'DisconnectIntegration',
    this.lambdaHandler,
  ),
});
this.webSocketApi.addRoute('$default', {
  integration: new WebSocketLambdaIntegration(
    'DefaultIntegration',
    this.lambdaHandler,
  ),
});
```

### Lambda Handler

When the request is made to the Lambda function, the request is processed and information about the connection stored in the DynamoDB.

```typescript
export const handler: Handler = async (event) => {
  if (isAPIGatewayProxyEvent(event)) {
    // WebSocket connection and disconnection handling
    const connectionId = event.requestContext.connectionId;
    console.log('endpoint:  ' + process.env.API_GATEWAY_ENDPOINT);

    if (event.requestContext.eventType === 'CONNECT') {
      await ddbDocClient.send(
        new PutCommand({
          TableName: process.env.CONNECTION_TABLE,
          Item: { connectionId },
        }),
      );
      return { statusCode: 200 };
    } else if (event.requestContext.eventType === 'DISCONNECT') {
      await ddbDocClient.send(
        new DeleteCommand({
          TableName: process.env.CONNECTION_TABLE,
          Key: { connectionId },
        }),
      );
      return { statusCode: 200 };
    }
```

This information will be used when a Kinesis Data Stream record is used to [invoke the Lambda function](https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html).

```typescript
this.lambdaHandler = new NodejsFunction(this, 'lambdaHandler', {
  entry: 'src/resources/handler/index.ts',
  runtime: Runtime.NODEJS_18_X,
  architecture: Architecture.ARM_64,
  timeout: Duration.seconds(60),
  role: lambdaHandlerRole,
  environment: {
    STREAM_NAME: props.kinesisDataStream.streamName,
    CONNECTION_TABLE: props.connectionTable.tableName,
    API_GATEWAY_ENDPOINT: `https://${this.webSocketApi.apiId}.execute-api.${this.webSocketApi.stack.region}.amazonaws.com/${this.webSocketStage.stageName}`,
  },
});

new EventSourceMapping(this, 'eventSourceMapping', {
  target: this.lambdaHandler,
  eventSourceArn: props.kinesisDataStream.streamArn,
  startingPosition: StartingPosition.LATEST,
});
```

Here we see the Lambda function being created and `EventSourceMapping` used to trigger the Lambda when a record is added to the Kinesis Data Stream.

```typescript
  } else if (isKinesisStreamEvent(event)) {
    // Kinesis Data Stream processing
    for (const record of event.Records) {
      const kinesisData = Buffer.from(record.kinesis.data, 'base64').toString(
        'utf8',
      );
      console.log('Kinesis Record:', kinesisData);

      const connections = await ddbDocClient.send(
        new ScanCommand({ TableName: process.env.CONNECTION_TABLE }),
      );
      const postData = JSON.parse(kinesisData);

      if (connections.Items) {
        console.log('Connections: ' + JSON.stringify(connections.Items));
        for (const connection of connections.Items) {
          try {
            await apiGatewayManagementApi.send(
              new PostToConnectionCommand({
                ConnectionId: connection.connectionId,
                Data: new TextEncoder().encode(JSON.stringify(postData)),
              }),
            );
          } catch (error) {
            if (
              error instanceof Error &&
              'statusCode' in error &&
              error.statusCode === 410
            ) {
              // Remove stale connections
              await ddbDocClient.send(
                new DeleteCommand({
                  TableName: process.env.CONNECTION_TABLE,
                  Key: { connectionId: connection.connectionId },
                }),
              );
            }
          }
        }
      }
    }
  }
```

Now, when the Lambda is triggered by a KDS event, the Lambda will check if there are any active connections in the DynamoDB. If there are, the record will be written to the API Gateway.

### Client

In the client we will create a connection to the API Gateway so we can receive messages as they arrive.

```typescript
useEffect(() => {
  const ws = new WebSocket(WEB_SOCKET_URL + '/' + WEB_SOCKET_STAGE);

  ws.onopen = () => {
    console.log('Connected to WebSocket');
    setSocket(ws);
    setConnected(true);
  };

  ws.onmessage = (event) => {
    console.log('Received message:', event.data);
    const data: Message = JSON.parse(event.data);
    setMessages((prevMessages) => [...prevMessages, data]);
  };

  ws.onerror = (error: Event) => {
    console.error('WebSocket error:', error);
  };

  ws.onclose = () => {
    console.log('WebSocket connection closed');
    setSocket(null);
    setConnected(false);
  };

  return () => {
    if (ws) {
      ws.close();
    }
  };
}, []);
```

Once the client establishes a connection to the API Gateway, when a message is received, the data will be saved to State and displayed.

```typescript
return (
  <div className='header'>
    {connected ? (
      <div style={{ color: 'green' }}>WebSocket connected</div>
    ) : (
      <div style={{ color: 'red' }}>WebSocket disconnected</div>
    )}
    <button onClick={clearMessages}>Clear</button>
    <div className='messages'>
      <h2>Messages</h2>
      <ul className='message-list'>
        {messages.map((message, index) => (
          <li key={index} className='message'>
            <MessageItem message={message} />
          </li>
        ))}
      </ul>
      <AlwaysScrollToBottom />
    </div>
  </div>
);
```

## GitHub

This demo can be found here: https://github.com/schuettc/react-websocket-reader-for-kds

## Deploy

To deploy this demo:

```
yarn launch
```

## Cleanup

To destroy these components:

```
yarn cdk destroy
```


In this demo, we will be building a React based WebSocket reader that uses Amazon API Gateway to read data from a Kinesis Data Stream

Creating a React based WebSocket reader for KDS


# Multiple CPU Architecture CDK Deployment of an Asterisk to ECS Fargate

This demo contains a CDK deployment of an Asterisk server to Amazon ECS using Fargate. This will allow us to deploy an Asterisk server to a Docker container.

[https://github.com/schuettc/cdk-fargate-asterisk](https://github.com/schuettc/cdk-fargate-asterisk)

## Docker Image

For this demo, we will be using the [andrius/asterisk](https://github.com/andrius/asterisk) Docker image.

## Asterisk Configuration

To allow for customized configuration, we will copy files from the local directory to the Asterisk server in the `Dockerfile`.

```docker
COPY config/* /etc/asterisk
COPY docker-entrypoint.sh /
RUN chmod +x /docker-entrypoint.sh
```

In this example, we are copying in several files for our configuration including a `pjsip.conf` and `extensions.conf` files.

```asterisk
[udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=PUBLIC_IP
external_signaling_address=PUBLIC_IP
allow_reload=yes
```

In the [`pjsip.conf`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/config/pjsip.conf) file, we are simply loading a basic `udp` transport. We will configure this during deployment later.

## Multiple Build Platforms

In order to accommodate deployments from multiple platforms, we will ensure that the deployed version matches the built version.

In the [`Dockerfile`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/Dockerfile) we will use `${BUILDPLATFORM}` to make sure we're building using the local architecture. We need to do this because we are copying files to the image and then building it before deploying it.

```docker
FROM --platform=${BUILDPLATFORM} andrius/asterisk
```

In the [`ecs.ts`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/ecs.ts) file, we will determine the local architecture and use that.

```typescript
let deployArch: CpuArchitecture;
const cpuArch = os.arch();
if (cpuArch === 'arm64') {
  deployArch = CpuArchitecture.ARM64;
} else {
  deployArch = CpuArchitecture.X86_64;
}
```

Then, when we create the Task, we will use that `deployArch` as part of the build for the `cpuArchitecture`.

```typescript
this.task = new FargateTaskDefinition(this, 'TaskDefinition', {
  memoryLimitMiB: 2048,
  cpu: 1024,
  runtimePlatform: {
    operatingSystemFamily: OperatingSystemFamily.LINUX,
    cpuArchitecture: deployArch,
  },
  taskRole: asteriskTaskRole,
  volumes: [
    {
      name: 'asteriskLogs',
      efsVolumeConfiguration: {
        fileSystemId: fileSystem.fileSystemId,
        transitEncryption: 'ENABLED',
        authorizationConfig: {
          accessPointId: asteriskAccessPoint.accessPointId,
          iam: 'ENABLED',
        },
      },
    },
  ],
});
```

Now the deployed version will match the locally built version.

For example, when the Docker image is built on an M1 Mac, the Architecture type will be `ARM64`.

![ARM64](/images/blog/ARM64.png)

However, if the Docker image is built on an X86 based CPU, the Architecture type will be `X86_64`.

![X86_64](/images/blog/X86_64.png)

## Access the Asterisk Server

Once deployed, the Asterisk server can be accessed using [`ecs-execute`](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html)

Included in the output of the CDK will be several commands that can be copied to the terminal for ssh access.

To access the running Asterisk:

- Copy/paste the `CLUSTER=` command
- Copy/paste the `TASK=` command
- Copy/paste either `aws ecs execute-command` command

## Asterisk Configuration

During deployment of the Fargate container, the Dockerfile will use [`docker-entrypoint.sh`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/docker-entrypoint.sh) as it's `ENTRYPOINT`. Everything in that file will be executed. We can use this to configure the Asterisk during deployment.

```bash
echo "METADATA: " ${ECS_CONTAINER_METADATA_URI_V4}
curl -o metadata.json ${ECS_CONTAINER_METADATA_URI_V4}/task
cat metadata.json
TASK_ARN=$( curl ${ECS_CONTAINER_METADATA_URI_V4}/task | jq -r '.TaskARN' )
echo "TASK_ARN: " $TASK_ARN
CLUSTER=$( curl ${ECS_CONTAINER_METADATA_URI_V4}/task | jq -r '.Cluster' )
echo "CLUSTER: " $CLUSTER
ENI=$(aws ecs describe-tasks --tasks $TASK_ARN --cluster $CLUSTER | jq -r '.tasks[0].attachments[0].details[1].value' )
echo "ENI: " $ENI
PUBLIC_IP=$( aws ec2 describe-network-interfaces --network-interface-ids $ENI | jq -r '.NetworkInterfaces[0].Association.PublicIp' )
echo "PUBLIC_IP: ${PUBLIC_IP}"

sed -i "s/PUBLIC_IP/$PUBLIC_IP/g" /etc/asterisk/pjsip.conf
```

With this shell script, we will determine the `PUBLIC_IP` of the container that is running and use that to configure the `pjsip.conf` file. This can be expanded to configure other parts of the Asterisk server as needed.

## Deploy/Destroy

To deploy this demo:

```bash
yarn launch
```

To destroy this demo:

```bash
yarn cdk destroy
```


This CDK will deploy a an Asterisk server to AWS Fargate from multiple CPU architectures

Multiple CPU Architecture CDK Deployment of an Asterisk to ECS Fargate


# Deploying Cross-Region Certificates with AWS Cloudfront via CDK

[AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) (ACM) can be used to deploy TLS certificates for use with things like [Amazon Cloudfront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html). However, ACM certificates must be deployed in `us-east-1`. In order to deploy an ACM certificate and associate with a resource outside of `us-east-1`, a multiple stack deployment must be used. The repo here: [https://github.com/schuettc/cdk-cross-region-cloudfront](https://github.com/schuettc/cdk-cross-region-cloudfront) will show an example of this.

## Certificate Stack

The first stack to be deployed will be the `CertificateStack`. This stack will create a `Certificate` in the `us-east-1` region that can be used by a Cloudfront Distribution in another region.

```typescript
interface CertificateStackProps extends StackProps {
  siteSubdomain: string;
  domain: string;
  hostedZoneId: string;
}

export class CertificateStack extends Stack {
  siteCertificate: Certificate;
  constructor(scope: Construct, id: string, props: CertificateStackProps) {
    super(scope, id, props);

    const certificateResources = new CertificateResources(this, 'certificate', {
      siteSubdomain: props.siteSubdomain,
      domain: props.domain,
      hostedZoneId: props.hostedZoneId,
    });

    this.siteCertificate = certificateResources.siteCertificate;
  }
}

const app = new App();

const certEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: 'us-east-1',
};

const certProps = {
  siteSubdomain: process.env.SITE_SUBDOMAIN || '',
  domain: process.env.DOMAIN || '',
  hostedZoneId: process.env.HOSTED_ZONE_ID || '',
};

const certStack = new CertificateStack(app, 'CertificateStack', {
  ...certProps,
  env: certEnv,
  crossRegionReferences: true,
});

app.synth();
```

Here we are explicitly declaring `us-east-1` as the region to deploy this `Stack` to because ACM certificates used with CloudFront _must_ use `us-east-1`. We are passing in to the `Stack` props from a `.env` file that will be used to create the `Certificate`. This `Certificate` will be used as input to the next `Stack`. Note that the `Stack` must take the input `crossRegionReferences: true` to let the next `Stack` use this `Certificate`.

## Site Stack

```typescript
interface SiteStackProps extends StackProps {
  siteCertificate: Certificate;
  siteSubdomain: string;
  domain: string;
  hostedZoneId: string;
}

export class SiteStack extends Stack {
  constructor(scope: Construct, id: string, props: SiteStackProps) {
    super(scope, id, props);

    const site = new SiteResources(this, 'site', {
      siteCertificate: props.siteCertificate,
      siteSubdomain: props.siteSubdomain,
      domain: props.domain,
      hostedZoneId: props.hostedZoneId,
    });

    new CfnOutput(this, 'distributionURL', {
      value: site.distribution.domainName,
    });

    new CfnOutput(this, 'siteUrl', {
      value: `https://${props.siteSubdomain}.${props.domain}`,
    });
  }
}

const app = new App();

const siteEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: 'eu-central-1',
};

const siteProps = {
  siteCertificate: certStack.siteCertificate,
  siteSubdomain: process.env.SITE_SUBDOMAIN || '',
  domain: process.env.DOMAIN || '',
  hostedZoneId: process.env.HOSTED_ZONE_ID || '',
};

new SiteStack(app, 'SiteStack', {
  ...siteProps,
  env: siteEnv,
  crossRegionReferences: true,
});

app.synth();
```

Here we are creating a second `Stack` as part of this deployment. This `Stack` will deploy the actual website using the `Certificate` from the previous `Stack`. The props used for this `Stack` are the same as the previous `Stack` with the addition of the `Certificate` created in the first `Stack`. This `Stack` uses a typical Single-Page Application (SPA) deployment of S3 + CloudFront with a specific `Certificate` and `ARecord` assigned.

```typescript
this.siteBucket = new Bucket(this, 'websiteBucket', {
  publicReadAccess: false,
  removalPolicy: RemovalPolicy.DESTROY,
  autoDeleteObjects: true,
});

const hostedZone = HostedZone.fromHostedZoneAttributes(this, 'hostedZone', {
  zoneName: props.domain,
  hostedZoneId: props.hostedZoneId,
});

this.distribution = new Distribution(this, 'CloudfrontDistribution', {
  enableLogging: true,
  domainNames: [props.siteSubdomain + '.' + props.domain],
  certificate: props.siteCertificate,
  minimumProtocolVersion: SecurityPolicyProtocol.TLS_V1_2_2021,
  defaultBehavior: {
    origin: new S3Origin(this.siteBucket),
    viewerProtocolPolicy: ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    cachePolicy: CachePolicy.CACHING_DISABLED,
  },
  defaultRootObject: 'index.html',
});

new ARecord(this, 'clientSiteARecord', {
  zone: hostedZone,
  target: RecordTarget.fromAlias(new CloudFrontTarget(this.distribution)),
  recordName: props.siteSubdomain + '.' + props.domain,
});
```

The result will be an SPA deployed to S3 with a CloudFront Distribution that uses a specific URL from Route53 and a Certificate provided by ACM. This site can be deployed in any Region while the Certificate will be deployed in `us-east-1` as required by CloudFront.

![Distribution](/images/blog/Distribution.png)

## .env File

To deploy this demo, a `.env` file must be used. This `.env` file will contain the following:

```bash
SITE_SUBDOMAIN = 'cross-region-site'
DOMAIN = 'example.com'
HOSTED_ZONE_ID = 'Z00000000000000000000'
```

## Result

![Result](/images/blog/Cross-Region-Deploy-Result.png)

The result is an [SPA deployed](https://cross-region-site.subaud.io/) to a non `us-east-1` Region while still using an ACM Certificate used by CloudFront all deployed by CDK. Information on [cross-region certificates](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_certificatemanager-readme.html#cross-region-certificates) is available on the AWS CDK Reference Documentation.

## Resources

- Github Repo: [https://github.com/schuettc/cdk-cross-region-cloudfront](https://github.com/schuettc/cdk-cross-region-cloudfront)


In order to deploy a Certificate with a CloudFront Distribution, a multi-stack CDK must be used to deploy the Certificate in us-east-1 and the SPA in a different Region.  This CDK deployment will show how to do that.

Deploy a Cross-Region SPA with Cloudfront using CDK


# Minecraft CDK Deployment using AWS Fargate

This [repo](https://github.com/schuettc/cdk-minecraft) will deploy an AWS Fargate based Minecraft server that uses Route 53 to update the service and activate the Minecraft server.

Much of the work here is based on the work by [doctorrat117](https://github.com/doctorray117) from [minecraft-ondemand](https://github.com/doctorray117/minecraft-ondemand).

## Overview

![Overview](/images/blog/Minecraft.png)

## .env File

The .env file used by this deployment includes several variables that will be referenced later. A sample .env file is included: [.env.sample](/.env.sample) and should be updated and renamed to `.env`.

```
MINECRAFT_EDITION = 'java'
SERVER_SUBDOMAIN = 'minecraft'
DOMAIN = 'example.com'
HOSTED_ZONE_ID = 'Z00000000000000000000'
MEMORY_SIZE = '8192'
CPU_SIZE = '4096'
SNS_EMAIL = 'admin@example.com'
STARTUP_MIN = '10'
SHUTDOWN_MIN = '20'
DEBUG = 'true'
```

A Route 53 domain and Hosted Zone ID is required for this deployment. These will be used to start the service.

### AWS Fargate Service

This deployment uses an AWS Fargate service to deploy two containers - the Minecraft server and a watchdog server. The Minecraft server is the reason for deploying this and will be used to play the game. The watchdog container is used to ensure that the Minecraft server is still being used.

#### Starting the Service

To start the service and allow someone to use the Minecraft server, a query to `SERVER_SUBDOMAIN`.`DOMAIN` will result in Route 53 updating Cloudwatch logs. This Cloudwatch log will trigger an AWS Lambda Function to set the `desired-count` of the Fargate service to 1.

```python
    if desired == 0:
        ecs.update_service(
            cluster=CLUSTER,
            service=SERVICE,
            desiredCount=1,
        )
        print("Updated desiredCount to 1")
    else:
        print("desiredCount already at 1")
```

By setting the `desired-count` to 1, the containers in the ECS service will be activated and available. The AWS ECS Service includes the Minecraft server container and a watchdog container. Both of these will be started when the `desired-count` is set to 1.

```typescript
this.service = new FargateService(this, 'FargateService', {
  serviceName: 'MineCraftService',
  cluster: this.cluster,
  capacityProviderStrategies: [
    {
      capacityProvider: 'FARGATE',
      weight: 1,
      base: 1,
    },
  ],
  taskDefinition: this.task,
  assignPublicIp: true,
  desiredCount: 0,
  vpcSubnets: { subnetType: SubnetType.PUBLIC },
  securityGroups: [props.securityGroup],
  enableExecuteCommand: true,
});

const minecraftServerContainer = this.task.addContainer(
  'MinecraftServerContainer',
  {
    image: ContainerImage.fromRegistry(props.serverConfig.image),
    environment: {
      EULA: 'TRUE',
      MEMORY: '8G',
    },
    portMappings: [
      {
        containerPort: props.serverConfig.port,
        hostPort: props.serverConfig.port,
        protocol: props.serverConfig.protocol,
      },
    ],
    essential: false,
    logging: props.serverConfig.debug
      ? new AwsLogDriver({
          logRetention: RetentionDays.THREE_DAYS,
          streamPrefix: 'minecraft',
        })
      : undefined,
  },
);

this.task.addContainer('WatchdogContainer', {
  image: ContainerImage.fromAsset(
    path.resolve(__dirname, './resources/watchdogContainer'),
  ),
  essential: true,
  environment: {
    CLUSTER: this.cluster.clusterName,
    SERVICE: 'MineCraftService',
    DNSZONE: props.subDomainHostedZoneId,
    SERVERNAME: `${props.serverSubDomain}.${props.domain}`,
    SNSTOPIC: props.snsTopic?.topicArn || '',
    STARTUPMIN: props.startupMin,
    SHUTDOWNMIN: props.shutdownMin,
  },
  logging: props.serverConfig.debug
    ? new AwsLogDriver({
        logRetention: RetentionDays.THREE_DAYS,
        streamPrefix: 'minecraft',
      })
    : undefined,
});
```

#### Stopping the Service

During normal operations, both the Minecraft container and Watchdog container will be active. The Minecraft server is used to play the game while the Watchdog server will monitor the activity of the Minecraft server. When the watchdog server determines that the Minecraft server has not been used for `SHUTDOWN_MIN`, the watchdog server will set the `desired-count` of the Fargate Service to 0. By setting the `desired-count` to 0, the containers will be stopped to reduce costs.

### Notification

When the AWS Fargate service starts or stops, a notification is sent to SNS.

```bash
function send_notification ()
{
  [ "$1" = "startup" ] && MESSAGETEXT="${SERVICE} is online at ${SERVERNAME}"
  [ "$1" = "shutdown" ] && MESSAGETEXT="Shutting down ${SERVICE} at ${SERVERNAME}"

  ## SNS Option
  [ -n "$SNSTOPIC" ] && \
  echo "SNS topic set, sending $1 message" && \
  aws sns publish --topic-arn "$SNSTOPIC" --message "$MESSAGETEXT"
}
```


This demo will use CDK to deploy a Minecraft server on AWS Fargate using Route 53 as the trigger

Deploy a Minecraft server with AWS Fargate and AWS CDK


In this demo, we will show how to conditionally deploy resources using environment variables.

## Passing Environment Variables

This CDK uses a Stack with several inputs. Besides the standard `env` input, we are also defining `StackProps` that will be used to pass the `bucketName` from the environment to the Stack.

```typescript
const devEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: process.env.CDK_DEFAULT_REGION,
};

const stackProps = {
  bucketName: process.env.BUCKET_NAME || '',
};

new ConditionalDeployment(app, 'ConditionalDeployment', {
  ...stackProps,
  env: devEnv,
});
```

Here we see the standard `projen` created `devEnv` and the App that is being deployed. We are additionally adding `stackProps` to the Stack that is being created and passing the environment variable `BUCKET_NAME` to it if it is present.

## Stack and StackProps

```typescript
interface ConditionalDeploymentProps extends StackProps {
  bucketName?: string;
}

let deploymentBucket: IBucket;

export class ConditionalDeployment extends Stack {
  constructor(scope: Construct, id: string, props: ConditionalDeploymentProps) {
    super(scope, id, props);
```

Here we have defined `ConditionalDeploymentProps` as a `StackProps` to be passed to the Stack as well as `deploymentBucket`. This will be used later with either a new bucket or the existing bucket.

## Condition

```typescript
if (props.bucketName) {
  deploymentBucket = Bucket.fromBucketName(this, 'Bucket', props.bucketName);
} else {
  deploymentBucket = new Bucket(this, 'Bucket', {
    encryption: BucketEncryption.S3_MANAGED,
    blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
    removalPolicy: RemovalPolicy.DESTROY,
    autoDeleteObjects: true,
  });
}
```

This is where we will check to see if a string has been passed as a prop named `bucketName` to the Stack. It is not required to be passed, but if it is, we want to use that bucket as the deployment destination. To do that, we need to get the [`IBucket`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.IBucket.html) using [`Bucket.fromBucketName`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.Bucket.html#static-fromwbrbucketwbrnamescope-id-bucketname).

If no prop named `bucketName` was passed to the Stack, we will create a bucket. In either case, the bucket that we will be deploying to is referenced by `deploymentBucket`.

## Deploying to the Bucket

```typescript
const data = {
  bucketName: deploymentBucket.bucketName,
  text: 'Hello World',
};

new BucketDeployment(this, 'Deployment', {
  sources: [Source.jsonData('config.json', data)],
  destinationBucket: deploymentBucket,
});
```

Now, we will create a simple JSON file using `Source.jsonData` and upload this file to the bucket. This will either be an existing bucket referenced in the environment variables, or a newly created bucket. In either case, we can use `deplyomentBucket` as the `destinationBucket` because we are always creating an `IBucket`. If the bucket already exists, we use `fromBucketName` and if the bucket does not exist, `new Bucket` will return an `IBucket`.

## Deploying with Environment Variables

> Note: You must replace `conditional-cdk-deploy-demo` with a unique name

```bash
export BUCKET_NAME=conditional-cdk-deploy-demo
yarn launch
```

or

```bash
BUCKET_NAME=conditional-cdk-deploy-demo yarn launch
```

Once completed, we can see that an existing S3 bucket has the `config.json` file in it.

```bash
aws s3 ls s3://conditional-cdk-deploy-demo
aws s3 cp s3://conditional-cdk-deploy-demo/config.json ./
cat config.json
```

## Deploying without Environment Variables

```
unset BUCKET_NAME
yarn launch
```

When the CDK is deployed, a new bucket will be created. This bucket name will be in the output of the CDK and can be used to verify the creation of the bucket and the deployment of the `config.json` file.

## Testing the CDK

In order to verify that our CDK is correct, we should test it. This is done as part of a projen build. In this demo, we are using Snapshots to test.

```typescript
test('Snapshot', () => {
  const app = new App();
  const stack = new ConditionalDeployment(app, 'test', {});

  const template = Template.fromStack(stack);
  expect(template.toJSON()).toMatchSnapshot();
});

test('SnapshotWithBucketName', () => {
  const app = new App();
  const stack = new ConditionalDeployment(app, 'test', {
    bucketName: 'test-bucket',
  });

  const template = Template.fromStack(stack);
  expect(template.toJSON()).toMatchSnapshot();
});
```

This will now create snapshots for both scenarios. Without the second snapshot, we would have uncovered lines in the test.


This demo will describe how to create a CDK with conditional resource deployment and how to use Environment Variables with that conditional deployment

Conditional Resource Deployment and Environment Variables with CDK


Building off of the previous example of [building CDK Custom Resources Constructs](https://subaud.io/blog/building-cdk-custom-resource-constructs-with-projen-and-typescript), in this post, we will look at the steps required to convert this from a JavaScript Lambda to a Typescript Lambda using some of the [magic of projen](https://projen.io/awscdk.html#aws-lambda-functions).

## CDK Construct Code

<pre>
.
├── .eslintrc.json
├── .gitattributes
├── .gitignore
├── .jsii
├── .mergify.yml
├── .npmignore
<mark>├── .projenrc.js</mark>
├── API.md
├── LICENSE
├── README.md
├── package.json
├── src
│   ├── custom-resource-function.ts
<mark>│   ├── custom-resource.lambda.ts
│   └── index.ts</mark>
├── test
│   └── customResource.test.ts
├── tsconfig.dev.json
├── tsconfig.json
└── yarn.lock
</pre>

### Lambda Function

In this example, we will be using projen AWS Lambda Functions to automatically create the Lambda function that will be used by the Custom Resource. In order to create this function, we will create `custom-resource.lambda.ts` in the `src` directory. This will include the Lambda code to be executed during the CDK deployment.

After creating this file, running `npx projen` will create the `custom-resource-function.ts` file in the `src` directory. This is what we will be using in the `index.ts` file as the Lambda function for the Custom Resource.

After importing the function:

```typescript
import { CustomResourceFunction } from './custom-resource-function';
```

We can reference it here:

```typescript
const customResourceLambda = new CustomResourceFunction(
  this,
  'customResourceLambda',
  {
    role: customResourceRole,
    architecture: Architecture.ARM_64,
    timeout: Duration.seconds(60),
  },
);
```

To define the runtime of the Lambda function, in the `.projenrc` file:

```js
  lambdaOptions: {
    runtime: awscdk.LambdaRuntime.NODEJS_18_X,
    bundlingOptions: {
      externals: ['aws-sdk'],
      sourcemap: true,
    },
  },
```

Be sure to check out projen documentation for details on how to use this. [https://projen.io/awscdk.html#aws-lambda-functions](https://projen.io/awscdk.html#aws-lambda-functions)

> **_NOTE:_** NODEJS_18_X is not currently available and this will default to NODEJS_14_X for now.

### Provider

Next, we will include a [`Provider`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.Provider.html) The [Provider Framework](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html#provider-framework) will simplify some of the responses in the Lambda function. This is the recommended approach when using Custom Resources in CDKs.

```typescript
const customResourceProvider = new Provider(this, 'customResourceProvider', {
  onEventHandler: customResourceLambda,
});
```

### Custom Resource

Finally, we will call this Custom Resource

```typescript
const customResourceResult = new CustomResource(this, 'customResourceResult', {
  serviceToken: customResourceProvider.serviceToken,
  properties: {
    customResourceNumber: props.customResourceNumber,
  },
});
```

## Custom Resource Lambda Code

The Typescript Lambda will use the type definitions from [`DefinitelyTyped`](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/aws-lambda) to make things easier in the Lambda code.

```typescript
import {
  CdkCustomResourceEvent,
  CdkCustomResourceResponse,
  Context,
} from 'aws-lambda';

export const handler = async (
  event: CdkCustomResourceEvent,
  context: Context,
): Promise<CdkCustomResourceResponse> => {
  console.log('Lambda is invoked with:' + JSON.stringify(event));

  const response: CdkCustomResourceResponse = {
    StackId: event.StackId,
    RequestId: event.RequestId,
    LogicalResourceId: event.LogicalResourceId,
    PhysicalResourceId: context.logGroupName,
  };

  if (event.RequestType == 'Delete') {
    response.Status = 'SUCCESS';
    response.Data = { Result: 'None' };
    return response;
  }

  try {
    const multiplyResult = event.ResourceProperties.customResourceNumber * 2;
    response.Status = 'SUCCESS';
    response.Data = { Result: multiplyResult };
    return response;
  } catch (error) {
    if (error instanceof Error) {
      response.Reason = error.message;
    }
    response.Status = 'FAILED';
    response.Data = { Result: error };
    return response;
  }
};
```

Because we used the `Provider` when creating this Custom Resource, the response is significantly easier. We just need to [return](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html#handling-lifecycle-events-onevent) a `SUCCESS` or `FAILED` to the `onEvent`. We can do this with the `CdkCustomResourceResponse`.

## Using the Construct

No actual changes are needed in the [demo](https://github.com/schuettc/cdk-custom-resource-construct-demo).

### CDK Stack Code

```typescript
import { CfnOutput, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { CustomResourceExample } from 'cdk-custom-resource-construct-example';

export class CdkCustomResourceConstructDemoStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const result = new CustomResourceExample(this, 'customResourceResult', {
      customResourceNumber: 5,
    });

    new CfnOutput(this, 'customResourceOutput', {
      value: result.customResourceResult,
    });
  }
}
```

### Deploy

```bash
git clone https://github.com/schuettc/cdk-custom-resource-construct-demo
cd cdk-custom-resource-construct-demo
yarn
yarn run build
yarn cdk deploy
```

### Result

```
CdkCustomResourceConstructDemoStack: deploying...
 ✅  CdkCustomResourceConstructDemoStack

✨  Deployment time: 81.79s

Outputs:
CdkCustomResourceConstructDemoStack.customResourceOutput = 10
Stack ARN:
arn:aws:cloudformation:us-east-1:112233445566:stack/CdkCustomResourceConstructDemoStack/e47e0d90-742d-11ed-ab03-128d8230a997

✨  Total time: 84.66s
```

## Resources

- [GitHub Repository for Construct](https://github.com/schuettc/cdk-custom-resource-construct-example)
- [GitHub Repository for Demo](https://github.com/schuettc/cdk-custom-resource-construct-demo)
- [NPM Package](https://www.npmjs.com/package/cdk-custom-resource-construct-example)
- [constructs.dev construct](https://constructs.dev/packages/cdk-custom-resource-construct-example)


An update to the previous CDK Construct Custom Resource post.  This time we will be using Typescript instead of JavaScript for the Lambda function.

Using a Typescript Lambda as a CDK Construct Custom Resource


In order to deploy a Python Lambda function with additional dependencies, we must use something that will [install those dependencies](https://packaging.python.org/en/latest/tutorials/managing-dependencies/). With NodeJS, we can use something like [`esbuild`](https://esbuild.github.io/) to do this. In a Typescript CDK, we can use npm or yarn to install this as a [development dependency](https://classic.yarnpkg.com/en/docs/dependency-types#toc-devdependencies). However, we do not have this option with a Python Lambda. To have this built during deployment, we can use the [bundlingOptions interface](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.BundlingOptions.html).

```typescript
this.queryLambda = new Function(this, 'QueryLambda', {
  code: Code.fromAsset(path.join(__dirname, 'resources/query_lambda'), {
    bundling: {
      image: Runtime.PYTHON_3_9.bundlingImage,
      command: [
        'bash',
        '-c',
        'pip install -r requirements.txt -t /asset-output && cp -au . /asset-output',
      ],
    },
  }),
  runtime: Runtime.PYTHON_3_9,
  vpc: props.vpc,
  vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
  architecture: Architecture.ARM_64,
  handler: 'index.handler',
  timeout: Duration.minutes(5),
  role: props.role,
  layers: [props.powerToolsLayer],
  environment: {
    RDS_SECRET_NAME: props.dataBase.secret?.secretName!,
  },
});
```

In [this](https://github.com/schuettc/cdk-private-rds-with-lambda/blob/main/src/lambda.ts) example from the [cdk-private-rds-with-lambda](https://github.com/schuettc/cdk-private-rds-with-lambda) repository, we can see the `QueryLambda` function is being created using `Code` from the `/resources/query_lambda` directory and bundled using a Docker image. This does require Docker desktop to be run locally or from the pipeline that is deploying this function.

When this Lambda function is deployed, `pip install` will be used with the `requirements.txt` file in the `/query_lambda` directory to create the zip file that will be uploaded as the Lambda function.

```
resources/
├── initialize_lambda/
│   ├── index.py
│   └── requirements.txt
└── query_lambda/
    ├── index.py
    └── requirements.txt
```


This article will show you how to deploy a Python Lambda function with additional dependencies using CDK

Deploying a Python Lambda with Requirements using CDK


In this blog, we will walk through building an [Amazon RDS](https://aws.amazon.com/rds/) database using CDK. This database will be built in an isolated subnet. An AWS Lambda function will be built to initialize this database during the deployment of the CDK. Another AWS Lambda function will be built to write data to this database once a day. An EC2 instance will be built to connect to this database.

## GitHub Repo

Full code is available here: https://github.com/schuettc/cdk-private-rds-with-lambda

## VPC - Virtual Private Cloud

The first Construct built in this CDK is the Amazon Virtual Private Cloud (VPC). This will lay the foundation for future networking and placement of infrastructure.

```typescript
this.vpc = new Vpc(this, 'VPC', {
  natGateways: 1,
  subnetConfiguration: [
    {
      cidrMask: 24,
      name: 'Private',
      subnetType: SubnetType.PRIVATE_ISOLATED,
    },
    {
      cidrMask: 24,
      name: 'PrivateWithEgress',
      subnetType: SubnetType.PRIVATE_WITH_EGRESS,
    },
    {
      cidrMask: 24,
      name: 'Public',
      subnetType: SubnetType.PUBLIC,
    },
  ],
});
```

We will be building a VPC with three SubnetTypes. This Construct will build a complete VPC infrastructure, including:

- Multi-AZ Subnets
- Route Tables
- Security Groups
- Internet Gateway
- NAT Gateway

We will be using this infrastructure for our EC2 instance, RDS database, and Lambda functions.

## PostgreSQL RDS Database

Once the VPC is created, we will be creating an RDS Database within it. In this example, we will be creating a PostgreSQL database.

```typescript
this.database = new DatabaseInstance(this, 'database', {
  engine: DatabaseInstanceEngine.POSTGRES,
  vpc: props.vpc,
  vpcSubnets: { subnetType: SubnetType.PRIVATE_ISOLATED },
  instanceType: InstanceType.of(
    InstanceClass.BURSTABLE4_GRAVITON,
    InstanceSize.LARGE,
  ),
  multiAz: false,
  allowMajorVersionUpgrade: true,
  autoMinorVersionUpgrade: true,
  backupRetention: Duration.days(21),
  securityGroups: [props.securityGroup],
});
```

Because we use `vpcSubnets: { subnetType: SubnetType.PRIVATE_ISOLATED }` this RDS instance will be created in a [subnet](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.SubnetType.html#private_isolated) that does not route traffic to the Internet. To connect to this RDS database, we will have to create resources within the VPC that can connect to it.

## Database Initializer Custom Resource

Once the PostgreSQL database has been created, we need to initialize it. This will be done using a Custom Resource during the deployment of the CDK. This Custom Resource will be an AWS Lambda function that creates a table. This AWS Lambda Function must be created in the same VPC as the RDS database.

```typescript
const initializeLambda = new Function(this, 'InitializeTableLambda', {
  code: Code.fromAsset(path.join(__dirname, 'resources/initialize_lambda'), {
    bundling: {
      image: Runtime.PYTHON_3_9.bundlingImage,
      command: [
        'bash',
        '-c',
        'pip install -r requirements.txt -t /asset-output && cp -au . /asset-output',
      ],
    },
  }),
  runtime: Runtime.PYTHON_3_9,
  vpc: props.vpc,
  vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
  architecture: Architecture.ARM_64,
  layers: [props.powerToolsLayer],
  role: props.role,
  handler: 'index.handler',
  timeout: Duration.minutes(5),
  environment: {
    RDS_SECRET_NAME: props.dataBase.secret?.secretName!,
  },
});
```

This AWS Lambda Function will be used by the Custom Resource to initialize the PostgreSQL database during the creation of the CDK.

### Database Initializer Function

```python
def create_table():
    create_table = """CREATE TABLE queries(
            id SERIAL PRIMARY KEY,
            query_date DATE
            )
            """
    try:
        cursor.execute(create_table)
        cursor.close()
        connection.commit()
    except (Exception, psycopg2.DatabaseError) as error:
        print(error)
    finally:
        if connection is not None:
            connection.close()
```

When this AWS Lambda Function is called during the deployment of the CDK, we will create a table with two columns: `id` and `query_date`. These columns will be used by the recurring Query function to populate the RDS database.

## EC2 Instance

In order to interact with the PostgreSQL database, we will be creating an EC2 instance that is able to connect to the database.

```typescript
const ec2Instance = new Instance(this, 'Instance', {
  vpc: props.vpc,
  vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
  instanceType: InstanceType.of(InstanceClass.C6G, InstanceSize.MEDIUM),
  machineImage: ami,
  init: CloudFormationInit.fromConfigSets({
    configSets: {
      default: ['install'],
    },
    configs: {
      install: new InitConfig([
        InitCommand.shellCommand('yum update -y'),
        InitCommand.shellCommand('yum upgrade -y'),
        InitCommand.shellCommand('amazon-linux-extras install postgresql15'),
      ]),
    },
  }),
  initOptions: {
    timeout: Duration.minutes(20),
    includeUrl: true,
    includeRole: true,
    printLog: true,
  },
  role: ec2Role,
});
```

This instance will be created in the same `PRIVATE_WITH_EGRESS` SubnetType that the AWS Lambda Functions are created in. This will allow us to install the [`psql` client](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html#USER_ConnectToPostgreSQLInstance.psql) and connect to the database. This instance can be used only as needed and stopped when not needed to reduce EC2 costs.

From the EC2 Console, you can Connect to the instance.

![EC2Instance](/images/blog/RDS-EC2Instance.png)

### Secret Manager

In order to connect to the PostgreSQL database, you will need the `hostname`, `username`, and `password`. These have been automatically generated for you and stored in [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/).

![SecretManger](/images/blog/RDS-SecretManager.png)

Once connected to the the EC2 Instance, using [AWS Session Manger](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) you can connect to the RDS database using `psql`.

```bash
psql -h host -p 5432 -U postgres postgres
```

In this example, replace `host` with the value from the Secrets.

![Secrets](/images/blog/RDS-Secrets.png)

At the prompt, enter the `password` from the Secrets.

### PostgreSQL Verification

From the prompt, verify that the table has been created:

```sql
\dt+
```

Output:

```
                      List of relations
 Schema |  Name   | Type  |  Owner   |  Size   | Description
--------+---------+-------+----------+---------+-------------
 public | queries | table | postgres | 0 bytes |
```

However, nothing has been created in the table yet:

```sql
SELECT * FROM queries;
```

Output:

```
 id | query_date
----+------------
(0 rows)
```

### Writing Data

To write data to the PostgreSQL database, you can wait for the EventBridge scheduled rule to trigger the AWS Lambda Function, or you can test the function manually. Once run, the AWS Lambda function should write a single record to the file that can be seen by using:

```SQL
SELECT * FROM queries;
```

With expected output similar to:

```
 id | query_date
----+------------
  1 | 2022-11-07
(1 row)
```

## Conclusion

Instructions for deploying this demo are available at the GitHub repo. Once deployed, you should now have an Amazon RDS database deployed to an isolated subnet that is able to be used by both an EC2 Instance and AWS Lambda function. This will allow you to update and interact with the PostgreSQL database while ensuring that it is in an isolated subnet. In future posts, we will explore how this database can be used with Amazon Quicksight to create customized reports and dashboards.


How to build a private RDS database and connect to it with an AWS Lambda function using AWS CDK.  

Using CDK to build an RDS database with AWS Lambda integration


Because GitHub will only provide stats for the previous 14 days, if we want to maintain long-term stats, we need to pull stats and store them. [PyGitHub](https://pypi.org/project/PyGithub/) is a useful Python library for doing that using the [GitHub API v3](https://docs.github.com/en/rest). This Python script will pull stats from queried repositories and store them in a CSV.

```python
import os
import csv
from github import Github

GITHUB_KEY = os.environ.get("POETRY_GITHUB_KEY")
g = Github(GITHUB_KEY)

with open("repos.csv", "w", newline="", encoding="utf-8") as csvfile:
    repo_writer = csv.writer(csvfile, delimiter=",")
    repo_writer.writerow([
      "Repo Name",
      "Repo Link",
      "Repo Pushed At",
      "Forks", "StarGazers",
      "Open Issues",
      "Security Alerts",
      "Open Pull Requests"])
    for repo in g.search_repositories(query="user:schuettc cdk"):
        repo_writer.writerow(
            [
                repo.name,
                repo.html_url,
                repo.pushed_at,
                repo.forks_count,
                repo.stargazers_count,
                repo.open_issues_count,
                repo.get_vulnerability_alert(),
                repo.get_pulls().totalCount,
            ]
        )
```

This script will query [GitHub](https://github.com) for [`user:schuettc cdk`](https://github.com/search?q=user%3Aschuettc+cdk&type=repositories). This query will return all GitHub repositories created by user [`schuettc`](https://github.com/schuettc) (me) with `cdk` in the repository name. The result will be used to create a CSV file that contains these repositories and various GitHub stats.

Be sure to create a [GitHub personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with an appropriate scope and save as `POETRY_GITHUB_KEY` in a local `.env` file to use.

The result will be something like this:

![CSV](/images/blog/PyGithubRepos.png)

- GitHub repository: [pygithub-query-csv](https://github.com/schuettc/pygithub-query-csv)


If you need to modify the keys of a Python dictionary, a recursive function can be a useful way to work through the entire dictionary.  This [gist](https://gist.github.com/schuettc/3875da7458e3573646599e70b7b17a61) is an example of how to do that.

Using PyGitHub to Manage and Track GitHub Repositories


A twist on the previous [Recursively Modify Python Dictionary](recursively-modify-python-dictionary), this function will modify a Python dictionary to convert snake_case keys to PascalCase keys.

```python
def snake_to_PascalCase(d):
    for k, v in d.copy().items():
        if isinstance(v, dict):
            d.pop(k)
            d[k.title().replace("_", "")] = v
            snake_to_PascalCase(v)
        elif isinstance(v, list):
            d.pop(k)
            d[k.title().replace("_", "")] = v
            for i in v:
                v.remove(i)
                v.append(snake_to_PascalCase(i))
        else:
            d.pop(k)
            d[k.title().replace("_", "")] = v
    return d
```

- Gist: [snake_to_PascalCase.py](https://gist.github.com/schuettc/7f59c5faaf0609ca04a5dc04751960eb)


A twist on the previous [Recursively Modify Python Dictionary](/content/blog/recursively-modify-python-dictionary.md), this function will modify a Python dictionary to convert snake_case keys to PascalCase keys.

snake_to_PascalCase


[NextJS](https://nextjs.org/learn/foundations/about-nextjs/what-is-nextjs) is a powerful React framework that we can use to deploy directly from GitHub to [AWS Amplify](https://aws.amazon.com/amplify/). We will also be using [CodeSandbox](https://codesandbox.io/docs/overview) to work with the code before deploying.

[![amplifybutton](https://oneclick.amplifyapp.com/button.svg)](https://console.aws.amazon.com/amplify/home#/deploy?repo=https://github.com/schuettc/nextjs-ssr-with-amplify-deploy)

## Working with CodeSandbox

After creating the GitHub repo, we will [import the code](https://codesandbox.io/docs/importing#import-from-github) into a [CodeSandbox project](https://codesandbox.io/p/github/schuettc/nextjs-ssr-with-amplify-deploy/main?file=%2FREADME.md). This will allow us to work with and explore the code before deploying to our Amplify App.

### Creating AWS Credentials

Because this demo will use an [AWS SDK](https://aws.amazon.com/sdk-for-javascript/) request ([DescribeInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html)), we will need to configure credentials that include permission to make this request. In order to do this, we will be creating a [User](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) and assigning it a [Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html). This Role should be limited in scope to only the Action that is required.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeInstances",
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}
```

When this User is created, you will get an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. We will be using these to configure our application so that it has permissions to `DescribeInstances`.

### Adding AWS Credentials

After the AWS Credentials have been created, they must be added to the application. To do this with Code Sandbox, we will use [Environment Variables](https://codesandbox.io/docs/secrets) in our container. If you want to make changes, you will need to fork this project. When you do this, these environment variables will not be copied so you must use your own AWS Credentials.

![ConfigEnvVar](/images/blog/ConfigEnvVariables.png)

![EnvVariables](/images/blog/EnvVariables.png)

### Using the AWS SDK with Credentials

After configuring the Environment Variables in Code Sandbox, we can use the AWS SDK in the [pages/api/instances.js](https://github.com/schuettc/nextjs-ssr-with-amplify-deploy/blob/main/pages/api/instances.js) file.

```javascript
import { EC2Client, DescribeInstancesCommand } from '@aws-sdk/client-ec2';
const config = {
  region: 'us-east-1',
  credentials: {
    accessKeyId: process.env.ACCESS_KEY_ID,
    secretAccessKey: process.env.SECRET_ACCESS_KEY,
  },
};

const client = new EC2Client(config);
```

### next.config.js

To pass [Environment Variables to Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/server-side-rendering-amplify.html#ssr-environment-variable-support), we need to modify the next.config.js file. We'll be adding these same Environment Variables to Amplify a little later.

```javascript
const withTranspileModules = require('next-transpile-modules');
const withPlugins = require('next-compose-plugins');

module.exports = withPlugins(
  [withTranspileModules(['@cloudscape-design/components'])],
  {
    env: {
      ACCESS_KEY_ID: process.env.ACCESS_KEY_ID,
      SECRET_ACCESS_KEY: process.env.SECRET_ACCESS_KEY,
    },
  },
);
```

### amplify.yml

To configure the build of the Amplify application, we include `amplify.yml` and instruct it to use Node version 16 as part of the build.

```yaml
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - nvm use $VERSION_NODE_16
        - npm ci
    build:
      commands:
        - nvm use $VERSION_NODE_16
        - npm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*
```

### Result

Now that we have our API configured with credentials, when the front end application uses this API, we will query the associated account for active instances in `us-east-1` and display them on a simple page. We can see these results live in our Code Sandbox now before we deploy to Amplify to ensure everything looks the way we want it.

![Result](/images/blog/Result.png)

## Deploying in AWS Amplify

In order to deploy to AWS Amplify, we will need to use the GitHub Apps feature to [authorize Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/setting-up-GitHub-access.html) to read your GitHub repository.

### Begin Deploy

After clicking the above `Deploy to Amplify Console` link, you will begin the process of deploying to Amplify.

![Deploy](/images/blog/Deploy.png)

### Add Environment Variables

At the next screen, you will be able to add Environment Variables. Please note the additional Environment Variable needed in addition to your Access Key ID and Secret Access Key:

`AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE` = `true`

![AddEnvVariables](/images/blog/AddEnvVariablesToAmplify.png)

### Deploying

Once added, the App will being deploying. This will fork the repository into your GitHub account and begin installing to Amplify.

![Deploying](/images/blog/Deploying.png)

### Deploy Failure

This first deploy should result in a failure to deploy that we will be fixing next.

![FailureToDeploy](/images/blog/DeployFailure.png)

## Finalizing Amplify Configuration

In order to [deploy an SSR Application on AWS Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/server-side-rendering-amplify.html), we must add appropriate Service Role permissions to correct this error:

> Cannot find any generated SSR resources to deploy. If you intend for your app to be SSR, please check your app Service Role permissions. Otherwise, please check out our docs on how to setup your app to be detected as SSG (https://docs.aws.amazon.com/amplify/latest/userguide/server-side-rendering-amplify.html#deploy-nextjs-app)

### Add Service Role

In the App settings, select General and Edit. If there is no available Service role, you will need to create a new service role.

![ServiceRole](/images/blog/ServiceRole.png)

Follow the prompts to create a new Service Role, assign that role in the Amplify App settings, and then Save.

### Update Build Settings

Additionally, you should configure the Build image settings. In the App settings, select Build settings and Edit. Set the Next.js version to `latest` and the Node.js version to `14`. This will ensure the AWS Lambdas that are created as part of this application use Node version 14.

![UpdateBuildSettings](/images/blog/BuildSettings.png)

### Redeploy

Return to your App and select `Redeploy this version`

![Redeploy](/images/blog/Redeploy.png)

### Success!

Your app should now successfully deploy and can be accessed at the Domain shown in the console.

![Success](/images/blog/Success.png)

## Resources

- [GitHub Repository](https://github.com/schuettc/nextjs-ssr-with-amplify-deploy)
- [Code Sandbox Project](https://codesandbox.io/p/github/schuettc/nextjs-ssr-with-amplify-deploy/main)
- [Amplify One-Click Deploy](https://console.aws.amazon.com/amplify/home#/deploy?repo=https://github.com/schuettc/nextjs-ssr-with-amplify-deploy)


[NextJS](https://nextjs.org/learn/foundations/about-nextjs/what-is-nextjs) is a powerful React framework that we can use to deploy directly from GitHub to [AWS Amplify](https://aws.amazon.com/amplify/). We will also be using [CodeSandbox](https://codesandbox.io/docs/overview) to work with the code before deploying.

Deploying a NextJS SSR Application to Amplify


Creating an [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (Amazon Machine Image) can be done via the AWS Console. It can also be created via AWS CLI or SDKs. This CDK Construct will assist with the creation of an AMI as part of a [CDK](https://aws.amazon.com/cdk/) deployment.

This AMI can then be used in a complex deployment that requires a lengthy initial build but would need to be deployed quickly as part of a an [Auto-Scaling Group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html).

The included example will show how you can create an AMI after deploying an EC2 Instance and then create a new EC2 Instance using the created AMI to deploy more quickly. Keep and eye out here for future deployments that will include more complex examples of this CDK Construct.

## Background

From [Creating an AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami):

> You can launch an instance from an existing AMI, customize the instance (for example, [install software](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-software.html) on the instance), and then save this updated configuration as a custom AMI. Instances launched from this new custom AMI include the customizations that you made when you created the AMI.

This CDK Construct will assist in you creating that AMI for later use.

## Installing

To add to your AWS CDK package.json file:

```bash
yarn add cdk-create-ami
```

## How It Works

To create an image:

```ts
import * as ami from 'cdk-create-ami';
```

```ts
const amiImage = new ami.CreateAMI(this, 'amiImage', {
  instanceId: baseInstance.instanceId,
  deleteAmi: true,
  deleteInstance: true,
  blockDeviceMappings: [
    {
      deviceName: '/dev/sdh',
      ebs: {
        volumeSize: 20,
        volumeType: ami.VolumeType.GP3,
        deleteOnTermination: true,
      },
    },
  ],
  tagSpecifications: [
    {
      resourceType: ami.ResourceType.IMAGE,
      tags: [{ key: 'TagKey', value: 'TagValue' }],
    },
  ],
});
```

This will take an already created [Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Instances.html) and convert it to an AMI. This process involves stopping the Instance and then creating the AMI. Besides typical AMI creation options regarding [block device mappings](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html) and [tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html), the AMI can be created with two options:

```ts
      deleteAmi: true,
      deleteInstance: true,
```

- deleteAmi: When the CDK is destroyed, if this is set to `True`, the AMI will be deleted. Otherwise, the AMI will be retained.
- deleteInstance: When the CDK is deployed, if this is set to `True`, the base image will be deleted. Otherwise, the instance will be retained in a `Stopped` state.

## Example

The associated example includes two Stacks that can be created.

- AMIExample - Deploys Instance and creates AMI from Instance
- InstanceExample - Deploys Instance from previously created AMI

### AMI Example

```bash
cd example
yarn ami
```

This will deploy an Instance and create an AMI from the created Instance.

#### Creating the Instance

```ts
const vpc = new VPC(this, 'VPC');
const baseInstance = new BaseInstance(this, 'Instance', {
  vpc: vpc.vpc,
  securityGroup: vpc.securityGroup,
  ec2Role: vpc.ec2Role,
});
```

The example will create a VPC and Instance to be used to create the AMI. This instance contains a [cloud-init script](example/resources/base_install.sh):

```bash
HOMEDIR=/home/ec2-user
yum update -y
yum install net-tools -y
yum install wget -y

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
LOCAL_HOSTNAME=$( curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname )
INSTANCE_ID=$( curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/instance-id )

echo "AMI Hostname: $LOCAL_HOSTNAME" >> /home/ec2-user/config.txt
echo "AMI InstanceId: $INSTANCE_ID" >> /home/ec2-user/config.txt
```

This will result in a file: `/home/ec2-user/config.txt` that contains the base instance information. This fille will be retained in the AMI.

```bash
AMI Hostname: ec2-54-152-127-245.compute-1.amazonaws.com
AMI InstanceId: i-002aeb6cdde92c9b5
```

#### SSM

The AMI information will be stored in AWS Systems Manager - Parameter Store

![CDK-Create-AMI-SSM](/images/blog/SSM.png)

### Instance Example

Once the AMI has been created, that AMI can be used to create a new Instance that has been pre-configured.

```bash
yarn instance imageId=IMAGEID
```

The IMAGEID to be used is provided as output from the AMI Example Stack.

This AMI Image ID is retrieved by the CDK:

```ts
const customAmi = new ec2.GenericSSMParameterImage(
  '/createAMI/' + props.imageId,
  ec2.OperatingSystemType.LINUX,
);
```

This AMI Image ID is used to create the new Instance:

```ts
const ec2Instance = new ec2.Instance(this, 'Instance', {
  vpc: props.vpc,
  instanceType: ec2.InstanceType.of(
    ec2.InstanceClass.T4G,
    ec2.InstanceSize.MEDIUM,
  ),
  machineImage: customAmi,
  // More Instance configuration here
});
```

This instance contains a [cloud-init script](example/resources/new_install.sh):

```bash
HOMEDIR=/home/ec2-user

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
LOCAL_HOSTNAME=$( curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname )
INSTANCE_ID=$( curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/instance-id )

echo "New Instance Hostname: $LOCAL_HOSTNAME" >> /home/ec2-user/config.txt
echo "New Instance InstanceId: $INSTANCE_ID" >> /home/ec2-user/config.txt
```

Because the Instance used to create the AMI has already updated and installed packages, these do not need to be run again. Instead, the new Instance Hostname and InstanceId will be copied to the existing `/home/ec2-user/config.txt` file.

```bash
AMI Hostname: ec2-54-152-127-245.compute-1.amazonaws.com
AMI InstanceId: i-002aeb6cdde92c9b5
New Instance Hostname: ec2-54-242-5-47.compute-1.amazonaws.com
New Instance InstanceId: i-0e67014a77d5d1995
```


Creating an [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (Amazon Machine Image) can be done via the AWS Console.  It can also be created via AWS CLI or SDKs.  This CDK Construct will assist with the creation of an AMI as part of a [CDK](https://aws.amazon.com/cdk/) deployment.

Create AMI CDK Construct


If you need to modify the keys of a Python dictionary, a recursive function can be a useful way to work through the entire dictionary. This [gist](https://gist.github.com/schuettc/3875da7458e3573646599e70b7b17a61) is an example of how to do that.

```python
def capitalize_keys(d):
    for k, v in d.copy().items():
        if isinstance(v, dict):
            d.pop(k)
            d[f"{k[0].upper() +k[1:]}"] = v
            capitalize_keys(v)
        else:
            d.pop(k)
            d[f"{k[0].upper() +k[1:]}"] = v
    return d
```

Each iteration through the function will look at the Value (v) and determine if it is a dict. If it is, the Key (k) will be removed and replaced with a capitalized version of the Key. Then, because we know the Value is a dict, the function will be called again with the Value as the input. If the Value is not a dict, we have reached the end of the dict and don't need to recurse again.

Other data manipulations can be made on the JSON object through these recursions as well.

For instance:

```python
def capitalize_keys(d):
    for k, v in d.copy().items():
        if isinstance(v, dict):
            d.pop(k)
            d[f"{k[0].upper() +k[1:]}"] = v
            capitalize_keys(v)
        else:
            if k == "keyToChange":
                v = int(v)
            d.pop(k)
            d[f"{k[0].upper() +k[1:]}"] = v
    return d
```

In this example, the Value (v) of the Key (k) 'keyToChange' will be changed from a `string` to an `int`.

An example dictionary that has been processed:

```json
[
  {
    appName: 'Capitalize',
    resources: {
      url: 'example.com',
      file: 'file.txt',
    },
  },
];
```

Result:

```json
[
  {
    AppName: 'Capitalize',
    Resources: {
      Url: 'example.com',
      File: 'file.txt',
    },
  },
];
```


Recursively Modify Python Dictionary


To add on to the previous [article](https://subaud.io/importing-an-amazon-lex-bot-with-cdk/) that described how to import an Amazon Lex Bot with CDK, I have created a [CDK Construct](https://constructs.dev/packages/cdk-lex-zip-import/v/0.0.4?lang=typescript) that you can import and use in your own CDK projects.

To add this to your CDK project, simply import the Construct:

```bash
yarn add cdk-lex-zip-import
```

Within your CDK:

```typescript
const bot = new lexupload.ImportBot(this, 'lexBot', {
  sourceDirectory: './resources/LexBot',
  lexRoleArn: lexRole.roleArn,
});
```

The `sourceDirectory` must include a file named `LexBot.zip`. This file will be uploaded to an S3 Bucket and then imported using a Lambda backed Custom Resource.

Additionally, a Resource Policy can be applied to the Alias once it is imported.

```typescript
bot.addResourcePolicy(resourceArn, policy);
```

A complete example might look like this:

```typescript
import { Stack, StackProps } from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as lexupload from 'cdk-lex-zip-import';
import { Construct } from 'constructs';

export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps = {}) {
    super(scope, id, props);

    const lexRole = new iam.Role(this, 'lexRole', {
      assumedBy: new iam.ServicePrincipal('lex.amazonaws.com'),
      inlinePolicies: {
        ['lexPolicy']: new iam.PolicyDocument({
          statements: [
            new iam.PolicyStatement({
              resources: ['*'],
              actions: ['polly:SynthesizeSpeech', 'comprehend:DetectSentiment'],
            }),
          ],
        }),
      },
    });

    const bot = new lexupload.ImportBot(this, 'lexBot', {
      sourceDirectory: './resources/LexBot',
      lexRoleArn: lexRole.roleArn,
    });

    const resourceArn = `arn:aws:lex:${this.region}:${this.account}:bot-alias/${bot.botId}/${bot.botAliasId}`;
    const policy = {
      Version: '2012-10-17',
      Statement: [
        {
          Sid: 'AllowChimePstnAudioUseBot',
          Effect: 'Allow',
          Principal: { Service: 'voiceconnector.chime.amazonaws.com' },
          Action: 'lex:StartConversation',
          Resource: resourceArn,
          Condition: {
            StringEquals: { 'AWS:SourceAccount': `${this.account}` },
            ArnEquals: {
              'AWS:SourceArn': `arn:aws:voiceconnector:us-east-1:${this.account}:*`,
            },
          },
        },
      ],
    };
    bot.addResourcePolicy(resourceArn, policy);
  }
}
```

For more information or to contribute, please see the [GitHub repo](https://github.com/schuettc/cdk-lex-zip-import).


To add on to the previous [article](https://subaud.io/importing-an-amazon-lex-bot-with-cdk/) that described how to import an Amazon Lex Bot with CDK, I have created a [CDK Construct](https://constructs.dev/packages/cdk-lex-zip-import/v/0.0.4?lang=typescript) that you can import and use in your own CDK projects.

A CDK Construct for Importing Amazon Lex Bots


Amazon Lex Bots are a way to use natural language conversational interfaces that can be used through a variety of integrations such as Facebook and Slack. A Lex Bot can be built and deployed through the AWS console. However, it can also be deployed by CDK, Cloudformation, or SDK. In this post, I will explain how to import an existing Lex Bot using CDK and SDK.

![LexBot](/images/blog/Directory.png)

After cloning [this repo](https://github.com/schuettc/cdk-lex-import), you will see a zipped LexBot in the `resources` directory. As part of the CDK, this file will be copied up with the Lex import Lambda. You can replace this Zip file with a Lex Bot of your choosing.

```typescript
const lexDeployLambda = new lambda.Function(this, 'lexDeployLambda', {
  runtime: lambda.Runtime.PYTHON_3_9,
  code: lambda.Code.fromAsset(path.join(__dirname, '../resources/lexBot')),
  handler: 'index.handler',
  architecture: lambda.Architecture.ARM_64,
  timeout: Duration.minutes(1),
  role: lexCustomResourceRole,
});

const uid: string = Names.uniqueId(this);

const LexResourceProvider = new cr.Provider(this, 'LexResourceProvider', {
  onEventHandler: lexDeployLambda,
});

const lexBot = new CustomResource(this, 'LexCustomResource', {
  serviceToken: LexResourceProvider.serviceToken,
  properties: { uid: uid, lex_role_arn: lexRole.roleArn },
});
```

While the CDK is being deployed, the Custom Resource Lambda will be triggered with a `Create` RequestType. This will cause the Lambda to begin the process of importing the bot.

```python
def create_bot(bot_name, lex_role_arn, account_id):
    response_data = {}
    upload_info = lex.create_upload_url()
    upload_bot(upload_info)
    import_bot(bot_name, upload_info["importId"], lex_role_arn)
    bot_id = get_bot_id(bot_name)
    bot_alias_id = get_bot_alias_id(bot_id)
    put_resource_policy(bot_id, bot_alias_id, account_id)
    build_bot(bot_id)
    response_data["bot_id"] = bot_id
    response_data["bot_alias_id"] = bot_alias_id
    return response_data
```

There are multiple steps required to import and build a Lex bot. This function will work through each of those.

The first step is to create a URL that will be used as part of the import. This is done with a single lexv2-models API call:

```python
upload_info = lex.create_upload_url()
```

Once this URL is created, it is passed to the upload_bot function and the `LexBot.zip` file is uploaded to the specified URL.

```python
def upload_bot(upload_info):
    http = urllib3.PoolManager()
    try:
        with open("LexBot.zip", mode="rb") as bot:
            file_data = bot.read()

    except Exception as e:
        error = {"error": f"Exception thrown: {e}"}
        print(error)
        raise Exception(error)
    try:
        upload = http.request(
            "PUT", upload_info["uploadUrl"], body=file_data, headers={"Content-Type": "application/zip"}
        )

    except Exception as e:
        error = {"error": f"Exception thrown: {e}"}
        print(error)
        raise Exception(error)
    logger.info(upload.data.decode("utf-8"))
    return upload
```

Once uploaded to S3, the bot must be imported.

```python
def import_bot(bot_name, import_id, lex_role_arn):
    bot_import_result = lex.start_import(
        importId=import_id,
        resourceSpecification={
            "botImportSpecification": {
                "botName": bot_name,
                "roleArn": lex_role_arn,
                "dataPrivacy": {"childDirected": False},
                "idleSessionTTLInSeconds": 600,
            },
        },
        mergeStrategy="Overwrite",
    )
    logger.info(bot_import_result)
    return bot_import_result
```

If a Resource Policy is required for your Bot, it can be added with the `put_resource_policy` function also included. The Bot will then be built and is now ready for use.

Once the Lambda has completed importing the Bot to Lex, it will return the bot_id and bot_alias_id to the CDK.

Once the Lex bot has been imported, it can be tested in the Lex console.

![LexTest](/images/blog/LexTest.png)

### Resources

- [GitHub Repo](https://github.com/schuettc/cdk-lex-import)
- [Amazon Lex](https://aws.amazon.com/lex/)
- [Boto3 - Lexv2-Models](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lexv2-models.html)


Amazon Lex Bots are a way to use natural language conversational interfaces that can be used through a variety of integrations such as Facebook and Slack.  A Lex Bot can be built and deployed through the AWS console.  However, it can also be deployed by CDK, Cloudformation, or SDK.  In this post, I will explain how to import an existing Lex Bot using CDK and SDK.

Importing an Amazon Lex Bot with CDK


## Full Stack CDK Example

This example will build a CDK Pipeline that will build a backend and frontend and then pass API Gateway URL information from the backend to the frontend. This information can be used to make calls to the backend without having to manually pass the URL information. When connected to a Github repo, the CDK pipeline will automatically trigger and rebuild so changes to any portion of the app through GitHub.

**Please note: this deployment will create a file that will be accessible to the public so sensitive information should not be included. **

![Full Stack App Overview](/images/Pipeline.png)

### CDK Pipeline

The pipeline created is a self-mutating pipeline associated with a GitHub repo using a CodeStar connection. This can be adjusted to other Pipeline [sources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.pipelines-readme.html#synth-and-sources).

This pipeline contains a single Stage with three Stacks.

```typescript
    const pipeline = new pipelines.CodePipeline(this, 'Pipeline', {
      ...
    });

    const stages = new Stages(this, 'Stages', {});
    pipeline.addStage(stages);
```

### Backend Stack

```typescript
export class Backend extends Stack {
  public readonly config: Object;

  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    ...
    this.config = {
      API_URL: api.url,
    };
  }
}
```

The Backend stack creates a sample Lambda function and associates it with an API Gateway. The URL from this API Gateway is used as the output in a JSON Object that will be used in the Config Stack.

### Frontend Stack

The Frontend Stack is a simple S3 + Cloudfront Distribution that will be used to host a React SPA. Before uploading to the S3 bucket with `s3deploy.BucketDeployment` it must be bundled. The output of this `yarn build` will be copied to the outputDir and deployed to the S3 bucket.

```typescript
const bundle = s3deploy.Source.asset('./site', {
  bundling: {
    command: [
      'sh',
      '-c',
      'echo "Docker build not supported. Please install esbuild."',
    ],
    image: DockerImage.fromRegistry('alpine'),
    local: {
      tryBundle(outputDir: string) {
        try {
          execSync('esbuild --version', execOptions);
        } catch {
          /* istanbul ignore next */
          return false;
        }
        execSync(
          'cd site && yarn install --frozen-lockfile && yarn build',
          execOptions,
        );
        copySync('./site/build', outputDir, {
          ...execOptions,
          recursive: true,
        });
        return true;
      },
    },
  },
});
```

### Config Stack

The Config stack creates a `config.json` file in the S3 bucket that was created in the Frontend Stack with the API URL information from the Backend Stack using a CustomResource.

```typescript
new customresource.AwsCustomResource(this, 'ConfigFrontEnd', {
  onUpdate: {
    service: 'S3',
    action: 'putObject',
    parameters: {
      Body: JSON.stringify(props.config),
      Bucket: props.siteBucket.bucketName,
      Key: 'config.json',
    },
    physicalResourceId: customresource.PhysicalResourceId.of(
      Date.now().toString(),
    ),
  },
  policy: customresource.AwsCustomResourcePolicy.fromSdkCalls({
    resources: customresource.AwsCustomResourcePolicy.ANY_RESOURCE,
  }),
});
```

### React App

With the Backend and Frontend created, the React App deployed to the S3 bucket must read the `config.json` file that was created in the Config Stack. It is very important to note that this file is publicly visible so you should not put any sensitive information in it. Another [method](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html) should be used to secure your API Gateway.

```javascript
export async function config() {
  const data = await fetch('./config.json').then((response) => response.json());

  const AmplifyConfig = {
    API: {
      endpoints: [
        {
          name: 'demoApi',
          endpoint: data.API_URL,
        },
      ],
    },
  };

  return AmplifyConfig;
```

The `Config.js` file is used to fetch the information in the `config.json` file that was written to the S3 bucket by the Config Stack. To use this locally, this file must be copied to the `src/site/public` directory.

```javascript
const apiConfig = await config();
API.configure(apiConfig);
const randomNumberResult = await API.post('demoApi', 'demo', {
  body: {},
});
setRandomNumber(randomNumberResult);
```

The React App uses Amplify to make API calls using the API information from the `Config.js` file. This could be enhanced with Cognito to provide API Gateway security.

Complete demo [here](https://github.com/schuettc/full-stack-cdk-example).


This example will build a CDK Pipeline that will build a backend and frontend and then pass API Gateway URL information from the backend to the frontend. This information can be used to make calls to the backend without having to manually pass the URL information.  When connected to a Github repo, the CDK pipeline will automatically trigger and rebuild so changes to any portion of the app through GitHub.

Creating a Full Stack App with CDK Pipelines


### Overview

![EC2](/images/blog/Example-EC2.png)

Cloud-init is a powerful way of configuring an EC2 instance. CDK can create an EC2 instance and use cloud-init to pass dynamically created variables to this EC2 instance which can be used to configure the instance. When combined, these tools can be used to create fully configured and deployed dynamic EC2 instances.

[This GitHub repo](https://github.com/schuettc/cdk-ec2-example) will deploy an EC2 instance using CDK. This EC2 instance will download and install [Asterisk 18](https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Documentation) on the EC2 instance. Additionally, it will create a `pjsip.conf` file and configure that using the Elastic IP address created by the CDK.

Once the Elastic IP is created, by the CDK, it is passed to the EC2 Instance using cloud-init:

```ts
      init: ec2.CloudFormationInit.fromConfigSets({
        configSets: {
          default: ['install', 'config'],
        },
        configs: {
          install: new ec2.InitConfig([
            ec2.InitFile.fromObject('/etc/config.json', {
              IP: ec2Eip.ref,
            }),
```

This file will be stored on the newly created instance based on resources created by the CDK. In this example, the Elastic IP address is passed to the JSON object. This information can also be [queried with metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html), but is used in this example as information that can be dynamically created by the CDK and passed to the EC2 Instance.

Files can be loaded to the EC2 instance from [multiple sources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.InitSource.html). In this example, we are loading a bash script from the local deployment of the CDK and executing it on the EC2 instance. This cloud-init configuration in the CDK will load the [`install.sh`](https://github.com/schuettc/cdk-ec2-example/blob/main/src/asteriskConfig/install.sh) file from the `./src/asteriskConfig/` directory into the `/etc/` directory of the Instance and then execute it.

```ts
            ec2.InitFile.fromFileInline(
              '/etc/install.sh',
              './src/asteriskConfig/install.sh',
            ),
            ec2.InitCommand.shellCommand('chmod +x /etc/install.sh'),
            ec2.InitCommand.shellCommand('cd /tmp'),
            ec2.InitCommand.shellCommand('/etc/install.sh'),
          ]),
```

The example script will download and install an Asterisk PBX on to the EC2 instance. Additional files are included in the GitHub repo that are used to more fully configure the Asterisk server using `jq` and `sed` with the information passed to the Instance from the CDK:

```bash
IP=$( jq -r '.IP' /etc/config.json )

sed -i "s/IP_ADDRESS/$IP/g" /etc/asterisk/pjsip.conf
```

[initOptions](https://docs.aws.amazon.com/cdk/api/v2//docs/aws-cdk-lib.aws_ec2.ApplyCloudFormationInitOptions.html) can also be used to ensure that the configuration of the EC2 instance succeeds.

```json
      initOptions: {
        timeout: Duration.minutes(15),
      },
```

If the timeout fails or the Instance returns a failure, the CDK will roll back to the previous state. When the cloud-init configuration of the Instance succeeds, it will pass this information back to the CDK. Until then, the CDK will remain in a Creating state and will not progress. This is useful when you want to ensure that the build and configuration of the EC2 instance succeeds before deploying additional resources with the CDK.

More details are provided in the [GitHub repo](https://github.com/schuettc/cdk-ec2-example).


Cloud-init is a powerful way of configuring an EC2 instance. CDK can create an EC2 instance and use cloud-init to pass dynamically created variables to this EC2 instance which can be used to configure the instance.  When combined, these tools can be used to create fully configured and deployed dynamic EC2 instances.

Building an EC2 Instance with CDKv2 and Cloud-Init


CDK Constructs are a great way to create reusable and flexible code for yourself and others. projen makes it easy to create and publish the project. CDK Custom Resources are a way to do complex deployments and deploy AWS resources not native to CDK within a CDK. In this example, an AWS Lambda will be used as a Custom Resource from a published package.

## Setting Up the Project

To do this yourself: `npx projen new awscdk-construct`

This will create a [projen](https://github.com/projen/projen) project to be used. More information is available here when working with [AWS CDK Constructs](https://github.com/projen/projen/blob/main/docs/awscdk-construct.md). Additionally, this can be set up to publish to the very useful [constructs.dev](https://constructs.dev/contribute) so that others can use your Construct.

## Publishing the Project

Create an Access Token within npm to allow GitHub to publish to npm. Add this Access Token to GitHub in the Secrets section of the repository Settings as `NPM_TOKEN`

```bash
npx projen build
git add .
git commit -m 'commit comment'
git push
```

This will start a GitHub workflow action that will publish to npm.

## Example Construct Code

Standard Imports:

```typescript
import * as path from 'path';
import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';
```

The Interface that will be used to take input from the deployable CDK. Because this is Typescript, these will be enforced but can be a wide range of types.

```typescript
export interface CdkCustomResourceExampleProps extends cdk.ResourceProps {
  readonly customResourceNumber: number;
}
```

This is the object that will be returned to the deployable CDK as the output from the Custom Resource:

```typescript
export class CustomResourceExample extends Construct {
  public readonly customResourceResult: string;

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

The IAM Role used by the Lambda:

```typescript
const role = new iam.Role(this, 'CustomResourceRole', {
  description: 'Custom Resource Construct Example',
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName(
      'service-role/AWSLambdaBasicExecutionRole',
    ),
  ],
});
```

The Lambda that will be created to be used as the Custom Resource:

```typescript
const fn = new lambda.Function(this, 'CustomResourceLambda', {
  runtime: lambda.Runtime.NODEJS_14_X,
  code: lambda.Code.fromAsset(path.join(__dirname, '../resources')),
  handler: 'index.handler',
  architecture: lambda.Architecture.ARM_64,
  role: role,
  timeout: cdk.Duration.minutes(1),
});
```

The Custom Resource that will be invoked using the above Lambda taking in the properties supplied by the deployable CDK.

```typescript
    const customResourceResult = new cdk.CustomResource(
      this,
      'customResourceResult',
      {
        serviceToken: fn.functionArn,
        properties: {
          customResourceNumber: props.customResourceNumber,
        },
      },
    );

    this.customResourceResult = customResourceResult.getAttString('Result');
  }
}
```

The Lambda code being invoked is a simple multiplication but can be used to create complex deployments that are not native to CDK. In order to simplify deployment, NodeJS has been used for the Lambda instead of Typescript. Typescript must be transpiled to NodeJS to run as a Lambda and using Typescript for the Construct allows us to take advantage of Types within the deployable CDK while still allowing for an easy-to-use package. Python could also be used for the same reasons.

## Demo CDK Code

To add the newly created package to the deployable CDK `yarn add cdk-custom-resource-construct-example`.

This will add it to the `package.json` like other installed dependencies.

```json
  "dependencies": {
    "aws-cdk-lib": "2.3.0",
    "cdk-custom-resource-construct-example": "*",
    "constructs": "^10.0.0",
    "source-map-support": "^0.5.16"
  }
```

In this simple example, the only resource being created is the output from the Custom Resource. `customResourceNumber` is required based on the configuration of the Interface in the Construct.

## Testing the CDK

```bash
git clone https://github.com/schuettc/cdk-custom-resource-construct-demo.git
cd cdk-custom-resource-construct-demo
yarn
yarn run build
yarn cdk deploy
```

This will deploy the CDK and produce the output of the Custom Resource.

```typescript
import { CfnOutput, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { CustomResourceExample } from 'cdk-custom-resource-construct-example';

export class CdkCustomResourceConstructDemoStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const result = new CustomResourceExample(this, 'customResourceResult', {
      customResourceNumber: 5,
    });

    new CfnOutput(this, 'customResourceOutput', {
      value: result.customResourceResult,
    });
  }
}
```

## Resources

- [GitHub Repository for Construct](https://github.com/schuettc/cdk-custom-resource-construct-example)
- [GitHub Repository for Demo](https://github.com/schuettc/cdk-custom-resource-construct-demo)
- [NPM Package](https://www.npmjs.com/package/cdk-custom-resource-construct-example)
- [constructs.dev construct](https://constructs.dev/packages/cdk-custom-resource-construct-example)


CDK Constructs are a great way to create reusable and flexible code for yourself and others.  projen makes it easy to create and publish the project.  CDK Custom Resources are a way to do complex deployments and deploy AWS resources not native to CDK within a CDK.  In this example, an AWS Lambda will be used as a Custom Resource from a published package.

Building CDK Custom Resource Constructs with projen and Typescript


Managing multiple AWS accounts with AWS CLI can be a challenge. Here is how I set up my macOS terminal. This configuration will set up a terminal shell that will show your AWS account and git information in the prompt. The example provided includes access key and SSO with MFA logins.

- Install [iTerm2](https://iterm2.com/)
- Install [Oh My Zsh](https://ohmyz.sh/#install)
- Install [Powerline Fonts](https://github.com/powerline/fonts)
- Install [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
- Configure [Command Completion for AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-completion.html#cli-command-completion-linux)
- Install [git](https://github.com/git-guides/install-git#install-git-on-mac)
- Install [fig](https://fig.io/)

### Configure Oh My Zsh - ~/.zshrc

```bash
ZSH_THEME="agnoster"
plugins=(git aws)
```

### Configure agnoster - ~/.oh-my-zsh/themes/agnoster.zsh-theme

This will remove the context from the prompt to shrink it down a little and add a right prompt with the current date/time. These are optional and can be customized to your preference.

```bash
#  prompt_context
RPROMPT="[%D{%y/%m/%f}|%@]"
```

### Configure iTerm Profile

```bash
Preferences -> Profile -> Text -> Font: Any of the Powerline Fonts
Preferences -> Profile -> Colors -> Color Presets: Solarized Dark
```

### Configure AWS Config - ~/.aws/config

This is a sample config file that shows how to use an account with and without SSO.

```text
[profile account1]
region=us-east-1
output=json

[profile account2]
region = us-east-1
output = json
sso_start_url = https://xxxxxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = ROLE
```

### Configure AWS Credentials - ~/.aws/credentials

Because the SSO account will acquire credentials during the login process, it is not needed here.

```text
[account1]
aws_access_key_id=XXXXXXXXXXXXX
aws_secret_access_key=XXXXXXXXXXXXXXXXXXXXXXXXX
```

### Using aws plugin

The Oh My Zsh aws plugin will allow you to easily switch between accounts.

- Switch to account without SSO: `asp account1`
- Switch to account with SSO and MFA: `asp account2 login`
- Clear account: `asp`

### Empty profile

It can be useful to have an empty profile that is used with exported `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN` information. To create a profile using AWS CLI:

```bash
aws configure set profile.PROFILE_NAME.region us-east-1
aws configure set profile.PROFILE_NAME.output json
aws configure set profile.PROFILE_NAME.aws_access_key_id ''
aws configure set profile.PROFILE_NAME.aws_secret_access_key ''
aws configure set profile.PROFILE_NAME.aws_session_token ''
```

## Configured Result

![Configured Shell](/images/blog/shell.png)


Managing multiple AWS accounts with AWS CLI can be a challenge.  Here is how I set up my macOS terminal.  This configuration will set up a terminal shell that will show your AWS account and git information in the prompt.  The example provided includes access key and SSO with MFA logins.

Setting up a shell for multiple AWS accounts


When building ARM64 resources with CDK Pipelines, it is necessary to have them built using an ARM64 Image with CodeBuild. Otherwise, you will get an error like this during the Synth action:

`[Warning] The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested`

To ensure that the image used is an arm64/v8 image, the Typescript code should look like this:

```typescript
const cdkPipeline = new pipelines.CodePipeline(this, 'Pipeline', {
  selfMutation: true,
  dockerEnabledForSelfMutation: true,
  dockerEnabledForSynth: true,
  synth: new pipelines.ShellStep('Synth', {
    input: pipelines.CodePipelineSource.connection(
      'repo/cdk-pipeline-deployment',
      'main',
      {
        connectionArn:
          'arn:aws:codestar-connections:us-east-2:xxxxxxxxxxx:connection/xxxxxxx-7d1c-453c-xxxx-1c73586de313',
      },
    ),
    commands: ['npm ci', 'npm run build', 'npx cdk synth'],
  }),
  synthCodeBuildDefaults: {
    buildEnvironment: {
      computeType: codebuild.ComputeType.LARGE,
      buildImage: codebuild.LinuxBuildImage.AMAZON_LINUX_2_ARM,
    },
  },
  assetPublishingCodeBuildDefaults: {},
  selfMutationCodeBuildDefaults: {},
  codeBuildDefaults: {},
});
```

At this point, Stages can be added with :

`cdkPipeline.addStage(...)`

This is a self-mutating build. However, if you add the Stage with ARM64 resources before adding the synthCodeBuildDefaults, it will fail. To mutate the pipeline to allow the Stage to be built, remove the Stage, add the buildEnvironment parameters, rebuild the pipeline, add the Stage back, and rebuild the pipeline again. Now this pipeline should use the correct image when building the ARM64 resources.


When building ARM64 resources with CDK Pipelines, it is necessary to have them built using an ARM64 Image with CodeBuild.  

Building ARM64 Infrastructure with CDK Pipelines


'Simple bash script to download and compile [SIPp](https://github.com/SIPp/sipp.git) on an Amazon Linux 2 instance. This can take a while to build because of the cmake dependency.'

```bash
yum groupinstall "Development Tools" -y
yum install ncurses-compat-libs ncurses-devel sudo wget openssl-devel pcap libpcap-devel libnet gsl -y
pushd /tmp
wget https://cmake.org/files/v3.18/cmake-3.18.0.tar.gz
tar -xvzf cmake-3.18.0.tar.gz
cd cmake-3.18.0
./bootstrap
make
sudo make install
popd
git clone https://github.com/SIPp/sipp.git
cd sipp
/usr/local/bin/cmake . -DUSE_PCAP=1 -DUSE_GSL=1
make
```


Simple bash script to download and compile [SIPp](https://github.com/SIPp/sipp.git) on an Amazon Linux 2 instance.  This can take a while to build because of the cmake dependency.

Installing SIPp on Amazon Linux 2 Instance


This simple script will look through a bucket to find all objects that match a `LastModified` date and delete. This can be adjusted to delete objects before, after, or matching the date specified. Use at your own risk.

```python
import boto3
from datetime import datetime, timezone

s3 = boto3.client("s3")
bucket = "INSERT_BUCKET_NAME"
paginator = s3.get_paginator("list_objects_v2")
pages = paginator.paginate(Bucket=bucket)
date_check = datetime(2021, 11, 1)

keys_to_delete = []
for page in pages:
    for object in page["Contents"]:
        if object["LastModified"] > date_check.replace(tzinfo=timezone.utc):
            keys_to_delete.append({"Key": object["Key"]})

s3.delete_objects(Bucket=bucket, Delete={"Objects": keys_to_delete})
```

Gist [here](https://gist.github.com/schuettc/83c2ef71b5604eff69d1248553a8ef2c).


This simple script will look through a bucket to find all objects that match a `LastModified` date and delete.  This can be adjusted to delete objects before, after, or matching the date specified.  Use at your own risk.

Bulk Delete S3 Objects by LastModified Date


Previously, we looked at how to use CDK Pipelines to create a [full stack deployment](https://subaud.io/creating-a-full-stack-app-with-cdk-pipeline/). This deployment used multiple Cloudformation stacks to create a front-end and back-end. This example will show a similar process, but uses a new technique that will allow us to use a single stack to deploy both front-end and back-end while still maintaining the ability to work on the front-end locally.

```typescript
export class SingleStackFullStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps = {}) {
    super(scope, id, props);
    const infrastructure = new Infrastructure(this, 'infrastructure');

    const site = new Site(this, 'Site', { apiUrl: infrastructure.apiUrl });
  }
}
```

The entry point to the CDK simply calls two separate Constructs. In this case, we are creating the back-end with the `infrastructure` Construct and the front-end with the `site` Construct. The `infrastructure` Construct contains an API Gateway that we will be using to invoke a Lambda function. The URL of this API Gateway will be passed to `site` Construct as a prop to be used there.

```typescript
const exampleLambda = new NodejsFunction(this, 'meetingLambda', {
  entry: 'resources/index.ts',
  bundling: {
    nodeModules: ['aws-lambda'],
  },
  handler: 'lambdaHandler',
  runtime: Runtime.NODEJS_16_X,
  architecture: Architecture.ARM_64,
  role: infrastructureRole,
  timeout: Duration.seconds(60),
  environment: {
    MEETINGS_TABLE: exampleTable.tableName,
  },
});
```

The Lambda function used in the back-end uses Typescript code and is built using the [NodejsFunction Construct](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_nodejs.NodejsFunction.html). This will use `esbuild` to transpile the Typescript code into Javascript to be run in the NodeJS Lambda function.

---

The front-end Construct will use a typical S3 Bucket + Cloudfront distribution to create a static website built from a React application.

The deployment to the S3 bucket will consist of two components: a production built version of the React application and JSON file with the URL from the API Gateway.

```typescript
const config = {
  apiUrl: props.apiUrl,
};

new BucketDeployment(this, 'DeployBucket', {
  sources: [bundle, Source.jsonData('config.json', config)],
  destinationBucket: this.siteBucket,
  distribution: this.distribution,
  distributionPaths: ['/*'],
});
```

The deployment uses [`Source.jsonData`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_deployment.Source.html#static-jsonwbrdataobjectkey-obj) to capture deploy-time values before it creates the key containing the JSON data in the S3 bucket. This allows us to create the API Gateway and pass the URL of this API Gateway to the S3 bucket as a JSON file in a single stack.

---

This JSON file will be read by the front-end React application in the [`Config.js`](https://github.com/schuettc/single-stack-full-stack-example/blob/main/site/src/Config.js) file:

```javascript
const config = await fetch('./config.json').then((response) => response.json());

export const AmplifyConfig = {
  API: {
    endpoints: [
      {
        name: 'exampleApi',
        endpoint: config.apiUrl,
      },
    ],
  },
};
```

To allow for a top level await, be sure to enable it in the [`webpack.config.js`](https://github.com/schuettc/single-stack-full-stack-example/blob/bf6fd9b7ac310a19a5f6ae5382316da37e708b6f/site/webpack.config.js#L61-L63) file:

```javascript
    experiments: {
        topLevelAwait: true,
    },
```

Within [`App.js`](https://github.com/schuettc/single-stack-full-stack-example/blob/main/site/src/App.js) this will be used to configure Amplify:

```javascript
import { AmplifyConfig as config } from './Config';
import { Amplify, API } from 'aws-amplify';
Amplify.configure(config);
```

This will be used to POST to the API Gateway to invoke the Lambda function and get the response.

```javascript
useEffect(() => {
  const fetchData = async () => {
    const exampleResponse = await API.post('exampleApi', 'example', {});
    console.log(exampleResponse);
    setHelloWorld(exampleResponse.message);
  };

  fetchData().catch(console.error);
}, []);
```

---

Additionally, working on the the React application locally is possible by copying the `config.json` from the S3 bucket to the local directory for use with `yarn run start`.

Creating additional `package.json` scripts with Projen can be done using `project.addTask`. This example uses a script to make deployments easy:

```javascript
project.addTask('launch', {
  exec: 'yarn && yarn projen && yarn build && yarn cdk bootstrap && yarn cdk deploy --hotswap && yarn configLocal',
});
```

This script will build and deploy the included CDK as well as download the `config.json` file for use locally using the `configLocal` script.

The `configlocal` script will download the `config.json` from the S3 bucket and copy to the appropriate local directory.

```javascript
project.addTask('getBucket', {
  exec: "aws cloudformation describe-stacks --stack-name single-stack-full-stack-example-dev --query 'Stacks[0].Outputs[?OutputKey==`siteBucket`].OutputValue' --output text",
});

project.addTask('configLocal', {
  exec: 'aws s3 cp s3://$(yarn run --silent getBucket)/config.json site/public/',
});
```

---

The result of this CDK is a fully built and deployed front-end and back-end React application that is hosted but can also be worked on locally.

The full code is available here: [https://github.com/schuettc/single-stack-full-stack-example](https://github.com/schuettc/single-stack-full-stack-example)


Previously, we looked at how to use CDK Pipelines to create a [full stack deployment](https://subaud.io/creating-a-full-stack-app-with-cdk-pipeline/).  This deployment used multiple Cloudformation stacks to create a front-end and back-end.  This example will show a similar process, but uses a new technique that will allow us to use a single stack to deploy both front-end and back-end while still maintaining the ability to work on the front-end locally.

Archive

2023

2022

2021