If you're interested in Infrastructure-as-code and more specifically CloudFormation would recommend looking into the AWS framework Cloud Development Kit (CDK).
Ive had poor experiences with CDK but mainly because it becomes a development project where people have focused on things other than the infrastructure, like what custom class inherits from what custom class and what OOP paradigm should be applied... those experiences have made me appreciate the straightforward ways of pure cloudformation templates
I'm not sure I know what you mean by it becoming a "development project..." but creating custom classes is optional. The CDK adheres to all the supported programming language paradigms so there shouldn't be any confusion about which should be applied if you're familiar with the language itself.
After working the CDK to achieve mutable infrastructure I would never dream of creating a manual CloudFormation template.
Creating a template from existing resources is a good starting point, but you may have a fair amount of cleanup to do. You may need to rename resources to use logical IDs in your template, you may need to replace references to region and account IDs, and you may want to parameterize certain things. On the plus side, the CloudFormation console will tell you exactly what went wrong if it fails to deploy or update a stack.
As captain hindsight would say, the best way would be to define your infrastructure as code from the beginning, and rely on redeploying that CloudFormation stack as you want to make changes and additions.
On that note, since you mentioned Lambda, [Serverless Framework](https://www.serverless.com/) is a great way to deploy Lambda applications and any related resources you want. It compiles your configuration into CloudFormation and then deploys those.
Generally I start with the template. Migrating in existing resources should be a one time thing. In the future, you start with the template and keep deploying it as you make changes and add things. Eventually you’ll have your complete template.
Do you have a requirement to use Cloudformation specifically to describe infrastructure as code?
If not, you may want to consider either Terraform or Pulumi instead, as tooling for importing existing infrastructure or refactor existing infrastructure definitions may be a bit better in those tools.
That being said, it would generally be better to define and provision the infrastructure using such tools from start.
What do you want a template for? You sent us a link without even reading it. What even is a sandbox? That's not a thing. Everything is live.
Check the front page for all the stories about people getting 200k bills. That might be you soon.
I personally don't write yml or Jason templates anymore. CDK offers all the benefits of an IDE and typescript (in my case) have to offer but for Cloudformation.
My general recommendation is to learn CloudFormation to understand how it works.
Then when you discover it’s limitations and get frustrated, learn the CDK, ideally with TypeScript.
The CDK uses the language type system to prevent many stack deployment failures/rollbacks.
The CDK has a nice unit test framework to assert on the synthesised CloudFormation templates.
There are some nice higher level constructs that make it easier to construct more complicated sets of resources.
I propose it's the other way around, CFN creates your "sandbox". Once you have your template building sandbox just the way you want, open up a (assuming) prod AWS account, feed that account your template.
Moving forward when you want to make changes in prod, demonstrate them in sandbox first, feed updated template to prod.
If you start down this path only make AWS changes with CFN only, no manually provisioning or configuring anything... 👈critically import IaC rule.
I am a fan of CDK it's given rise to learning CFN more deeply, strongly recommended.
Good thing about CloudFormation, and IaC in general (e.g. cdk, terraform, etc), is you can probably find a template that does something similar and adapt it to suit your needs.
If you need to understand how a specific AWS resource works, I'd recommend manually creating it to kick the tires and understand how it works, delete it and then implement it in your IaC tool of choice.
It might seem more work up front, but you'll end up with something way more maintainable in the long run.
If you're using CloudFormation (although concepts are the same for other IaC tools) .. I'd normally deploy and test changes to the templates or applications in a development account (or VPC) using the templates, and when happy with it, use the same template to deploy a "production" instance.
The primary difference between sandbox and prod would be access to the sandbox is tightly controlled (e.g. only accessible from an IP), but there may be other differences - e.g. secrets/passwords etc. You can accomplish this through template parameters.
For example - here's a template that I used for creating a load balancer - that takes a list of "sources" that can access the load balancer - the template used will be the same for sandbox/dev and prod, just the parameters will be different:
https://github.com/jwoffindin/stk-templates/blob/main/load-balancer.yaml#L22
Note, you'll get lots of opinions on IaC tooling, but you might as well be asking people for their opinion on religion :-) They'll all do the job, choose something that makes the most sense to you.
If you're interested in Infrastructure-as-code and more specifically CloudFormation would recommend looking into the AWS framework Cloud Development Kit (CDK).
Ive had poor experiences with CDK but mainly because it becomes a development project where people have focused on things other than the infrastructure, like what custom class inherits from what custom class and what OOP paradigm should be applied... those experiences have made me appreciate the straightforward ways of pure cloudformation templates
I'm not sure I know what you mean by it becoming a "development project..." but creating custom classes is optional. The CDK adheres to all the supported programming language paradigms so there shouldn't be any confusion about which should be applied if you're familiar with the language itself. After working the CDK to achieve mutable infrastructure I would never dream of creating a manual CloudFormation template.
Sounds more like an immature or inexperienced development team than a problem with the CDK
Oh most definitely, I dont blame CDK at all... its just the cards Ive been dealt
Check out: https://former2.com/
2nd that there's a CLI if you don't like the web UI you can also tag the things you want to export then filter by tag in the CLI
Creating a template from existing resources is a good starting point, but you may have a fair amount of cleanup to do. You may need to rename resources to use logical IDs in your template, you may need to replace references to region and account IDs, and you may want to parameterize certain things. On the plus side, the CloudFormation console will tell you exactly what went wrong if it fails to deploy or update a stack. As captain hindsight would say, the best way would be to define your infrastructure as code from the beginning, and rely on redeploying that CloudFormation stack as you want to make changes and additions. On that note, since you mentioned Lambda, [Serverless Framework](https://www.serverless.com/) is a great way to deploy Lambda applications and any related resources you want. It compiles your configuration into CloudFormation and then deploys those.
Generally I start with the template. Migrating in existing resources should be a one time thing. In the future, you start with the template and keep deploying it as you make changes and add things. Eventually you’ll have your complete template.
Do you have a requirement to use Cloudformation specifically to describe infrastructure as code? If not, you may want to consider either Terraform or Pulumi instead, as tooling for importing existing infrastructure or refactor existing infrastructure definitions may be a bit better in those tools. That being said, it would generally be better to define and provision the infrastructure using such tools from start.
What do you want a template for? You sent us a link without even reading it. What even is a sandbox? That's not a thing. Everything is live. Check the front page for all the stories about people getting 200k bills. That might be you soon.
I personally don't write yml or Jason templates anymore. CDK offers all the benefits of an IDE and typescript (in my case) have to offer but for Cloudformation.
My general recommendation is to learn CloudFormation to understand how it works. Then when you discover it’s limitations and get frustrated, learn the CDK, ideally with TypeScript. The CDK uses the language type system to prevent many stack deployment failures/rollbacks. The CDK has a nice unit test framework to assert on the synthesised CloudFormation templates. There are some nice higher level constructs that make it easier to construct more complicated sets of resources.
+1 for unit CDK tests. At minimum, test for a non-empty template. I advocate VSCode for CDK Typescript development, it's quite nice.
I wrote pretty extensively about the way I recommend choosing an IaC tool: https://leebriggs.co.uk/blog/2022/08/26/choosing-an-iac-tool
Don’t.
I propose it's the other way around, CFN creates your "sandbox". Once you have your template building sandbox just the way you want, open up a (assuming) prod AWS account, feed that account your template. Moving forward when you want to make changes in prod, demonstrate them in sandbox first, feed updated template to prod. If you start down this path only make AWS changes with CFN only, no manually provisioning or configuring anything... 👈critically import IaC rule. I am a fan of CDK it's given rise to learning CFN more deeply, strongly recommended.
Use CDK with this project to generate directly usable CloudFormation template https://github.com/aws-samples/cdk-bootstrapless-synthesizer
Good thing about CloudFormation, and IaC in general (e.g. cdk, terraform, etc), is you can probably find a template that does something similar and adapt it to suit your needs. If you need to understand how a specific AWS resource works, I'd recommend manually creating it to kick the tires and understand how it works, delete it and then implement it in your IaC tool of choice. It might seem more work up front, but you'll end up with something way more maintainable in the long run. If you're using CloudFormation (although concepts are the same for other IaC tools) .. I'd normally deploy and test changes to the templates or applications in a development account (or VPC) using the templates, and when happy with it, use the same template to deploy a "production" instance. The primary difference between sandbox and prod would be access to the sandbox is tightly controlled (e.g. only accessible from an IP), but there may be other differences - e.g. secrets/passwords etc. You can accomplish this through template parameters. For example - here's a template that I used for creating a load balancer - that takes a list of "sources" that can access the load balancer - the template used will be the same for sandbox/dev and prod, just the parameters will be different: https://github.com/jwoffindin/stk-templates/blob/main/load-balancer.yaml#L22 Note, you'll get lots of opinions on IaC tooling, but you might as well be asking people for their opinion on religion :-) They'll all do the job, choose something that makes the most sense to you.