Template anatomy

Resources, and the sections around them.

Beginner12 min · lesson 2 of 12

A CloudFormation template is a structured document — YAML (preferred, readable) or JSON — with a fixed set of top-level sections. Only Resources is required; the rest are optional scaffolding around it. Resources is where you declare each AWS resource by a logical ID, its Type (the AWS resource kind), and its Properties. References between resources build the dependency graph, exactly like other IaC tools.

template.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: A logging bucket with versioning
Resources:
LogsBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: acme-logs-prod
VersioningConfiguration:
Status: Enabled
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true

The sections around Resources

The optional sections make a template reusable and expressive: Parameters take input at deploy time, Mappings are lookup tables (e.g. AMI per region), Conditions gate whether resources are created, Outputs export values (and can be imported by other stacks), and Metadata/Transform add tooling hints and macros. You will meet each, but the mental model is: Resources is the what, everything else shapes how it is parameterized and wired.

Template sections
required
Resources
the AWS resources to create
common optional
Parameters
deploy-time inputs
Mappings / Conditions
lookups + gating
Outputs
export values
Transform
SAM / macros
Start with Resources; add sections as the template needs inputs, logic, or exports.
Prefer YAML, and validate before deploy
YAML templates support comments and short-form intrinsic functions (!Ref, !Sub) that make them far more readable than JSON. Whatever you write, run aws cloudformation validate-template (and cfn-lint) before deploying — a template that is syntactically valid can still be caught early for bad references and property types, saving a failed stack and a rollback.