10 Infrastructure as Code Examples for 2026

Your team ships a hotfix at 6:40 p.m. Staging passed. Production fails. An environment variable was changed by hand three weeks ago, an IAM permission exists in one account but not another, and nobody is fully sure which security group rule is serving traffic. At that point, infrastructure as code becomes a survival tool for a startup, not a nice process upgrade.

IaC puts infrastructure in version-controlled files, under review, with CI checks and a repeatable path to rebuild what broke. That matters for speed, but it also matters for risk. Manual changes create hidden drift, widen your audit gap, and make incident response slower because the team is reconstructing decisions from screenshots, shell history, and memory.

For US startups and SMBs, the primary payoff is operational discipline with a smaller team. You reduce the odds that one engineer becomes the human control plane. You also get a clearer way to price your architecture choices, because code makes it easier to see what you are running, where you duplicated resources, and which environments should scale down after hours.

Security also gets better when it is defined with the stack. IAM policies, network rules, encryption settings, secret handling, and logging should be reviewed in the same workflow as the infrastructure they protect. If you're also tightening security while you automate, keep ThreatCrush's 2026 security automation guide nearby. Security controls need to be codified with the infrastructure, not bolted on after the stack is already live.

Analysts at MarketsandMarkets describe demand for IaC in terms of cloud setup, deployment automation, and disaster recovery in their infrastructure as code market overview. That tracks with what happens inside early-stage companies. The first win is rarely elegance. It is getting consistent environments, faster recovery, and fewer late-night fixes caused by undocumented changes.

The 10 examples below are meant to help you choose, not just copy syntax. Each one includes where it fits, where it creates operational overhead, what security details teams often miss, and how I would assess it for an SMB that needs reliability without hiring a large platform team.

1. Terraform HCL Configuration for AWS Multi-Region Deployment

Terraform is still the default answer when a startup wants one workflow across cloud services, regions, and sometimes multiple providers. If you need to stand up VPCs, subnets, EC2, RDS, IAM roles, and routing across more than one AWS region, HCL is often the fastest path to a shared language your team can read.

A simple pattern looks like this: one root module per environment, regional modules for shared networking, and app-specific modules for databases or compute. Keep providers explicitly aliased by region. Don't let region selection hide inside variables if your team is still small. Invisible magic makes outages harder to debug.

What works in practice

Terraform is strongest when you treat it like product code, not a folder full of .tf files someone runs from a laptop. That means remote state, pull-request reviews, linting, and a predictable module layout.

• Use remote state early: Store state in S3 or a managed backend before more than one engineer touches production.
• Version modules: A private module registry or disciplined Git tagging prevents “small” module edits from breaking multiple stacks.
• Separate blast radius: Split networking, data, and app layers when possible so one change doesn't threaten everything.

Practical rule: If your Terraform state feels too important to lose, it's too important to keep local.

Trade-offs for SMBs

Terraform's flexibility is also where small teams get cut. State management becomes a real operational problem once you have many resources and environments. That gap shows up especially hard in SMBs trying to scale without a platform team, which is exactly the governance problem described by Platform Engineering's discussion of infrastructure as code setups.

Cost-wise, Terraform itself isn't the expensive part. The hidden bill comes from resource sprawl when modules create “just in case” infrastructure. Security-wise, the common failure mode is secrets leaking into variables, state, or CI output. Use a secrets manager, mark sensitive values correctly, and scan plans before apply.

For SMBs, Terraform is a strong fit when you want cloud-agnostic habits even if you're currently all-in on AWS. It's less pleasant when one SRE is managing dozens of services and nobody has time to impose naming, state, and policy discipline.

2. CloudFormation YAML Templates for AWS Native Infrastructure

CloudFormation is what I recommend when the team is AWS-focused and wants first-party behavior more than cross-cloud portability. If your stack is mostly VPC, ECS, Lambda, RDS, IAM, CloudWatch, and S3, native AWS templates can be a cleaner operational choice than introducing another abstraction layer.

