What is IaC in AWS - why you stop clicking in the console

Infrastructure as code (IaC) means writing down what you want your servers, databases, and networks to look like in a text file, then having a tool build it for you — instead of clicking through the AWS console by hand every time. The direct answer to "why stop clicking" is repeatability: a template can be run the same way twice, a mouse click cannot. But here's the part almost nobody tells you upfront: adopting a tool like AWS CloudFormation does not physically stop anyone on your team from opening the console and changing something anyway. IaC doesn't lock the door. It just makes sure you find out when someone walked through it.

Jake found this out the expensive way. He runs a small phone shop, and about a year ago he decided the shop's inventory site needed "the cloud." He spent a Saturday in the AWS console clicking together a database, a web server, and a load balancer. It worked. Six months later a part-time employee accidentally deleted the database instance while poking around, trying to be helpful. Jake had no record of how the original one was configured — no notes, no screenshots, nothing. He spent two full days on the phone with AWS support trying to remember 14 different settings he'd picked without writing any of them down.

That's the actual cost of clicking. Not "it's unprofessional" — a customer's order history, gone, and a shop owner who couldn't reopen for two days during his busiest week. Infrastructure as code exists specifically to make that story impossible, because the "settings" live in a file instead of in someone's memory.

What "infrastructure as code" actually means

Strip away the buzzword and IaC is a simple trade: instead of using your mouse to create an Amazon EC2 instance (a virtual server AWS rents you by the hour) through the console, you write a text file that describes the server — its size, its network, its storage — and hand that file to a tool. The tool reads the file and makes the real AWS account match it. Change the file, run the tool again, and your infrastructure changes to match. Delete the file's contents, run the tool, and the resources get torn down.

This is exactly the same shift software engineers went through decades ago when they stopped emailing each other zip files of code and started using version control — a system that tracks every change to a set of files, who made it, and when, so any change can be reviewed or undone. IaC just applies that same discipline to servers and networks instead of application code. Your infrastructure file goes into the same kind of repository your application code lives in (commonly a Git repository, the most widely used version control system), so a change to your database's backup settings gets reviewed the same way a change to your checkout code does.

Also Read : What Is Amazon CloudFront? The Copy of Your Site Everywhere

The word you'll see everywhere: "template"

On AWS, the file you write is called a template. It's a plain text file, formatted as either JSON (a data format that uses curly braces and quotation marks — machine-friendly but easy to fat-finger) or YAML (a format that uses indentation instead of brackets, easier for a human to read and the one most AWS documentation examples use). The template lists every resource you want — a database here, a storage bucket there, an instance running your website — along with the settings for each one. AWS CloudFormation, the built-in AWS service for this, reads that template and creates everything it describes, in the right order, tracking the dependencies between resources so a database gets created before the application that needs it tries to connect.

That preview matters more than it sounds like it should. A change set is CloudFormation's summary of exactly what would happen if you applied your updated template: which resources get created, which get modified in place, and — critically — which get replaced entirely, meaning the old one is deleted and a new one takes its place. If you rename an Amazon RDS database instance in your template, for example, CloudFormation doesn't rename it quietly. It has to delete the old database and create a new one, because a database's name isn't something you can change on an existing instance. Without a change set, you'd only discover that the hard way, after your data was already gone. With one, you see "replacement" flagged in advance and you can back your data up first, or decide not to make that change at all.

What clicking in the console actually costs you

Nobody sits down and decides to build unreliable infrastructure. It happens by accumulation. Every environment you build by hand in the console is a little different from the last one, because human memory is a bad configuration file. Ethan calls this "snowflake infrastructure" — every server unique, none of them identical, all of them fragile in slightly different ways.

Here's the pattern, in the order it usually bites:

