Unable to fetch paramters (Param Value) from parameter store for this account

Question

I get the error:

$ aws cloudformation deploy --template-file ./packaged-stack.yml --stack-name mystackname --capabilities CAPABILITY_NAMED_IAM`


An error occurred (ValidationError) when calling the CreateChangeSet operation: Unable to fetch parameters [XXX] from parameter store for this account.

What is wrong here?

The weird thing is XXX is the value from paramter store, so CloudFormation is actually able to get the value ... but it seems like its trying to read from the paramter whose name is the value it got out ... I think my usage is incorrect?

AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: '...'

Parameters:
  BaseStack:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /some/thing/baseStack

The value stored in /some/thing/baseStack is XXX in this example

Incogitant

Could this be a rights problem forums.aws.amazon.com/thread.jspa?messageID=804038 ? – Carse

I'm running into the same problem. Have you been able to figure this out? – Teleprinter

Sorry to bother you, did you got this figured out, @JiewMeng. Thank you. I encountered a similar issue when deploy an AWS tutorial -aws.amazon.com/blogs/compute/… (and github.com/aws-samples/aws-sar-lambda-publish-amazonmq) Thank you! – Argueta

Answer 1

This usually happens when you pass the parameters from one template to another.

Template 1 has parameter reading from SSM store and passing it to another template

Parameters:
  SNSTopicArnParam:
    Description: Arn of the SNS topic
    Type: AWS::SSM::Parameter::Value<String>
    Default: /arn/topics/topic1
Resources:
  CallOtherStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: someurl/template2.yaml
      Parameters:
        SNSTopicArn: !Ref SNSTopicArnParam

And Template 2 has the following parameter and resources (will be erroring with the Unable to fetch parameters error.)

Parameters:
  SNSTopicArnFromCaller:
    Description: Arn of the SNS topic
    Type: AWS::SSM::Parameter::Value<String>
    Default: /arn/topics/topic1
Resources:
  NewSubscription:
    Type: AWS::SNS::Subscription
    Properties:
      Parameters:
        TopicArn: !Ref SNSTopicArnFromCaller
        Endpoint: someValue
        Protocol: SQS

This is because the template one would have the value of /arn/topics/topic1 (the arn of the topic) and pass the arn value to template2 while calling it. And template2 has the type of the value as another SSM parameter.

To resolve this, the template2 parameter type should be just the type of the actual parameter value. In this case, it should be String

so, template 2 should be updated as below to work properly

Parameters:
  SNSTopicArnFromCaller:
    Description: Arn of the SNS topic
    Type: String
Resources:
  NewSubscription:
    Type: AWS::SNS::Subscription
    Properties:
      Parameters:
        TopicArn: !Ref SNSTopicArnFromCaller
        Endpoint: someValue
        Protocol: SQS

Kannry

Answer 2

We had a similar issue and found that we hit this issue when updating the definition of the parameter.

Our situation was:

Created stack with parameter StageName with type String default Dev.

We then moved to using the parameter store and updated the parameter definition to be of type AWS::SSM::Parameter::Value and default with the parameter store path.

When calling the update stack, Cloudformation was reading the existing value 'Dev' and passing this in as the default to the parameter and so it was then looking for the parameter store value at path Dev. Obviously this didn't exist and resulted in the error:

An error occurred (ValidationError) when calling the CreateChangeSet operation: Unable to fetch parameters [Dev] from parameter store for this account.

The easiest fix for us was to delete the stack and recreate but can see this being a problem for others. If anybody has a better 'upgrade' method it would be good to find out.

We were deploying using sam deploy for a Lambda so not sure if this applied to update-stack for other stacks.

UPDATE**

I tried recreating this via create/update stack but failed so it looks like this issue is restricted to the pacakge/deploy upgrade mechanism

Godspeed

Answer 3

it seems that updating a stack will not update the default value for the stack parameters. if you want to update the default value, you need to rename the parameter and then update the stack. once that works, you can immediately rename the parameter back.

side note: if you just want "local variables" or "config" data in a cloudformation yaml, just use the mappings section to store config rather than parameter defaults. honestly, this behavior of parameter defaults is so unintuitive, we just forbid them entirely in our codebase.

Underage

This was the simplest answer and it worked best for me (changing the name back was not required in my case). – Broddy

Great! This is a quick and efficient fix. Thank you! I prefer to do this rather than deleting and recreating the stack as I've been doing before and SteveB suggests. – Trinette

This was my fix too! I was baffled why this behaviour only happened in one environment/account. – Centi

Answer 4

I had the same issue. Updated an existing stack set instance parameter from a string to a parameter store lookup and the stack instance update failed for one of three accounts with error Unable to fetch parameters ['string'] from parameter store for this account. Unfortunately, due to the fact that these instances were in production accounts, deleting and redeploying was not an option.

I opened a support case with AWS and they agreed with the diagnosis in this thread. The following was the suggestion, which worked.

1. Update the stuck stack instance while specifying a parameter list but with no parameter values. This should reset the parameters back to the StackSet defaults.
   • I did this successfully with the following AWS CLI command: aws cloudformation update-stack-instances --stack-set-name stack-set-name --accounts "############" --regions us-east-1 --parameter-overrides
2. Attempt to update the stack instance again with the desired parameters.

In my case I did not need to perform step 2 because I wanted to use the default value of the parameters. Others may need to pass desired parameters in this second step.

Hope this helps.

Hurtle

Answer 5

When using nested stacks the param Type must be String as the Ref to the parameter in the main stack would result in being a String

main template -> root stack

"Parameters": {
  "MyParam": {
    "Description": "My description",
    "Type": "AWS::SSM::Parameter::Value<String>"
  }
}
...
"MyNestedStack": {
  "Type": "AWS::CloudFormation::Stack",
  "Properties": {
    "Parameters": {
      "MyParamFromMain": { "Ref": "MyParam" }
    }
  }
}

2nd template -> nested / child stack

"Parameters": {
  "MyParamFromMain": {
    "Description": "My description",
    "Type": "String"
  }
}

Febrific

Answer 6

For anyone using cross account CDK Pipelines who may find this: make sure you are referencing parameters in the correct account.

We have numerous complex cross account CICD pipelines and was seeing

Unable to fetch parameters [<parameter_name>] from parameter store for this account.

Turns out I was accidentally deploying a stack to the incorrect env (the wrong account) in a Stage.

Bodrogi

Answer 7

I encountered this issue while changing the type of the parameters from Type: String to Type: AWS::SSM::Parameter::Value<String> in an existing stack template.

If you are unable to delete the stack in case you have stateful resources like s3 buckets, a simpler workaround would be renaming the Parameter names in the CloudFormation template (e.g. AccountId -> AccountId2) and deploy(update) the stack and after successful update (new resources with new logical id should have created), rename parameters again to correct logical id AccountId2 -> AccountId) and update the stack again!

Trichromatism