A strong CloudFormation setup usually starts with one stack for networking, another for shared data or messaging, and separate application stacks for each service. Nested stacks help once templates get large, but don't use them to hide bad stack boundaries. If rollback behavior is confusing in development, it'll be worse during an incident.

Why some teams prefer it

CloudFormation's biggest advantage is alignment with AWS itself. When your engineers already live in AWS consoles, IAM, and service docs, the mental model stays consistent. Change sets are especially useful for small teams because they force one more review step before mutation.

• Use change sets in CI: Review intended impact before deployment.
• Keep parameters boring: Region, environment, instance class, and retention settings are good candidates. Don't parameterize every line.
• Store templates with app code: Infra and application changes should travel together when they depend on each other.

CloudFormation also pairs naturally with AWS-native serverless and event-driven tooling. If your future includes SAM or CDK, starting with CloudFormation isn't wasted effort.

Security and cost notes

The main cost risk is stack bloat. Teams often keep adding resources to a “main” stack because it feels convenient, then discover they can't update safely. Keep stacks small enough that rollback is understandable.

For security, IAM resources deserve extra scrutiny in review. The failure mode isn't usually syntax. It's broad permissions that get copied from one template to another because deployment pressure was high. Use explicit policies where possible, and review stack changes like code that could open your perimeter.

For SMBs, CloudFormation makes sense when AWS is your platform and likely to stay that way. It's less attractive if your team already anticipates multi-cloud work or if you want one toolset across AWS and Kubernetes infrastructure.

3. Kubernetes YAML Manifests for Container Orchestration

Kubernetes YAML is one of the most common infrastructure as code examples people touch without always calling it IaC. Your Deployments, Services, Ingress objects, ConfigMaps, Secrets, and network controls are all declarative infrastructure definitions. If you run containerized apps in EKS, GKE, AKS, or on-prem clusters, this is operational infrastructure, not just app config.

Many startup teams get into trouble at this stage. Kubernetes makes it easy to ship manifests. It does not make it easy to maintain sane defaults.

A typical starting point is a Deployment, a Service, and an Ingress with environment-specific overlays. That's fine. What isn't fine is skipping requests, limits, probes, and network policy because “we'll add them later.”

To ground that visually:

The operational reality

Kubernetes YAML works best when you keep the base manifests small and push repetition into Helm or Kustomize. Raw YAML everywhere becomes a copy-paste graveyard fast.

• Set resource requests and limits: Without them, one noisy service can starve the cluster.
• Use namespaces deliberately: Team, environment, and workload boundaries get clearer.
• Enforce network policies: Default-open pod networking is convenient until it isn't.

In one DevOps transformation case study, a global e-commerce company improved deployment frequency, shortened lead time, reduced MTTR, and lowered change failure rate after adopting IaC with cloud automation, according to Aurotek's DevOps ROI case study collection. The lesson for Kubernetes teams is familiar: the gains came from codified, repeatable environments and less manual intervention, not from YAML alone.

Kubernetes rewards discipline. It punishes teams that treat the cluster as a dumping ground for defaults.

A quick explainer helps if you're onboarding newer engineers:

Use case for SMBs

For SMBs, Kubernetes YAML makes sense when you're already committed to containers and need repeatable deployments across environments. It's a poor fit if your workload is still simple enough for a managed platform or serverless setup.

Cost control comes down to cluster sizing and manifest hygiene. Over-requested CPU and memory waste money. Under-requested resources create instability. Security-wise, avoid embedding secrets directly, restrict service account permissions, and don't assume the managed control plane solves your workload security for you.

4. Ansible Playbooks for Configuration Management and Deployment

Ansible is the tool I reach for when the infrastructure exists but the server configuration is inconsistent. It's less about creating every cloud primitive and more about making sure machines behave the same way every time. Package installs, user accounts, SSH hardening, app config files, cron jobs, service restarts, and deployment steps all fit naturally here.

This is especially useful in hybrid reality. A lot of startups have cloud VMs, maybe a few legacy boxes, and one awkward workload that isn't ready for containers. Ansible handles that mess better than tools that assume everything is greenfield.

