What’s New in Ansible Certified Content Collection for AWS

Amazon Web Services (AWS) customers managing infrastructure at scale face a common challenge: automation that works today but becomes a liability tomorrow. As your AWS footprint grows, spanning multiple accounts, regions, and services, the automation scripts that once seemed sufficient begin to show cracks. A missing error message here, an inconsistent module behavior there, and suddenly your deployment pipeline is fragile, difficult to debug, and resistant to change.

The amazon.aws Ansible collection version 11.0.0 addresses this challenge head-on. Rather than simply adding new features, this release focuses on making your AWS automation more resilient, maintainable, and aligned with the operational standards that enterprise teams require. For AWS customers using Ansible to manage their cloud infrastructure, this means fewer surprises during deployments, faster troubleshooting when issues arise, and automation that scales confidently alongside your business.

Building on the enhancements introduced in version 10.2.0, this release completes previously announced deprecations, aligns with modern AWS Software Development Kit (AWS SDK) requirements, and refactors core utilities to provide a more consistent developer experience. For teams managing production workloads on AWS, these improvements translate directly to reduced operational overhead and increased confidence in your infrastructure-as-code.

In this blog, we’ll explore what’s new in amazon.aws 11.0.0, recap the key updates from 10.2.0 that set the foundation for this release, and provide a practical upgrade plan to help AWS customers transition smoothly while minimizing disruption to existing automation workflows.

Improved Stability and Maintainability for Amazon S3 Automation

If you’ve ever debugged Amazon Simple Storage Service (Amazon S3) automation failures, you know how frustrating vague error messages can be. A generic “403 Forbidden” might hide:

- A bucket policy issue
- An IAM policy issue
- A region mismatch

This often leads to a time-consuming manual investigation.

Version 11.0.0 of amazon.aws, the Ansible Certified Content Collection for AWS, introduces a rebuilt S3 layer with centralized error handling via S3ErrorHandler.

Clearer Insights: Translates raw AWS service errors into specific, actionable messages. Instead of generic failures, you now get clear, specific messages that point directly to the root cause.
Uniform Logic: The s3_bucket and s3_object modules along with their _info counterparts now share underlying code, ensuring consistent authentication and endpoint behavior.
Faster Resolution: Troubleshooting that once took hours is reduced to minutes by pinpointing exactly whether the issue lies in IAM permissions, bucket policies, or network routing.

For teams managing large-scale S3 deployments across multiple AWS accounts and regions, these improvements mean fewer unexpected failures and faster resolution when issues do occur. Your engineers can spend less time debugging automation and more time building features that matter to your business.

Major Changes and Updates

Version 11.0.0 is a major release and includes the removal of previously deprecated functionality across several modules. Users upgrading from earlier versions should review these changes carefully.

Updated AWS SDK Dependencies

To access the latest security patches and features, ensure your environment meets these minimums:

Boto3 / Botocore: 1.35.0+
AWS CLI: 1.34.0+

Older SDK versions may still work, but compatibility is not guaranteed or tested. Red Hat Ansible Automation Platform will display warnings if deprecated SDK versions are detected. Please refer to individual module documentation for version-specific requirements. Check out the module documentation for the minimum required version for each module.

Removed Deprecated Module Functionality

This collection standardizes how modules return data and accept parameters, creating a more uniform experience when building automation workflows. The changes complete deprecations announced in earlier releases, reducing module complexity while ensuring consistent behavior across the collection. Your playbooks will be easier to read and maintain as a result of these simplifications.

Enforcing Safety and Separation of Concerns

S3 Object Lookups: The s3_object module no longer supports mode: list. You must now use the dedicated s3_object_info module for read-only queries.

Example: Migration to read-only queries

# OLD
- name: Retrieve S3 object metadata 
  amazon.aws.s3_object: 
    bucket: my-bucket 
    mode: list 

# NEW (v11.0.0) 
- name: Retrieve S3 object metadata 
  amazon.aws.s3_object_info: 
    bucket_name: my-bucket

This architectural change prevents accidental data alterations when your intent is simply to query object information. For read-only operations, use s3_object_info as the dedicated module for S3 object lookups.

S3 Key Handling: Leading slashes (/) in S3 keys are no longer supported to ensure uniform key naming across all AWS services.

Example: Migration to Standard Keys

# OLD (Triggers a failure in v11.0.0) 
- amazon.aws.s3_object: 
    bucket: my-bucket 
    object: /test_directory 
    permission: bucket-owner-full-control 
    mode: create 

