Building Highly Available AWS Infrastructure: Infrastructure as Code - Part 5

Throughout this series, we've built a highly available AWS infrastructure from the ground up. We started with Part 1 laying the foundations with ALB and Auto Scaling, moved to Part 2 with containerization using ECS, explored Part 3 going serverless with Fargate, and in Part 4 we learned how to fail gracefully.

You might have noticed something about all those examples: I used the AWS CLI.

There's a good reason for that. CLI commands are clean, simple, and easy to follow. They let you focus on what you're building without getting lost in the syntax of a particular IaC tool. They're perfect for learning.

But when it comes time to actually deploy your infrastructure to production? You should absolutely be using Infrastructure as Code.

Why Infrastructure as Code Matters

Let me be blunt: if you're clicking around in the AWS Console or running CLI commands manually in production, you're doing it wrong. Here's why:

Repeatability - Can you recreate your entire infrastructure from scratch? What if you need a second environment for staging? Or a disaster recovery setup in another region?

Version Control - Your infrastructure should be in Git, just like your application code. You should be able to see who changed what, when, and why.

Review Process - Infrastructure changes should go through the same review process as code changes. Pull requests, approvals, and CI/CD pipelines.

Documentation - Your IaC is your documentation. It's always up to date because it is the actual state of your infrastructure.

Disaster Recovery - If everything burns down, can you rebuild it in hours instead of days or weeks?

If you answered "no" or "maybe" to any of those questions, you need IaC.

The Main Players

Let's talk about the three major tools in the AWS IaC space. I've used all of them in production, and each has its place.

AWS CloudFormation

What it is: AWS's native Infrastructure as Code service. You define your infrastructure in JSON or YAML templates, and CloudFormation creates and manages everything for you.

Strengths:

• Native AWS integration - It's built by AWS, for AWS. Everything new in AWS gets CloudFormation support quickly (usually).
• No additional authentication - Uses your existing IAM credentials. No separate state files to manage.
• Change sets - Preview exactly what will change before you apply it.
• Stack outputs and cross-stack references - Clean way to share resources between stacks.
• Free - No additional cost beyond the AWS resources you create.

Weaknesses:

• Verbose - YAML/JSON templates can get long and repetitive.
• Learning curve - The syntax and intrinsic functions can be confusing.
• Limited logic - You can't easily do loops, conditionals get messy, and there's no real programming constructs.
• Debugging - Error messages can be cryptic, and rollbacks can be frustrating.

My take: CloudFormation is solid and reliable. I used it for years, especially with the SAM (Serverless Application Model) extension for Lambda-based applications. It works great for straightforward deployments, but once your infrastructure gets complex, the template files become unwieldy.

Terraform

What it is: HashiCorp's multi-cloud Infrastructure as Code tool. It uses HCL (HashiCorp Configuration Language) and can manage resources across AWS, Azure, GCP, and hundreds of other providers.

Strengths:

• Multi-cloud - If you're working across multiple cloud providers, Terraform is hard to beat.
• Cleaner syntax - HCL is more readable than CloudFormation YAML/JSON.
• Strong community - Tons of modules and examples available.
• Plan/Apply workflow - See exactly what will change before you make changes.
• Mature ecosystem - Been around for years, well-tested at scale.

Weaknesses:

• State file management - You need to manage state files carefully. Lose the state, lose track of your infrastructure.
• Additional tooling - Another tool to install, update, and maintain.
• AWS lag - New AWS services/features sometimes lag behind CloudFormation support.
• Authentication overhead - Need to manage credentials separately from AWS.

My take: I tried Terraform. I really did. For multi-cloud scenarios, it's probably the right choice. But for AWS-only deployments, I found the state file management to be more trouble than it was worth, and the learning curve didn't pay off for my use cases. It just wasn't for me. But that's personal preference—many developers swear by it, and I respect that.

AWS CDK (Cloud Development Kit)

What it is: Define your infrastructure using actual programming languages (TypeScript, Python, Java, C#, Go). The CDK synthesizes your code into CloudFormation templates and deploys them.

Strengths:

• Real programming languages - Loops, conditionals, functions, classes, interfaces—all the power of a real language.
• Type safety - If you use TypeScript, you get IntelliSense and compile-time error checking.
• Reusability - Create constructs (reusable components) and share them across projects or teams.
• Cleaner code - Express complex infrastructure patterns in much less code than raw CloudFormation.
• L1, L2, L3 constructs - Choose your abstraction level. Low-level for control, high-level for productivity.
• Still CloudFormation - Under the hood, it generates CloudFormation, so you get all the benefits of CloudFormation without the verbose YAML.

Weaknesses:

• AWS-only - It's designed for AWS. If you need multi-cloud, look elsewhere.
• Learning curve - You need to understand both the programming language AND AWS concepts.
• Generated templates - Sometimes debugging requires looking at the generated CloudFormation, which can be ugly.
• Rapid evolution - The CDK moves fast. Sometimes too fast. Breaking changes happen.

My take: This is my go-to now. I love writing infrastructure in TypeScript and Python (I typically use Python just as a personal preference, but I appreciate the flexibility of both). The ability to use real programming constructs, create reusable patterns, and leverage the type system has been a game-changer. Plus, I've built a custom addon tool I call the CDK-Factory that streamlines my workflow even further. I'll write more about that tool in a future blog post.

Which One Should You Choose?

Here's my honest advice:

If you're AWS-only and like programming:
→ Go with CDK. The productivity gains are real.

If you need multi-cloud support:
→ Terraform is probably your best bet.

If you want something simple and AWS-native:
→ CloudFormation (especially with SAM for serverless) is solid and reliable.

If you're not sure:
→ Start with CloudFormation. It's free, it's native, and you can always migrate to CDK later (they both use CloudFormation under the hood anyway).

The Real Point

Here's the thing: the specific tool matters less than using some tool.

Using CloudFormation, CDK, or Terraform is infinitely better than:

• Clicking around in the AWS Console
• Running CLI commands manually
• Keeping infrastructure details in your head or a wiki somewhere
• Crossing your fingers during disaster recovery

Pick a tool. Learn it. Use it. Your future self (and your team) will thank you.

What's Next?

We've covered the architecture, the components, the resilience strategies, and now the deployment philosophy. But I bet you're thinking: "This is all great in theory, but what does it actually look like?"

Want to see the actual code?

In Part 6, I'm going to share the complete Infrastructure as Code for everything we've built in this series. The full ALB setup, Auto Scaling groups, ECS clusters, Fargate tasks, health checks, CloudFront distributions, Route 53 configurations—all of it.

I'm putting the finishing touches on it now. Stay tuned—it should be ready soon.

Until then, if you need help designing, building, or migrating your AWS infrastructure to production-ready IaC, that's exactly what we do at Geek Cafe Architecture Consulting and Platform Maintenance. We help you build, deploy, and maintain production-ready infrastructure so you can focus on what matters most—building great software.

---

Have questions about Infrastructure as Code or want to share your own IaC journey? I'd love to hear from you. Drop me a line.