Where playbooks shine

The best Ansible setups use roles, clean inventories, and idempotent tasks. The worst ones become giant procedural scripts disguised as YAML.

• Break work into roles: Web server, runtime, monitoring agent, and app deployment should be reusable units.
• Use Vault for secrets: Never leave credentials in plain variables.
• Run check mode in CI: It won't catch everything, but it catches enough to justify the habit.

A lot of teams combine Terraform and Ansible for good reason. Terraform creates the network and compute. Ansible configures the hosts. That split maps well to startup teams because it keeps each tool doing what it's good at.

Recovery, auditability, and drift

One of the underappreciated benefits is recovery speed when a machine drifts or dies. In a survey discussed by env0's DORA metrics perspective on infrastructure as code, teams reported that version-controlled infrastructure history reduced MTTR by 70 to 80 percent, and developer time savings reached up to 40 percent per project after IaC adoption. That tracks with what experienced operators see in practice. If your host configuration is codified, replacing a broken node becomes routine instead of archaeological work.

For SMBs, Ansible is a strong fit if you still run VMs directly, manage internal tools on hosts, or need a low-friction automation layer without installing agents. The main trade-off is that Ansible can encourage imperative habits. If your playbooks read like shell scripts with YAML indentation, maintenance gets ugly fast.

Security-wise, lock down SSH access, scope credentials tightly, and treat inventory files as sensitive operational data. Cost-wise, Ansible saves money indirectly by reducing manual server babysitting and shortening recovery work.

5. Docker Compose YAML for Local Development and Multi-Container Applications

Docker Compose isn't a full cloud provisioning system, but it belongs on this list because it solves one of the most expensive forms of engineering waste: local environment inconsistency. If every developer boots a slightly different stack for the API, database, cache, worker, and frontend, you'll keep paying for bugs that shouldn't exist.

Compose gives startups a practical bridge between laptop development and containerized deployment. A docker-compose.yml file can define service dependencies, ports, volumes, networks, and environment variables in one place. That alone can stabilize onboarding and day-to-day work.

What good Compose usage looks like

Compose is best for local and lightweight integration environments. It's not the right answer for complex production orchestration.

• Separate dev and prod concerns: Use overrides or separate files instead of one giant compromise config.
• Define health checks: Startup order without service readiness checks is fragile.
• Use named volumes intentionally: Persist what should survive restarts, not everything by default.

If your team is moving toward container-based delivery, understanding the impact of containerization on CI/CD matters because local Compose workflows often shape how people design images, dependency graphs, and testing steps later.

Use case for SMBs

For SMBs, Compose is one of the highest-ROI infrastructure as code examples because it improves engineering consistency quickly. A new hire can often go from clone to running stack with a small set of commands instead of tribal-knowledge setup docs.

The downside is false confidence. A Compose stack that works locally does not prove your service will behave correctly behind a load balancer, with production networking, or under orchestration. Keep the scope honest. Use it to standardize development and smoke-test multi-service behavior.

Security notes are straightforward. Don't hardcode secrets in the compose file, be careful with exposed ports, and review mounted volumes so you don't accidentally give a container broad access to the host filesystem. Cost impact is mostly positive through faster onboarding and fewer environment-specific bugs.

6. Pulumi Python or TypeScript Code for Programmatic Infrastructure

Pulumi is one of the clearest examples of where IaC is heading. Instead of using a domain-specific format like HCL or plain YAML, you define infrastructure in a general-purpose language such as Python or TypeScript. That changes who can contribute and how much software engineering discipline you can bring into the infra layer.

If your application team already lives in TypeScript or Python, Pulumi can reduce the context switch between app code and infra code. Loops, functions, tests, shared libraries, and stronger abstractions become natural. For startups that want developers to participate in infrastructure without learning a separate syntax first, that's a real advantage.

Where it fits well

Pulumi works especially well when infrastructure logic is dynamic or when you want reusable internal components instead of a pile of templates. It also aligns with the growing interest in Infrastructure-from-Code, where infra definitions stay closer to application logic. That emerging shift, and the team-structure decisions around it, is outlined in Architect Elevator's discussion of IaC and IfC trends.

