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.
- 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:
- nginxProvisioning 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.
Practice what you learned
1. What happens when the ec2_instance module is run again with the same name tag against an already-existing instance?
2. What must be installed on the control node in addition to the relevant Ansible collection to use most cloud provisioning modules?
3. What is the purpose of add_host in a cloud provisioning playbook?
4. Why do many teams still pair Ansible with a tool like Terraform for provisioning?
5. Where should cloud provider credentials used by provisioning modules be stored?
Was this page helpful?
You May Also Like
Dynamic Inventory
Inventory plugins and scripts that pull host lists from live sources like cloud APIs instead of static files, keeping Ansible's view of infrastructure accurate as it changes.
Idempotency in Ansible
The principle that running a playbook repeatedly against the same hosts produces the same end state, and why purpose-built modules achieve it while raw command/shell tasks require extra guards.
Ansible Tower and AWX
A web-based control plane for Ansible that adds job templates, RBAC, scheduling, and notifications on top of core Ansible, available as the open-source AWX project or the commercial Ansible Automation Platform.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics