It has been known for some time that AWS CDK offers an extremely rich class of constructs in its library, and one of the best examples of a construct are AWS resources. In addition, it is extremely rare that you find a resource existing without context and with no relation to other resources. So, when you’re looking to connect the resources between the proper graphs for infrastructure, we would have to model the interdependencies that exist between the constructs.
If we were using AWS CloudFormation, then we would be either using Fn: :ImportValue, Fn: :Ref or Export, Parameters, and Outputs. However, you go about it in a different manner in AWS CDK, especially if you are looking to preserve the idiomatic way.
The Options We Have
There are two different scenarios we are faced with right here, and they are:
- Internal sharing between AWS CDK Stacks and Constructs.
- Sharing in different ways across external AWS CloudFormation and AWS CDK templates.
We will be discussing both of them in order so that you have the complete picture.
Unlock the future of intelligent applications with our cutting-edge Generative AI integration services!
Sharing Internally
The meaning of internal sharing is that we will be sharing resources between the lower-level and higher-level Constructs, which includes Stacks inside the AWS CDK Application.
- Single Stack
It can be done easily as the properties can be accessed, e.g., sharing the reference across constructs as you pass it to the Constructs. It will ensure that AWS CDK makes the discovery that we’re inside a single stack and will be using Fn::Ref through AWS CloudFormation logical identifiers. - Multiple Stacks
If you’re looking to build an infrastructure graph between multiple stacks, you will have to rely on a similar solution as the one we have just discussed above. The only exception will be that you’ll be using Fn::ImportValue, Outputs, and Exports.
If you have previously worked in AWS CloudFormation with this, you will know that this can be bad and good at the same time. You will face the reality that very rarely would you want a coupling between stacks as tight as this, which is mainly due to the functionality.
The good news is that there are two options at your disposal to avoid that. These are:- Parameters – these have their own set of problems
- Since we can use both programming language and code, you can easily employ AWS SSM Parameter Store values, which are great for this case and a bit similar to Exports; however, there won’t be any tight coupling involved.
SERVICE DISABLED VETERAN OWNED SMALL BUSINESS (SDVOSB)
Sharing Externally
Now we get to the other end of the spectrum. You should know that AWS CDK has been designed to work flawlessly in mixed environments, with the clever assumption that we won’t rewrite everything immediately into AWS CDK. Therefore, you will have to find a way to exchange information in a bidirectional way between the existing AWS CloudFormation and the AWS CDK stacks.
Sharing between AWS CDK and AWS CloudFormation
We will use the help of an example to explain this process to you easily.
If you have a VPC inside a CDK application, while you’re looking to use the template of AWS CloudFormation, it will function exactly like sharing templates across plain CFN templates. We will be using Exports and Outputs in one template, and the other will include Imports or Parameters.
You can easily export in AWS CDK by calling vpc.export() inside the CDK application. That will create Experts for every attribute of your VPC, which another CDK stack will have to import, and these outputs will be available for all AWS CloudFormation stacks in any regions you are operating in. All you will need to do is deploy through AWS CDK and select your preferred method to get the VPC information into another template.
Important Note
If you’re not thrilled about the naming convention by default of the Exports (it’s something that can be understood as they are designed in such a way that you consume them transparently), it can be changed by you. All you must do is add some extra outputs (through new Output ()) into your CDK stack, and that will directly translate into the Outputs section of AWS CloudFormation, and you can also create exported values if you want too as well.
Sharing between AWS CloudFormation and AWS CDK
Now we will be analyzing the case in reverse, and if you have an existing VPC that has been deployed via CloudFormation or else, and you want to use it in a CDK application.
Here you will want to import it through Vpc.fromLookup(…) (through its name or some other options) or Vpc.fromVPCAttributes(…) (it’s going to be more flexible as there are several attributes in the VpcAttributes struct). Also, you can do additional resources similarly (e.g., Bucket.fromBucketArn(…)), as that will add new values in the context.
Small Disadvantaged Business
Small Disadvantaged Business (SDB) provides access to specialized skills and capabilities contributing to improved competitiveness and efficiency.
The Bottom Line
Sharing resources in AWS CDK is an essential topic and one that you should keep in mind because it serves multiple purposes. If you are managing existing infrastructure, you should know the different ways you can share resources in AWS CDK. Since AWS CDK is also a part of AWS CloudFormation, many people feel that it is both a blessing (as you can easily use the existing mechanisms) and can be a curse (because the mechanisms you use can constrain you in different cases).
The primary job of individuals is trying to understand and then select the machinery that is appropriate for the job. That is easier said than done, especially when it comes to AWS CDK, as there are so many complexities involved, but hopefully, this article has made it easier for you to understand some of them.
Further blogs within this Ways to Share Resources in AWS CDK category.