Fitness functions on AWS

On a cloud platform, much of the architecture is configuration: accounts, networks, IAM, managed services. That makes it unusually well suited to fitness functions, because configuration can be checked automatically before it’s deployed and continually after.

AWS’s own Architecture Blog has a post on this: Using cloud fitness functions to drive evolutionary architecture.

Where checks run

Stage	Type	AWS / ecosystem tools
Author time / PR	Triggered, static	cdk-nag, CloudFormation Guard (cfn-guard), Checkov, OPA/Conftest on Terraform plans, IAM Access Analyzer policy validation and custom policy checks
Deploy time	Triggered	CloudFormation Hooks, Control Tower proactive controls, pipeline gates in CodePipeline / GitHub Actions
Preventive (always on)	Continual	Service Control Policies (SCPs), Resource Control Policies (RCPs), tag policies, Control Tower preventive controls
Detective (runtime)	Continual	AWS Config rules and conformance packs, Security Hub standards, Control Tower detective controls, GuardDuty
Operational	Continual, holistic	CloudWatch alarms on SLOs, CloudWatch Synthetics canaries, X-Ray / OpenTelemetry traces
Resilience	Triggered or temporal	AWS Fault Injection Service (FIS) experiments, AWS Resilience Hub assessments
Cost	Continual / triggered	AWS Budgets, Cost Anomaly Detection, Infracost on pull requests
Well-Architected	Temporal, partly manual	Well-Architected Tool reviews, custom lenses

Shift left, but keep the backstop

Run the same rule at several stages if you can: a Checkov or Guard rule in the PR gives fast feedback, and an AWS Config rule catches drift and anything created outside the pipeline.

Example fitness functions

Written as objective statements, with where they’d run:

• Encryption: every S3 bucket, EBS volume, and RDS instance is encrypted with KMS. (Guard/Checkov in PR; Config rule at runtime.)
• No public data stores: no S3 bucket or RDS instance is publicly accessible. (S3 Block Public Access at org level; Config rule; SCP.)
• Region restriction: workloads only run in approved regions. (SCP denying other regions.)
• Tagging: every resource has owner, cost-centre, and data-classification tags. (Tag policy; Config required-tags rule.)
• Least privilege: no IAM policy grants *:*; unused permissions are reviewed. (Access Analyzer policy checks in PR; Access Analyzer unused-access findings at runtime.)
• Multi-AZ: production databases and load balancers span at least two AZs. (cdk-nag / Guard; Resilience Hub.)
• Recovery: a service survives the loss of one AZ with p95 latency under its SLO. (FIS experiment in a pre-production environment, run on a schedule.)
• Cost: a pull request that raises a workload’s monthly estimate by more than 10% needs explicit approval. (Infracost in CI.)
• Isolation between quanta: a service’s database security group only allows traffic from that service. (Config custom rule or VPC Reachability Analyzer.)
• Drift: no CloudFormation stack is in a drifted state for more than 24 hours. (Scheduled drift detection.)

Making guardrails evolvable

Guardrails are architecture too, so they need to evolve:

• Keep SCPs, Config rules, and Guard rules in source control with tests and a pipeline.
• Roll out new controls in detective mode first, look at findings, then make them preventive.
• Have a clear exception process (time-boxed, recorded as an ADR) so teams aren’t stuck.
• Review controls periodically; retire ones that no longer reflect a priority.