No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

re: concurrency <https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html>
I haven't use it in pulumi yet but I assume there's a property to set those limits

re 3)  we did setup with pulumi
this <https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html>

4) yes <https://aws.amazon.com/about-aws/whats-new/2019/11/aws-lambda-supports-max-retry-attempts-event-age-asynchronous-invocations/>

Thank you very much! I’ll start reading this right away!

By the way, is there any good practice for folder structuring? Where would you define each piece of infra and domain logic

There's a few old chats on the subject, the key points where everyone seem to agree are:

• keep things that change at the same rate together
• better to have multiple stacks/projects than a monolithic one

I have :
• functions with app code and infra folder, that's one pulumi project
• frontend - with its own infra (S3+cloudfront+route 53) 
• infrastructure with everything else (VPC, cognito, sqs, codebuild/pipeline)

Arguably I can split further, especially the codepipeline seems a bit out of place.

So you split your folder per “features” and inside each feature you have the infra and the app code?

For example:

```root/
├─ frontend/
│  ├─ infra/
│  │  ├─ index.ts
│  ├─ src/
├─ backend/
│  ├─ infra/
│  │  ├─ index.ts
│  ├─ src/
├─ shared-infra/
│  ├─ index.ts```

then inside share infra I have

/route53
/sqs
/dyanamo
/etc

<@U01Q0T99P88> I see. How does Pulumi know to look for the `index.ts` inside infra?

There's a 'main'  property in the Pulumi.yaml, set it to the folder name