search

IaC

In Infrastructure as Code (IaC) tools like Terraform, AWS CloudFormation, Pulumi, Ansible, etc., while the syntax and tooling differ, the core concepts largely remain the same and live above the implementation layer. Here's a list of common, higher-level concepts that are shared across most IaC tools:

hashtag
🔁 1. Declarative Configuration

  • You declare what you want, not how to do it.

  • State-based: You describe the desired end state.

  • Tools figure out how to reach that state.

hashtag
📦 2. Resources

  • The fundamental unit of infrastructure (e.g., EC2 instance, S3 bucket, VPC).

  • Defined with properties/configuration.

  • Resources can depend on other resources.

hashtag
🌐 3. Providers/Modules/Plugins

  • Interface to cloud platforms (AWS, Azure, GCP, etc.).

  • Allow abstraction and communication with different APIs.

  • E.g., Terraform’s AWS provider, CloudFormation's resource types.

hashtag
🔗 4. Dependency Management

  • Automatic resolution of which resources depend on others.

  • Ensures proper creation/destruction order.

hashtag
🪢 5. Variables and Parameters

  • Input values to customize infrastructure.

  • Reuse and parameterize templates/modules.

hashtag
📤 6. Outputs

  • Expose key information after deployment (e.g., public IP, DNS name).

  • Used for chaining in multi-stack or multi-module setups.

hashtag
📝 7. Templates / Modules / Reusable Code Blocks

  • Encapsulation of repeated logic.

  • Promote reuse and modularity.

  • Terraform: Modules; CloudFormation: Nested Stacks/Macros.

hashtag
📁 8. State Management

  • Tracks current vs desired infrastructure.

  • Terraform uses state files; CloudFormation stores state in the AWS backend.

  • Helps with planning, drift detection, and targeted updates.

hashtag
🔍 9. Plan and Apply (Preview and Deploy)

  • Dry-run feature: Preview changes before applying.

  • Terraform: terraform plan → terraform apply.

  • CloudFormation: ChangeSets → Execute.

hashtag
🧪 10. Drift Detection

  • Identify configuration drift between actual and declared state.

  • Essential for long-term infrastructure correctness.

hashtag
🧯 11. Error Handling and Rollbacks

  • Most tools support rollback on failure.

  • CloudFormation has built-in rollback; Terraform requires manual intervention unless handled with create_before_destroy.

hashtag
🔐 12. Security and Secrets Management

  • Injecting secrets safely via environment variables, external vaults, or secret managers.

  • Avoid hardcoding sensitive data.

hashtag
📊 13. Tagging / Metadata Support

  • Apply tags or metadata to resources for cost tracking, auditing, and organizing.

hashtag
✅ 14. Validation and Linting

  • Syntax and logic checks before deployment.

  • Terraform: terraform validate, CloudFormation: cfn-lint.

hashtag
🏗️ 15. Idempotency

  • Running the same code multiple times leads to the same result (no duplicate infra).

These concepts live above the actual code or language and are foundational to IaC philosophy regardless of the tool you're using.

Would you like this mapped specifically for Terraform vs CloudFormation vs Pulumi in a comparison table?

Here's a feature-by-feature comparison table of the major Infrastructure as Code (IaC) tools:

Comparing Azure ARM Templates, AWS CloudFormation, and Terraform across common IaC concepts.

Concept / Feature

ARM Templates (Azure)

CloudFormation (AWS)

Terraform (Multi-Cloud)

Language

JSON / Bicep (DSL for ARM)

JSON / YAML

HCL (HashiCorp Configuration Language)

Provider Scope

Azure-only

AWS-only

Multi-cloud (AWS, Azure, GCP, etc.)

Declarative

✅ Yes

✅ Yes

✅ Yes

Resources

Azure resources (VMs, VNets, etc.)

AWS resources (EC2, S3, etc.)

Any supported provider (AWS, Azure, GCP, etc.)

Modules / Reusability

Bicep modules / Linked templates

Nested stacks / Macros

Native Modules (reusable, composable)

Inputs (Parameters / Variables)

Parameters

Parameters

Variables

Outputs

Outputs

Outputs

Outputs

State Management

Managed by Azure (implicit)

Managed by AWS (implicit)

Local or Remote (e.g., S3 + DynamoDB for locking)

Change Preview

❌ No native preview (Bicep adds limited support)

✅ Change Sets

✅ terraform plan

Drift Detection

⚠️ Limited via az resource show / Azure Portal

✅ Built-in

✅ terraform plan (manual)

Rollback on Failure

✅ Yes

✅ Yes

❌ No (must be handled manually)

Loops and Conditionals

✅ Yes (especially in Bicep)

✅ Yes

✅ Yes (using count, for_each, and dynamic)

Secret Management

Integrates with Azure Key Vault

Integrates with AWS Secrets Manager / SSM

External tools (Vault, SSM, etc.)

Custom Resources / Extensibility

Azure Functions / Deployment Scripts

AWS Lambda-backed custom resources

✅ Providers and custom plugins

CLI Tooling

az deployment group create, bicep

aws cloudformation CLI

terraform CLI

Ecosystem & Community

Smaller, Azure-centric

AWS-centric

Huge community + registry of reusable modules

Testing & Validation Tools

bicep build, bicep linter

cfn-lint, cfn-nag

terraform validate, tflint, checkov, etc.

Visual Authoring Support

Azure Portal, VS Code (Bicep)

AWS Console / Designer

Terraform Cloud, VS Code extensions

Idempotency

✅ Yes

✅ Yes

✅ Yes

Execution Mode

Directly via Azure Resource Manager

Directly via CloudFormation service

Plan → Apply via Terraform CLI or Cloud/Enterprise

License

Free, built-in to Azure

Free, built-in to AWS

Open-source + Terraform Cloud (freemium/paid)

Learning Curve

Moderate (easier with Bicep)

Easy to moderate

Moderate (more flexible = more complexity)

hashtag
✅ Summary:

  • ARM Templates: Best for pure Azure environments. Use Bicep to simplify.

  • CloudFormation: Best for AWS-native setups, tightly integrated with AWS.

  • Terraform: Most flexible, reusable, and multi-cloud capable. Best for complex or hybrid environments.

Let me know if you want a downloadable version (e.g., PDF or CSV) or visual chart format!

PreviousRepeated questionsNextadvance

Last updated