I have had some serious issues with time accuracy on my Ubuntu EC2 machines, with drifts of more than 60 seconds.

A possible solution is running ntpdate or ntp, but I can't get them to work on EC2:

$ sudo ntpdate ntp.nasa.gov time-b.nist.gov

23 Jun 07:17:23 ntpdate[3878]: no server suitable for synchronization found

What have I tried:

• The ports on the specific machine I am testing are open for TCP and UDP, inbound and outbound (see below).


• I have tested this behaviour in more than one machine.


• I have tried different time servers.


• I have tried both ntpdate and ntp.

Any idea how to sync the time on my machines?

Security groups

Detailed logs

$ sudo ntpdate -vd ntp.nasa.gov time-b.nist.gov

23 Jun 07:24:08 ntpdate[3890]: ntpdate 4.2.6p5@1.2349-o Wed Oct  9 19:08:07 UTC 2013 (1)

Looking for host ntp.nasa.gov and service ntp

host found : ntp-nasa.arc.nasa.gov

Looking for host time-b.nist.gov and service ntp

host found : time-b.nist.gov

transmit(198.123.30.132)

transmit(129.6.15.29)

transmit(198.123.30.132)

transmit(129.6.15.29)

transmit(198.123.30.132)

transmit(129.6.15.29)

transmit(198.123.30.132)

transmit(129.6.15.29)

transmit(198.123.30.132)

transmit(129.6.15.29)

198.123.30.132: Server dropped: no data

129.6.15.29: Server dropped: no data

server 198.123.30.132, port 123

stratum 0, precision 0, leap 00, trust 000

refid [198.123.30.132], delay 0.00000, dispersion 64.00000

transmitted 4, in filter 4

reference time:    00000000.00000000  Mon, Jan  1 1900  0:00:00.000

originate timestamp: 00000000.00000000  Mon, Jan  1 1900  0:00:00.000

transmit timestamp:  d752549e.e0fc7517  Mon, Jun 23 2014  7:24:14.878

filter delay:  0.00000  0.00000  0.00000  0.00000

         0.00000  0.00000  0.00000  0.00000

filter offset: 0.000000 0.000000 0.000000 0.000000

         0.000000 0.000000 0.000000 0.000000

delay 0.00000, dispersion 64.00000

offset 0.000000



server 129.6.15.29, port 123

stratum 0, precision 0, leap 00, trust 000

refid [129.6.15.29], delay 0.00000, dispersion 64.00000

transmitted 4, in filter 4

reference time:    00000000.00000000  Mon, Jan  1 1900  0:00:00.000

originate timestamp: 00000000.00000000  Mon, Jan  1 1900  0:00:00.000

transmit timestamp:  d752549f.142f86b3  Mon, Jun 23 2014  7:24:15.078

filter delay:  0.00000  0.00000  0.00000  0.00000

         0.00000  0.00000  0.00000  0.00000

filter offset: 0.000000 0.000000 0.000000 0.000000

         0.000000 0.000000 0.000000 0.000000

delay 0.00000, dispersion 64.00000

offset 0.000000



23 Jun 07:24:17 ntpdate[3890]: no server suitable for synchronization found

Your security groups look like the VPC version, if that's the case I had to open UDP123/UDP* on my Network ACLs in order for it to work. VPCs have two layers of packet filtering, the Network ACL followed by the Security Groups. The SGs are STATEFUL (do not require inbound rules when connecting out first) but the NACLs are STATELESS (require rules to receive packets). Once I added the appropriate configuration line NTP worked perfectly.

I only added the line to my external NACL which run my service instances so they can access the outside NTP, they then run an NTP proxy for the rest of my network.

Good luck!

In EC2 the -u flag is required:

$ sudo ntpdate -u ntp.nasa.gov time-b.nist.gov

24 Jun 11:16:33 ntpdate[27714]: adjust time server 129.6.15.29 offset 0.047272 sec

From the manual:

   -u     Direct ntpdate to use an unprivileged port for outgoing packets.  This is most useful when behind a firewall that blocks incoming traffic to

          privileged ports, and you want to synchronise with hosts beyond the firewall. Note that the -d option always uses unprivileged ports.

Amazon provides Amazon Time Sync Service which eliminates the time drift you are experiencing. The overall steps to take on each EC2 instance are:

1. Remove NTP using sudo apt-get remove ntp


2. Install Chrony using sudo apt install chrony


3. use sudo vim /etc/chrony/chrony.conf to edit the file to include server 169.254.169.123 prefer iburst
   


4. Restart Chrony using sudo /etc/init.d/chrony restart


5. Verify Chrony is using the correct IP using chronyc sources -v and verifying that the output includes '^* 169.254.169.123'


6. Identify the best city to use by browsing the directories in ls /usr/share/zoneinfo/
   


7. Update the timezone from UTC using the path from the previous step, such as sudo timedatectl set-timezone /usr/share/zoneinfo/America/Chicago