AWS CodeBuild构建阶段出现SINGLE_BUILD_CONTAINER_DEAD错误的排查咨询

Let’s break down your issue and walk through the most likely causes, starting with the most probable:

1. Out-of-Memory (OOM) is the Primary Suspect #

The error message explicitly calls out "out of memory" as a top cause, and this aligns perfectly with your scenario: you’re deploying 7-10 Lambda modules in a single build run, and the issue started randomly (a classic sign of gradual resource creep). Here’s why this makes sense:

• Dependency bloat: Over time, your Lambda functions might have added new npm dependencies, or the versions you’re installing (including serverless@${SERVERLESS_VERSION}) could have grown in size or memory footprint.
• Concurrent operations: Your install.sh and deploy.sh scripts might be handling multiple functions in parallel (e.g., installing dependencies for all functions at once or deploying several Lambdas simultaneously). This can spike memory usage beyond your CodeBuild container’s limits.
• Default resource limits: If you’re using the default CodeBuild instance type (build.general1.small with 3GB memory), this might no longer be enough for your expanded deployment workflow.

To validate this:

• Check your CodeBuild logs for any mentions of OOM killer or explicit memory exhaustion messages.
• Temporarily switch your CodeBuild project to a larger instance type (e.g., build.general1.large with 7GB memory) and see if the error stops occurring.

2. AWS Policy/Service Changes Are Unlikely But Worth Checking #

While far less probable, there are a couple of service-related angles to consider:

• End-of-life runtime deprecation: Node.js 10 reached end-of-life in April 2021, and AWS has been phasing out support for older runtimes. It’s possible the underlying CodeBuild container image for Node.js 10 was updated recently, introducing subtle resource compatibility issues or stricter resource limits.
• CodeBuild container updates: AWS occasionally updates the base images used for CodeBuild containers, which could change how memory is allocated or managed. However, these updates are usually announced, and breaking changes are rare for stable, existing workflows.

3. Other Potential Triggers #

• Script modifications: If you’ve updated install.sh or deploy.sh recently (even small changes), they might now include more memory-intensive operations (e.g., additional build steps, unoptimized asset packaging, or parallelization that wasn’t there before).
• Serverless version changes: If ${SERVERLESS_VERSION} is set to a recent update, the new version might have bugs or increased memory usage that’s causing the container to crash. Try pinning to the exact serverless version that worked reliably last month to test this.
• Temporary file buildup: Over time, cached dependencies or temporary build artifacts could be consuming disk space, which can indirectly impact memory availability in containerized environments.

Recommended Next Steps #

1. Verify memory limits first: Upgrade your CodeBuild instance size temporarily to rule out OOM issues—this is the fastest way to confirm the root cause.
2. Audit recent changes: Check if any updates were made to your deployment scripts, dependency versions, or Lambda function code in the weeks before the error started.
3. Test single-function deployments: Deploy just one Lambda at a time instead of all 7-10. If the error goes away, you’ll know the problem is related to concurrent resource usage.
4. Upgrade Node.js: Since Node.js 10 is no longer supported, migrating to a newer runtime (like Node.js 18, which is fully supported by Lambda) will not only resolve potential compatibility issues but also give you access to better memory management features.

内容的提问来源于stack exchange，提问作者hüseyin Armağan