Vibe Architecting an API Gateway HTTP API

“Vibe coding” is the latest hype, so I thought I would give it a try. I was working with a customer to understand some security boundaries between an API Gateway HTTP API and a ALB target. Basically I wanted to “vibe architect” the CDK version of the image below:

So I used this prompt with AWS Q Developer inside Visual Studio Code for a CDK project.

create an AWS CDK project with the following components: 1) a API Gateway HTTP API targeting an ALB as the integration. 2) create a lambda custom authorizer for the HTTP API that adds data to the context. 3) have the integration from REST API to ALB add the context as a custom HTTP header. 4) create a new VPC for the ALB, and add a VPC Link to the HTTP API. 5) add another lambda function as the target for the ALB and print out the custom header. 6) recommend any security group logic to only allow HTTP traffic from the API Gateway HTTP API

It deployed, but when I tested using curl it didn’t work, but why? I looked at the code and realized it missed my “step 6” and didn’t create a security group for VPC link. I vibed coded some more with vpcLinkSecurityGroup = new ec2.SecurityGroup(...), added to ALB with albSecurityGroup.addIngressRule(vpcLinkSecurityGroup, ...), and included securityGroups: [vpcLinkSecurityGroup] on the apigatewayv2.VpcLink.

Tried again, and still didn’t work - but where? I had no idea because there wasn’t enough logging. I did some more vibe coding to add ALB Access Logging and VPC Flow logging.

I still was not seeing any logs indication my ALB targeted Lambda function was being called. But with the ALB and VPC logging, I realized it wasn’t leaving the API Gateway. I next found a problem with HTTP API access logging which was missing the $context.authorizer.error variable to resolve

Now I had the clue my HTTP API Lambda authorizer was generated to return a 2.0 payload format, but the HttpLambdaAuthorizer was not configured for responseTypes: [apigatewayv2_authorizers.HttpLambdaResponseType.SIMPLE]

At least now my Lambda function was being called, but I still needed to tweak some .appendHeader vs replaceHeader parameters mappings

I’m asking myself if this was better than doing everything myself. It was faster to get the CDK project setup and deployed. However, I still had to understand the stack was missing parts of the architecture, debug from the logs, and understand key details of the implementation like authorizer payload format and api parameters mappings.