AWS SRA examples are deliberately incomplete, and that is the point

The templates illustrate a pattern, and say so up front

The first thing the introduction tells you is what these templates are not. The AWS service configurations and resources they deploy, including IAM roles and policies, are described as deliberately very restrictive, and they are intended to illustrate an implementation pattern rather than provide a complete solution. You may need to modify and tailor them to suit your environment and security needs.

That framing matters more than it first appears, because most infrastructure examples on GitHub are copied without much thought and end up either too permissive to be defensible or too restrictive to run. This repository is explicit that the defaults are the restrictive end, which makes it usable as a baseline to loosen deliberately rather than a finished configuration to ship.

The audience is engineers and developers who need to deploy AWS security services into an AWS Organizations multi-account environment, either with AWS Control Tower as the landing zone or without it. The patterns are aligned with the AWS Security Reference Architecture, the prescriptive guidance document that describes the recommended set of security services for a multi-account setup. So the repository is the code half of a written architecture: the guide says what should be in place, and these templates are a way of getting a version of it into an account.

Control Tower 4.0 needs two integrations switched on first

The compatibility notice at the top of the README is the most operationally important paragraph in the file. This version of the code library is compatible with AWS Control Tower 4.0 environments, with no manual template changes required. But two integrations that are optional in Control Tower 4.0 have to be turned on explicitly in the landing zone settings before the SRA solutions function correctly: the AWS Config integration and the CloudTrail integration.

Miss that and the failure appears late, as solutions that do not behave as their templates describe, and the fix is a setting change rather than a code change. The README points to the Control Tower 4.0 migration guide for the migration details, and for anything that still goes wrong it tells you to submit a GitHub issue or contact your AWS Account Manager. That second route is a signal about the support model, which is worth weighing before you commit to it in a regulated environment.

The same notice also implies a compatibility matrix that the reader has to supply. A library that is compatible with Control Tower 4.0 and says nothing here about earlier Control Tower versions leaves you to infer which landing zone generation each release was built against.

Easy Setup selects the solutions through template parameters

Deployment is organised around two paths in a Control Tower environment. The recommended one is AWS SRA Easy Setup with an AWS Control Tower landing zone, and the step sequence is: set up Control Tower in a new or existing account, choose a deployment method, deploy the AWSControlTowerExecution role into the management account if you are using CfCT, and then use the parameters in the easy setup template to choose which SRA solutions to deploy.

That last point is the useful one. Solution selection is a parameter, not a code fork, so you can change the set of deployed solutions during initial setup or update it later. For an organisation that wants a small set of controls first and more later, that is a materially different experience from editing templates.

The manual path in a Control Tower environment is deliberately lower level. It starts the same way, then has you deploy the Common Prerequisites solution, with the note that this only needs to be done once for all the solutions, and then choose between CloudFormation StackSets and stacks or CfCT. The same structure exists for an AWS Organizations environment without Control Tower, with an Easy Setup path and a Manual Setup path, and there is a separate section for the details of the easy setup implementation. A Quick Setup with CloudFormation path is marked deprecated, so anything you find describing that route is describing the older flow.

Three deployment paths cover the same patterns

The code library can be deployed with CloudFormation or with Terraform, and inside a Control Tower environment the CloudFormation route splits again into stack sets and stacks on one side and Customizations for AWS Control Tower on the other. Each path has its own implementation details section in the documentation.

The deployment matrix is what the introduction is careful about. Solutions that require AWS Control Tower have been deployed and tested in a Control Tower environment using CloudFormation, CfCT and Terraform. Solutions that do not require Control Tower have been tested in an AWS Organizations environment using CloudFormation and Terraform. The word tested is doing work there, since it tells you which combinations have been exercised and, by omission, that the non-Control-Tower solutions have not been tested with CfCT, which would not apply in any case.

So the choice of path follows your landing zone rather than your preference. Control Tower users pick between the stack set route and the CfCT route, with easy setup recommended in both cases, and organizations users without Control Tower use the CloudFormation or Terraform variants. The repository also lists sections for example solutions, utils, environment setup and the repository and solution naming convention, which is where the per-solution detail lives once you have chosen a path.

The Python in the repository is glue for the templates

Although the project is catalogued as a Python project, it is not an application you run. The Python is the tooling around the templates. The pyproject file describes a poetry project named aws_sra_examples, version 2.1.8, requiring Python ^3.12, with boto3 for AWS calls, crhelper, the library used to write CloudFormation custom resources, setuptools and urllib3. The Python source lives under the aws_sra_examples/ directory in the repository.

The development dependency list is long and tells you what the project considers quality. There is pytest with coverage, mocking and xdist for parallel runs, black for formatting, isort for import order and mypy for typing, plus a large flake8 stack with plugins for docstrings, bandit, bugbear, print statements, pytest style and roughly two dozen more rules, along with darglint for docstring argument checking, dlint, safety for dependency scanning and aws-lambda-typing. The repository root also carries a.flake8 config, a.safetyci.yml and a.safety-policy.json, so the scanning is wired into the project's own tooling rather than left to the reader.

What this means in practice is that the templates are the product and the Python is what makes them deployable, validate themselves and integrate with the templates that need to react to resources being created. A reader who only wants the architecture can ignore the code entirely, and a reader who wants to extend a template will spend most of the time in this Python rather than in the YAML.

Three licences and a release line that lags the code

The licensing here is split, and the repository says so at the top of the README, where the documentation is marked with the SPDX identifier CC-BY-SA-4.0 and carries an Amazon copyright notice. The project root holds a LICENSE file, a LICENSE-SAMPLECODE file and a LICENSE-SUMMARY file, which is the standard way of separating the licence of the documentation, the licence of the sample code and a summary of both, and the repository is classified as using a custom licence that GitHub cannot categorise. The pyproject metadata separately declares the MIT-0 License for the project, and there is a dedicated section for the licence summary in the table of contents. Anyone copying a template into a commercial product needs to read those three files rather than assume a single permissive grant.

Version numbers are not a reliable guide to what is in the tree. The pyproject file records version 2.1.8, the published releases visible for the repository are v3.1.0 from February 2024, SRA v2.1.4 from July 2022 and SRA v2.1.0 from April 2022, and the last push was on 2026-09-07. Those are inconsistent with each other, so the tag names and the packaging version number are not tracking the same thing.

The repository is not archived, and the changes since the last tag are recorded in CHANGELOG.md and in CONTRIBUTING.md rather than in release notes attached to a tag. For an adopter, the practical advice is to work from the main branch, read CHANGELOG.md for what changed, and treat a release tag as a marker rather than a supported version. There is no package index entry, no install step and no test suite you run against your own account before deploying, so the validation burden sits with the deploying team.

Editorial conclusion

AWS SRA Examples suits a team standing up an AWS Organizations landing zone, with or without Control Tower, that needs a defensible starting configuration and someone to tailor it. It does not suit a team expecting a product that can be deployed and left alone, since the repository states the templates illustrate an implementation pattern and will need modification for your environment, and the documentation asks you to open a GitHub issue or contact your AWS Account Manager when something breaks. Verify first that AWS Config and CloudTrail integrations are enabled in your Control Tower 4.0 landing zone, that the common prerequisites solution has been deployed once, and that the release tag you plan to use matches the Control Tower version in your organisation.

Frequently asked questions

Official sources

1. aws-samples/aws-security-reference-architecture-examples on GitHub
2. Issues
3. README
4. Releases