What’s new in Ansible Certified Content Collection for AWS

March 2, 2026
Alina Buzachis
Related topics:
Automation and managementDatabasesHybrid cloud
Related products:
Red Hat Ansible Automation PlatformRed Hat Ansible Automation Platform via AWS

In large-scale AWS management, prioritizing speed often compromises long-term stability. This creates an automation debt, where aging dependencies and inconsistent workarounds linger in your codebase until they inevitably trigger a mid-migration failure. With the release of amazon.aws 11.0.0, the Red Hat Ansible Certified Content Collection for AWS shifts its focus from simply adding features to making cloud automation easier to operate, easier to maintain, and resilient enough for long-term enterprise needs. This release emphasizes stability, consistency and supportability, helping teams manage AWS environments with greater confidence.

Building on the enhancements introduced in version 10.2.0, this release emphasizes stability, consistency, and supportability. By completing previously announced deprecations and aligning with modern AWS tooling, we’re helping teams manage their environments with greater confidence.

In this article, we’ll highlight what’s new in amazon.aws 11.0.0, recap notable updates from 10.2.0 and outline what users should consider when planning an upgrade.

Improved stability and maintainability for Amazon S3 automation

If you’ve ever spent an afternoon chasing a generic “403 Forbidden” error only to realize it was a subtle bucket policy mismatch, you know the frustration of opaque S3 debugging. A major focus of the amazon.aws 11.0.0 release is turning those black box failures into actionable insights by refactoring the internal module_utils/s3  utilities.

This new release also offers cleaner debugging with centralized error handling through the new S3ErrorHandler. Instead of cryptic logs, you’ll receive descriptive messages that point exactly to the failure point, allowing you to fix issues in minutes rather than hours.

Behavior is now predictable. By consolidating logic across the collection, the s3_bucket and s3_object behave identically regarding authentication and endpoint handling. No more special cases depending on which module you call. These smarter wrappers now power the s3_bucket and s3_object modules and their _info counterparts, ensuring a consistent experience across your storage automation.

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 to ensure a smooth transition.

Updated AWS SDK dependencies

To unlock the latest AWS features and security patches, we have bumped the minimum supported versions for the AWS SDKs.  We now require botocore and boto3 version 1.35 or newer, and awscli version 1.34 or newer.

While older versions might still function, upgrading ensures you aren't running on deprecated foundations that are no longer tested against modern AWS APIs. 

Red Hat Ansible Automation Platform will display warnings if it detects deprecated SDK versions. 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

To ensure a more consistent developer experience, we are standardizing return values and parameter types across the collection. These removals represent long-standing deprecations and simplify module behavior while improving consistency across the collection and making your playbooks more readable.

Enforcing safety and separation of concerns

We have removed the list mode from the s3_object to enforce a strict separation of concerns. This prevents scenarios where a user might accidentally modify data when they only intended to query it. For lookups, s3_object_info is now the single source of truth. We also removed support for leading slashes (/) in object keys to ensure consistent behavior across all S3 operations. Additionally, we removed the ability to pass dualstack and endpoint_url in s3_object_info, eliminating invalid configuration combinations that could lead to unexpected connectivity issues.

Standardizing returns for better templating

We are also enforcing cleaner data structures across the board to improve Jinja2 compatibility. In route53_info, we have retired AWS-style CamelCased returns (i.e.,  ResourceRecordSets and HostedZones) in favor of Ansible-native snake_case formats. This ensures your templates look and feel like the rest of your automation.

Similarly, iam_user now returns data exclusively under the user key (removing the deprecated iam_user return key), eliminating the guesswork of which key to use for follow-up tasks.

Simplifying configuration and audits

Finally, we have streamlined input parameters to reduce complexity. We simplified ec2_security_group by removing support for nested lists of strings in rules.cidr_ip and rules.cidr_ipv6, enforcing a flat, explicit structure that is easier for security teams to audit.

We also removed the deprecated function parameter from lambda_info, leaving a leaner interface that aligns with modern Lambda definitions.

Highlights from amazon.aws 10.2.0

Version 10.2.0 introduced several important updates that set the stage for 11.0.0. If you skipped that update, here are the highlights you’ve missed.

New and enhanced functionality

