Advanced 15 min read

Managing Resource Dependencies

By the end of this lesson, you'll be able to:

  • Explain how a reference between resources creates an implicit dependency CloudFormation can infer
  • Explain when an explicit dependency declaration is actually needed, versus being unnecessary
  • Read a simple example of one resource referencing another

Prerequisites: "Stacks, Parameters, and Outputs"

References: one resource pointing at another

Templates frequently need one resource to use a value that another resource produces — an application resource that needs a Security Group's identifier, for example. The mechanism for this is a reference (commonly !Ref, and for retrieving a resource's specific attribute rather than its main identifier, !GetAtt). Rather than a person manually copying a generated identifier from one resource into another after the first one is created, the template just references it, and CloudFormation resolves that reference automatically once the referenced resource actually exists.

References imply dependencies — CloudFormation infers them

Diagram showing an application resource referencing a Security Group, with a note that CloudFormation infers from this reference alone that the Security Group must exist before the application resource, without a separate explicit dependency declaration.
CloudFormation infers this dependency from the reference itself — an explicit declaration is for the rarer cases a reference doesn't already cover, not everywhere.

This matters practically: when one resource references another, CloudFormation already knows the referenced resource has to exist first — it doesn't need to be told separately. This is a direct, template-level example of the same idea Module 9 introduced for ECS deployments: dependencies between pieces of infrastructure are a real thing to reason about, and here, a reference is usually enough to express one correctly.

Explicit dependencies: for the cases a reference doesn't already cover

An explicit dependency mechanism does exist, for situations where one resource genuinely needs to wait for another but doesn't reference any of its values directly — so CloudFormation has no reference to infer the relationship from. This lesson deliberately doesn't turn this into a rule to apply everywhere: adding an explicit dependency to every resource "just in case" adds unnecessary complexity and coupling to a template without a real reason. Use one when a reference genuinely doesn't already express the relationship that exists — not as a defensive habit.

Exercise

A template has an application resource whose configuration includes a reference to a Security Group resource's identifier. A teammate suggests also adding an explicit dependency declaration between the two "just to be safe." Using this lesson's reasoning, explain whether that's actually necessary, and why.

Show hint

The reference itself already tells CloudFormation about the relationship — think about what an extra explicit declaration would actually add here.

Managing Resource Dependencies Quiz

1. A template resource references another resource's identifier using !Ref. What does CloudFormation do with this information?

2. An explicit dependency declaration should be added to every resource in a template as a defensive habit.

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

When one resource in a template references another — using a mechanism like !Ref — CloudFormation infers from that reference alone that the referenced resource must exist first, without needing an explicit dependency declaration for that case; explicit dependency declarations exist for the rarer situations a reference doesn't already cover, not as something to add to every resource by habit.