Improve AWS Lambda experience

[Lms24]

I investigated AWS lambda support in the last couple of days and found multiple issues we should tackle to improve the SDK/Usage experience with our @sentry/aws-serverless SDK and AWS Lambda layer:

### General AWS Lambda Support
- [ ] #12392
- [ ] #12407
- [ ] https://github.com/getsentry/sentry-javascript/pull/12430
- [ ] Docs: Remove "Container Image" guide in favour of better Lambda Layer guide

### ESM Lambda Support
- [ ] Ensure SDK works in ESM and manual setup (WIP)
- [ ] Docs: Document how to use Sentry with ESM lambda functions
- [ ] Investigate why Otel AwsLambda instrumentation doesn't work in ESM

### Nice to Have
- [ ] Once auto instrumentation works in ESM create an ESM lambda layer (https://github.com/getsentry/sentry-javascript/issues/12322)
- [ ] Once layer is available, adjust Sentry integration to auto-add layer

[G-Rath]

Not sure if you're already tracking this or what, but fwiw it looks like switching to @sentry/aws-serverless adds an extra 2.2mb to my lambdas - it doesn't sound like a stated or expected goal, and I imagine some "new" size is in new feature stuff, but it still feels like a weird jump given https://github.com/getsentry/sentry-javascript/pull/11052 says "removes all GCP related code".

Something else I find telling is that installing @sentry/serverless only adds 19 packages whereas @sentry/aws-serverless adds 82 on my project apparently - again, not the end of the world and I've not done any digging, but thought you might be interested 🙂

The lambdas themselves are typescript based, compiled with serverless v3 + tsc as per https://github.com/ackama/serverless-aws-template

[Lms24]

@G-Rath the increase in dependencies and size is caused by us switching to OpenTelemetry for instrumentation. By default, the our AWS Serverless SDK does not include performance instrumentation (e.g. for databases like postgres). However, if you only use tsc to build your functions I'm fairly sure that some unused code and dependecies are not tree-shaken out. Meaning your build might be larger than it has to be.

Have you looked into bundlers like rollup? they should be able to tree-shake out all unused code.

That being said, I have never heard of sls before so not sure if it does any optimizations under the hood. My reference is basically manually zipping up a lambda function including its node_modules and deploying it with the AWS CLI. In this workflow, I know for sure that no code elimination is done at all.

[G-Rath]

@Lms24 thanks for following up so quickly, and sorry for my delay in responding.

You're right that neither tsc or sls do treeshaking - so far we've not used any tree shaking for our serverless functions as they're small enough, fast enough, and non-critical in their current form, and everytime I've looked at bundler integrations for serverless they've always seemed overly complex relative to that; totally accept those that downside is by our choice so if you've focused on optimizing size based on treeshaking that's fair (though I'm still a little sad that "us switching to " has resulted in such a huge leap but oh well that is what it is).

I have never heard of sls before so not sure if it does any optimizations under the hood

sls is the short cli command for the serverless framework - the main optimization v3 does out of the box is allow you to exclude whole files but that's part of the whole "you're not treeshaking" thing since it lets you axe "not javascript" kind of files emass rather than anything surgical.

(on an aside, it's a great way to get that "eehhh wat" feeling as you go through the list of file extensions in your node_modules - you (won't) be surprised at what stray files get captured in published packages...)