AI Governance and Compliance on AWS: Config, CloudTrail, and Audit Manager

Task 5.1 is about securing the AI system — identity, encryption, keeping traffic private. This task is about governance and compliance: making sure the system is run according to policies and regulations, and being able to prove it. The two overlap, and several services here are ones a security engineer already knows, but the governance lens asks different questions: Is this resource configured the way our policy requires? Who did what, and when? Can we show an auditor evidence that we meet a standard?

A simple way to hold the domain together is the chain regulation to control to evidence. A regulation or internal policy says something must be true — for example, training data must stay in a particular country, or all activity must be logged. A control is how you make that true — a configuration rule, an encryption setting, a retention policy. Evidence is the proof you collected that the control is working — configuration history, API logs, a compliance report. Governance is running this chain continuously, not once.

For the exam, keep these services at a recognition level. You do not need to configure them; you need to know which one answers which governance question. The rest of this lesson takes them in pairs by the question they answer, gives you a comparison table, then covers the data-governance policies and processes that wrap around the tooling. Governance is as much about policy and process as it is about any single AWS service.

AWS Config answers is this resource configured the way it should be? It records the configuration of your AWS resources and how that configuration changes over time, and it evaluates resources against rules that represent your desired state — for example, a managed rule that flags any storage bucket that is not encrypted, or any Amazon EBS volume that is not encrypted. Each resource gets a configuration timeline: what its settings were at each point and when they changed. Config gives you a continuous picture of compliance — which resources meet your policies right now, which drifted, and when. For a generative AI deployment, Config can confirm that the buckets holding training data stay encrypted and that logging stays switched on. When the need is to track resource configuration and compliance over time, the service is AWS Config.

Config can also deploy a whole framework's worth of rules at once. A conformance pack is a collection of Config rules (and optional remediation actions) deployed as one unit to an account or across an organization, with its own compliance dashboard and timeline. AWS publishes sample conformance pack templates for common frameworks — for example HIPAA Security, PCI DSS and NIST — and you can write your own. A conformance pack checks the technical controls that can be evaluated as Config rules; it does not cover procedural controls such as whether policies are documented.

Amazon Inspector answers a different question: are there known vulnerabilities in my workloads? It is an automated vulnerability management service that continually scans Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions for known software vulnerabilities (published CVEs in operating-system packages and code libraries), and checks EC2 instances for unintended network exposure. Because scanning is continual, a newly published CVE produces a new finding without anyone re-running a scan. In a governance program, Inspector provides ongoing assurance that the infrastructure and code running your AI application are not carrying unpatched, exploitable software.

The pairing is easy to remember: Config watches configuration and compliance state, Inspector watches for vulnerabilities. Both run continuously so governance is an ongoing measurement rather than a one-time snapshot, and both feed the evidence you later hand to an auditor.

Two services deal specifically with proving compliance against recognized standards, and they are distinguished by whose compliance they document: Audit Manager documents yours, Artifact provides AWS's.

AWS Audit Manager helps you prove your compliance. It continuously collects evidence about how you use AWS — from Config rules, CloudTrail events, service API calls and security-control findings — and maps that evidence to the controls of a framework such as SOC 2, PCI DSS or HIPAA, or a custom framework, organizing it into an assessment you can export as an audit report. Instead of manually screenshotting settings before an audit, the evidence is gathered automatically.

Availability change: since 30 April 2026 Audit Manager is in maintenance mode. It can no longer be set up in new accounts, and existing customers cannot extend it to new Regions or new organizations — but customers who already use it carry on as normal, including creating new assessments (and organization-level customers can still add accounts from that organization to assessments). AWS recommends AWS Config conformance packs for compliance monitoring in new accounts. So treat Audit Manager as the evidence-collection service an existing customer uses, and conformance packs as the route for a new account. Conformance packs are not a like-for-like replacement: they record configuration items as evidence rather than a full audit report, and some frameworks (notably SOC 2 and GDPR) have no AWS template, so you would build a custom pack or use a partner compliance tool.

