Jets application timing out on describe_stacks at /lib/jets/aws_info.rb:76

I have used the basic QuickStart steps to create an application to troubleshoot timeout issues when trying to run Jets in a VPC to connect to a PostgreSQL db.

I basically did:

gem install jets
jets new demo --database=postgresql
cd demo
jets generate scaffold product name:string
rm db/migrate/2020* # to make sure not to nuke my actual database
vim .env.development # edit with local db settings
jets deploy

I have set vpc_config with subnets and security groups.

Jets.application.configure do
  config.function.vpc_config = {
    security_group_ids: %w[sg-08888aa27ec9e4494],
    subnet_ids: %w[subnet-0e963b10cf3beb0c6],

I keep getting timeout issues, so I have removed Jets.once and replaced it with the code it actually calls, adding logger output to drive down to the problem code.

At this point the code is timing out at /lib/jets/aws_info.rb:76, as follows.

resp = cfn.describe_stacks(stack_name: Jets::Naming.parent_stack_name)

Jets::Naming.parent_stack_name properly returns ‘demo-dev’.

Any idea on this one?

Wondering if the subnet has a NAT, found that lambda needs that. Also updated this post

Thanks for the reply!

I did figure it out - the reference to the NAT Gateway triggered the solution. I don’t want to spend money on a NAT Gateway just for CF access, so I just create a VPC Endpoint in the Lambda function’s subnet, as in the below CFT snippet.

Of course, use real IDs for the VPC and Subnet.

AWSTemplateFormatVersion: 2010-09-09
    Type: AWS::EC2::VPCEndpoint
      PrivateDnsEnabled: true
      ServiceName: !Sub com.amazonaws.${AWS::Region}.cloudformation
      - subnet-0e963b64cf3beb0c6
      VpcEndpointType: Interface
      VpcId: vpc-c67676a3

Cool. Enabling the VPC endpoint for CloudFormation is pretty neat! Thanks!

If I can get a few minutes I will try to put together a PR for supporting this more easily.

This solved my setup issue as well. This seems a bit buried, is it in the docs somewhere?