Sunset Sentry AWS Lambda Integration

[Lms24]

Problem Statement

Currently, there are multiple ways how we instruct users to install Sentry SDKs in their AWS Lambda functions, one of them being the Sentry AWS Lambda Integration. This integration is currently un-owned and at least for NodeJS problematic because it does not support ESM-based lambdas. Therefore, the SDK team decided to sunset the integration.

Current state of AWS Lambda setup documentation

- In-product onboarding prmarily recommends and integrates our AWS Lambda Integration   but it also provides a fallback to manual setup (which only shows CJS and NPM package-based setup:  - SDK Docs show our recommended way of using the function: Adding a layer to the Lambda functions and initializing the SDK via environment variables. In JS-ESM specific guides, we recommend an NPM-based approach due to the lack of a functioning ESM Lambda layer. Improving this is tracked in https://github.com/getsentry/sentry-javascript/issues/12856 and out of scope for this issue. Examples: [Node (CJS)](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/install/cjs-layer/), [Node (ESM)](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/install/esm-npm/), [Python](https://docs.sentry.io/platforms/python/integrations/aws-lambda/manual-layer/), [.NET](https://docs.sentry.io/platforms/dotnet/guides/aws-lambda/) (which AFAICT, is not supported in the integration and doesn't publish a layer) - [Cloud Monitoring docs](https://docs.sentry.io/organization/integrations/cloud-monitoring/aws-lambda/) only mention our AWS integration with a few caveats that it doesn't work in certain scenarios (e.g. Node ESM lambdas).

Solution Brainstorm

After an internal discussion, we decided to sunset our AWS Lamda integration.

Why sunset out AWS Lambda integration?

• In its current state, it causes incorrect SDK setups for Node ESM-based lambda functions
• It requires users to add Sentry to AWS Cloud Formation so that the integration gets permissions to add layers. This is especially painful when re-visiting the integration to update layer versions as you need to look up your account id as well as the external cloud formation Id.
• It can't automatically update lambda layers, meaning, updating to a more recent SDK version also requires manual intervention (via the integration UI or in the AWS console)
• It requires users to select a specific region and only looks up available functions within this region. This makes the setup quite cumbersome for multi-region users
• The integration does not support .NET lambda functions at all
• While the idea of being able to set up Sentry in multiple Lambdas at once sounds intriguing, we heavily question the target audience group for whom this is useful:
  • AWS Lambda beginners likely don't have more than a handful of lambdas
  • AWS (Lambda) power users likely use Terraform or related IaC tools to declare their Lambdas
  • Assuming multiple lambdas in different regions, multi-region UX in the integratino is pretty bad (see further above)
  • Related, (At least in JS), there are frameworks and services around AWS lambda which provide their own abstractions to add layers and env variables (e.g. SLS).
• Related, the integration does not permit any kind of SDK configuration. For instance, it always sets a tracesSampleRate of 1.0.

From a user's PoV, the integration therefore:

• conveyed a false sense of "security" as users would assume that setup was successful, when in reality, the integration didn't set up the SDK completely, or at all (e.g. in newly created Node lambda functions which are ESM by default)
• limited functionality: only made initial setup a bit easier (only in some cases)
• made updating the SDK more cumbersome than just bumping the layer in the AWS console
• required special permission via the cloud formation stack. Something that could be more painful than directly adding the layer in the AWS console (depending on org structure and permissions in AWS)

In contrast to the integration, our recommended approaches will show the easiest manual setup path per platform. This usually means adding a Lambda layer and setting environment variables. In special cases (JS ESM, .NET), it currently requires more manual setup/code modifications. But these are required anyway and the integration couldn't have helped us here. Terraform/Lambda abstraction users can simply replace the manual layer and env variable setup with their IaC strategy.

Course of Action

Sunsetting the AWS integration involves multiple steps:

1. Remove our AWS Lambda integration from in-product onboarding
2. Remove docs mentioning our AWS Lambda integration and clean up documentation
   • Prefer AWS layers or direct in-code alternatives
   • Nice to have: provide guidance on Terraform-based setups (?)
3. (Specifics TBD): Hide AWS Lambda integration from newly created projects/orgs
   • Is there precedence with other integrations we can base this step on?
4. Eventually completely remove AWS Lambda integration

Once we pick this up, we can extract these steps into dedicated sub issues

Customer Impact

• For customers who used the integration before, they likely only use it sporadically when (1) adding Sentry to new Lambda functions or (2) updating layers. Both cases don't work well with the integration as outlined above.
  • We will send out comms informing integration users of the sunset (which is also a possibility to revisit, if we get feedback that the integration is immensely helpful for someone)
• For new customers, the sunset is good because it removes a lot of ambiguity how to set up Sentry in AWS Lambda. Showing a good manual setup strategy is better than showing 3 different docs around a semi-working "automatic" setup.
• As outlined above, power users who rely on terraform or other IaC likely didn't use the integration at all

Product Area

Integrations, Onboarding, SDK Docs, Product Docs

[Lms24]

Migration Path

What happens when moving away from a Lambda function that was originally instrumented via the integration to manually upgrading and managing the lambda layer

1. Created a new org and new project in Sentry
2. Created a new AWS Lambda function in the AWS console.
3. Converted it to CJS and verified that it's still executed correctly
4. Added Sentry via the integration
   • welp, tried to add sentry via the integration but it simply did nothing :( No layer was added and neither were env variables set :(
   • so instead, I just added the layer manually to simulate what the integration should do
5. Sent an error and trace to Sentry to verify correctness
6. Removed the AWS Lambda integration from my new org
7. Error and trace were still sent correctly
8. updated to another layer in AWS console
9. Error and trace were still sent correctly

[bruno-garcia]

btw we didn't bother adding AWS support in .NET because most .NET ppl use Azure. We added GCP early on because it was like 10 lines of code, but adoption is extremely low.