Dedicated subnets are preferred for lambda function association with VPCs?

There is no specific requirement or recommendation to use dedicated subnets for Lambda functions when associating them with a VPC. In fact, Lambda functions can be placed in the same private subnets as other resources like applications or databases.

The key considerations when placing Lambda functions in a VPC are:

1. Ensure the Lambda function has access to the resources it needs to interact with (e.g., databases, other internal services).

2. If the Lambda function needs internet access or needs to call public AWS services, you'll need to set up a NAT Gateway in a public subnet and configure the route table of the private subnet where the Lambda function resides to route internet-bound traffic through the NAT Gateway.

3. If you don't need internet access but still need to access AWS services, consider using VPC endpoints to allow private communication with those services.

4. Make sure the security groups associated with the Lambda function allow the necessary inbound and outbound traffic.

Given these considerations, you can place your Lambda functions in your existing private application subnets if that meets your needs. There's no inherent advantage to creating dedicated subnets just for Lambda functions.

However, if you have specific security or network isolation requirements, or if you anticipate a large number of Lambda functions that might benefit from separate management, you could consider using dedicated subnets. But this is not a general best practice or requirement.

Remember that Lambda functions in a VPC use elastic network interfaces (ENIs), which count towards your ENI limit per subnet. If you're deploying many functions, you might want to spread them across multiple subnets to avoid hitting these limits.
Sources
Connecting a Lambda in a VPC to an api gateway | AWS re:Post
Lambda in RDS VPC needs bi-directional inet access | AWS re:Post
AWS Lambda function not connecting to external services | AWS re:Post