Workload discovery failing - getting "Not Discovered" for configured region - DNS errors

[mmigliari]

The WebUI works fine.

However, when I add the account and the default region I use, It stays stuck in "Not discovered".

Uppon checking the logs for the ECS scheduled task that runs every 15 minutes, I get the following error:

`
{
"errors": [
{
"path": [
"getRelationships"
],
"data": null,
"errorType": "Lambda:Unhandled",
"errorInfo": null,
"locations": [
{
"line": 3,
"column": 7,
"sourceName": null
}
],
"message": "getaddrinfo EAI_AGAIN neptunedbinstance-uajoduxukoed.asdasdasdasd.us-east-1.neptune.amazonaws.com"
}
],
"query": "\n query getRelationships($pagination: Pagination) {\n getRelationships(pagination: $pagination) {\n target {\n id\n label\n }\n id\n label\n source {\n id\n label\n }\n }\n}",
"variables": {
"pagination": {
"start": 0,
"end": 2500
}
},
"level": "error",
"message": "Error executing gql request",
"timestamp": "2024-10-03T21:30:53.891Z"
}

then

{
"msg": "[{"path":["getRelationships"],"data":null,"errorType":"Lambda:Unhandled","errorInfo":null,"locations":[{"line":3,"column":7,"sourceName":null}],"message":"getaddrinfo EAI_AGAIN neptunedbinstance-uajoduxukoed.asdasdasdasd.us-east-1.neptune.amazonaws.com"}]",
"stack": "Error: [{"path":["getRelationships"],"data":null,"errorType":"Lambda:Unhandled","errorInfo":null,"locations":[{"line":3,"column":7,"sourceName":null}],"message":"getaddrinfo EAI_AGAIN neptunedbinstance-uajoduxukoed.asdasdasdasd.us-east-1.neptune.amazonaws.com"}]\n at /code/src/lib/apiClient/appSync.js:57:33\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async Object.getDbRelationshipsMap (/code/src/lib/utils.js:174:24)\n at async Promise.all (index 1)\n at async discoverResources (/code/src/lib/index.js:19:69)\n at async discover (/code/src/index.js:15:3)",
"level": "error",
"message": "Unexpected error in Discovery process.",
"timestamp": "2024-10-03T21:30:53.892Z"
}
`

i.e. its giving a DNS resolving error on the neptune endpoints.

My dev machine is in the same VPC via VPN, and I've setup the security groups permissively for neptune. I resolve just fine when I do a "telnet endpoint 6174".

The route table of the subnets where everything was setup has a NAT gateway.

This is driving me nuts and I'm almost giving up on this solution. Can someone assist?

[mmigliari]

@svozza can you lend a hand?

[svozza]

Ah sorry, I missed this! Is the solution running it a pre-existing VPC?

[mmigliari]

Yes, on an existing VPC

…

On Fri, 4 Oct 2024 at 10:32 Stefano Vozza ***@***.***> wrote: Ah sorry, I missed this! Is the solution running it a pre-existing VPC? — Reply to this email directly, view it on GitHub <#553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVNXFHY7X772TB6EXKHGUXDZZ2KG5AVCNFSM6AAAAABPKVLQIGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBUGQ2DQMI> . You are receiving this because you authored the thread.Message ID: <aws-solutions/workload-discovery-on-aws/repo-discussions/553/comments/10844481 @github.com>

[svozza]

Hmm, could be any number of things. Can you email me at my-github-username@amazon.com as I'd rather not ask you intimate questions about your VPC configuration in public. :)

[mmigliari]

Email sent! Thank you for your kindness

[mmigliari]

Hi @svozza just to give you feedback. I managed to resolve the issue, and this might be worth modifying the gremlin lambda cloudformation template.

I added an outbound rule to the lambda's security group for UDP port 53 on 0.0.0.0/0 CIDR. This is to allow for outbound DNS lookups. It worked. You may want to revise the CloudFormation template for this.

Thanks for all your assistance btw!

[svozza]

Oh wow, that's very interesting! Did the discovery process run successfully after you made the change?

[mmigliari]

yup!