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
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
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.