The Well-Architected Framework is the AWS documentation people read for a certification and then leave alone. A 2026 security review is still worth doing. It is not worth doing against a rewrite that the Security Pillar has not published.
The Security Pillar revision history lists its latest update as November 6, 2024: refreshed guidance across SEC 2, SEC 3, SEC 4, SEC 6, SEC 7, SEC 8, SEC 9, SEC 10, and SEC 11. The row before that is June 27, 2024. There is no 2025 or 2026 edition on that page. The current whitepaper text already describes newer products, including Security Hub exposure findings announced at re:Invent 2025, so the body has moved past the date in the header. Cite the live page, and check the revision table before you tell a board the pillar was rewritten this year.
Three reviews will still surface gaps. They live in a lens, a detection stack, and the compute questions you already had.
Models, data, and endpoints
Generative AI security is a lens, not a new section of SEC 1 through SEC 11. The Generative AI Lens was first published on April 15, 2025, and updated on November 19, 2025 with agentic AI guidance, responsible AI updates, and new scenarios. Its security focus areas are endpoint security, response validation, event monitoring, prompt security, excessive agency, and data poisoning.
That is the review for Amazon Bedrock and Amazon SageMaker AI. Who can invoke the model, which data the customization job can read, whether the endpoint is reachable from the internet, and what an agent is allowed to call after it answers. The Security Pillar still expects least privilege, data classification, and logging. The lens asks those questions in the shape of a model, a prompt, and a tool call. Apply both lenses to the same workload in the Well-Architected Tool. A Security Pillar pass that never loads the Generative AI Lens will not ask them.
One detection layer
SEC 4 already describes detective controls as a stack, not three products you might buy later.
Amazon GuardDuty watches CloudTrail, VPC Flow Logs, DNS, and EKS audit logs for threat behavior, and it pulls those streams itself. AWS Config, often through Security Hub CSPM standards and conformance packs, evaluates whether resources still match the controls you claimed. Security Hub CSPM is the place those findings are aggregated, prioritized, and handed to remediation. The current pillar text then points at Security Hub's exposure findings, which correlate signals from GuardDuty, Amazon Inspector, Amazon Macie, and Security Hub CSPM into an assumed attack path.
In October 2026 the packaging caught up with that picture. GuardDuty Runtime Monitoring is included in the Security Hub Threat Analytics plan. If Security Hub is enabled in the account and Region, runtime monitoring for EC2, EKS, and ECS on Fargate is billed under Security Hub rather than as a separate GuardDuty line. The detectors and finding types stay the same. What changes is that a team can no longer treat "we have GuardDuty" and "we have Security Hub" as two unrelated checkboxes. The review question is whether findings land in one place, whether Config is actually evaluating the controls you named, and whether anyone remediates the high-severity items.
Containers were already in the compute questions
Infrastructure protection for Kubernetes did not arrive as a new best-practice ID in 2026. SEC05 expects network layers and control of traffic inside them. SEC06 expects hardened compute, signed artifacts, and less interactive access. On EKS that is a network policy, a Pod Security Standard, and an image that ECR scanning and a signature check will actually admit.
GuardDuty already consumes EKS audit logs, and Runtime Monitoring covers the cluster. The miss in most reviews is that the platform team answers SEC06 for EC2 and never walks the same questions through the cluster: which namespaces can egress, whether privileged pods are still allowed, and whether the node role is the identity the workload uses. Those are the questions that find things. They were in the pillar before this year.
The tool is the review
The AWS Well-Architected Tool is the part teams skip. Define the workload, select the Well-Architected Framework lens, and add the Generative AI Lens when the workload calls a model. Answer the Security Pillar questions with the people who run the system in the room. A single pillar, for one workload they know, is a few hours. A six-pillar review of a platform nobody can describe is a different project.
Each answer that falls short becomes a high or medium risk on an improvement plan, tied to a best practice such as SEC04-BP03. Save a milestone so the next review has a baseline. The plan is not a ticket. Copy the high risks into the tracker your security team already uses, with an owner and a date. That list is what a CISO can take to a board. An architecture risk with no owner stays invisible until it is an incident.
Start with one production workload. Load the Security Pillar and, if a model is in the path, the Generative AI Lens. Leave with the high risks written down.