# NEW (v11.0.0) 
- amazon.aws.s3_object: 
    bucket: my-bucket 
    object: test_directory 
    permission: bucket-owner-full-control 
    mode: create

S3 configuration cleanup: The following parameters have been removed from s3_object_info to avoid invalid configuration combinations that could cause connectivity issues:

dualstack
endpoint_url

Standardizing Returns for Better Templating

To improve consistency and simplify templating, this release standardizes how modules return data.

Route53: aligning with Ansible conventions

To align with Ansible conventions, the route53_info module has transitioned from AWS-style CamelCase returns (ResourceRecordSets and HostedZones) to Ansible-standard snake_case formatting.

Old:

{{ records.ResourceRecordSets[0] }}

New:

{{ records.resource_record_sets[0] }}

IAM: simplifying return structure

The iam_user module now returns all data under a single user key, removing the deprecated iam_user return key. This eliminates ambiguity about which data structure to reference in subsequent automation tasks. For organizations managing AWS Identity and Access Management (AWS IAM) users at scale across multiple accounts, this standardization ensures your automation behaves predictably regardless of the number of users or accounts involved.

Old:

{{ result.iam_user.user_id }}

New:

{{ result.user.user_id }}

Simplifying Configuration and Audits

The collection simplifies module parameters to reduce configuration complexity. The ec2_security_group module no longer accepts nested lists of strings for rules.cidr_ip and rules.cidr_ipv6, instead requiring a flat structure for CIDR rules, making them easier to audit and compliant with automated review tools.

# Before (Nested) 
- name: Create a security group 
  amazon.aws.ec2_security_group: 
    name: my-sg 
    rules: 
       - proto: tcp 
         from_port: 8182 
         to_port: 8182 
         cidr_ipv6: 
           - 64:ff9b::/96 
           - ["2620::/32"] 
- proto: tcp 
  ports: 5665 
  cidr_ip: 
     - 172.16.1.0/24 
     - 172.16.17.0/24 
     - ["10.0.0.0/8", "10.20.0.0/24"] 
 
# After (v11.0.0) 
- name: Create a security group 
  amazon.aws.ec2_security_group: 
    name: my-sg 
    rules: 
- proto: tcp 
         from_port: 8182 
         to_port: 8182 
         cidr_ipv6: 
           - 64:ff9b::/96 
           - 2620::/32 
- proto: tcp 
  ports: 5665 
  cidr_ip: 
     - 172.16.1.0/24 
     - 172.16.17.0/24 
     - 10.0.0.0/24 
     - 10.20.0.0/24

The lambda_info module has also been simplified, with the deprecated function parameter removed. This streamlined interface better reflects current AWS Lambda service definitions.

Highlights from amazon.aws 10.2.0

Version 10.2.0 laid the groundwork for the 11.0.0 release with several significant enhancements. If you haven’t upgraded from earlier versions, here’s what these updates bring to your AWS automation.

New and Enhanced Functionality

This release introduced improvements spanning database performance, storage provisioning, and template simplification.

High-Performance Databases

Applications with demanding I/O requirements need storage that can keep pace. The rds_instance module now supports the io2 storage type, providing access to higher IOPS thresholds for database workloads. This enhancement allows your automation to provision Amazon Relational Database Service (Amazon RDS) instances capable of handling intensive transactional workloads without requiring manual configuration adjustments.

Example: Provisioning an io2 RDS Instance

- name: Create high-performance RDS instance 
  amazon.aws.rds_instance: 
    id: my-db-instance 
    state: present 
    engine: postgres 
    username: "{{ username }}" 
    password: "{{ password }}" 
    storage_type: io2 
    iops: 3000 
    allocated_storage: 100 
    db_instance_class: db.m5.large

Modern EC2 Limits

Automation tools should reflect current service capabilities, not outdated constraints. We’ve increased the throughput (old: up to 1000 MiB/s, new: up to 2000 MiB/s) and IOPS limits (old: up to 16000, new: up to 80000) for GP3 volumes in both ec2_launch_template and ec2_vol modules. These updated limits match current AWS service quotas, ensuring your automation can provision high-performance storage configurations without encountering artificial restrictions.

Example: Maximizing GP3 Throughput

- name: Create GP3 volume with high throughput 
  amazon.aws.ec2_vol: 
    instance: "{{ my_instance_id }}" 
    volume_type: gp3 
    volume_size: 100 
    iops: 40000       # Higher performance now supported 
    throughput: 1000  # Previously not possible in older versions

Simplified Templating

