The situation
A twenty-person healthcare startup sells a note-taking tool to small clinics. A clinician records a consultation, the audio is transcribed, and a summarisation feature built on Amazon Bedrock turns the transcript into a structured clinical note the clinician reviews and signs. Transcripts land in an S3 bucket. The application runs in containers on ECS from an image held in Amazon ECR. A Bedrock guardrail sits in front of the model to block a short list of things the note should never contain.
A hospital group wants to license the product. Its assessor has sent five questions with a fortnight to answer them.
- Prove that the S3 bucket holding transcripts has never allowed public access.
- Prove that the container running the summarisation service has no known critical vulnerabilities.
- Show who deleted the guardrail on the 14th, and when it was put back.
- Provide AWS’s own SOC 2 report covering the Regions this runs in.
- Say whether anything wasteful or misconfigured is sitting in the account.
The engineer who picked up the ticket opened the console, typed “compliance” into the search bar, and got a list of services that all sound like they might do the job. Two days later the team is still arguing about which one to start with, and nobody has produced a single document.
What actually matters
Every one of those five questions is a request for evidence, and evidence has an author. Four of the questions ask for evidence about this startup’s own account, generated by tooling the startup switched on. One of them, the SOC 2 request, asks for evidence about AWS: the security of the data centres, the hypervisors, and the managed services underneath, which is AWS’s half of the shared responsibility model and not something the startup can produce at all. Sorting the questions by who wrote the answer down splits the list before any service gets named, and it is the split that people skip.
Then the object. A service that inspects something can only ever answer questions about that thing. The settings on a resource, the API calls made against an account, the software packages installed in an image, and the design of a workload are four separate objects, and no amount of configuring one tool will make it see another. A tool that watches configuration cannot tell you who changed it. A tool that records who changed things cannot tell you whether the change was allowed. A vulnerability scanner cannot tell you either, because it is looking inside the software rather than at the account around it. Matching the object to the question is most of the work here, and it is the distinction that sorts security controls apart as well.
The third thing is time, and it is the one that hurts a fortnight before an assessment. Questions one and three ask about the past. “Has never allowed public access” and “who deleted it on the 14th” can only be answered by a service that was already recording on the day in question. Switching a recorder on today produces a history that starts today, which answers nothing about last month. Questions two and five are different: they ask about the state of things right now, so a scan started this afternoon is a perfectly good answer by Friday. Sorting the questions into “needs a recording that already exists” and “can be answered by looking now” tells the team which two to panic about.
One more thing worth setting straight before the services get named. AWS does have a service whose job is assembling evidence into an audit-ready package, AWS Audit Manager, and it does not appear on this certification’s in-scope service list. An evidence question in this track is answered by putting AWS Config, AWS CloudTrail, and AWS Artifact together, rather than by naming a single service that does all three.
What we’ll filter on
- What object does it inspect? Resource configuration, API activity, installed software, account-wide checks, or the design of a workload.
- Whose evidence is it? Something generated about your account and your resources, or something AWS publishes about itself.
- Does answering need it to have been switched on beforehand? A historical question is only answerable by a recorder that was already running.
- Is it continuous or point-in-time? Something that keeps watching and flags a change, or something that produces a snapshot when asked.
- Which of the assessor’s five questions does it settle on its own? If the answer is none of them, it is not the service to start with.
The landscape
AWS Config records the configuration of your resources and how that configuration changes over time. Every time a tracked resource is created or modified, Config writes a configuration item: a timestamped snapshot of that resource’s settings. Stacked up, those items give a resource timeline you can scroll back through. On top of the timeline sit Config rules, which evaluate a resource against a desired condition (an S3 bucket must block public access, an EBS volume must be encrypted) and mark it compliant or non-compliant. Config answers questions about settings and drift: what was this resource set to, when did it change, and does it currently meet the rule.
AWS CloudTrail records the API calls made in your account. Who called it, which identity, from which IP address, against which resource, at what time, and whether it succeeded. It is on by default for management events, which are the control-plane actions: creating a role, deleting a guardrail, changing a bucket policy. Bedrock runtime calls sit in that default record too, so an InvokeModel call is captured with the identity that made it, the time and the model that ran, though never the prompt sent or the completion returned. Data events, the higher-volume record of individual object reads and writes and of runtime activity against resources such as Bedrock agents and knowledge bases, are opt-in and cost extra. CloudTrail answers questions about actions and actors, never about whether the resulting state was correct.
Amazon Inspector scans workloads for software vulnerabilities. It covers EC2 instances, container images in Amazon ECR, and Lambda functions, discovering them automatically and comparing the packages inside them against published vulnerability databases. It rescans when a new vulnerability is disclosed, so an image that was clean on Monday can be flagged on Thursday without anybody pushing a new build. Inspector answers questions about the software inside a workload, and knows nothing about the account configuration around it.
AWS Artifact is the portal where AWS publishes its own compliance evidence for you to download: SOC 1, SOC 2 and SOC 3 reports, ISO certificates, PCI attestations, and the regional and country-specific paperwork underneath them. It also holds agreements you can accept online, such as a Business Associate Addendum for a workload handling protected health information. Artifact carries no information about your account at all. It is AWS handing you the audited proof of its half of the shared responsibility model.
AWS Trusted Advisor inspects your account against a catalogue of best-practice checks and reports what it finds, grouped into cost optimisation, performance, security, fault tolerance, service limits, and operational excellence. Idle load balancers, security groups open to the world, buckets without versioning, service quotas you are close to hitting. A subset of checks is available to every account and the full catalogue comes with Business or Enterprise Support. Trusted Advisor answers “is anything in this account wasteful, or set up against advice, right now”. That is a sweep, not proof of a specific claim.
AWS Well-Architected Tool is where you record a structured review of a workload against the Well-Architected Framework’s pillars: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. You answer the framework’s questions about your workload, the tool records the answers, identifies the risks, and gives you a dated improvement plan you can revisit. Nothing is scanned. The evidence is your team’s own considered assessment of the design, written down where it can be reviewed later, and there is an AI lens for machine-learning workloads specifically.
Amazon CloudWatch rounds out the set because it is in scope and gets swapped in here by mistake. CloudWatch collects metrics and logs and raises alarms on them, so it tells you how the system is behaving: latency, error rates, invocation counts, and the contents of your application logs. It is where several of the other services deliver their output, including CloudTrail if you send a trail to a log group and Bedrock model invocation logging. Operational visibility is not the same as compliance evidence, and asking CloudWatch whether a bucket was public gets you nothing.
Evaluation
Side by side
| Service | What it inspects | Whose evidence | Point-in-time or continuous | The question it settles |
|---|---|---|---|---|
| AWS Config | Resource configuration and its history | Yours | Continuous, from when recording started | Was this resource ever set that way, and does it meet the rule now |
| AWS CloudTrail | API calls made in the account | Yours | Continuous, management events on by default | Who did this, when, and from where |
| Amazon Inspector | Software packages in EC2, ECR images, Lambda | Yours | Continuous, rescans on new disclosures | Does this workload contain a known vulnerability |
| AWS Artifact | AWS’s own audited controls | AWS’s | Point-in-time reports you download | Can AWS prove its half of the shared responsibility model |
| AWS Trusted Advisor | The account against best-practice checks | Yours | Continuous checks, read as a current snapshot | Is anything wasteful or misconfigured right now |
| AWS Well-Architected Tool | The design of a workload against the pillars | Yours, written by your team | Point-in-time review, repeated on a cadence | Have we assessed this workload’s risks and recorded the plan |
Which gate the question falls through
Reading the table across a row is more useful than reading it down a column. Config and CloudTrail look adjacent because both keep a continuous record of the account, and they are answering completely different questions: one holds the settings, the other holds the actions. A change to a bucket policy appears in both, as a new configuration item in Config and as a PutBucketPolicy call in CloudTrail, and only together do they tell you what changed and who changed it.
Artifact is the odd one out on the “whose evidence” column, and that single column is what stops it being reached for by mistake. Every other row produces evidence about your workload. Artifact produces evidence about AWS’s. An assessor asking for a SOC 2 report is asking about the platform, and no amount of scanning your own account will produce it.
Trusted Advisor and Well-Architected Tool both look like reviews and they are not the same shape. Trusted Advisor is automated, runs against the account continuously, and produces findings nobody wrote by hand. Well-Architected Tool is a workshop with a record attached: your team answers the framework’s questions, and the output is a risk list and an improvement plan carrying your team’s judgement rather than a scanner’s.
The solution
Answer the five questions with four services, and start with the two that depend on history.
Question one, the bucket that must never have been public, goes to AWS Config. Turn on the configuration recorder for S3 if it is not already running, then open the bucket’s configuration timeline and read it back. If the s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited managed rules have been evaluating, the compliance history against those rules is the cleaner artefact, because it is a dated record of a rule being met rather than a screenshot of a settings page. The gotcha is the one flagged earlier: if Config was switched on last Tuesday, “never” starts last Tuesday. If that is the situation, the honest answer to the assessor is the recorded history you do have plus the account-level S3 Block Public Access setting and the date it was applied, and Config from here on. Do not present a two-week timeline as if it covered two years.
Question three, who deleted the guardrail, goes to AWS CloudTrail. Guardrail deletion is a management event, so it is in the default 90-day Event history whether or not anybody configured anything, and the 14th falls inside that window. Search on the event name, read the identity, the time, and the source IP, and search again for the creation event that put it back. Two gotchas matter. Event history keeps 90 days and no more, so anything older needs a trail that was already delivering to S3; a startup that has never created one has a hard ceiling on what it can prove. And CloudTrail records that a model was invoked rather than what was said to it, so a question about which prompts went through the model in that window needs a separate mechanism, Bedrock model invocation logging to S3 or Amazon CloudWatch, and that only holds data if it was enabled at the time.
Question two, the container vulnerabilities, goes to Amazon Inspector. Enable it for Amazon ECR, let it scan the image the summarisation service runs from, and export the findings filtered to critical severity. This is the easiest of the five, because Inspector answers about the present: a scan run this week is valid evidence about this week, and the continuous rescanning means the report stays true as new vulnerabilities are disclosed. Give the assessor the finding list and the date, and say what the remediation cadence is.
Question four, the SOC 2 report, goes to AWS Artifact. Sign in, accept the confidentiality terms, and download the current SOC 2 Type II report along with the ISO 27001 certificate; check that the Regions in use are listed in the report’s scope, because a report that does not cover your Region is not evidence about your workload. While in there, accept the Business Associate Addendum if the healthcare workload needs one and nobody has done it. Downloading a report takes minutes, so this is the question to clear on day one and stop thinking about.
Question five, the sweep for waste and misconfiguration, goes to AWS Trusted Advisor. Open the checks, read the security and cost categories, and hand over the current findings with a note on which ones are being fixed and which are accepted. If the account is on Basic support the visible check set is small, and saying so plainly is better than implying the sweep was exhaustive.
That leaves the thing the assessor did not ask for and the hospital group’s next assessor will. Nothing in the five questions demonstrates that the team has ever sat down and reviewed the design of this workload as a whole. The AWS Well-Architected Tool is where that review gets recorded, and running one against the summarisation workload, with the AI lens, produces a dated risk list and improvement plan that answers the question before it is asked. It takes half a day and it is the only item on this list where the evidence is your team’s own reasoning rather than a service’s output.
Worked example
Two of the five, traced end to end.
“Prove the transcripts bucket has never allowed public access”
The object is a resource setting, so this is AWS Config and not CloudTrail. Config is enabled in the Region with the recorder covering AWS::S3::Bucket, and the two managed public-access rules are attached. Open the bucket in the Config console, choose its resource timeline, and the configuration items appear in order: created in January, encryption changed in March, lifecycle policy added in June. Each item carries the full settings at that moment, including the public access block configuration, and a diff against the item before it.
The artefact to hand over is not that timeline as a screenshot. It is the compliance history for the two rules over the period the assessor cares about, exported, showing the bucket evaluated compliant at every evaluation. Alongside it goes the date Config recording started, because that date is the honest boundary of the claim. If recording started in January and the bucket was created in January, the claim covers the bucket’s whole life and the answer is clean.
“Who deleted the guardrail on the 14th?”
The object is an action, so this is AWS CloudTrail and not Config. Config will tell you the guardrail stopped existing; it will not name a person. In the CloudTrail console, filter Event history by event name for the guardrail deletion, with a time range around the 14th. One event comes back. Expand it and the record names the IAM identity that made the call, whether it was a user or an assumed role, the source IP, the user agent (console or SDK), and the exact timestamp. Filter again for the creation event and you get the second half: who put it back, and the gap between the two.
What that gap tells you is the window during which model output went out unguarded, which is a bigger finding than the assessor’s question. CloudTrail will list the invocations that happened in it, caller and model and timestamp, and stop there. Confirming what actually went through the model needs the invocation logs, which hold the text CloudTrail leaves out, and if those logs were not enabled at the time the window is unrecoverable. Say so, and turn them on.
What’s worth remembering
- AWS Config records what a resource was configured to and how that changed; AWS CloudTrail records who called which API and when, and answering “what changed and who changed it” needs both.
- Amazon Inspector looks inside a workload for known software vulnerabilities in EC2 instances, Amazon ECR container images, and Lambda functions, and knows nothing about the account configuration around it.
- AWS Artifact hands you AWS’s own audited compliance reports, so it answers questions about the platform’s half of the shared responsibility model rather than anything about your account.
- AWS Trusted Advisor sweeps an account against best-practice checks across cost, performance, security, fault tolerance, service limits and operational excellence, which is a health check rather than proof of a specific claim.
- AWS Well-Architected Tool records your team’s own structured review of a workload against the framework pillars, so its evidence is a written judgement and not a scan result.
- A question about the past can only be answered by a recorder that was already running, so switching on Config or a CloudTrail trail during an assessment starts a history rather than producing one.