What breaks first	Why clicking causes it	What a template fixes
"It works in staging but not production"	Staging and production were built by hand, months apart, by people who each picked slightly different settings without realizing it.	The same template deploys both. Any difference has to be written down as a deliberate parameter, not left to memory.
Nobody knows how the network is configured	The only record of a security group's rules (a security group is a virtual firewall around your resource) is whatever's currently showing in the console, with no history of who changed it or why.	The template is the record. Anyone can read it without touching the live account, and version control shows every past change.
A 2 a.m. "quick fix" nobody remembers	Someone edits a setting directly during an incident to stop the bleeding, then forgets to fix it "properly" afterward.	CloudFormation's drift detection flags that resource as no longer matching the template, so the change doesn't disappear silently.
Rebuilding after a disaster takes days, not minutes	Recreating a hand-built environment means someone trying to remember every click they made, sometimes years ago.	Re-run the same template in a new account or Region. CloudFormation stack sets can even do this across many accounts at once.

Every one of those rows costs real time, and time is the one thing a small shop owner like Jake genuinely cannot buy more of on a Saturday. The pitch for IaC isn't that it's more "professional." It's that it converts infrastructure from something a person has to remember into something a computer can just re-read.

Declarative vs. imperative: the split that confuses everyone at first

Every IaC tool falls into one of two families, and picking the wrong mental model is the number-one reason beginners feel lost in their first week.

Declarative tools want you to describe the end state — "I want one database, this size, in this network" — and leave the how entirely up to the tool. CloudFormation templates and Terraform configuration files both work this way. You never write "create the database, then create the security group, then attach it." You just list what should exist, and the tool figures out the order and the API calls.

Imperative tools want you to write the steps, in a real programming language, using loops and conditionals if you want them. The AWS Cloud Development Kit (AWS CDK) sits in an interesting middle ground here: you write imperative-feeling code — real TypeScript, Python, Java, C#, or Go, with functions and classes — but that code doesn't directly build anything. It "synthesizes" (CDK's term for compiles) into a declarative CloudFormation template, which then gets deployed the normal declarative way. You get the readability of a real programming language and the safety net of CloudFormation's change sets and rollback underneath it.

The AWS-native tools: CloudFormation, SAM, and CDK

AWS gives you three closely related tools rather than one, and the overlap between them trips people up. Here's what actually separates them.

AWS CloudFormation is the foundation. It's the service that actually reads a template and provisions resources — everything else on this list eventually produces a CloudFormation template and hands it off to CloudFormation to run. You can manage CloudFormation stacks (a stack is the running, deployed set of resources that came from one template) through the AWS Management Console, the AWS Command Line Interface (AWS CLI, a way of controlling AWS from a terminal instead of a browser), or an SDK (software development kit — a code library for calling AWS from your own programs).

AWS Serverless Application Model (AWS SAM) is a shorthand layer on top of CloudFormation, built specifically for serverless applications — meaning applications made of AWS Lambda functions (small pieces of code that run on demand without you managing a server), API Gateway endpoints, and similar pay-per-use pieces. A SAM template lets you describe a Lambda function and its trigger in a handful of lines that would take many more lines of raw CloudFormation. Behind the scenes, the SAM CLI expands your short template into a full CloudFormation template before deploying it.

AWS CDK, as covered above, lets you write that same underlying CloudFormation template using a general-purpose programming language instead of YAML or JSON. You define reusable pieces called constructs (an AWS CDK term for a packaged, reusable chunk of infrastructure — think "a function that returns a fully configured database plus its network and security group in one call") and compose them into stacks. The CDK Toolkit — its command-line tool — lets you run cdk synth to generate the CloudFormation template, cdk diff to compare your code against what's currently deployed, and cdk deploy to ship it, which under the hood submits a change set to CloudFormation just like a hand-written template would.

Tool	What you write	Best fit
CloudFormation	YAML or JSON template	Teams entirely on AWS who want zero extra tooling to install
AWS SAM	Short YAML, expands to CloudFormation	Serverless apps built mostly on Lambda
AWS CDK	TypeScript, Python, Java, C#/.NET, or Go	Teams that would rather write functions than YAML, and want reusable building blocks
Terraform (third-party)	HCL, a purpose-built configuration language	Multi-cloud teams, or shops that standardized on it before going all-in on AWS

Terraform, Pulumi, and the multi-cloud alternative

