What is cloud automation?

Infrastructure as Code (IaC) replaces manual, error-prone cloud resource management with version-controlled, repeatable configurations. This topic covers cloud automation concepts, the problems IaC solves, and how declarative tools like Terraform fit into a modern DevOps workflow.

You can refer to the following transcript:

The problem with manual infrastructure management

As cloud adoption grows, so does the complexity of managing resources. With a handful of ECS instances, the Alibaba Cloud console works fine. At hundreds or thousands of instances—spread across VPCs, SLB instances, and Auto Scaling groups—clicking through the console becomes a liability.

The traditional approach relies on documents: runbooks, spreadsheets, and wiki pages that record what was configured, what names were assigned, and what parameters were set. This breaks down in two predictable ways:

• Human error: Documents drift from reality. Operators make mistakes, skip steps, or interpret instructions differently.

• Environment inconsistency: Without a single source of truth, each environment—development, testing, production—becomes a "snowflake": a unique configuration that cannot be reproduced automatically.

Replicating an environment from development to production using documents alone is slow and unreliable. Environment drift causes deployment failures that are hard to diagnose and harder to prevent.

What is IaC?

Infrastructure as Code (IaC) converts your infrastructure into version-controlled code. Just as the same source code always compiles to the same binary, an IaC configuration always produces the same environment—no matter how many times you run it.

IaC captures not just what resources exist, but how they relate: an ECS instance that belongs to a specific VPC, sits behind an SLB instance, and scales with Auto Scaling. That entire topology lives in code—reviewable, auditable, and reproducible.

Tools like APIs, CLIs, SDKs, and ROS (Resource Orchestration Service) all support IaC workflows. Terraform has become the most widely adopted approach for declarative IaC on Alibaba Cloud.

Imperative vs. declarative approaches

Two styles of IaC exist, each with different tradeoffs.

Imperative (CLIs, SDKs): You specify every step—call create-instance, then modify-instance, then pass the security group ID. You control the sequence. This gives you precision and flexibility, but requires you to understand the dependencies between every operation and update your scripts whenever infrastructure changes.

Declarative (Terraform, ROS templates): You describe the desired end state—"I need an ECS instance with these parameters in this VPC"—and the tool figures out how to get there. The key property is idempotency: run the same configuration ten times and the result is always the same environment. The tradeoff is less step-by-step control, but significantly less code to maintain.

Terraform is declarative. You define resources, parameters, and their relationships in configuration files. Terraform compares that definition against the current state and makes only the changes needed to match.

IaC in a DevOps pipeline

IaC becomes most powerful when integrated with version control and CI/CD. Every infrastructure change goes through a pull request: reviewable, comparable, and reversible.

Consider a concrete example. Your application runs on:

• ECS (compute)

• Auto Scaling (traffic handling)

• VPC (internal networking)

• SLB (public endpoint)

A new business requirement means adding RDS. Without IaC, adding RDS to three environments (development, testing, production) is three manual operations with three chances for drift. With IaC:

1. Add the RDS resource to your Terraform configuration.

2. Apply in development. Validate.

3. Apply in testing. Confirm consistency with development.

4. Apply in production.

Because all three environments are defined by the same code, consistency is structural—not something you check for manually.

Parallel deployment: a recommended migration practice

When upgrading infrastructure (for example, from V1 to V2), keep both versions running simultaneously for a validation period. This is practical with IaC because creating and destroying environments is fast and low-cost.

While V1 serves production traffic, V2 runs in parallel. Once V2 is validated, run terraform destroy on V1. This approach isolates risk: a failed V2 rollout has no impact on the live environment.

Running parallel environments does increase costs temporarily. The stability and reduced rollback risk are worth it.

Benefits of IaC

• Automation: Code replaces manual processes. Human errors drop. Managing thousands of instances becomes as straightforward as managing ten.

• Flexibility: No more clicking through consoles or following lengthy operation manuals. A single parameter change in code propagates across your entire infrastructure.

• Reusability: Infrastructure patterns become modules. Spin up a new environment by referencing existing code, not rewriting it. Roll back by reverting a commit.

• Security: Permission policies, network access rules, and compliance baselines are all codified and auditable. Security posture is maintained continuously, not enforced ad hoc.

Getting started

If you are new to IaC on Alibaba Cloud, a practical starting point is:

1. Pick a small, isolated resource (a VPC or a single ECS instance).

2. Write a Terraform configuration that describes it.

3. Run terraform plan to preview changes before applying.

4. Add the configuration to a GitHub or GitLab repository for version control.

Building the habit of code-first infrastructure on a small scope makes the transition to managing large-scale environments much smoother.