aws-cdk | AWS Cloud Development Kit is a framework for defining cloud | Continuous Deployment library

You missed .promise(), so it don't await until the request is completed.

For the first question:

And if I change to Source.asset("./build") I get the error: ... Why is it searching for the build directory on my machine?

This is happening when you run cdk synth locally. Remember, cdk synth will always reference the file system where this command is run. Locally it will be your machine, in the pipeline it will be in the container or environment that is being used by AWS CodePipeline.

Dig a little deeper into BucketDeployment
But also, there is some interesting things that happen here that could be helpful. BucketDeployment doesn't just pull from the source you reference in BucketDeployment.sources and upload it to the bucket you specify in BucketDeployment.destinationBucket. According to the BucketDeployment docs the assets are uploaded to an intermediary bucket and then later merged to your bucket. This matters because it will explain your error received Error: Cannot find asset at C:\Users\pupeno\Code\ww3fe\build because when you run cdk synth it will expect the dir ./build as stated in Source.asset("./build") to exist.

This gets really interesting when trying to use a CodePipeline to build and deploy a single page app like React in your case. By default, CodePipeline will execute a Source step, followed a Synth step, then any of the waves or stages you add after. Adding a wave that builds your react app won't work right away because we now see that the output directory of building you react app is needed during the Synth step because of how BucketDeployment works. We need to be able to have the order be Source -> Build -> Synth -> Deploy. As found in this question, we can control the order of the steps by using inputs and outputs. CodePipeline will order the steps to ensure input/output dependencies are met. So we need the have our Synth step use the Build's output as its input.

Concerns with the currently defined pipeline
I believe that your current pipeline is missing a CodeBuildStep that would bundle your react app and output it to the directory that you specified in BucketDeployment.sources. We also need to set the inputs to order these actions correctly. Below are some updates to the pipeline definition, though some changes may need to be made to have the correct file paths. Also, set BucketDeployment.sources to the dir where your app bundle is written to.

Thanks to this demo stack I found that you:

1. create the Cognito User Pool and Client
2. create ApplicationLoadBalancedFargateService
3. add a AuthenticateCognitoAction to the fargateService listener like this:

I would strongly advise moving from the Docker directory to ECR public gallery to avoid ratelimit issues: https://gallery.ecr.aws/

That said, to answer the question about the number of NATs created. As you can see in the CDK docs, what you're seeing reflects the default behavior (emphasis mine):

A VPC consists of one or more subnets that instances can be placed into. CDK distinguishes three different subnet types:

Public (SubnetType.PUBLIC) - public subnets connect directly to the Internet using an Internet Gateway. If you want your instances to have a public IP address and be directly reachable from the Internet, you must place them in a public subnet.

Private with Internet Access (SubnetType.PRIVATE_WITH_NAT) - instances in private subnets are not directly routable from the Internet, and connect out to the Internet via a NAT gateway. By default, a NAT gateway is created in every public subnet for maximum availability. Be aware that you will be charged for NAT gateways.

Isolated (SubnetType.PRIVATE_ISOLATED) - isolated subnets do not route from or to the Internet, and as such do not require NAT gateways. They can only connect to or be connected to from other instances in the same VPC. A default VPC configuration will not include isolated subnets,

A default VPC configuration will create public and private subnets. However, if natGateways:0 and subnetConfiguration is undefined, default VPC configuration will create public and isolated subnets.

So a separate NAT is created for every Public subnet.

Also, the docs for the natGateways parameter mentioned above also describe the default behavior:

(default: One NAT gateway/instance per Availability Zone)

To limit the number of AZs used by the VPC, specify the maxAzs parameter. Set it to 1 to only have a single NAT per VPC.

If you're fine with making the resources in the VPC publicly reachable from the internet, you can place them in Public subnets and avoid the creation of NATs altogether.

This is because imported resources cannot be modified. As you pointed out in the comments, setting up the notification involves modifying the Topic resource, specifically its access policy.

Reference: https://docs.aws.amazon.com/cdk/v2/guide/resources.html#resources_importing

It's typically a one time thing per account per region. The infrastructure in that stack is shared among your CDK apps.

There was a change in format a while ago that required an update of the stack, but since then it has remained largely unchanged.

The docs on bootstrap are probably more helpful than the Github Link: CDK Bootstrapping.

Each CloudFormation stack created by a CDK app only belongs to one CDK app, they shouldn't be shared. The outputs can be referenced from other apps, but each stack should belong to one app.

That's why you can mix and match CDK versions across different stacks. Usually each CDK app maps to one or more CloudFormation stacks.

So I found a solution. Maybe not the solution. Indeed, this seems quite convoluted ... and I am sure there is a better way.

So the solution lies in the fact that the ShellStep in the CodePipeline construct attaches the output of additionalInputs (so the result of the previous CodeBuildStep i.e. lambdaBuildStep) in a specific directory which is dynamically generated but stored in an environment variable called CODEBUILD_SRC_DIR_BuildLambda_lambda_repo so you can see it's a combination of the name of the CodeBuildStep and the repo (with the dash changed to underscores).

So my solution was to use this environment variables as my Lambda code asset.

You cannot depend on CDK pipeline to fix itself if the synth stage is failing, since the Pipeline CloudFormation Stack is changed in the SelfMutate stage which uses the output of the synth stage. You will need to do one of the following options to fix your pipeline:

1. Run cdk synth and cdk deploy PipelineStack locally (or anywhere outside the pipeline, where you have the required AWS IAM permissions). Edit: You will need to temporarily set selfMutatation to false for this to work (Reference)

2. Temporarily remove route53.HostedZone.fromLookup and route53.CnameRecord from your MainStack while still keeping the rolePolicyStatements change. Commit and push your code, let CodePipeline run once, making sure that the Pipeline self mutates and the IAM role has the required additional permissions. Add back the route53 constructs, commit, push again and check whether your code works with the new changes.

This is extremely stupid mistake. I currently have 2 users in my machine setup and I was using the wrong one to deploy.

After performing aws configure with the credentials of the correct account I was able to deploy