This is an AWS-focused site, so the depth above leans that direction, but it would be dishonest to write a "what is IaC" post and pretend Terraform doesn't exist — it's the tool most non-AWS teams reach for first, and plenty of AWS shops use it anyway. Terraform is declarative, like CloudFormation, but it's built by HashiCorp rather than AWS, and it works against dozens of providers — AWS, Google Cloud, Microsoft Azure, and many smaller ones — using the same configuration language for all of them. The trade-off is that Terraform keeps its own record of what it manages in something called a state file, and if that file is lost or gets out of sync with reality, Terraform genuinely loses track of what it owns. CloudFormation doesn't have this problem in the same way, because AWS itself keeps the state — there's no separate file for you to protect.

There's a fifth option worth a one-line mention: Pulumi, which — like Terraform — works across multiple cloud providers, but — like CDK — lets you write actual general-purpose programming languages instead of a bespoke configuration syntax. If CDK's appeal is "real code instead of YAML" and Terraform's appeal is "one tool for every cloud," Pulumi is aimed at teams who'd like both at once, at the cost of adding yet another tool and account to your stack for a small AWS-only shop to manage.

How a CloudFormation deployment actually runs, start to finish

It helps to walk through the mechanics once, because "it just works" isn't a satisfying explanation for a shop owner who wants to know what he's trusting with his customer data.

1. You write a template. A YAML or JSON file listing the resources you want and their settings — for example, an Amazon RDS database instance, its size, and the network it should live in.
2. You create a stack. Through the console, the AWS CLI, or an SDK, you tell CloudFormation "here's my template, build it." That running set of resources is now called a stack, and it has a name you'll refer to for every future update.
3. CloudFormation figures out the order. It reads the dependencies between resources — a database subnet group has to exist before the database that uses it — and makes the underlying AWS API calls in the right sequence automatically. You never have to write "do this first."
4. You make a change by editing the template, not the resource. Want a bigger database? Change the size value in the file. You never open the RDS console and drag a slider.
5. You generate a change set before applying it. This shows you exactly what will be created, modified in place, or replaced — including a warning when a change would delete and recreate something, which matters enormously for anything holding data.
6. You review, then execute the change set. Only after you (or, on a mature team, a second reviewer) has looked at the preview does CloudFormation actually touch the account.
7. If something fails mid-deployment, CloudFormation rolls back automatically to the last known working state, rather than leaving your account half-built and broken.

There's also a cheap sanity check worth running before any of that: CloudFormation's template validation. Running it against your template checks whether the file is syntactically valid JSON — and if it isn't, whether it's at least valid YAML — flagging basic structural errors before you've committed to anything. It's not a substitute for a change set, though. Validation only confirms the file is well-formed; it has no idea whether the resources inside it make sense together, or whether applying it would quietly replace your database. Think of it as a spell-checker, not a proofreader — it catches the typo that would otherwise stop your deployment cold, but it will happily wave through a perfectly well-formed template that's about to do something you didn't intend.

That last point is the one people find hardest to believe until they've seen it. A partial console click-through leaves you with whatever got created before you hit an error — a half-built environment you now have to manually clean up. A failed CloudFormation deployment reverses itself.

Drift: the thing IaC doesn't actually prevent

Here's the counterintuitive part worth sitting with. CloudFormation does not physically stop anyone with console access from clicking a setting and changing it directly. Nothing about using a template revokes anyone's ability to open the EC2 console and resize an instance by hand. What CloudFormation gives you instead is a way to find out that it happened: drift detection.

Drift is CloudFormation's word for a resource whose actual, live configuration no longer matches what the template says it should be. Running drift detection compares the two and flags the difference. A resource comes back as IN_SYNC if it still matches, MODIFIED if a tracked property has changed, or DELETED if it's gone entirely; resources CloudFormation can't check come back NOT_CHECKED. A whole stack is marked DRIFTED if even one of its resources has drifted.

So the honest framing isn't "IaC stops manual changes." It's "IaC turns a manual change from an invisible risk into a visible, named one you can act on." Detecting drift and preventing it are two different jobs, and the next section is about the second one.

Fixing drift once you find it

