AnsibleByExample

Ansible Playbook Example: Create an S3 Bucket with Encryption

Beginner
2024-01-014By Luca Berton

Lesson 1 of 25 in AWS Automation

AWS with Ansible — full curriculum
  1. 1. AWS Basics for Ansible
  2. 2. Installing the amazon.aws Collection and boto3
  3. 3. AWS Credentials and Profiles: Safe Configuration
  4. 4. Your First AWS Playbook: Regions, Tags and Idempotency
  5. 5. AWS Dynamic Inventory with the aws_ec2 Plugin
  6. 6. Grouping and Filtering Hosts with keyed_groups and Filters
  7. 7. Provisioning EC2 Instances
  8. 8. AMIs and Launch Templates
  9. 9. Building VPC Networks with Ansible
  10. 10. Security Groups and Network Access Control
  11. 11. Elastic IPs and Load Balancers
  12. 12. S3 Buckets and Object Management
  13. 13. IAM Users, Roles and Policies
  14. 14. RDS Databases with Ansible
  15. 15. Route 53 DNS Automation
  16. 16. CloudWatch Monitoring and Alarms
  17. 17. Managing Secrets: Secrets Manager, SSM Parameter Store and Ansible Vault
  18. 18. Post-Provisioning Configuration with Roles
  19. 19. Bridging Provisioning and Configuration: add_host and wait_for
  20. 20. Auto Scaling Groups and Rolling Updates
  21. 21. Validating Infrastructure with Assertions and Health Checks
  22. 22. Error Handling and Rollback in AWS Playbooks
  23. 23. Structuring a Reusable AWS Automation Project
  24. 24. Cost Control and Teardown Playbooks
  25. 25. Capstone: Provision and Configure a Multi-Tier AWS Application
View path overview →

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed the new Automation Portal in AAP 2.7 — a self-service template gallery where operators click "Start" without knowing where a playbook lives or how it's configured. One of the catalog entries was Cloud - Create S3 Bucket, described as creating a compliant S3 bucket with encryption. Here's a runnable playbook that matches that job.

Example playbook

---
- name: "Cloud - Create S3 Bucket"
  hosts: localhost
  gather_facts: false
  connection: local

  vars:
    bucket_name: "acme-app-logs-prod"
    bucket_region: "eu-west-1"
    kms_key_alias: "alias/s3-default"
    bucket_tags:
      environment: "production"
      owner: "platform-team"
      cost_center: "cc-4821"

  tasks:
    - name: Create S3 bucket
      amazon.aws.s3_bucket:
        name: "{{ bucket_name }}"
        region: "{{ bucket_region }}"
        state: present
        tags: "{{ bucket_tags }}"

    - name: Enforce default encryption with KMS
      amazon.aws.s3_bucket:
        name: "{{ bucket_name }}"
        region: "{{ bucket_region }}"
        state: present
        encryption: "aws:kms"
        encryption_key_id: "{{ kms_key_alias }}"

    - name: Block all public access
      amazon.aws.s3_bucket:
        name: "{{ bucket_name }}"
        region: "{{ bucket_region }}"
        state: present
        public_access:
          block_public_acls: true
          ignore_public_acls: true
          block_public_policy: true
          restrict_public_buckets: true

    - name: Enable versioning for recovery and compliance
      amazon.aws.s3_bucket:
        name: "{{ bucket_name }}"
        region: "{{ bucket_region }}"
        state: present
        versioning: true

What it does

The playbook builds an S3 bucket in four idempotent steps: create the bucket with baseline tags, turn on default server-side encryption using a KMS key, lock down every public-access setting, and enable versioning. Each task targets the amazon.aws.s3_bucket module and can be re-run safely — running it twice won't recreate the bucket or fail, it just confirms the desired state.

This is exactly the shape of job the Automation Portal template wraps: a platform team pre-builds and tests the playbook, sets survey fields for bucket_name, bucket_region, and tags, and publishes it as "Cloud - Create S3 Bucket." A developer or app owner then clicks Start, fills in a short form, and gets a compliant bucket without ever opening a YAML file or knowing which controller node the job runs from.

Splitting encryption, public-access blocking, and versioning into separate tasks (rather than one giant module call) makes the playbook easier to read in job output and easier to extend — for example, adding a lifecycle policy task later without touching the rest.

Notes / Gotchas

  • Credentials: this playbook assumes AWS credentials are supplied via an AAP credential attached to the job template (or environment variables/instance profile when run outside AAP) — don't hardcode aws_access_key/aws_secret_key in the play.
  • KMS key must exist first: encryption_key_id expects an existing alias or ARN; the module won't create the key for you.
  • Bucket names are global: S3 bucket names are unique across all of AWS, not just your account — a survey-driven template should validate or namespace the name to avoid collisions.
  • Public access block vs. bucket policy: public_access settings block ACL- and policy-based public exposure, but a bucket policy explicitly granting public reads can still conflict — audit policies separately if compliance requires it.
  • Collection requirement: amazon.aws.s3_bucket ships in the amazon.aws collection; make sure it's installed in the execution environment the job template uses, or the job will fail at task one with a "couldn't resolve module" error.

Takeaway

A handful of amazon.aws.s3_bucket tasks are enough to produce a tagged, encrypted, locked-down, versioned bucket — and wrapping that playbook in a self-service template, as shown for AAP 2.7's Automation Portal, turns it into a one-click action for anyone who needs storage without needing AWS console access.

References

All Tutorials