The reason you want to stop your instance while the AMI is created (default behavior) is so that the snapshot of the root file system is completely consistent. Without this, you risk copying the block device while not all application or system file system changes have not yet been written from memory to disk.
This risk is increased the more active your server is with disk writes.
If you have a fairly quiet server, you can create an EBS boot AMI without stop/start (reboot) using these steps:
WARNING! THESE STEPS ARE NOT THE RECOMMENDED WAY TO CREATE AN AMI (IMAGE) FROM A RUNNING INSTANCE
If possible, log in to your server and run the following command to flush pending writes to disk. Writes made after this command may not make it to disk and applications may be saving their own changes in memory getting ready to write to disk, so there's your risk of inconsistency.
Create a snapshot of your root EBS volume and wait until it has completed.
Register the snapshot as an AMI (Image).
Steps 2 and 3 can be done through command line or through the EC2 console.
The tricky part is that you need to pick the correct AKI (kernel) and ARI (ramdisk) when you register the snapshot as an AMI. Find the kernel and ramdisk that were used by your running instance and use the same ones. For modern Ubuntu AMIs, no ramdisk is needed so leave it unspecified.
Test the new AMI carefully to make sure that you didn't create problems by not having a consistent file system. Note that problems may take a while to show up as they could be with any file/directory that was open near the time of the snapshot.
I cared so much about creating consistent snapshots, that I put together the community's best practices and published a command line tool to do it on a running system:
This may not be the best choice for EBS root volumes, though, as there are open log files and other conflicts that may be possible. Plus, most people aren't running XFS in the root disk.