Comment 8 for bug 1202758

Interesting, i launched 10 instances and grepped cloud-init timestamps.
it seems pretty reliable that the ifdownup cycle is reported to take between 12 and 22 seconds.

$ cat /etc/cloud/cloud.cfg.d/my.cfg
datasource:
 Azure:
  hostname_bounce:
   # policy can be 'on', 'off' or 'force'
   policy: force
   # the method 'bounce' command.
   command: ["bash", "-xc", 'date; cat /proc/uptime; time echo ifdown $interface; cat /proc/uptime; date; cat /proc/uptime; time echo ifup $interface; cat /proc/uptime; date']

I put the above in that file, and then
echo "ubuntu" | time sudo sh -c 'tee /etc/hostname; hostname -F /etc/hostname; ifdown eth0; ifup eth0;' ; sudo rm -Rf /var/lib/cloud/ /var/log/cloud-init.log

and reboot.

The issue seems to be ntpdate somehow getting in the way, although I'm not exactly sure how.
If I put the .cfg file in place above, and then do:

chmod ugo-x /etc/network/if-up.d/ntpdate
sudo rm /var/lib/cloud/instance/obj.pkl ; time sudo cloud-init init
..
real 0m1.273s
user 0m0.791s
sys 0m0.257s

then this will take wall clock ~1.2 seconds.
doing the same with execute permissions on that file takes much longer.
$ sudo chmod ugo+x /etc/network/if-up.d/ntpdate; sudo rm /var/lib/cloud/instance/obj.pkl ; time sudo cloud-init init
...
real 0m7.689s
user 0m0.804s
sys 0m0.267s

just for reference, actually counting in my head, there is a measurable difference in time (ie, its not just a clock-getting-set-while-counting-thing).

You can run the above without rebooting too, and you'll see the issue.