Working with DNS records in Jinja2 templates previously required complex parsing logic. The route53 module now includes the record_values return key, which supports cleaner dot-notation access and replaces the deprecated values key.

Minor Improvements and Bug Fixes

Beyond major features, version 10.2.0 addressed several operational pain points:

Better Hybrid Cloud Support

Teams using S3-compatible storage endpoints benefit from improved error handling in module_utils/s3. The collection now handles HTTP 403 and 501 errors more gracefully, reducing confusion when automation interacts with non-AWS S3-compatible services.

Faster IAM Debugging

Troubleshooting IAM policy syntax errors can be time-consuming. The sts_assume_role module now provides specific error messages when policy documents contain formatting issues, helping you identify and fix problems more quickly.

Security Compliance

We corrected a logic issue in s3_bucket that could prevent AES256 encryption from being applied correctly when bucket_key_enabled was set to false. This fix ensures your encryption settings are applied exactly as specified in your playbooks.

Trustworthy Documentation

The lambda_info module documentation now accurately reflects the actual return values, ensuring your Jinja2 templates reference the correct data structures.

Deprecations

While the following deprecations from 10.2.0 won’t be enforced until December 1, 2026, updating your playbooks now prevents future disruptions and keeps your automation aligned with current standards.

VPC DHCP Options

The collection is standardizing naming conventions. Update any references to the dhcp_config return value to use dhcp_options instead in both ec2_vpc_dhcp_option and ec2_vpc_dhcp_option_info modules.

Route53 Records

The generic values key in route53 module is being replaced with record_values, which provides a more structured approach to handling complex DNS data.

We recommend making these updates proactively to ensure smooth operation as you approach the enforcement deadline.

Under the Hood: Notes for Developers and Contributors

Beyond user-facing changes, amazon.aws 11.0.0 includes substantial internal refactoring. We’ve removed deprecated internal interfaces, parameters, and legacy configuration options to streamline the codebase and improve long-term maintainability.

A cleaner codebase translates to fewer edge cases and faster resolution of future issues. If you maintain custom modules, plugins, or internal integrations built on this collection, review the complete release notes for details on removed internal APIs. This ensures your custom automation components remain compatible with the updated foundation.

Your Upgrade Action Plan

Upgrading to version 11.0.0 provides an opportunity to assess and improve your AWS automation health. Follow these steps to ensure a smooth transition:

Audit Your Environment

Verify that your control nodes run awscli version 1.34.0 or later, along with boto3 and botocore version 1.35.0 or later. These updated SDKs provide access to current AWS features and security patches. For teams managing automation across multiple control nodes, consider implementing automated checks to verify SDK versions across your infrastructure.

Scan Your Playbooks

Search your codebase for the removed parameters and deprecated return values discussed in this article. Use grep, your IDE’s search functionality, or other code analysis tools to identify patterns that need updating, such as the old Route53 CamelCase returns or the deprecated iam_user key.

Update Logic

Refactor automation that depends on removed functionality, including the deprecated S3 list mode or Amazon EC2 nested list structures. This is an opportunity to improve code quality and reduce technical debt in your automation workflows.

Validate in Staging

Test your updated playbooks in a non-production environment before deploying to production. With stricter key handling now enforced (such as the prohibition on leading slashes in S3 keys), thorough testing helps identify issues before they impact production workloads. Leverage your existing CI/CD pipelines to validate automation changes systematically.

These steps ensure you’re not just upgrading versions, but actively strengthening the reliability of your automation infrastructure.

Conclusion

The amazon.aws 11.0.0 release represents more than a version increment. It is a commitment to building AWS automation that remains reliable over time. Through refactored utilities, removed deprecated features, and alignment with current AWS SDKs, this release provides a foundation for more predictable automation, clearer debugging, and long-term stability.

Combined with the performance improvements from 10.2.0, these updates enable teams to build automation that works reliably today and remains maintainable tomorrow. We encourage you to review the release notes, update your playbooks accordingly, and leverage these improvements to strengthen your AWS automation infrastructure.

Get Started

Ready to upgrade your AWS automation? Here are your next steps:

For teams new to Ansible automation on AWS, these resources provide comprehensive guidance on infrastructure-as-code best practices. Experienced users will find advanced patterns for managing complex, multi-account AWS environments at scale.

Learn More

Attend Red Hat Summit 2026 and AWS re:Invent 2026
Additional Red Hat on AWS blogs
AWS Marketplace Red Hat Ansible Automation Platform on AWS

IBM & Red Hat on AWS