Do I need to make a partition on an EBS volume? What is better?

Inside EC2, to me, it only really makes sense to use the entire volume for the filesystem, because of the flexibility allowed by Elastic Block Store (EBS) volumes, which are much different than many physical disks, in the sense that you can provision them as needed, destroy them as needed, attach and detach them from instances without rebooting, and take snapshots and clone them without using the instance's processor, memory, or I/O. And, without a partition table, resizing when you need more space is cake.

Need a bigger filesystem? If you're using the entire volume without a partition table, it's very straightforward.

Make an EBS snapshot of the volume using the AWS console, with the volume still mounted and in use. You will not actually use this snapshot, but trust me for a moment. If you recently made a snapshot of the volume, and still have it, you could skip this step, because the purpose here is to make the rest of the steps faster.

Unmount the volume.

Take a second snapshot. This is the one you want. We made the previous one because it will make this snapshot much faster. When EBS takes a snapshot, it saves the disk contents to a hidden repository on S3. For each consecutive snapshot of the same volume, only the changed blocks need to be stored, so this snapshot will be built, mostly, with stored pointers to the location of all the data that's already been captured, and only changed blocks will be physically backed up.

Create a new volume, using the last snapshot.

Attach the new volume to the instance in place of the old one, and mount it. Verify the data as needed.

Then, you can use resize2fs to grow the filesystem to fill the available size on the new volume, while the volume is in use.

Then delete the first snapshot above. EBS will "roll forward" everything it contains that is also needed by the final snapshot, so the final snapshot is still valid.

As a final step, you may want to warm up the new volume using sudo dd if=/dev/xvdx of=/dev/null bs=1M. When a volume is created from a snapshot, the contents of the volume are loaded "lazily" from the snapshot onto the actual volume, which means the volume becomes fully available before its performance is optimal. If you ask for something from the volume that hasn't been loaded yet by the background process, you'll still get it almost immediately, but not as fast as if the background process had loaded everything. The dd operation, above, does a physical read of the entire volume, causing the whole thing to be available with the lowest possible latency, more quickly than it otherwise might. This is documented as something that should be done with the volume unmounted, but whether you do it before or after the resize isn't terribly important. The various flavors of pre-warming EBS volumes is discussed at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-prewarm.html ...

To me, using the entire volume for the filesystem, without a partition table, seems like the only way to go, since it minimizes downtime and the opportunity for error. All of my EBS (and ephemeral, for that matter) volumes are done this way, except for some very early ones.

You can, of course, use fdisk or parted to create and modify the partition table in the customary way, but -- in my opinion -- this is unnecessarily adding additional "moving parts" ... which usually translates to more opportunity for error.

If you know how to get your local machine's X-Server working, and accepting incoming connections from the EC2 instance in order to display the GUI output locally, you can also easily use the graphical tool gparted on EC2 instances, with the graphical interface displaying on your local workstation screen -- yes, this works, I've done it -- but getting that working is outside the scope of this question.