What each instance's clock is actually locked to and how far off it is right now — the chrony daemon's reference source, offset and leap status collected fleet-wide through Run Command — together with the configured time source in chrony.conf and the UTC time stamps CloudTrail already writes on every audit record
The API supplies the facts, but a human judgement against a documented baseline turns them into evidence.
Fetch
$ aws ssm send-command --document-name AWS-RunShellScript --targets Key=tag:Environment,Values=<ENVIRONMENT_TAG> --parameters 'commands=["chronyc tracking","chronyc sources -v | grep -F ^*","grep -E \"^(server|pool|refclock)\" /etc/chrony.conf"]' --output-s3-bucket-name <EVIDENCE_BUCKET> --output-s3-key-prefix au-08$ aws ssm list-command-invocations --command-id 11111111-2222-3333-4444-555555555555 --details --query 'CommandInvocations[].{Instance:InstanceId,Status:Status,Output:CommandPlugins[].Output}'$ aws cloudtrail lookup-events --max-results 5 --query 'Events[].{Name:EventName,Time:EventTime,Source:EventSource}'Expected output
For every managed instance, a chronyc tracking block whose Reference ID is A9FEA97B (169.254.169.123) — the local Amazon Time Sync Service — with System time within your documented granularity of NTP time (microseconds on a healthy instance), a small RMS offset, and Leap status Normal; a chronyc sources line beginning ^*, which marks the preferred source, pointing at 169.254.169.123 (or fd00:ec2::123 on a Nitro instance using the IPv6 endpoint); and a chrony.conf that names that endpoint and no unapproved public NTP pool. Every invocation should come back Status Success — an instance that returns nothing is an instance whose clock you have not evidenced. From CloudTrail, EventTime values in UTC, which is what the record format guarantees: eventTime is documented as 'the date and time the request was completed, in coordinated universal time (UTC)'.
Map — what it proves
- recipe1
- recipe— an authored recipe collects evidence for this control
- KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
- orphan— no Key Security Indicator reaches it — a person writes it up instead
What else these families can fetch:AU 11/27 →
GovCloud
The local Amazon Time Sync Service is reachable from any AWS Region, GovCloud included, at the link-local addresses 169.254.169.123 (IPv4) and fd00:ec2::123 (IPv6, Nitro instances only), and Systems Manager and CloudTrail are both available in AWS GovCloud (US); instance, document and trail ARNs use partition arn:aws-us-gov. One difference to plan around: precision time placement groups — the route to the enhanced Amazon Time Sync Service and the PTP hardware clock — are documented as available in all AWS Commercial Regions, so expect NTP-level accuracy rather than microsecond PHC accuracy in GovCloud
Notes & assertions
The clock is telemetry; the mapping and the granularity are not. AU-8 wants time stamps for audit records that use an internal clock mapped to UTC and meet a granularity you defined — chrony proves the host clock is disciplined to an authoritative UTC source and by how much it is off, and CloudTrail's eventTime is UTC by contract, so the AWS-generated half of your audit trail satisfies the mapping without any work of yours. What no command proves is that your own application writes its records from that clock in UTC: chrony can be flawless while code stamps local time or truncates to the second, and comparing the measured offset against your defined granularity is a judgement against a policy number. Scope honesty matters here too — this is a point-in-time sample of the instances Run Command could reach, so an unmanaged, stopped or unreachable instance is silently absent; join the results against your managed-instance inventory before calling the fleet covered, and remember containers and serverless compute have no chrony to query. If you claim sub-millisecond granularity, note that a PTP hardware clock passes no error bound to chrony (chrony then assumes an error bound of 0): read /sys/bus/pci/devices/<pci-slot>/phc_error_bound and add it, or run ClockBound. Leap seconds are smeared on the NTP endpoints but not on the PHC, so do not configure both smeared and non-smeared sources. Substitute your real targets, bucket and command id; send-command returns the CommandId that the second call consumes, and plugin Output is truncated at 2500 characters, which is why the S3 output bucket is worth setting.
References
- Amazon EC2: precision clock and time synchronization (Amazon Time Sync Service, leap smearing) https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
- Amazon EC2: set the time reference to the local Amazon Time Sync Service (169.254.169.123, fd00:ec2::123, chronyc tracking) https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html
- Amazon EC2: compare timestamps with ClockBound (clock error bound, phc_error_bound) https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compare-timestamps-with-clockbound.html
- AWS CLI: ssm send-command (AWS-RunShellScript) https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html
- AWS CLI: ssm list-command-invocations (--details, CommandPlugins Output) https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html
- CloudTrail record contents: eventTime is recorded in UTC https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
- AWS CLI: cloudtrail lookup-events (90-day window) https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html
This AWS mapping is authored opinion (overlay v3.0.0), versioned separately from the dataset and written against ruleset 2026.07.14.01. The upstream FedRAMP dataset names none of these tools.
The Monitoring, Logging, and Auditing run (7)
- automatable
- partial — needs judgement
- narrative — no API proves this
Every authored recipe filed under MLA, in the order the plan works them. The mark says how much of the evidence the command produces on its own.
- partialAWS Config compliance results proving the audit trail exists and is protected — CloudTrail enabled and multi-region so management events are captured account-wide, log-file validation on so records are tamper-evident, and SSE-KMS encryption on so the logs themselves are protected at restcontinuousconfig-cloudtrail-audit-loggingAWS Config · AWS CloudTrail · AWS KMS
- partialAWS Config compliance results proving continuous security monitoring is switched on account-wide — GuardDuty threat detection enabled (optionally centralized to a delegated admin) and Security Hub aggregating control findingscontinuousconfig-threat-monitoring-enabledAWS Config · Amazon GuardDuty · AWS Security Hub
- partialThe metric filters that turn audit log events into metrics, the alarms built on them, and Config's confirmation that those alarms actually notify someone — the automated-mechanism half of audit reviewweeklycloudwatch-log-review-alertingAmazon CloudWatch Logs · Amazon CloudWatch · AWS Config
- partialHow long audit records are kept, how much space they occupy, and whether the pipeline that delivers them is currently failing — retention settings on every log group and log bucket, the storage they consume, and the trail's own delivery-error fieldsdailyaudit-log-retention-and-delivery-failureAmazon CloudWatch Logs · Amazon S3 · AWS CloudTrail · AWS Config · Amazon CloudWatch
- partialWhat each instance's clock is actually locked to and how far off it is right now — the chrony daemon's reference source, offset and leap status collected fleet-wide through Run Command — together with the configured time source in chrony.conf and the UTC time stamps CloudTrail already writes on every audit recordyou are heredailyclock-synchronization-and-timestampsAmazon EC2 · AWS Systems Manager · AWS CloudTrail
- partialA demonstration run against the live log estate that audit records can be reduced, sorted and searched on demand by event criteria — the standing saved queries, the query that ran, and the report it returnedquarterlyaudit-reduction-and-report-generationAmazon CloudWatch Logs · AWS CloudTrail · Amazon Athena · Amazon S3
- partialFor each artifact actually running in the boundary, the cryptographic answer to whether it came from the build this provider claims built it: the signed provenance statement, the certificate identifying the workflow that produced it, and the transparency-log timestamps that make the signature checkable later. Collected alongside the two things that decide whether that answer can be trusted at all — the version of the verifying client, and the record of which deployed artifacts were submitted for verification in the first place.on-changebuild-provenance-attestation-verificationGitHub artifact attestations