About SSM Parameter resolution in a template

[claudevandort]

Description:

I've seen several issues about or related to SSM Parameter resolution in sam local, although I'm rather confused since one issue answer says that SSM Parameters are not supported by the SAM CLI, but this other one says SSM Parameters get resolved in the root template (and not in child templates if you have).

After trying on my own I notice that SSM Parameters are not resolved at all by the SAM CLI locally, is this a bug or intended behavior? if so, why?

[dcabib]

Hey @claudevandort! 👋

Great question, and yeah, I can totally see why you're confused - those two issues you referenced are kinda talking past each other.

TL;DR: In my point of view, SAM CLI doesn't resolve SSM parameters at all when running locally. It's not a bug, it's intentional.

Here's the deal:

When you run sam local, it's designed to work completely offline - no AWS API calls needed. SSM parameters live in AWS, so to resolve them, SAM would need to:

1. Have AWS credentials configured
2. Make actual SSM API calls
3. Handle rate limits, permissions, etc.

That's not really the vibe for local development, you know? The whole point is to test stuff quickly without hitting AWS.

What's actually happening:

When SAM CLI processes your template parameters, it just looks for the Default value in your Parameters section. That's it. No fancy SSM resolution, no API calls - just grabs whatever's in Default and moves on.

If there's no Default value, it'll try to use the parameter name as-is, which is why you see those weird errors like trying to use /development/mem as a number (spoiler: doesn't work 😅).

The confusion in those issues:

• Issue #2743: Correctly says "SAM CLI doesn't support this" ✅
• Issue #2763: The maintainer said params get "resolved in the root template" but that's kinda misleading - they meant SAM reads the Default value from the root template, NOT that it actually resolves SSM parameters

Your workaround options:

Option 1: Use parameter overrides (easiest)

sam local invoke --parameter-overrides "ParamName=ActualValue"

Option 2: Add Default values to your template

Parameters:
  MySSMParam:
    Type: AWS::SSM::Parameter::Value<String>
    Default: "some-local-test-value"  # Add this for local testing

Option 3: Need real SSM values? Deploy to AWS and use sam remote invoke instead - that'll actually hit your deployed Lambda and resolve SSM params for real.

Bottom line:

This isn't a bug - it's by design. SAM local = offline testing. SSM params = AWS service. They don't mix.

If you think SAM should support SSM resolution for local testing (like, optionally with credentials), that'd be a feature request rather than a bug report. But honestly, the --parameter-overrides approach works pretty well for most folks.

Hope this clears things up! Let me know if you have any other questions 🙂