I read this App Runner (AR) deep dive and attempted to replicate the example for a production app. I've followed the steps to the letter but for the life of me cannot figure out why my NestJS app emits an Error: connect ETIMEDOUT
when it tries to connect to ElastiCache. I've a VPC with 6 subnets in the same AZ. Half of those subnets are private. I lauched my AR service in the private subnets and ElasticCache with non-cluster mode in the public subnets. I've created a security group for ElastiCache and I've changed its inbound rules for port 6379
so it can accept connection from the default security group which houses the AR by following the instructions here. I've followed the instructions in the docs but cannot come right at all. Here are the latest CloudWatch logs for the app
...+02:00 [Nest] 16 - ... <cluster>.gtvll.st.0001.use1.cache.amazonaws.com
...+02:00 [Nest] 16 - ... 6379
...+02:00 [Nest] 16 - ... Error: connect ETIMEDOUT
...+02:00 [Nest] 16 - ... Error: connect ETIMEDOUT
...+02:00 [Nest] 16 - ... Retry time exhausted
...+02:00 /app/node_modules/ioredis/built/Redis.js:207
I provisioned an EC2 instance in the same VPC with the default security group and ssh
d and could redis-cli -h <endpoint> -p <port>
from there without any issues. Could it be private subnets are preventing AR from connecting to ElastiCache? I created an ElastiCache instance in one of the private subnets but couldn't come right when I redeployed AR service.