CloudFormation Template Generator

Scaffold an AWS CloudFormation template by ticking the resources you need — an encrypted S3 bucket, a DynamoDB table, a Lambda function with an execution role, an SQS queue, or an SNS topic. Choose YAML or JSON, and the tool writes a valid template with safe defaults and an Outputs section. Copy it and deploy with aws cloudformation deploy. Generated entirely in your browser.

Resources:
template.yaml

How to use the CloudFormation Template Generator

Choose YAML or JSON — both are valid CloudFormation, and YAML is the more common choice because it supports comments and the short intrinsic functions like !Ref and !GetAtt. Set a stack description, then tick the resources you want. Every resource is named relative to the stack with !Sub "${AWS::StackName}-...", so the same template can be deployed several times under different stack names without clashing.

Copy the template to a file and deploy it with aws cloudformation deploy --template-file template.yaml --stack-name my-stack --capabilities CAPABILITY_IAM (the capability flag is required because the Lambda option creates an IAM role). The generated resources use conservative defaults — block-public-access and encryption on the bucket, pay-per-request billing on the table, a minimal Lambda execution role — which you should review and extend for production. The Outputs section exposes the key identifiers so other stacks or scripts can reference them.

What CloudFormation does

CloudFormation is AWS's native infrastructure-as-code service. You describe the resources you want in a template — a declarative document in YAML or JSON — and CloudFormation creates, updates, and deletes them as a single unit called a stack. Instead of clicking through the console or scripting a sequence of CLI calls, you declare the desired end state and let the service work out the order of operations, wait for dependencies, and roll back automatically if any step fails.

A template has a few top-level sections. Resources is the only required one: each entry has a logical name, a Type like AWS::S3::Bucket, and a Properties block. Parameters let you pass values in at deploy time; Outputs export identifiers such as a bucket name or a queue URL for humans or other stacks to consume. The power comes from intrinsic functions — !Ref to reference another resource or parameter, !GetAtt to read an attribute like a role's ARN, and !Sub to interpolate values into strings — which let resources wire themselves together without hard-coded IDs.

Because a stack is managed as a whole, CloudFormation tracks every resource it created and can tear the entire thing down cleanly, which makes it well suited to reproducible environments and ephemeral test infrastructure. It also detects drift when someone changes a managed resource by hand, helping you keep reality and code in sync. This generator produces a small, correct template with the most common resources so you have a working starting point rather than a blank file, then you extend it with parameters, conditions, and additional resources as the stack grows.

Common use cases

  • New stacks. Start from a valid template with common resources instead of a blank file.
  • Learning CloudFormation. See how resources, intrinsic functions, and outputs fit together.
  • Serverless scaffolds. Generate a Lambda with its execution role and a queue or topic to trigger it.
  • Reproducible test infra. Stand up an encrypted bucket and a table that you can deploy and delete cleanly.

Frequently asked questions

Should I use YAML or JSON for CloudFormation?
Both are fully supported. YAML is usually preferred because it allows comments and the short intrinsic-function syntax (!Ref, !GetAtt, !Sub), which makes templates more readable. JSON is handy when generating templates programmatically. This tool produces either; the resources and behaviour are identical.

Why does deploying need CAPABILITY_IAM?
CloudFormation requires explicit acknowledgement before it creates or modifies IAM resources, as a safety measure. The Lambda option here creates an execution role, so you must pass --capabilities CAPABILITY_IAM (or CAPABILITY_NAMED_IAM for named roles) when deploying, or the operation is rejected.

What do !Ref, !GetAtt, and !Sub do?
!Ref returns the default identifier of a resource or the value of a parameter; !GetAtt reads a specific attribute, such as a role ARN or a queue URL; !Sub substitutes variables into a string, including pseudo-parameters like ${AWS::StackName}. Together they wire resources to each other without hard-coded IDs.

Are the generated defaults production-ready?
They are safe starting points, not a finished design. The bucket blocks public access and enables encryption, the table uses on-demand billing, and the Lambda role is minimal. For production you will typically add parameters, tighter IAM, monitoring, removal policies, and resource-specific tuning. Review every property before deploying.

How do I update or delete the stack later?
Re-run aws cloudformation deploy with the same stack name to apply changes — CloudFormation computes a change set and updates only what differs. To remove everything the template created, run aws cloudformation delete-stack --stack-name my-stack, which deletes the managed resources as a unit (subject to any retention policies you set).