Skip to main content
Hi everyone — welcome to the next lesson, focused on CloudFormation resources. CloudFormation resources are the central elements of a CloudFormation template. They declare the AWS services and objects that CloudFormation will create and manage — for example, Amazon EC2 instances, Amazon S3 buckets, AWS RDS databases, and Amazon DynamoDB tables. At a high level, each resource definition specifies:
  • a logical ID (the template-local name you reference),
  • a resource Type (for example, AWS::S3::Bucket or AWS::EC2::Instance),
  • and optional Properties that configure how CloudFormation should create the resource.
When you submit a template, CloudFormation analyzes resource references and dependencies, determines a safe create/update/delete order (honoring explicit DependsOn or implicit references), and provisions resources accordingly.
A CloudFormation resource block generally contains:
  • A logical ID (the template identifier you use with intrinsic functions),
  • Type (the AWS resource type),
  • Properties (resource-specific configuration),
  • Optional fields like DependsOn, Metadata, DeletionPolicy, UpdatePolicy, and Condition.

​
Resource anatomy (YAML example)

This concise example shows an S3 bucket and a bucket policy that depends on the bucket. It demonstrates logical IDs, the Type field, Properties, intrinsic functions (!Ref and !Sub), and an explicit DependsOn to control creation order. 
Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-example-bucket

  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    DependsOn: MyS3Bucket
    Properties:
      Bucket: !Ref MyS3Bucket
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Sid: PublicReadGetObject
            Effect: Allow
            Principal: "*"
            Action: "s3:GetObject"
            Resource: !Sub "arn:aws:s3:::${MyS3Bucket}/*"
Key takeaways from the example:
  • MyS3Bucket is the logical ID used elsewhere in the template (for example, with !Ref or !GetAtt).
  • Type identifies the AWS resource type (here AWS::S3::Bucket and AWS::S3::BucketPolicy).
  • Properties contains the resource-specific configuration.
  • DependsOn ensures CloudFormation creates MyS3Bucket before MyBucketPolicy.
  • !Ref returns the referenced resource value (often the resource name or ID). !Sub composes ARNs or other strings with variables.

​
Creation order, dependencies, and references

CloudFormation automatically orders operations when it can detect implicit references (e.g., when one resource property references another). Use DependsOn for explicit ordering when:
  • implicit references are not detected, or
  • you need strict control over resource creation order.
Common intrinsic functions and how they connect resources:
Intrinsic FunctionUse CaseExample
!RefReturns a resource’s reference value (name or ID)Bucket: !Ref MyS3Bucket
!GetAtt (Fn::GetAtt)Retrieves a specific attribute (ARN, endpoint, etc.)Endpoint: !GetAtt MyLoadBalancer.DNSName
!SubSubstitutes variables into strings (useful for ARNs)Resource: !Sub "arn:aws:s3:::${MyS3Bucket}/*"
Use these functions to wire resources together so CloudFormation understands dependencies and ordering.

​
Optional resource fields worth noting

These fields help control lifecycle behavior, attach metadata, or gate resource creation. Use them to fine-tune how CloudFormation manages resources.
FieldPurposeCommon Values / Notes
DependsOnExplicit creation orderName or list of logical IDs
MetadataArbitrary structured data attached to the resourceUseful for tooling or configuration data
DeletionPolicyControl behavior on stack deletionDelete, Retain, Snapshot (for RDS/EBS)
UpdatePolicyRolling update / replacement behaviorUsed with AutoScaling/EC2/ELB updates
ConditionCreate resource only if condition is trueReferences Conditions defined at template top
Be cautious when renaming a resource’s logical ID. CloudFormation treats a renamed logical ID as a new resource and will create a replacement and delete the original (unless a DeletionPolicy prevents deletion), which can result in data loss or downtime.

​
Best practices and tips

  • Always use meaningful logical IDs — they’re referenced by other resources and appear in change sets.
  • Favor intrinsic functions over hard-coded values to keep templates reusable.
  • Use Conditions to create environment-specific resources (dev vs prod).
  • Apply DeletionPolicy for stateful resources (S3, RDS) to avoid accidental data loss.
  • Test changes using Change Sets to preview resource replacements and deletions.

​
Summary

  • Resources are the core building blocks of a CloudFormation template.
  • Each resource requires a logical ID, a Type, and typically a Properties block.
  • Connect resources with intrinsic functions (!Ref, !GetAtt, !Sub) so CloudFormation can determine dependency order.
  • Use DependsOn for explicit ordering, and DeletionPolicy/UpdatePolicy/Metadata/Condition to manage lifecycle and behavior.
This lesson introduced CloudFormation resources, their structure, and how to connect and manage them inside templates. Subsequent material covers common resource types and practical multi-resource templates.

Watch Video