• Use stacks for environments: Keep dev, staging, and prod isolated but structurally similar.
• Create reusable components: Encode your VPC, service, or database patterns once.
• Test infrastructure code: Even lightweight tests catch bad assumptions earlier.

Field advice: If your app engineers keep asking for “real code” instead of templates, pay attention. Tool fit matters.

Trade-offs for startup teams

Pulumi isn't automatically better just because it uses a familiar language. It can also encourage overengineering. I've seen teams build elaborate abstractions before they had stable requirements. The result was hard-to-read infra code that looked clever and slowed everyone down.

For SMBs, Pulumi is attractive when you have strong software engineers who want to own more of the delivery stack and you value code reuse heavily. It's less ideal when your team wants simple, highly standardized templates that non-developers can parse quickly.

Security and cost concerns are the same old truths in a different wrapper. Secrets still need disciplined handling. Provisioning logic still needs review. And rich language features make it easier to accidentally generate too much infrastructure if your abstractions are sloppy.

7. AWS SAM Templates for Serverless Deployments

If you're building on Lambda, API Gateway, SQS, SNS, DynamoDB, and other event-driven AWS services, SAM is one of the cleanest infrastructure as code examples available. It sits close to CloudFormation but removes a lot of repetitive setup for serverless apps.

This matters for startups because serverless can be a very efficient way to ship products without taking on full-time cluster or VM operations. You define functions, events, policies, and APIs in YAML, test locally, and deploy in a repeatable way.

Why SAM is practical

The biggest operational benefit is consolidation. App code and infra definitions can live together in a way that's easy to reason about. A handler, its IAM policy, and its trigger don't need to be scattered across multiple tooling layers.

• Use local testing: sam local start-api is worth the setup.
• Keep IAM narrow: SAM policy templates are convenient, but convenience can become over-permissioning.
• Organize functions by domain: Avoid one template where every function in the company lives forever.

Serverless also changes your cost model. You don't pay for idle capacity the same way you do with always-on compute. That makes SAM appealing for bursty workloads, internal tools, and early-stage products with uneven traffic.

Security and SMB fit

The easy mistake is assuming “managed” means “secure by default.” Function permissions, environment variables, dead-letter handling, and public API exposure still need review. If a function touches sensitive data, its execution role deserves the same scrutiny you'd give a service account in Kubernetes.

For SMBs, SAM is a strong fit when the product is event-driven, API-heavy, or still proving demand and you want low ops overhead. It's less compelling when your architecture already centers on long-running containers or when your team needs portability outside AWS.

Operationally, keep observability in mind. Serverless systems are easy to deploy and easy to lose track of. Instrument logs, tracing, and alerting from the start, or debugging a chain of events will become expensive in engineer time.

8. Helm Charts for Kubernetes Application Packaging and Templating

Helm exists because raw Kubernetes YAML doesn't scale gracefully once you have multiple services, environments, and shared deployment patterns. A chart gives you packaging, templating, values files, and release handling in a way that can keep cluster operations sane.

For startups running several services on Kubernetes, Helm often becomes the line between manageable reuse and endless manifest duplication. I've seen teams resist it because templates feel abstract. Then six months later they have five nearly identical Deployments with tiny hand-edited differences and no confidence in what should be standardized.

Where Helm helps most

Helm is strongest when you need environment variation without rewriting the base deployment every time. Image tags, replica settings, resource limits, ingress hosts, and feature flags all belong in values, not in copied files.

• Start from proven charts: Community charts can save time, but review them carefully before production use.
• Lint every change: helm lint should be automatic.
• Keep values files readable: If nobody can tell what differs between staging and prod, your chart design is off.

A healthy Helm setup usually pairs with GitOps tooling so releases are visible and revertable. That's much safer than one engineer manually running upgrade commands from memory.

Security, cost, and team impact

Helm can hide dangerous complexity. A chart that renders correctly can still deploy insecure defaults, broad RBAC, or wasteful resource allocations. Review rendered manifests, not just template files.

