Build an AAP Self-Service Template: Provision an AWS EC2 Instance

Why Self-Service EC2 Provisioning Matters

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed one of the headline features of Ansible Automation Platform (AAP) 2.7: the new Automation Portal. Instead of asking developers to hunt through job templates, learn survey field names, or figure out which project holds the right playbook, the Automation Portal exposes a self-service gallery of pre-approved templates. Each one has a single "Start" button. Click it, answer a short form, and the automation runs — no knowledge of Ansible internals required.

Among the templates shown live in the demo catalog was Cloud - Provision AWS EC2 Instance: a template that spins up an EC2 instance with standard tagging applied automatically. This article walks through how a platform engineering team would design, build, and publish that exact template so it shows up correctly in the Automation Portal catalog.

See also: Build an AAP Self-Service Template: Create a Compliant S3 Bucket

What the Demo Catalog Looked Like

The Bunnik demo catalog spanned several operational domains, not just cloud. Seeing the full list helps clarify where EC2 provisioning fits in the bigger self-service picture:

Step 1: Write the Underlying Playbook

The self-service experience is only as good as the job template underneath it. Start with a playbook that provisions the instance and immediately applies your organization's standard tagging scheme — this is exactly the behavior called out in the demo.

---
- name: Cloud - Provision AWS EC2 Instance
  hosts: localhost
  gather_facts: false
  connection: local

  vars:
    instance_type: "{{ ec2_instance_type | default('t3.medium') }}"
    environment_tag: "{{ ec2_environment | default('dev') }}"

  tasks:
    - name: Launch EC2 instance
      amazon.aws.ec2_instance:
        name: "{{ ec2_name }}"
        key_name: "{{ ec2_key_pair }}"
        instance_type: "{{ instance_type }}"
        image_id: "{{ ec2_ami_id }}"
        subnet_id: "{{ ec2_subnet_id }}"
        security_group: "{{ ec2_security_group }}"
        wait: true
        tags:
          Name: "{{ ec2_name }}"
          Environment: "{{ environment_tag }}"
          Owner: "{{ ec2_requester }}"
          CostCenter: "{{ ec2_cost_center }}"
          ManagedBy: "ansible-automation-platform"
      register: ec2_result

    - name: Report provisioned instance details
      ansible.builtin.debug:
        msg: >
          Instance {{ ec2_result.instances[0].instance_id }}
          launched in {{ ec2_subnet_id }} with tags applied.

Notice that every variable a requester might normally have to guess — AMI ID, subnet, security group, cost center — is parameterized. That parameterization is what the survey layer will drive.

See also: Build an AAP Self-Service Template: Request an Azure Resource Group

Step 2: Design the Survey for Non-Expert Requesters

The whole point of the Automation Portal is hiding complexity. A well-designed survey turns a raw job template into something a developer or business user can complete in under a minute:

• Instance name (text field, required)
• Environment (multiple choice: dev, staging, production)
• Instance size (multiple choice: small / medium / large, mapped internally to real instance types)
• Cost center (text field, required, validated against a regex if your finance team needs a specific format)
• Requester email (text field, auto-populated from the logged-in user where possible)

Step 3: Publish the Template to the Automation Portal

Once the job template and survey exist in AAP, publishing it into the Automation Portal catalog is a matter of:

1. Marking the job template as available for self-service (visible in the portal, not just the controller UI).
2. Assigning it a clear, action-oriented name — the demo catalog's naming convention (Cloud - Provision AWS EC2 Instance) uses a Domain - Action pattern that keeps a growing catalog scannable.
3. Setting RBAC so only appropriate teams can see and launch it — self-service does not mean unrestricted access.
4. Confirming the "Start" button surfaces the survey correctly and that credentials (AWS access in this case) are attached to the template rather than requested from the end user.

See also: Build an AAP Self-Service Template: After Hours Branch Access Report

Standard Tagging: Why It's Non-Negotiable

The demo explicitly called out "standard tagging" as part of what the EC2 template does automatically. This is a governance win as much as a technical one — every instance created through the portal gets consistent Environment, Owner, CostCenter, and ManagedBy tags without the requester having to know or care about your tagging policy. That consistency pays off downstream in cost allocation reports, security audits, and automated lifecycle policies (e.g., a nightly job that stops all Environment=dev instances outside business hours).

Key Takeaways

• AAP 2.7's Automation Portal turns job templates into a one-click, self-service catalog — no playbook or survey knowledge required by the requester.
• The Cloud - Provision AWS EC2 Instance template demoed at Red Hat Tech Day Netherlands 2026 spins up an instance and applies standard tagging automatically, removing a common source of cloud governance drift.
• A good self-service template pairs a parameterized playbook with a short, focused survey — hide complexity, don't just relocate it.
• Credentials belong on the job template, never in the requester's hands, preserving both the self-service experience and your security posture.
• Consistent naming (Domain - Action) and tight RBAC keep a growing self-service catalog usable as more templates are added alongside network, branch, and patching automations.