1. Run drift detection on the stack. This can be done on the whole stack or on an individual resource within it.
2. Review the reported differences. CloudFormation shows you which properties changed, whether a value was added, removed, or is simply not equal to what the template expects.
3. Decide which side is "right." Sometimes the manual change was the correct emergency fix and the template is now the outdated one — in which case update the template to match reality. Other times the manual change was a mistake and should be reverted to match the template.
4. Apply the fix. Either update and redeploy the template so it captures the new intended state, or use CloudFormation's resource import feature to bring an out-of-band change back under management, or manually correct the live resource to match the template again.

Drift detection isn't perfect, either, and it's worth knowing where it falls short so you don't over-trust it. It only checks resource types that support drift detection at all — anything else always shows NOT_CHECKED. It doesn't detect drift on nested stacks automatically; those need their own separate drift check. And for security reasons, some properties are never returned by the underlying service in the first place — CloudFormation can't tell you an IAM user's login password has drifted, because AWS never exposes that value to check against.

Locking down who can click: the IAM side of this

Drift detection tells you after someone clicked. If you want to actually stop it, that's a job for IAM (AWS Identity and Access Management, the service that controls who can do what in your account) — not for CloudFormation. It's worth being specific about how, because "just use IAM" is the kind of vague advice that helps nobody.

IAM policies for CloudFormation use action names prefixed with cloudformation: — things like cloudformation:CreateStack, cloudformation:UpdateStack, and cloudformation:CreateChangeSet for making changes, or the read-only cloudformation:DescribeStacks, cloudformation:DescribeStackEvents, and cloudformation:GetTemplate for people who only need visibility into what's deployed. You attach the change-making actions to an IAM role that your deployment pipeline assumes, and to nobody else, so a person browsing the console can look but can't touch.

But this is the part that trips people up: locking down CloudFormation's own API actions isn't enough by itself. Permissions for the underlying resources still apply the exact same way whether someone creates an Amazon EC2 instance directly, or CloudFormation creates it on their behalf. If a user still has permission to launch instances or modify a database attached to their own IAM identity, they can bypass your entire templated process and go straight to the console, because CloudFormation isn't the only door into that resource — it's just the door you want people to use. Real enforcement means removing broad resource permissions from individual engineers and granting them only through the role your deployment tooling assumes. Jake's part-time employee who deleted that database never should have had permission to delete a database instance in the first place; CloudFormation wasn't the gap, the IAM policy was.

Which tool actually fits your situation

The popular advice online tends to flatten this into "just use Terraform, everyone does." That's not wrong for a lot of teams, but it's not universally right either, and repeating it without qualification does a disservice to anyone who's simply on AWS and nowhere else.

If your entire footprint is AWS and you want the smallest number of moving parts, CloudFormation wins — no state file, no separate installation, native rollback, and change sets built in. If you're building mostly Lambda-based serverless applications, SAM's shorthand saves real typing without giving up anything CloudFormation offers underneath. If your team already thinks in TypeScript or Python and would rather build reusable functions than copy-paste YAML blocks across a dozen templates, CDK is worth the learning curve — you keep CloudFormation's safety net while writing in a language your developers already know. Terraform earns its place the moment "AWS-only" stops being true — a second cloud provider, a SaaS platform you also need to provision, or a team that standardized on it long before this decision was yours to make.

Getting started without breaking anything that's already live

The single biggest mistake first-timers make is trying to write a template for a production environment that already exists and is already serving customers. Don't. Start somewhere the stakes are low.

Start in a brand-new, empty environment. A test AWS account, or a throwaway set of resources with nothing important attached, is the right place to write your first template and watch it succeed or fail without consequences. Deploy it. Break it on purpose. Delete the stack and rebuild it. This is where you learn what a change set actually looks like when it's about to replace something, before that "something" is your customer database.

Only after that, bring existing resources under management. If you've already got hand-built infrastructure you want to convert, CloudFormation supports importing existing resources into a stack, so you don't have to delete and recreate something that's already running correctly just to get it under template control. This is exactly the situation Jake was in with his hand-clicked database — resource import means he could have brought his existing database under CloudFormation's management without ever having to rebuild it from scratch or risk losing data in the process.

