> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Serverless Framework and SAM Guide

> Evaluate serverless deployment tools against all cloud APIs they use, not only the function service.

Serverless Framework and AWS SAM are orchestration tools. Their normal deployment paths commonly use CloudFormation, S3, IAM, Lambda, API Gateway, logs, and sometimes ECR. A supported function or object-storage operation does not make the whole deployment path compatible.

## Separate local and remote evidence

`sam build`, `sam local invoke`, package creation, and Serverless configuration validation can run locally. They are valuable application tests, but they do not prove that Cloud Adapter supports deployment, function management, or invocation in a target environment.

Record each phase separately:

| Phase              | Typical dependencies                                        |
| ------------------ | ----------------------------------------------------------- |
| Build              | Local runtime, package manager, container engine.           |
| Package            | Local files, S3 or ECR for remote assets.                   |
| Deploy             | CloudFormation, IAM, Lambda, S3, API Gateway, logs.         |
| Invoke and observe | Lambda, API Gateway, logs, metrics, tracing.                |
| Remove             | CloudFormation and every service owning retained resources. |

## Capture the real call graph

Pin the CLI and plugin versions, then run a disposable project with SDK/CLI debug logging in an isolated environment. Inventory every AWS service and operation. Check each against the service catalog and document any API the tool calls before it reaches the function resource.

Do not suppress denied or unsupported discovery calls simply to make the command continue. A skipped IAM, stack, or logs operation can produce a deployment that appears successful but cannot be operated or removed safely.

## Minimal compatibility fixture

Once the entire call graph is covered, use one small function with:

* no production data;
* one explicit runtime and handler;
* one simple invocation payload;
* no custom resources;
* no broad IAM policy;
* a unique stack and artifact prefix;
* a documented cleanup owner.

Test package upload, deployment status polling, invocation, logs or diagnostic response, configuration update, failed update, rollback, and removal. Verify the native target resources after every mutating phase.

## SAM-specific cautions

* `sam local` tests a local emulator path, not Cloud Adapter.
* Managed S3 packaging can introduce a bucket and endpoint you did not configure explicitly.
* Guided deployment stores answers for future runs; review the resulting configuration before reuse.
* Container-image functions add ECR operations and image-platform constraints.

## Serverless Framework cautions

* Plugins can add service calls that are absent from the base framework.
* Variable resolvers may call SSM, Secrets Manager, CloudFormation, or other APIs before deployment.
* Deployment buckets and pruning plugins can delete shared artifacts.
* Removal behavior depends on CloudFormation and target retention semantics.

## Choose a smaller first proof

If the full deployment path is not covered, test the supported API directly with an SDK or the [AWS CLI guide](/cloud-adapter/guides/aws-cli). Treat local serverless tests as application evidence, not as Cloud Adapter compatibility evidence.

Use [Testing Your Adapters](/cloud-adapter/local-testing/testing-your-adapters) to define the fixture and [Debugging Your Adapters](/cloud-adapter/debugging/overview) to classify remote failures.