Ansible for Cloud Provisioning

Analogy categoryAnalogies

Provisioning Cloud Infrastructure with Ansible

Ansible modules such as amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine, and google.cloud.gcp_compute_instance let a playbook create, modify, and destroy cloud resources declaratively, describing the desired end state rather than a sequence of imperative API calls. This lets a team treat infrastructure provisioning and host configuration as one tool and one language, rather than needing a separate provisioning tool bolted in front of the configuration step — though in practice many teams still pair Ansible with a dedicated provisioning tool like Terraform for the resource-graph and state-locking benefits it provides.

🏏

Cricket analogy: Using Ansible to provision cloud servers is like a franchise using the same auction system to both sign new players and manage existing squad contracts, keeping recruitment and retention in one unified process rather than two separate systems.

Modules, Collections, and Idempotent Provisioning

Cloud provisioning modules are idempotent by design: running ec2_instance again with the same name tag doesn't create a duplicate instance, it converges the existing one toward the declared state (or reports no change if it already matches). These modules ship in collections such as amazon.aws, azure.azcollection, and google.cloud that must be installed separately via ansible-galaxy collection install, and they typically require the corresponding vendor SDK — boto3 and botocore for AWS, the Azure Python SDK, or google-auth and google-api-python-client for GCP — to be present on the control node (or in the execution environment) alongside the collection itself.

🏏

Cricket analogy: Idempotent provisioning is like re-submitting the same team sheet for a rain-delayed match — the scorer recognizes it's unchanged and doesn't re-register the same eleven players twice.

yaml

- name: Provision and register a web server instance
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Launch (or converge) EC2 instance
      amazon.aws.ec2_instance:
        name: "web-{{ env }}-01"
        region: us-east-1
        instance_type: t3.medium
        image_id: ami-0abcdef1234567890
        key_name: platform-key
        security_groups: ["web-sg"]
        tags:
          Environment: "{{ env }}"
          Role: web
        wait: true
      register: ec2_result

    - name: Add new instance to in-memory inventory
      ansible.builtin.add_host:
        name: "{{ item.public_ip_address }}"
        groups: just_provisioned
      loop: "{{ ec2_result.instances }}"

- name: Configure freshly provisioned web servers
  hosts: just_provisioned
  become: true
  roles:
    - nginx

Provisioning Plus Configuration in One Playbook

The add_host and group_by modules register newly created cloud instances into an in-memory inventory group within the same playbook run, as shown in the code above, so a subsequent play in the same playbook file can immediately target and configure those freshly provisioned hosts without waiting for a separate dynamic inventory refresh. This is what lets a single ansible-playbook invocation both stand up new EC2 instances and finish configuring them with a web server role in one pass, which is convenient for smaller environments even though larger organizations often split provisioning and configuration into separate pipeline stages for auditability.

🏏

Cricket analogy: Using add_host to register new instances mid-play is like a substitute fielder being added to the official team list the moment they step onto the field, immediately available for the next over without a separate paperwork step.

Many teams use Terraform (or a similar tool) purely for provisioning and reserve Ansible for configuration management, since Terraform's resource graph and state file give stronger drift detection across complex multi-resource dependencies. Ansible's cloud modules are a great fit when you want a single, lighter-weight tool to handle both concerns.

Cloud credentials passed to provisioning modules should come from Tower/AWX credential objects, environment variables, or Ansible Vault — never committed in plaintext to a playbook repository, since ec2_instance and similar modules accept access keys directly as parameters if you let them.

Ansible cloud modules like ec2_instance, azure_rm_virtualmachine, and gcp_compute_instance provision infrastructure declaratively.
Cloud provisioning modules are idempotent — re-running them converges existing resources instead of creating duplicates.
Cloud modules live in separate collections (amazon.aws, azure.azcollection, google.cloud) installed via ansible-galaxy.
Collections typically require a vendor SDK (e.g. boto3) present on the control node or execution environment.
add_host and group_by register newly provisioned instances into in-memory inventory within the same play run.
This enables provisioning and configuration in a single playbook invocation, though many teams split the two stages.
Cloud credentials must be sourced from Vault or credential objects, never hardcoded in playbook repositories.