Keep the template in version control from day one, even before you've deployed anything with it. A template sitting only on your laptop provides almost none of the benefit — the whole point is a shared, reviewable, historied record.

If you'll eventually manage the same setup across multiple AWS accounts or Regions — say, a production account and a separate account for testing — look at CloudFormation stack sets before you build that manually a second time. Stack sets deploy the same template consistently across many accounts and Regions from one operation, and they come in two permission models worth knowing apart before you pick one. Self-managed permissions are the manual option: you create an IAM role in the account you're administering from, and a matching execution role in every target account, then set up a trust relationship between the two yourself. This works with any AWS account, including ones outside AWS Organizations (AWS's service for centrally managing multiple accounts as a single organization). Service-managed permissions are the automated option: if your accounts are already managed through AWS Organizations, CloudFormation creates the necessary IAM roles for you behind the scenes, and you can also turn on automatic deployment so stack instances get created automatically in any new account added to the organization later. The trade-off is that service-managed stack sets don't support nested stacks or templates that use macros or transforms, and CloudFormation won't deploy stacks into the organization's management account itself even though that account is technically part of the organization. For a shop with two or three AWS accounts set up informally, self-managed permissions are usually the simpler starting point; for a company already standardized on AWS Organizations, service-managed permissions save you the manual role setup entirely.

The mistakes that quietly undo all of this

Treating the console as a "just this once" escape hatch. Every "just this once" click that isn't reflected back into the template is a drift event waiting to be discovered later, usually at the worst possible moment. If you must make an emergency console change during an incident, the discipline that actually works is: fix it live, then immediately update the template to match, then redeploy so the template and reality agree again.

Giving everyone on the team full console access "to be safe." If anyone can change anything by hand at any time, your templates become documentation of intent rather than a guarantee of reality. The teams that get the most value from IaC eventually restrict who can make manual changes at all, scoping IAM policies so day-to-day changes have to go through the template-and-deploy path, not the console.

Writing one enormous template for everything. A single template covering your entire account becomes slow to update and terrifying to touch, because every change set for it touches dozens of unrelated resources at once. CloudFormation's answer to this is nested stacks: you split a large template into smaller, focused ones — a load balancer configuration, a networking layer — and reference each one from a parent template using the AWS::CloudFormation::Stack resource type. The result is a hierarchy: a root stack sits at the top, and every stack it references, directly or through another nested stack, ultimately traces back to that same root. If your nested template lives as a separate file, the AWS CLI's cloudformation package command uploads it to an Amazon S3 bucket for you and rewrites your top-level template to point at that S3 location automatically, so you're not doing that step by hand every time the nested piece changes. The payoff is the same one application developers get from splitting one giant file into modules: each piece stays small enough that a reviewer can actually understand what a change set to it is about to do, instead of scrolling through hundreds of unrelated resources to find the three lines that changed.

Assuming CloudFormation's rollback means "nothing bad can happen." Rollback protects you from a half-finished deployment. It does not protect you from a change that succeeds completely but does something you didn't intend — like the RDS rename example earlier, where "success" means your old database is gone and a new, empty one has replaced it. The change set preview is what protects you from that, not the rollback.

What using CloudFormation itself actually costs

This is one of the most common questions and one of the easiest to answer clearly: for the standard AWS resource types — anything in the AWS:: or Alexa:: namespace — there is no additional charge for using CloudFormation at all. You pay for the Amazon EC2 instance, the RDS database, the storage bucket, exactly as if you'd created it by hand in the console. CloudFormation itself adds $0 to that bill.

Where charges do appear is a narrower case: third-party resource types from the CloudFormation Registry, or custom hooks (small pieces of validation logic you write yourself that run during a deployment). Those are billed per "handler operation" — a create, update, delete, read, or list action CloudFormation performs against that resource type. The first 1,000 handler operations per account each month are included in AWS's free tier. Beyond that, each additional handler operation costs $0.0009, and if any single operation takes longer than 30 seconds to complete, the time above that 30-second mark is billed at $0.00008 per second on top of the per-operation charge. Standard AWS data transfer rates apply as usual.

To make that concrete: say you manage 500 third-party resources of one custom type, and you perform one operation on each of them every day for a month, with none of those operations running past the free 30-second window. That's 500 resources times 30 daily operations, or 15,000 handler operations for the month. Subtract the 1,000 free-tier operations, multiply the remaining 14,000 by $0.0009, and the monthly bill comes to $12.60 — for that one custom resource type, nothing more. For a shop like Jake's, using only native AWS resource types through CloudFormation, none of this ever shows up on the bill at all; it's purely a consideration for teams building or consuming custom, third-party resource providers.

The edge cases nobody mentions until you hit them

"Equal but not identical" false-positive drift. Drift detection can flag a property as changed even when nothing meaningfully different has happened — for example, if your template says a memory setting is 1024 MB and the live resource reports it as 1 GB. Those numbers mean the same thing, but they're not written identically, and drift detection compares values, not meanings. If you see drift on a value you're confident you never touched, check whether it's this kind of cosmetic mismatch before assuming someone made an unauthorized change.

Attached resources living in different stacks. Some resources are meant to attach to others — an SNS subscription attaching to a topic, or a security group ingress rule attaching to a security group. CloudFormation can usually work out these attachment relationships within a single template, but if the two halves live in separate stacks, drift results for them can be unreliable, because CloudFormation can't analyze the relationship across stack boundaries the same way.

Properties the underlying service simply won't return. Some values are never handed back by AWS for security reasons — an IAM user's login password being the clearest example — so CloudFormation has no way to compare them and can't include them in drift results at all. Don't rely on drift detection to catch a manual change to something like this; it structurally can't see it.

Nested stacks need their own drift check. If your template calls another template as a nested stack, running drift detection on the parent stack does not automatically check the nested one. Each needs to be checked on its own, at every level of the hierarchy.

When clicking in the console is still the right call

It's worth being honest about the limits here, because a post that pretends IaC is the answer to every situation isn't giving you the full picture. If you're exploring an AWS service for the very first time to understand what it even does — poking around Amazon Bedrock's console to see what a model playground looks like, for instance — clicking is faster and perfectly reasonable. Nobody writes a CloudFormation template to satisfy fifteen minutes of curiosity. The moment that experiment turns into something you intend to keep running, that's the moment to capture it in a template, either by writing one from what you learned or by using resource import to bring the thing you already built under management.

Similarly, one-off, truly disposable resources with no data attached and a lifespan measured in hours don't always earn the overhead of a template. The judgment call is simple: if losing this resource, or being unable to recreate it exactly, would cost you real time or real data, it belongs in a template. If it wouldn't, don't feel obligated to formalize it just for the sake of consistency.

Ethan's honest opinion

"People treat this as an all-or-nothing religious choice, and it isn't one," Ethan told Jake over coffee one Monday morning — the same Monday, coincidentally, that the shop's printer had jammed twice before 9 a.m. "Your printer doesn't need a template. Your customer database absolutely does. The test isn't 'is this cloud infrastructure,' it's 'would I be upset if I couldn't remember how I built this.'"

Frequently asked questions

What is Infrastructure as Code in simple terms?

It's describing your servers, databases, and networks in a text file instead of building them by clicking through a cloud console, and then having a tool read that file and build the real thing to match. Change the file, run the tool again, and the infrastructure changes with it.

Is Infrastructure as Code the same thing as DevOps?

No. DevOps is a broader set of practices and culture around building and operating software quickly and reliably. IaC is one specific technique that supports it — it makes infrastructure changes fit into the same review-and-automate workflow as application code, which is a big part of what makes fast, reliable DevOps practices possible in the first place.

Do I need to know how to code to use IaC?

Not in the traditional programming sense. A CloudFormation template written in YAML looks more like a structured list than a program — you're naming resources and setting values, not writing loops or functions. AWS CDK is the exception, since it does use a real programming language, but plain CloudFormation or AWS SAM don't require prior coding experience to get started.

What is the difference between declarative and imperative IaC?

Declarative tools, like CloudFormation and Terraform, have you describe the end result you want and leave the tool to figure out how to get there. Imperative approaches have you write out the steps yourself. AWS CDK is a hybrid: you write imperative-style code in a real language, but it compiles down into a declarative CloudFormation template before anything is deployed.

Is AWS CloudFormation free?

Using CloudFormation with standard AWS resource types costs nothing extra — you only pay for the resources it creates, the same as if you'd built them by hand. Charges only appear for third-party resource types or custom hooks, billed per handler operation, with 1,000 free operations per account each month and $0.0009 per operation beyond that.

What's the real difference between CloudFormation and Terraform?

Both are declarative, but CloudFormation is AWS-only and AWS itself keeps track of what's deployed, with no separate file for you to manage. Terraform works across many cloud providers with one configuration language, but it keeps its own state file to track what it manages, and that file has to be protected and kept in sync or the tool loses track of your resources.

What is a CloudFormation stack?

A stack is the running set of AWS resources that were created from one CloudFormation template. You give a stack a name when you create it, and every future update to that infrastructure happens by updating the same stack rather than starting a new one.

What is a CloudFormation change set and why does it matter?

A change set is a preview of exactly what CloudFormation is about to do to a stack before it does it — which resources will be created, modified in place, or deleted and replaced. It matters because a replacement means data loss for anything that holds state, like a database, and the change set is what lets you catch that in advance instead of discovering it after the fact.

What is configuration drift and how do I fix it?

Drift is when a resource's actual, live configuration no longer matches what your template says it should be, usually because someone changed it directly in the console instead of through the template. Fix it by running drift detection, reviewing which properties differ, and then either updating your template to reflect the new intended state or correcting the live resource to match the template again.

Can CloudFormation stop people from making changes in the console?

No, not by itself. CloudFormation detects and reports when a manual change has happened; it doesn't have a built-in way to block console access. Actually preventing manual changes requires a separate control, such as restricting IAM permissions so that broad resource actions live only in an automated deployment role, not in individual users' own policies.

What is the AWS CDK and how is it different from CloudFormation?

AWS CDK is an open-source framework that lets you define your infrastructure using a real programming language — TypeScript, Python, Java, C#/.NET, or Go — instead of writing YAML or JSON by hand. It doesn't replace CloudFormation; it generates a CloudFormation template from your code and then deploys through CloudFormation the same way a hand-written template would.

Can I bring existing AWS resources under CloudFormation management?

Yes. CloudFormation supports importing existing resources into a stack, so you can bring infrastructure you originally built by hand under template management without deleting and recreating it, which avoids the data loss or downtime that recreating it from scratch would risk.

What happens if a CloudFormation deployment fails halfway through?

CloudFormation automatically rolls the stack back to its last known working state when an error occurs during a deployment, rather than leaving the account in a half-built condition that you'd have to manually clean up.

Should a small team even bother with Infrastructure as Code?

If the infrastructure holds real customer data, or if losing the ability to recreate it exactly would cost real time, then yes — the value shows up the first time someone leaves, a resource gets accidentally deleted, or you need a second identical environment. For truly disposable, one-off resources with nothing important attached, the overhead may not be worth it yet.

What is AWS SAM and when should I use it instead of plain CloudFormation?

AWS SAM is a shorthand template format built specifically for serverless applications made of Lambda functions and their triggers. Use it when most of what you're deploying is Lambda-centric, since it lets you describe a function and its trigger in far fewer lines than raw CloudFormation would require, while still deploying through CloudFormation underneath.

What is the safest way to start using IaC without breaking production?

Write and deploy your first template against a brand-new, empty environment or test account, not something already serving customers. Once you're comfortable with how change sets and rollbacks behave, bring existing production resources under management using CloudFormation's resource import feature instead of rebuilding them from scratch.

Revision note. Written September 2026, but this will need a revisit if AWS reshapes how change sets, drift detection, or stack sets permissions behave, or if a new AWS-native IaC tool joins this list. If you're the one who inherited a pile of hand-clicked infrastructure with no record of how it was built, you're not behind — you're exactly the person this whole approach was built for, and the first template you write today is the last time you'll ever have to remember those settings from memory again.