AWS Artifact gives you AWS's compliance documentation. It is a self-service portal with two parts: reports — AWS's audit reports and certifications such as SOC 1, SOC 2, ISO and PCI — and agreements, where you review and accept legal agreements with AWS, such as the Business Associate Addendum (BAA) a healthcare organization needs before it processes protected health information under HIPAA. These documents show how the AWS infrastructure underneath your workload is audited and certified — the AWS side of the shared responsibility model your own auditors will ask about.

The distinction is a common trap: Audit Manager (or, for a new account, a Config conformance pack) assesses your environment; Artifact hands you AWS's reports and agreements about AWS's environment.

AWS CloudTrail is your audit trail of API activity. It records the actions taken in your account — which IAM identity made a call, which service and action, when, and from which IP address — whether the caller was a person, an SDK, or another service. Event history keeps the last 90 days of management events automatically; a trail delivers events continuously to Amazon S3 for long-term retention. For governance this is the record of accountability: if someone changed a model's permissions or altered a training-data bucket's policy, CloudTrail captured the call.

Amazon Bedrock model calls are part of that trail. InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream are logged as CloudTrail management events, so they are recorded by default. The event shows who called which model, when and from where — but it records call metadata, not the prompt or the generated text. Capturing the content of AI interactions is a separate, opt-in feature, Amazon Bedrock model invocation logging, covered under data governance below.

CloudTrail and AWS Config are often confused. CloudTrail records actions — the API calls that happened. Config records state — how a resource is configured and whether that configuration is compliant. A governance program uses both: Config's timeline tells you when a bucket's policy became public and that it is now non-compliant, and CloudTrail tells you which principal made the call that changed it.

AWS Trusted Advisor inspects your account automatically and provides best-practice recommendations in categories including cost optimization, performance, security, fault tolerance, and service limits (services approaching their quotas). Typical findings include an unrestricted SSH port, Amazon EBS volumes with no snapshots, low-utilization Amazon EC2 instances and an IAM root account without MFA, and every finding links to the remediation it recommends. Every account can see the service-limit checks and a core set of security and fault-tolerance checks; the full set of checks (including most cost-optimization checks) needs a Business-level or Enterprise-level AWS Support plan.

Trusted Advisor has a near-twin: the AWS Well-Architected Tool. Both relate to AWS best practices, but they work differently.

The difference is the input: Trusted Advisor reads the account itself and needs nothing from you, while the Well-Architected Tool depends on the answers your team gives about how one workload is designed.

These services often appear side by side, so the discriminator is the exact governance job each one does. Read the scenario for the verb and the target.

A quick way to keep them straight: Config is configuration state, CloudTrail is actions taken, Inspector is vulnerabilities, Audit Manager assembles your evidence, Artifact gives you AWS's reports and agreements, and Trusted Advisor is the automated best-practice checker. Anchor on the purpose, not the configuration details, and the confusable pairs (Config versus CloudTrail, Audit Manager versus Artifact, Trusted Advisor versus the Well-Architected Tool) stop being confusable.

Data-governance strategies are the policies that decide how data is handled across its life — how long it is kept, where it may live and be processed, and how its use is recorded and watched. Each is a policy you set and then enforce with AWS features.

Lifecycles and retention

Data lifecycles define the stages data moves through — created, used, archived, and eventually deleted — so nothing is kept forever by accident or thrown away too soon. Retention is the rule for how long data is kept before deletion, often set by regulation; a policy might require application logs to be kept for five years and then deleted. On AWS, an Amazon S3 Lifecycle configuration implements both automatically: transition actions move objects to cheaper storage classes (such as S3 Glacier) after a set age, and expiration actions delete them when the retention period ends. S3 Intelligent-Tiering is different — it moves objects between access tiers to save cost but never deletes anything, so on its own it cannot enforce a retention limit.

Residency

Data residency is about where data is stored and processed. Many regulations require that certain data stay within a specific country or geography, so you choose AWS Regions accordingly and prevent processing elsewhere. For a generative AI system, residency covers prompts and responses as well as training data — and that matters with Amazon Bedrock cross-Region inference, which routes requests to other Regions to add capacity:

