c10.6 Keep system clocks consistent with Amazon Time Sync
Synchronize and protect system time across all components using the Amazon Time Sync Service so audit log timestamps are accurate and consistent.
Requirement 10
Log and Monitor All Access to System Components and Cardholder Data
PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.
10.6 Time-synchronization mechanisms support consistent time settings
- 10.6.1 System clocks and time synchronized using time-sync technology Covered
- 10.6.2 Systems configured to correct and consistent time Covered
- 10.6.3 Time synchronization settings and data protected Covered
How to implement on AWS
Use the Amazon Time Sync Service via the link-local endpoint (169.254.169.123 IPv4 / fd00:ec2::123 IPv6, reachable on EC2 without internet access) as the time source for all instances. Note: the NTP source is OS-level configuration inside the instance, not an IAM setting — manage and enforce it with Systems Manager (State Manager / RunCommand) and restrict who can log into the instances. Monitor clock drift with Amazon CloudWatch (for example using ClockBound) and alert on sync failures. Containers and managed services inherit synchronized time from the host.
Practical implementation
How this control is implemented in each reference architecture:
Point every instance at the Amazon Time Sync link-local endpoint via SSM-managed OS config, and monitor drift with CloudWatch.
- Configure the OS NTP client to use the Amazon Time Sync link-local endpoint (169.254.169.123 / fd00:ec2::123).
- Manage and enforce that NTP configuration at the OS level with Systems Manager (State Manager association), and restrict instance login so the time config can't be changed ad hoc.
- Monitor clock drift and alert on time-sync failures with CloudWatch (e.g. ClockBound metrics).
How to validate: Instances resolve time from the Amazon Time Sync endpoint, the NTP config is enforced via SSM, and CloudWatch alerts on drift/failure.
Avoid: Treating time config as an IAM permission or assuming a Config managed rule exists for NTP — it is OS config, enforced via SSM and monitored via CloudWatch.
Standardize the Amazon Time Sync OS config via golden images + SSM across accounts, and centralize drift alerts.
- Bake the Amazon Time Sync NTP configuration into golden AMIs / launch templates used across accounts.
- Enforce and remediate the NTP OS configuration fleet-wide with Systems Manager; use a custom Config rule (Lambda) if you need config-state reporting (there is no managed NTP rule).
- Centralize clock-drift and sync-failure alerts to the security account via CloudWatch.
How to validate: Golden images set the Amazon Time Sync endpoint; SSM enforces the OS config across accounts; CloudWatch centralizes drift alerts.
Avoid: Relying on a non-existent managed Config rule for time sync. Enforce via SSM; report via a custom rule or CloudWatch.
PCI validation
Testing procedures
- Examine instance OS time configuration to verify it uses the Amazon Time Sync Service, that the config is enforced (e.g. via Systems Manager), and that drift is monitored and alerted.
Evidence in AWS
- OS NTP/chrony configuration pointing at 169.254.169.123 / fd00:ec2::123
- Systems Manager State Manager association enforcing the time config
- CloudWatch alarms for clock drift / time-sync failure
Customized approach
Customized Approach Objective
- 10.6 — System clocks and time are synchronized and the time data is protected.
AWS services
Learning resources
References
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
PCI DSS Security Maturity Model