Provides infrastructure layer compute capabilities, including both bare metal and virtual servers with various optimizations includins compute, memory, IO, and disk. Also supports accelerations options such as GPUs, FPGAs, Inferentia and Trainium.
Provides image recognition capability for images (in batch or real-time) and video that provides a analysis of the content such as real-world objects, faces, celebrities, and path mapping.
Provides a publish/subscribe notification service with multiple subscription types including Amazon Simple Queue Service (SQS), Amazon Kinesis Data Firehose, AWS Lambda, generic HTTPS endpoints, SMS and email.
A serverless, fully-managed, message queue service that supports producing, store, and consuming messages and enables loose coupling between applications.
Provides private networking capability spanning multiple availability zones and supporting subnets, routing, network access control groups, security groups and gateways.
Provides tracing of service invocations in distributed applications for observability, allowing users to diagnose issues or optimize their service interactions.
AWS CloudFormation is a service which provides orchestration of infrastructure build out. CloudFormation is a great example of Infrastructure as Code, where a text file which can be stored in a version control system (such as AWS CodeCommit) is used to create a Software Defined Data Center. Nested CloudFormation Templates allows for reuse and automation, two fundamentals of DevOps.
AWS has added new capabilities to CloudFormation since it’s launch. One example is the new YAML syntax. There are still a number of restrictions though.
One restriction is the number of resources that a single CloudFormation template can define. A resource could be a Subnet definition, an EC2 instance, or an Auto Scaling Group. Basically, if it gets created within AWS, it’s probably a resource. CloudFormation sets a limit of 200 resources per template.
Another restriction is that a single CloudFormation template cannot be larger than 460,800 bytes. While this seems like a huge number, consider that the user data field of an EC2 instance could be 16,384 bytes. These restrictions are listed here.
One way around these restrictions, and which has the added advantage of providing reuse is to use nested CloudFormation templates.
Nested CloudFormation Templates
When a resource from one CloudFormation template is another CloudFormation template, then you have nested CloudFormation templates.
I first used nested CloudFormation templates when I wanted to install Apache Kafka. Kafka has a dependency on Apache ZooKeeper. Building the ZooKeeper and Kafka setup into one CloudFormation template would make it difficult to reuse the ZooKeeper for other applications that depend on it.
Instead, I built one CloudFormation template which included two nested CloudFormation templates. One built the ZooKeeper cluster, the other built the Kafka cluster.
To further improve reuse, CloudFormation can pass parameters from the parent template to the nested template, and outputs from the nested template can be accessed in the parent template.
Modern infrastructure often contains building blocks. Database server clusters, application server clusters and web server clusters are just a few examples. Nested CloudFormation templates provides an efficient way to build this infrastructure in a reusable way.
All data and information provided on this site is for informational
purposes only. cloudninja.cloud makes no representations as to accuracy,
completeness, currentness, suitability, or validity of any information
on this site and will not be liable for any errors, omissions, or
delays in this information or any losses, injuries, or damages
arising from its display or use. All information is provided on an
as-is basis.
This is a personal weblog. The opinions expressed here represent my
own and not those of my employer. My opinions may change over time.