For SMBs, Helm makes sense when Kubernetes is already established and you want internal standards for deployment shape. It's overkill if you only run one or two simple workloads and haven't stabilized your cluster conventions yet.

Cost-wise, Helm doesn't save money directly. It helps teams standardize requests, autoscaling patterns, and sidecar usage, which can reduce waste if you review those defaults. Security-wise, use it to enforce good patterns, not to mass-produce bad ones.

9. CDK in TypeScript for Infrastructure as Code

AWS CDK is often the right answer for teams that are fully committed to AWS and want infrastructure defined in TypeScript rather than YAML. It synthesizes to CloudFormation, but the authoring experience is much closer to software development than to writing raw templates.

That combination is powerful for product teams already writing backend services in TypeScript. Shared constructs, typed configs, and code reuse make infra easier to standardize. For example, you can create one opinionated construct for a service that includes logging, alarms, IAM defaults, and networking instead of rebuilding that logic by hand for every app.

Why CDK works for some founders

The appeal is speed with guardrails. You can express AWS patterns at a higher level than CloudFormation and still stay inside the AWS ecosystem.

• Prefer higher-level constructs: They reduce boilerplate and usually encode better defaults.
• Test stack assertions: Infra code deserves tests, especially around IAM and networking.
• Split stacks by ownership: Don't let one monolith CDK app become your entire platform.

CDK is also a good cultural fit when developers own more of the deployment path. You're using application-language habits on the infrastructure side without moving away from AWS-native deployment machinery.

SMB use case and caution points

For SMBs, CDK is a strong fit if your backend engineers know TypeScript, your cloud strategy is AWS-first, and you want abstractions you can package internally. It's less attractive if you expect provider neutrality or if your ops team prefers highly explicit templates over generated output.

The common risk is abstraction creep. Teams get excited about constructs and build a private framework before they've proven the deployment patterns they want to standardize. Keep the first generation simple.

Security-wise, generated infrastructure can still produce broad permissions if your constructs are careless. Review synthesized output for sensitive changes. Cost-wise, CDK improves developer productivity more than cloud spend directly, though reusable patterns can reduce expensive configuration mistakes.

10. Bicep Templates for Azure Infrastructure Deployment

If your startup runs on Azure, Bicep is usually the cleaner choice over raw ARM templates. It keeps the Azure-native model but makes authoring more maintainable. That matters because few teams enjoy writing large JSON templates by hand, and maintainability is what decides whether IaC survives past the first implementation.

Bicep works well for virtual networks, app services, storage accounts, managed identities, key vaults, and Azure policy-aligned deployments. The syntax is compact enough that teams can review it without feeling like they're parsing machine output.

Why Bicep is worth adopting

Bicep's module system is the practical win. You can package standard networking, security, and application patterns and reuse them cleanly across environments.

• Use modules for shared patterns: Networking and identity are obvious first candidates.
• Validate inputs with decorators: Prevent bad parameter values before deployment.
• Lint before every release: Catch style and quality issues early.

For Azure teams, this usually becomes the maintainable middle ground. You stay close to the platform, but the code is readable enough to survive team changes and growth.

Security and SMB fit

For SMBs, Bicep is the right fit when Azure is your primary cloud and you want native alignment without living in ARM JSON. It's especially useful in organizations that already depend on Microsoft tooling, identity, and governance features.

The same security themes apply here too. Managed identities beat embedded credentials. Key Vault should handle secrets. Network exposure and role assignments deserve review in every pull request.

Cost-wise, Bicep helps by making repeatable environments easier to tear down and rebuild, which reduces the “temporary” Azure resources that linger. It won't solve spend by itself, but it makes lifecycle discipline more realistic.

IaC Examples: Side-by-Side Comparison

Choosing Your IaC Stack Key Takeaways for SMBs

A five-person startup usually feels this decision when something breaks at the wrong time. A production fix needs to go out, a new environment has to be created fast, and nobody wants to guess whether the last manual change in AWS, Azure, or Kubernetes was documented anywhere. That is the moment your IaC choice stops being a tooling preference and becomes an operating model decision.

