We recently migrated a .NET Core application from .NET 8 to .NET 10 and moved its hosting model from AWS Lambda to ECS. The service acts as a wrapper around a downstream API that reads and updates client “fact find” data.

Post-migration, we started seeing critical issues:

Users were seeing other users’ data

Updates were being applied to the wrong clients

Users could access data they shouldn’t have permission to see

This was a data isolation failure. The root cause turned out to be a misuse of a singleton combined with differences in execution models between Lambda and ECS.

Architecture Context

The service:

Accepts user requests

Adds headers (auth/user context)

Calls a downstream API

Returns processed responses

A shared configuration object ( ConnectionOptions ) was introduced to manage headers for outbound calls.

This object:

Was registered as a singleton

Was mutated per request to inject headers

Why It “Worked” on Lambda

AWS Lambda has a different execution model:

Each invocation typically…