• A geographic cross-Region inference profile (for example EU or US) routes requests only to Regions inside that geography, so processing stays within it — the choice when residency rules apply.
• A global cross-Region inference profile can route requests to any supported commercial Region worldwide, trading residency for capacity and lower cost.

CloudTrail records cross-Region inference calls in the source Region, with the Region that actually ran the request. Residency is easy to confuse with data lineage, a Task 5.1 term: lineage records where data came from and how it was transformed, not where it is allowed to live.

Logging, monitoring and observation

Logging records what happens to data and systems; monitoring and observation mean actively watching those logs and metrics so you notice problems, misuse or drift rather than discovering them afterwards. For AI interactions, three AWS records answer three different questions:

Each record answers only its own question — content, caller identity or aggregate trend — so a requirement spanning several of them needs the matching records combined; metrics alone show trends, not content. Put together, a data-governance strategy states the lifecycle and retention rules, pins processing to compliant Regions, and keeps AI interactions logged and monitored.

Governance processes are the organizational habits that keep AI systems within policy: written rules, scheduled and event-driven reviews, openness about how AI is used, and trained people. Policies are the written rules for building and running AI systems — what data may be used, who approves a model for production, what must be logged. A review cadence means systems are re-examined on a regular schedule (for example quarterly) rather than approved once and forgotten. Review strategies decide what triggers a review and how it is done — and a fixed calendar is not always enough: an event-triggered review runs whenever something material changes — a new model version, a change to the training or retrieval data, a new use case or user group — alongside the periodic review, so changed behaviour is checked when it appears rather than at the next scheduled date. Other triggers include a major data change or a new use case.

Transparency standards require you to be clear about where AI is used and how its decisions are reached — for example, telling job applicants that an AI tool screens their CVs and what factors it weighs. Team training requirements ensure the people building and operating AI understand the policies and their own duties under them, often as a condition of getting access to production systems.

Governance frameworks give structure to all of this. The one the exam guide names is the AWS Generative AI Security Scoping Matrix, described in the next section.

The AWS Generative AI Security Scoping Matrix is a framework that places a generative AI workload into one of five scopes based on how you use the model — whether you consume someone else's application, build your own application on an existing model, or change or create the model itself. The scope tells you which security and governance responsibilities are yours; the further you move toward training your own model, the more you own.

Two distinctions do most of the work. First, retrieval-augmented generation (RAG) does not change the model: adding your documents to prompts at query time keeps an application in Scope 3, whereas training the model's weights on your data (fine-tuning) moves it to Scope 4. Second, each step to a higher scope adds the responsibilities shown in its row on top of those you already carry. In every scope, AWS remains responsible for the underlying cloud infrastructure, as the shared responsibility model describes.

Here is how the pieces fit together for one deployment. A healthcare company deploys a generative AI assistant that answers staff questions from internal clinical documents, and it must satisfy regulators.

First it writes the policies: which data the assistant may use, who signs off before it goes live, a quarterly review cadence, and an extra review whenever the underlying model version changes. Before any patient data is processed, its legal team accepts the BAA in AWS Artifact. For data governance, patient data must stay in-country, so the team pins storage and inference to Regions in that country for residency (using a geographic inference profile only if its geography satisfies the rule), sets a multi-year retention rule enforced by an S3 Lifecycle configuration, and turns on Bedrock model invocation logging so prompts and responses can be reviewed. To scope the work, it uses the Generative AI Security Scoping Matrix: the assistant uses RAG over an unmodified foundation model, so it is Scope 3.

Then it wires up the AWS services. Because its AWS account is new, it cannot set up Audit Manager, so it deploys the AWS Config conformance pack for HIPAA Security, which continuously checks that data buckets stay encrypted and logging stays on and shows a compliance dashboard. AWS CloudTrail records every API call, including each model invocation, as the audit trail of who did what. Amazon Inspector scans its Lambda functions and container images for vulnerabilities, and AWS Artifact provides AWS's own SOC and ISO reports for the infrastructure layer. When the regulator arrives, the company can show the chain from regulation to control to evidence for each requirement — which is exactly what governance is meant to produce.