Shared Resources Depends On

CloudFormation has a concept of the DependsOn Attribute. Normally, you do not have to use it as CloudFormation is smart enough to figure out how to sequence the creation of the dependent resources most of the time. For example, if you are creating a Route53 Record that’s connected to ELB, CloudFormation knows to create the ELB before proceeding to create the Route53 record. There are times though when you need to specify the DependsOn attribute to control the creation order explicitly.

Jets creates most of the resources for you via Nested CloudFormation stacks. Shared Resources themselves are nested stacks. Sometimes you want to create resources in different nested stacks and one of them dependent on the other. This is a case where the DependsOn attribute is required.

The Jets::Stack DSL makes managing dependencies between nested stacks simple with the depends_on declaration. In addition to setting up the DependsOn attribute between the nested stacks appropriately, Jets also passes the Outputs of the independent stack to the dependent stack so that it has access to the resources. An example helps explain this.

DependsOn Example

Let’s say we wanted to create a CloudWatch Alarm and an SNS Alert and organized them in different classes. The CloudWatch Alarm depends on the SNS Alert. So the SNS Alert needs to be created before the Alarm. Here’s how we achieve this with the depends_on declaration.

app/shared/resources/alert.rb:

class Alert < Jets::Stack
  sns_topic(:billing_alert)
end

app/shared/resources/alarm.rb:

class Alarm < Jets::Stack
  depends_on :alert

  cloudwatch_alarm(:billing_alarm,
    alarm_description: "Alarm if AWS spending is too much",
    namespace: "AWS/Billing",
    metric_name: "EstimatedCharges",
    dimensions: [{name: "Currency", value: "USD"}],
    statistic: "Maximum",
    period: "21600", # every 6 hours
    evaluation_periods: "1",
    threshold: "100",
    comparison_operator: "GreaterThanThreshold",
    alarm_actions: [ref(:billing_alert)],
end

By declaring depends_on :alert in the Alarm class, Jets creates the Alert stack first and then creates the Alarm stack afterwards. Jets also passes all the outputs from the Alert stack to the Alarm stack as Parameters. This allows the Alarm class to reference the BillingAlert SNS topic with ref(:billing_alert) even though it was created in another stack.

With this design, Jets makes it is easy to create many nested stacks and use resources from each other.

App Classes: Controllers, Jobs, Etc

The depends_on declaration also works in non-shared app classes. When you add depends_on to an app class like a controller or a job, Jets will ensure that the resources are created in the dependent order and also pass the outputs of the independent stack to the dependent stack. This is useful in case you want to reference a resource from one stack to another.

Pro tip: Use the <- and -> arrow keys to move back and forward.

Edit this page

See a typo or an error? You can improve this page. This website is available on GitHub and contributions are encouraged and welcomed. We love pull requests from you!