Difference between Construct and Stack


Apps, stacks and constructs

When you start building AWS infrastructure using CloudFormation via AWS CDK, there are some details you need to know. And that’s the difference between the different concepts behind it. One of them use to be the difference between construct and stack.

First of all, you need to know that there are three different concepts when you want to start using AWS CDK as IaC. We will have, conceptually, the following: the app, stacks and constructs. All of them combined, will allow you to have all your application components created/deployed to AWS. To make it simple, the app is the root element of your new application. And inside each app, you can have one or more stacks.

What is a Stack?

Every stack is the definition of a group of deployable resources, which means that inside of it you will add the definition of the different components to deploy on AWS. Each stack has its own information about the account and region where you need the group of contained resources to be deployed to. Therefore, you can create multiple stacks within a unique app, and you will have the ability to deploy each of these stacks to different accounts and regions.

Finally, inside every stack, we have the constructs that represent the specific resources you want to create. Such a Lambda function, a SQS or whatever other element. Basically, when you hear “construct” we are most of the times talking about future tangible services/components deployed on AWS. Or at least close to be that, as we will see now.

But what is really a construct?

A construct is basically an abstract way of naming a cloud component, whether we are referring to a particular AWS service (SQS, Lambda, Dynamo…) or a group of these that can, as example, define its relationships to finally build a Stack. This means that we can have a “root” construct with an internal inverted tree of other low-level constructs inside, and they can also be reused. That would be the main difference between construct and stack. Construct is the way of grouping your infrastructure definition at more tangible level, whereas the stack is referring to the group of those that define where (account and region) to deploy them.

Until now, we’ve only talked about a generic concept of constructs and how they can relate with the AWS services that we can see in AWS. Now we will see that we have three different levels of abstractions on constructs after they are grouped by a Stack. And as per AWS naming, we have L1, L2 and L3 constructs. It basically means:

  • L1 constructs: the lowest level of constructs. They directly represent the AWS CloudFormation resources available 1 to 1. They are the ones that you will see in your CDK as “CfnWhatever“.
  • L2 constructs: you have more abstraction with some AWS help, so you don’t need to know all the specific implementation details of every single service. And also helps you with some useful methods to make your live easier.
  • L3 constructs: the higher level of abstraction provided by AWS on the CDK. They call it “patterns”, which basically means you can easily create an AWS service with some really basic knowledge of the CloudFormation implementation and they will build the architecture for you behind. Something like new Queue(scope, constructId, deadLetterQueue), and you have a proper queue with an attached dead-letter queue.

What is the real benefit of constructs?

Besides all the terminology and abstraction levels, at the end of the day, it means that: using AWS CDK and its constructs, you can easily build and deploy infrastructure as a code to your AWS account/s. It provides the flexibility to either use the existing higher-level constructs straight away to build and deploy your stacks, build even higher custom levels of abstraction for your company specific needs, or implement your services in a very granular manner going through more low-level constructs.

All in all, hope this was helpful for you and you can now understand a bit more the logic of constructs. In any case, I leave you here with the full AWS official documentation to learn more about them if you feel you need it.

Leave a Reply

Your email address will not be published. Required fields are marked *