Start with the team you have, not the platform maturity you hope to have in a year. If one engineer owns infrastructure part time, the best stack is usually the one that is easiest to review, easiest to hire for, and hardest to misuse under pressure. For many U.S. SMBs, that means choosing fewer tools with clearer ownership instead of chasing the most flexible combination on paper.

Terraform remains the default pick for startups that need shared cloud provisioning across accounts, environments, or providers. The upside is portability and a large hiring pool. The cost is operational discipline. Remote state, module standards, provider version pinning, secret handling, and policy checks all need real ownership. Without that, Terraform spreads fast and becomes expensive to clean up later.

AWS-first teams usually benefit from staying closer to the platform. CloudFormation fits organizations that want direct AWS parity and fewer abstraction layers. SAM is often the faster route for Lambda and API-driven products where local testing and simple deployment flows matter. CDK works well for teams that already write a lot of TypeScript and want to reuse software engineering patterns, but it can hide generated complexity from engineers who never inspect the CloudFormation underneath.

Azure-first teams should usually choose Bicep unless there is a strong reason not to. It is easier to maintain than raw ARM JSON and keeps deployment logic close to Azure's native model. That matters for small teams because every extra translation layer adds debugging time, and debugging time is labor cost.

Containers change the decision tree. Kubernetes YAML is hard to avoid once you run production workloads on Kubernetes, but raw manifests alone become painful as services multiply. Helm starts paying off when you need repeatable releases, environment-specific values, and versioned packaging. Docker Compose still has a place, but mostly on laptops and in lightweight integration testing. Using Compose as a production strategy usually creates reliability gaps, weak secrets handling, and messy scaling limits.

Ansible fills a different gap. It is useful when you still have VMs, legacy services, compliance-driven host configuration, or one-off systems that are not worth containerizing yet. That is common in SMB environments. The trade-off is drift. If teams run playbooks inconsistently or keep making direct server changes, Ansible can document intent without enforcing it.

The strongest setup for many startups is layered, not pure. Terraform or Bicep handles base infrastructure. SAM or CDK covers AWS serverless where it reduces friction. Helm manages Kubernetes applications once the cluster estate gets real. Ansible stays focused on host configuration and awkward edge systems. That mix is easier to defend than trying to force one tool to solve every problem badly.

Security should narrow your options fast. Pick tooling your team can review line by line. IAM sprawl, wildcard permissions, public storage defaults, and secrets committed into repos are usually process failures expressed through IaC. Tools with policy checks, reusable secure modules, and clear plans reduce risk. Tools that generate a lot of hidden behavior can be fine in experienced hands, but they are a bad fit for a small team that is still building cloud review habits.

Cost control follows the same pattern. IaC does not reduce spend by itself. It gives you repeatable ways to enforce instance sizes, shut down preview environments, tag resources for chargeback, and catch expensive changes in code review before they hit the bill. SMBs should value that more than feature breadth. A simpler stack with tight approval rules often saves more money than a more flexible stack with weak governance.

For U.S. startups, the market is mature enough that tool choice is rarely blocked by ecosystem risk. As noted earlier, North America remains a large IaC market, which usually means better contractor availability, more mature vendor support, and easier hiring for common stacks. That helps, but it does not remove the need for standards, ownership, and review discipline inside your team.

A practical rule works well here. Choose the stack a new engineer can understand in a week, a senior engineer can secure in a month, and the company can still afford to maintain after the first growth sprint.

For AWS-specific planning and migration context, IT Cloud Global, LLC AWS guide is a useful companion read.

DevOps Connect Hub helps U.S. startups and SMBs make smarter DevOps decisions before tooling sprawl, hiring mistakes, and cloud costs pile up. If you're choosing between Terraform, Kubernetes, Ansible, CDK, or a mixed stack, visit DevOps Connect Hub for practical guides, vendor comparisons, and implementation advice built for founders, CTOs, and engineering leaders.