Daemonic Dispatches

FreeBSD ZFS AMIs Now Available

Earlier today I sent an email to the freebsd-cloud mailing list:

Hi EC2 users,

FreeBSD 12.0-RELEASE is now available as AMIs with ZFS root disks in all 16
publicly available EC2 regions:

[List elided; see the GPG-signed email for AMI IDs]

The ZFS configuration (zpool named "zroot", mount point on /, /tmp,
/usr/{home,ports,src}, /var/{audit,crash,log,mail,tmp}) should match what
you get by installing FreeBSD 12.0-RELEASE from the published install media
and selecting the defaults for a ZFS install.  Other system configuration
matches the FreeBSD 12.0-RELEASE AMIs published by the release engineering
team.

I had to make one substantive change to 12.0-RELEASE, namely merging r343918
(which teaches /etc/rc.d/growfs how to grow ZFS disks, matching the behaviour
of the UFS AMIs in supporting larger-than-default root disks); I've MFCed
this to stable/12 so it will be present in 12.1 and later releases.

If you find these AMIs useful, please let me know, and consider donating to
support my work on FreeBSD/EC2 (https://www.patreon.com/cperciva).  If
there's enough interest I'll work with the release engineering team to add
ZFS AMIs to what they publish.

In the interests of both transparency and following my own advice of "we need to write more how-to-do-foo walkthroughs", here's the process I used to create those images.

1. Launch a FreeBSD 12.0-RELEASE AMI Builder instance; in the us-east-1 region, this is ami-09baac3ede1d33201. Due to issues related to disk device names, the AMI Builder doesn't work on the latest "nitro" instances; and because of what we're going to be doing, we need an instance with lots of RAM — so I used a t2.2xlarge instance for this.
2. Wait about 10 minutes (the AMI Builder boots into RAM but then needs to spend some time extracting FreeBSD before you can connect); then SSH in as ec2-user and su to root (no password needed).
3. The AMI Builder starts us off with FreeBSD installed onto a UFS filesystem, so we need to move those bits safely out of the way:

   mdconfig -a -t swap -s 3G -u 2
   newfs /dev/md2
   mkdir /mdisk
   mount /dev/md2 /mdisk
   tar -czf /mdisk/base.tgz --exclude .snap -C /mnt .
   umount /mnt
   

4. Next, wipe the old UFS bits out of the way and repartition the disk:

   gpart destroy -F ada0
   dd if=/dev/zero bs=128k of=/dev/ada0
   gpart create -s gpt ada0
   gpart add -a 4k -s 512K -t freebsd-boot ada0
   gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
   gpart add -a 1m -t freebsd-zfs -l disk0 ada0
   

5. Create all of the standard FreeBSD/ZFS datasets:

   zpool create -o altroot=/mnt -O compress=lz4 -O atime=off -m none -f zroot ada0p2
   zfs create -o mountpoint=none zroot/ROOT
   zfs create -o mountpoint=/ -o canmount=noauto zroot/ROOT/default
   mount -t zfs zroot/ROOT/default /mnt
   zfs create -o mountpoint=/tmp -o exec=on -o setuid=off zroot/tmp
   zfs create -o mountpoint=/usr -o canmount=off zroot/usr
   zfs create zroot/usr/home
   zfs create -o setuid=off zroot/usr/ports
   zfs create zroot/usr/src
   zfs create -o mountpoint=/var -o canmount=off zroot/var
   zfs create -o exec=off -o setuid=off zroot/var/audit
   zfs create -o exec=off -o setuid=off zroot/var/crash
   zfs create -o exec=off -o setuid=off zroot/var/log
   zfs create -o atime=on zroot/var/mail
   zfs create -o setuid=off zroot/var/tmp
   zpool set bootfs=zroot/ROOT/default zroot
   

6. And now we can extract FreeBSD back onto the newly-ZFS disk:

   tar -xf /mdisk/base.tgz -C /mnt
   

7. We no longer have a UFS filesystem, so we can get rid of the current contents of fstab(5); but we do need some configuration settings to support ZFS instead:

   : > /mnt/etc/fstab
   echo 'zfs_load="YES"' >> /mnt/boot/loader.conf
   echo 'kern.geom.label.disk_ident.enable="0"' >> /mnt/boot/loader.conf
   echo 'kern.geom.label.gptid.enable="0"' >> /mnt/boot/loader.conf
   echo 'vfs.zfs.min_auto_ashift=12' >> /mnt/etc/sysctl.conf
   echo 'zfs_enable="YES"' >> /mnt/etc/rc.conf
   

8. And in order to make ZFS expand when we first boot, we need an updated script for /etc/rc.d/growfs:

   svnlite export https://svn.freebsd.org/base/head/libexec/rc/rc.d/growfs
   cp growfs /mnt/etc/rc.d/growfs
   

9. Finally we can "poweroff" the instance

   shutdown -p now
   

   and then use the EC2 Management Console to create an image from the instance (or run aws ec2 create-image).

Thanks to the freebsd-cloud and freebsd-fs mailing lists, and Ben Woods in particular, for testing and feedback on my earlier attempts.

The many ways to launch FreeBSD in EC2

Talking to FreeBSD users recently, I became aware that while I've created a lot of tools, I haven't done a very good job of explaining how, and more importantly when to use them. So for all of the EC2-curious FreeBSD users out there: Here are the many ways to launch and configure FreeBSD in EC2 — ranging from the simplest to the most complicated (but most powerful):

Launch FreeBSD and SSH in

This is the most straightforward way to get started with FreeBSD: Using either the EC2 API (most easily accessed via the awscli package) or the AWS Console, spin up a "stock FreeBSD" AMI. You have a few choices to make here:

1. Whether to use the Community or Marketplace AMIs.
2. Which EC2 Region you want to launch your instance into.
3. Which of many EC2 instance types you want to use.
4. How large you want the root disk to be (the root filesystem will be resized automatically if you select a size larger than the default 10 GB) and whether to attach additional disks.

For a "hobbyist" the easiest answers will probably be to use the Marketplace AMIs, in the EC2 region which is geographically closest to you, with a t2.micro and a single 10 GB disk (the default).

After you launch the instance, you can ssh in as the ec2-user user and then su to root (no password required). From this point on, setting up your EC2 instance is just like setting up a physical server.

Launch FreeBSD and provide user-data

But what if you want a more automated process — something which will yield a consistent configuration, without the time-consuming process of SSHing in to set things up? Enter configinit.

When you launch an EC2 instance, you have the option of providing it with some "user-data". On FreeBSD, this is processed by configinit, which is a tool I wrote for configuring FreeBSD systems. For example, you can pass user-data of

>>/etc/rc.conf
firstboot_pkgs_list="apache24"
apache24_enable="YES"

to have FreeBSD install the apache24 package when it first boots and enable the Apache daemon. For more complex configurations you can provide a tarball containing files with directives to append to or replace multiple configuration files; to launch Portsnap mirrors, I have a configinit file which adds lines to rc.conf and newsyslog.conf, creates lighttpd.conf, runs a script to start synchronizing with the portsnap master server, etc.

Use the AMI Builder to create a customized FreeBSD AMI

Maybe rather than having commands run when FreeBSD first boots, you'd prefer to set things up ahead of time. Enter the FreeBSD AMI Builder.

This is an AMI which boots into a memory disk and installs FreeBSD onto the root disk — and then lets you make further changes before you create a new AMI from it. Long time EC2 users may recall that in the early days of EC2 — when everything was Ubuntu — the normal way to create a new AMI was to boot up an instance, make changes, and then package it up; this follows the same idea, but because the AMI Builder boots into a memory disk it avoids "contaminating" the image you're creating with keys and log files.

To make the process of building new AMIs even easier, the AMI Builder can make use of IAM Roles and runs configinit; so you can repeatably create customized FreeBSD AMIs in a matter of minutes with a single command.

I have built FreeBSD AMI Builder images in the us-east-1 region; the currently supported releases are FreeBSD 11.2 (ami-000414bbf0ee227c5) and FreeBSD 12.0 (ami-09baac3ede1d33201).

Build a FreeBSD AMI from a modified FreeBSD source tree

The options above all give you a FreeBSD RELEASE — possibly customized by installing extra packages and editing configuration files, but (unless you launch the AMI Builder and then buildworld/buildkernel inside there) you'll be running the binaries shipped by the FreeBSD Project. What if you have changes to FreeBSD itself — say, if there's a bug which was fixed after the release which you need to backport the fix for, or you need a custom kernel configuration? Enter make ec2ami.

This is in fact the exact mechanism used by the FreeBSD release engineering team to produce official FreeBSD AMIs — of course, they have the AWS keys needed to publish images into the official FreeBSD Release Engineering AWS account, but anyone with an AWS account can follow the same process using their own keys. Just run a buildworld/buildkernel of your modified FreeBSD, set up a few parameters (AWS keys, AWS region, and an S3 bucket to be used for staging the upload), and cd /usr/src/release && make ec2ami.

Build your own disk image

Finally, some people will want to build AMIs which are even more customized than you can easily do via the FreeBSD release code. Maybe you want to have a system which boots into a memory disk, so that it will keep working even if its EBS volume dies. Maybe you want to boot from NFS, making use of Amazon's Elastic File System (aka. NFS-as-a-service). Maybe you want to build an AMI for a completely different OS. For this, there's bsdec2-image-upload.

As the name suggests, that tool simply uploads a disk image and bakes it into an EC2 AMI. If you're going this route, everything else is up to you... but if you need to go this route, you're doing something sufficiently obscure that you almost certainly need to do everything yourself anyway.

---

I hope I've provided tools which help you to run FreeBSD in EC2, no matter how common or unusual your needs are. If you find my work useful, please consider supporting my work in this area; while this is both something I enjoy working on and something which is useful for my day job (Tarsnap, my online backup service), having support would make it easier for me to prioritize FreeBSD/EC2 issues over other projects.

How to port your OS to EC2

I've been the maintainer of the FreeBSD/EC2 platform for about 7.5 years now, and as far as "running things in virtual machines" goes, that remains the only operating system and the only cloud which I work on. That said, from time to time I get questions from people who want to port other operating systems into EC2, and being a member of the open source community, I do my best to help them. I realized a few days ago that rather than replying to emails one by one it would be more efficient to post something publicly; so — for the benefit of the dozen or so people who want to port operating systems to run in EC2, and the curiosity of maybe a thousand more people who use EC2 but will never build AMIs themselves — here's a rough guide to building EC2 images.

Prerequisites

Before we can talk about building images, there are some things you need:

• Your OS needs to run on x86 hardware. 64-bit ("amd64", "x86-64") is ideal, but I've managed to run 32-bit FreeBSD on "64-bit" EC2 instances so at least in some cases that's not strictly necessary.
• You almost certainly want to have drivers for Xen block devices (for all of the pre-Nitro EC2 instances) or for NVMe disks (for the most recent EC2 instances). Theoretically you could make do without these since there's some ATA emulation available for bootstrapping, but if you want to do any disk I/O after the kernel finishes booting you'll want to have a disk driver.
• Similarly, you need support for the Xen network interface (older instances), Intel 10 GbE SR-IOV networking (some newer but pre-Nitro instances), or Amazon's "ENA" network adapters (on Nitro instances), unless you plan on having instances which don't communicate over the network. The ENA driver is probably the hardest thing to port, since as far as I know there's no way to get your hands on the hardware directly, and it's very difficult to do any debugging in EC2 without having a working network.
• Finally, the obvious: You need to have an AWS account, and appropriate API access keys.

Building a disk image

The first step to building an EC2 AMI is to build a disk image. This needs to be a "live" disk image, not an installer image; but if you have a "live USB disk" image, that's almost certainly going to be the place to start. EC2 instances boot with a virtual BIOS so a disk image which can boot from a USB stick is almost certainly going to boot — at least as far as the boot loader — in EC2.

You're going to want to make some changes to what goes into that disk image later, but for now just build a disk image.

Building an AMI

I wrote a simple tool for converting disk images into EC2 instances: bsdec2-image-upload. It uploads a disk image to Amazon S3; makes an API call to import that disk image into an EBS volume; creates a snapshot of that volume; then registers an EC2 AMI using that snapshot.

To use bsdec2-image-upload, you'll first need to create an S3 bucket for it to use as a staging area. You can call it anything you like, but I recommend that you

• Create it in a "nearby" region (for performance reasons), and
• Set an S3 "lifecycle policy" which deletes objects automatically after 1 day (since bsdec2-image-upload doesn't clean up the S3 bucket, and those objects are useless once you've finished creating an AMI).

You'll also need to create an AWS key file in the format which bsdec2-image-upload expects:

ACCESS_KEY_ID=...
ACCESS_KEY_SECRET=...

Having done that, you can invoke bsdec2-image-upload:

# bsdec2-image-upload disk.img "AMI Name" "AMI Description" aws-region S3bucket awskeys

There are three additional options you can specify:

• --sriov: Mark the AMI as supporting the Intel 10 GbE SR-IOV network interface.
• --ena: Mark the AMI as supporting the Amazon ENA network interface.
• --public: Copy the image out to all the EC2 region and mark the AMIs as public.

After it uploads the image and registers the AMI, bsdec2-image-upload will print the AMI IDs for the relevant region(s). (Either for every region, or just for the single region where you uploaded it.)

Go ahead and create an AMI now, and try launching it.

Boot configuration

Odds are that your instance started booting and got as far as the boot loader launching the kernel, but at some point after that things went sideways. Now we start the iterative process of building disk images, turning them into AMIs, launching said AMIs, and seeing where they break. Some things you'll probably run into here:

• EC2 instances have two types of console available to them: A serial console and an VGA console. (Or rather, emulated serial and emulated VGA.) If you can have your kernel output go to both consoles, I recommend doing that. If you have to pick one, the serial console (which shows up as the "System Log" in EC2) is probably more useful than the VGA console (which shows up as "instance screenshot") since it lets you see more than one screen of logs at once; but there's a catch: Due to some bizarre breakage in EC2 — which I've been complaining about for ten years — the serial console is very "laggy". If you find that you're not getting any output, wait five minutes and try again.
• You may need to tell your kernel where to find the root filesystem. On FreeBSD we build our disk images using GPT labels, so we simply need to specify in /etc/fstab that the root filesystem is on /dev/gpt/rootfs; but if you can't do this, you'll probably need to have different AMIs for Nitro instances vs. non-Nitro instances since Xen block devices will typically show up with different device names from NVMe disks. On FreeBSD, I also needed to set the vfs.root.mountfrom kernel environment variable for a while; this also is no longer needed on FreeBSD but something similar may be needed on other systems.
• You'll need to enable networking, using DHCP. On FreeBSD, this means placing ifconfig_DEFAULT="SYNCDHCP" into /etc/rc.conf; other systems will have other ways of specifying network parameters, and it may be necessary to specify a setting for the Xen network device, Intel SR-IOV network, and the Amazon ENA interface so that you'll have the necessary configuration across all EC2 instance types. (On FreeBSD, ifconfig_DEFAULT takes care of specifying the network settings which should apply for whatever network interface the kernel finds at boot time.)
• You'll almost certainly want to turn on SSH, so that you can connect into newly launched instances and make use of them. Don't worry about setting a password or creating a user to SSH into yet — we'll take care of that later.

At this point, you should be able to launch an EC2 instance, get console output showing that it booted, and connect to the SSH daemon. (Remember to allow incoming connections on port 22 when you launch the EC2 instance!)

EC2 configuration

Now it's time to make the AMI behave like an EC2 instance. To this end, I prepared a set of rc.d scripts for FreeBSD. Most importantly, they

• Print the SSH host keys to the console, so that you can veriy that they are correct when you first SSH in. (Remember, Verifying SSH host keys is more important than flossing every day.)
• Download the SSH public key you want to use for logging in, and create an account (by default, "ec2-user") with that key set up for you.
• Fetch EC2 user-data and process it via configinit to allow you to configure the system as part of the process of launching it.

If your OS has an rc system derived from NetBSD's rc.d, you may be able to use these scripts without any changes by simply installing them and enabling them in /etc/rc.conf; otherwise you may need to write your own scripts using mine as a model.

Firstboot scripts

A feature I added to FreeBSD a few years ago is the concept of "firstboot" scripts: These startup scripts are only run the first time a system boots. The aforementioned configinit and SSH key fetching scripts are flagged this way — so if your OS doesn't support the "firstboot" keyword on rc.d scripts you'll need to hack around that — but EC2 instances also ship with other scripts set to run on the first boot:

• FreeBSD Update will fetch and install security and critical errata updates, and then reboot the system if necessary.
• The UFS filesystem on the "boot disk" will be automatically expanded to the full size of the disk — this makes it possible to specify a larger size of disk at EC2 instance launch time.
• Third-party packages will be automatically fetched and installed, according to a list in /etc/rc.conf. This is most useful if configinit is used to edit /etc/rc.conf, since it allows you to specify packages to install via the EC2 user-data.

While none of these are strictly necessary, I find them to be extremely useful and highly recommend implementing similar functionality in your systems.

Support my work!

I hope you find this useful, or at very least interesting. Please consider supporting my work in this area; while I'm happy to contribute my time to supporting open source software, it would be nice if I had money coming in which I could use to cover incidental expenses (e.g., conference travel) so that I didn't end up paying to contribute to FreeBSD.

Tarsnap pricing change

I launched the current Tarsnap website in 2009, and while we've made some minor adjustments to it over the years — e.g., adding a page of testimonials, adding much more documentation, and adding a page with .deb binary packages — the changes have overall been relatively modest. One thing people criticized the design for in 2009 was the fact that prices were quoted in picodollars; this is something I have insisted on retaining for the past eight years.

One of the harshest critics of Tarsnap's flat rate picodollars-per-byte pricing model is Patrick McKenzie — known to much of the Internet as "patio11" — who despite our frequent debates can take credit for ten times more new Tarsnap customers than anyone else, thanks to a single ten thousand word blog post about Tarsnap. The topic of picodollars has become something of an ongoing debate between us, with Patrick insisting that they communicate a fundamental lack of seriousness and sabotage Tarsnap's success as a business, and me insisting that using they communicate exactly what I want to communicate, and attract precisely the customer base I want to have. In spite of our disagreements, however, I really do value Patrick's input; indeed, the changes I mentioned above came about in large part due to the advice I received from him, and for a long time I've been considering following more of Patrick's advice.

A few weeks ago, I gave a talk at the AsiaBSDCon conference about profiling the FreeBSD kernel boot. (I'll be repeating the talk at BSDCan if anyone is interested in seeing it in person.) Since this was my first time in Tokyo (indeed, my first time anywhere in Asia) and despite communicating with him frequently I had never met Patrick in person, I thought it was only appropriate to meet him for dinner; fortunately the scheduling worked out and there was an evening when he was free and I wasn't suffering too much from jetlag. After dinner, Patrick told me about a cron job he runs:

Got dinner with @cperciva in Tokyo. At the end of dinner, told him about my cron job that polls Tarsnap looking for picodollars to go away.

After laughing then confirming I was serious he suggested I tell you, Twitter, so here you are.

I can be patient.

— Patrick McKenzie (@patio11) March 9, 2018

I knew then that the time was coming to make a change Patrick has long awaited: Getting rid of picodollars. It took a few weeks before the right moment arrived, but I'm proud to announce that as of today, April 1st 2018, Tarsnap's storage pricing is 8333333 attodollars per byte-day.

This addresses a long-standing concern I've had about Tarsnap's pricing: Tarsnap bills customers for usage on a daily basis, but since 250 picodollars is not a multiple of 30, usage bills have been rounded. Tarsnap's accounting code works with attodollars internally (Why attodollars? Because it's easy to have 18 decimal places of precision using fixed-point arithmetic with a 64-bit "attodollars" part.) and so during 30-day months I have in fact been rounding down and billing customers at a rate of 8333333 attodollars per byte-day for years — so making this change on the Tarsnap website brings it in line with the reality of the billing system.

Of course, there are other advantages to advertising Tarsnap's pricing in attodollars. Everything which was communicated by pricing storage in picodollars per byte-month is communicated even more effectively by advertising prices in attodollars per byte-day, and I have no doubt that Tarsnap users will appreciate the increased precision.

FreeBSD/EC2 history

A couple years ago Jeff Barr published a blog post with a timeline of EC2 instances. I thought at the time that I should write up a timeline of the FreeBSD/EC2 platform, but I didn't get around to it; but last week, as I prepared to ask for sponsorship for my work I decided that it was time to sit down and collect together the long history of how the platform has evolved and improved over the years.

Normally I don't edit blog posts after publishing them (with the exception of occasional typographical corrections), but I do plan on keeping this post up to date with future developments.

• August 25, 2006: Amazon EC2 launches. It supports a single version of Ubuntu Linux; FreeBSD is not available.
• December 13, 2010: I manage to get FreeBSD running on EC2 t1.micro instances.
• March 22, 2011: I manage to get FreeBSD running on EC2 "cluster compute" instances.
• July 8, 2011: I get FreeBSD 8.2 running on all 64-bit EC2 instance types, by marking it as "Windows" in order to get access to Xen/HVM virtualization. (Unfortunately this meant that users had to pay the higher "Windows" hourly pricing.)
• January 16, 2012: I get FreeBSD 9.0 running on 32-bit EC2 instances via the same "defenestration" trick. (Again, paying the "Windows" prices.)
• August 16, 2012: I move the FreeBSD rc.d scripts which handle "EC2" functionality (e.g., logging SSH host keys to the console) into the FreeBSD ports tree.
• October 7, 2012: I rework the build process for FreeBSD 9.1-RC1 and later to use "world" bits extracted from the release ISOs; only the kernel is custom-built. Also, the default SSH user changes from "root" to "ec2-user".
• October 31, 2012: Amazon launches the "M3" family of instances, which support Xen/HVM without FreeBSD needing to pay the "Windows" tax.
• November 21, 2012: I get FreeBSD added to the AWS Marketplace.
• October 2, 2013: I finish merging kernel patches into the FreeBSD base system, and rework the AMI build (again) so that FreeBSD 10.0-ALPHA4 and later use bits extracted from the release ISOs for the entire system (world + kernel). FreeBSD Update can now be used for updating everything (because now FreeBSD/EC2 uses a GENERIC kernel).
• October 27, 2013: I add code to EC2 images so that FreeBSD 10.0-BETA2 and later AMIs will run FreeBSD Update when they first boot in order to download and install any critical updates.
• December 1, 2013: I add code to EC2 images so that FreeBSD 10.0-BETA4 and later AMIs bootstrap the pkg tool and install packages at boot time (by default, the "awscli" package).
• December 9, 2013: I add configinit to FreeBSD 10.0-RC1 and later to allow systems to be easily configured via EC2 user-data.
• July 1, 2014: Amazon launches the "T2" family of instances; now the most modern family for every type of EC2 instance (regular, high-memory, high-CPU, high-I/O, burstable) supports HVM and there should no longer be any need for FreeBSD users to pay the "Windows tax".
• November 24, 2014: I add code to FreeBSD 10.2 and later to automatically resize their root filesystems when they first boot; this means that a larger root disk can be specified at instance launch time and everything will work as expected.
• April 1, 2015: I integrate the FreeBSD/EC2 build process into the FreeBSD release building process; FreeBSD 10.2-BETA1 and later AMIs are built by the FreeBSD release engineering team.
• January 12, 2016: I enable Intel 82599-based "first generation EC2 Enhanced Networking" in FreeBSD 11.0 and later.
• June 9, 2016: I enable the new EC2 VGA console functionality in FreeBSD 11.0 and later. (The old serial console also continues to work.)
• June 24, 2016: Intel 82599-based Enhanced Networking works reliably in FreeBSD 11.0 and later thanks to discovering and working around a Xen bug.
• June 29, 2016: I improve throughput on Xen blkfront devices (/dev/xbd*) by enabling indirect segment I/Os in FreeBSD 10.4 and later. (I wrote this functionality in July 2015, but left it disabled by default a first because a bug in EC2 caused it to hurt performance on some instances.)
• July 7, 2016: I fix a bug in FreeBSD's virtual memory initialization in order to allow it to support boot with 128 CPUs; aka. FreeBSD 11.0 and later support the EC2 x1.32xlarge instance type.
• January 26, 2017: I change the default configuration in FreeBSD 11.1 and later to support EC2's IPv6 networking setup out of the box (once you flip all of the necessary switches to enable IPv6 in EC2 itself).
• May 20, 2017: In collaboration with Rick Macklem, I make FreeBSD 11.1 and later compatible with the Amazon "Elastic File System" (aka. NFSv4-as-a-service) via the newly added "oneopenown" mount option (and lots of bug fixes).
• May 25, 2017: I enable support for the Amazon "Elastic Network Adapter" in FreeBSD 11.1 and later. (The vast majority of the work — porting the driver code — was done by Semihalf with sponsorship from Amazon.)
• December 5, 2017: I change the default configuration in FreeBSD 11.2 and later to make use of the Amazon Time Sync Service (aka. NTP-as-a-service).

The current status

The upcoming FreeBSD release (11.2) supports: IPv6, Enhanced Networking (both generations), Amazon Elastic File System, Amazon Time Sync Service, both consoles (Serial + VGA), and every EC2 instance type (although I'm not sure if FreeBSD has drivers to make use of the FPGA or GPU hardware on those instances).

When a FreeBSD/EC2 instance first launches, it uses configinit to perform any desired configuration based on user-data scripts, and then (unless configinit is used to change this) resizes its root filesystem to fit the provided root disk, downloads and installs critical updates, sets up the ec2-user user for SSH access, and prints SSH host keys to the consoles.

If there's something else you think FreeBSD should support or a change you'd like to see to the default configuration, please let me know.