Skip to main content
Hi everyone — in this lesson we cover access control for CloudFormation stack actions: the core IAM permissions you grant to create, modify, or delete CloudFormation stacks, and the complementary service-level permissions CloudFormation needs to provision resources defined in your templates. Why this matters: granting CloudFormation stack actions alone lets principals operate on stacks, but templates frequently create or modify AWS resources (S3, EC2, IAM, etc.), so you must also grant the appropriate service permissions for those resources.
  • CloudFormation stack lifecycle actions control stack operations.
  • Service-specific permissions (S3, EC2, IAM, etc.) are required for the template to succeed.
  • Use least-privilege: scope actions and resources narrowly and only grant what is necessary.
Table: Primary CloudFormation stack actions
Action (IAM)PurposeTypical use case
cloudformation:CreateStackCreate a new stack and start provisioningDeploy a new application stack from a template
cloudformation:UpdateStackApply updates to an existing stackChange configuration or resource types in an existing stack
cloudformation:DeleteStackDelete a stack and remove its resourcesTear down environments or test stacks
CloudFormation actions control stack lifecycle operations, but templates execute service-specific APIs. Ensure you also grant the required service permissions (for example, S3, EC2, IAM) so CloudFormation can create or modify the underlying resources.
A slide titled "Access Control for CloudFormation Stack Actions" showing three actions — Create, Update, and Delete — each with a short description of what users can do and the corresponding IAM permissions (cloudformation:CreateStack, cloudformation:UpdateStack, cloudformation:DeleteStack).
Example IAM policy Below is a practical IAM policy that combines CloudFormation stack permissions with a minimal set of service-level actions for S3 and EC2, plus an iam:PassRole entry when CloudFormation needs to assume an execution role. This demonstrates the common pattern of pairing CloudFormation actions with the underlying AWS service permissions your templates require. 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudFormationStackActions",
      "Effect": "Allow",
      "Action": [
        "cloudformation:CreateStack",
        "cloudformation:UpdateStack",
        "cloudformation:DeleteStack",
        "cloudformation:DescribeStacks",
        "cloudformation:ListStackResources"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3AndEC2Permissions",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:PutObject",
        "s3:PutBucketPolicy",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PassRoleIfNeeded",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": "arn:aws:iam::123456789012:role/CloudFormationExecutionRole"
    }
  ]
}
Notes on the example
  • cloudformation:DescribeStacks and cloudformation:ListStackResources are useful read-only actions so users can inspect stack status and the resources a stack manages.
  • iam:PassRole: many templates create or configure resources that require an IAM role to be passed—PassRole must permit passing exactly the roles CloudFormation will use. Scope PassRole to specific ARNs for least privilege.
  • Replace Resource ”*” with the smallest possible scope in production. Ideally, lock permissions down to specific stack ARNs, S3 bucket ARNs, or EC2 instance tags as applicable.
Recommended service permission examples
ServiceCommon actions you might needNotes
S3s3:CreateBucket, s3:PutObject, s3:PutBucketPolicyRestrict to bucket ARNs and required prefixes
EC2ec2:RunInstances, ec2:TerminateInstances, ec2:CreateTagsRestrict AMI IDs, instance profiles, and subnet/resource ARNs where possible
IAMiam:PassRoleScope to the exact role ARNs used by CloudFormation
Deleting a stack (cloudformation:DeleteStack) is destructive: it removes resources created by the stack. Grant delete permissions only to trusted principals and consider safeguards such as service control policies (SCPs), approval workflows, or MFA-protected operations.
Best practices and tips
  • Least privilege: scope both actions and Resource ARNs narrowly. Avoid ”*” in production.
  • Pair stack actions with service-level permissions your templates require; review templates to determine exact permissions.
  • Use CloudFormation execution roles (and explicit iam:PassRole permission) to centralize the credentials CloudFormation uses to create resources.
  • Use Describe/List operations to let operators inspect stacks without granting destructive actions.
  • Consider implementing guardrails with AWS Organizations SCPs, AWS Config rules, or manual approvals for destructive operations.
Links and references Summary
  • Use cloudformation:CreateStack, cloudformation:UpdateStack, and cloudformation:DeleteStack to control stack lifecycle.
  • Always grant the necessary service-level permissions (S3, EC2, IAM, etc.) that your CloudFormation templates require.
  • Enforce least privilege: scope actions and resources narrowly, and grant iam:PassRole only for the specific execution role(s) CloudFormation will use.

Watch Video