One important update provides enhanced functionality, including better database performance, increased throughput and IOPS limits, and simplified templating.

  • High-performance databases: Mission-critical applications cannot afford storage bottlenecks. We updated rds_instance to support the io2 storage type, giving you access to significantly higher IOPS. This ensures your automated database deployments are ready for the most demanding, data-intensive workloads without manual intervention.
  • Modern EC2 limits: There is nothing worse than your automation failing because a tool imposes lower limits than the cloud provider itself. We increased throughput and IOPS limits for GP3 volumes in ec2_launch_template and ec2_vol. This aligns the collection with current AWS service limits, ensuring you can provision high-performance storage at scale without hitting artificial ceilings.
  • Simplified templating: Parsing DNS records in Jinja2 used to require complex filters and loops. Route53 added the record_values return key, which supports cleaner dot notation. This small change drastically simplifies your template logic, reducing spaghetti code and making your DNS automation easier to read and maintain.

Minor improvements and bug fixes

Beyond the headline features, we’ve improved features that often slowed down development. These updates are focused on reliability and debugging speed:

  • Better hybrid cloud support: For teams using S3-compatible object storage, we enhanced how module_utils/s3 handles HTTP 403 and 501 errors. This reduces confusing failure signals when your automation interacts with non-AWS endpoints.
  • Faster IAM debugging: IAM policies are notoriously difficult to troubleshoot. We’ve improved sts_assume_role to provide specific error messaging when a policy document is malformed, saving you from hunting for syntax errors in JSON strings.
  • Security compliance: We fixed a logic gap in s3_bucket to ensure that AES256 encryption is correctly applied even when bucket_key_enabled is set to false. This ensures your security posture matches exactly what you defined in your playbook.
  • Trustworthy documentation: We corrected invalid return value documentation for lambda_info, ensuring that the reference materials you rely on for Jinja2 templating match the actual module behavior.

Deprecations

Great automation is built to last, but relying on deprecated features creates technical debt that eventually comes due. While the following deprecations from 10.2.0 won’t be enforced until December 1, 2026, acting now ensures your playbooks remain resilient and aligned with modern standards long before the deadline arrives.

  • VPC DHCP options: We are standardizing naming conventions. Calls using the dhcp_config return value should update to dhcp_options.
  • Route53 records: We are retiring the generic values key in resource record sets in favor of record_values. This new key provides a more robust structure for complex DNS data.

We recommend updating your playbooks today to ensure a seamless transition and prevent any disruptions to your automated workflows.

Under the hood: Notes for developers and contributors

In addition to the user-facing updates, amazon.aws 11.0.0 includes significant internal refactoring. We have removed deprecated internal interfaces, parameters, and legacy configuration options to simplify the codebase and improve maintainability.

This matters because a cleaner codebase means fewer edge cases and faster bug fixes in the future. If you maintain custom modules, plug-ins, or internal integrations that rely on this collection, we recommend reviewing the full release notes for details on removed internal APIs. This ensures that the foundation of your automation remains robust and maintainable.

Your upgrade action plan

Moving to a major version like 11.0.0 is the perfect opportunity to perform a health check on your cloud automation. To ensure a seamless transition, we recommend the following steps:

  1. Audit your environment: Ensure your control nodes are running awscli ≥ 1.34.0 and boto3 / botocore ≥ 1.35.0. These modern SDKs are critical for accessing the latest AWS features and security patches.
  2. Scan your playbooks: Search for the removed parameters we discussed (i.e., the old Route53 CamelCase returns or the deprecated iam_user key).
  3. Update logic: Refactor any automation that relies on the deprecated S3 list mode or EC2 nested lists.
  4. Validate in staging: Because strict key handling is now enforced (e.g., no leading slashes in S3 keys), testing your playbooks in a non-production environment is essential before full deployment.

Following these steps ensures you aren't just upgrading, but actively improving the resilience of your automation pipeline.

Final thoughts

The release of amazon.aws 11.0.0 is about more than just a version bump; it is a commitment to the long-term health of your AWS automation. By refactoring key utilities, removing deprecated features, and aligning with modern AWS SDKs, we are providing a platform that offers more predictable automation, easier debugging, and a stronger foundation for the future.

Along with the performance enhancements from 10.2.0, these updates enable teams to build automation that isn’t just working for now, but is stable, reliable, and aligned with modern AWS and Ansible best practices. We encourage users to review the release notes, update playbooks as needed, and take advantage of these improvements to simplify and strengthen enterprise AWS automation.

Get started with Red Hat Ansible Automation Platform Service on AWS. Check out the Amazon Web Services Guide. Try our the hands-on interactive labs. Read the e-book, Using automation to get the most from your public cloud.

Learn more: