Here I'm talking about cloud servers (from any vendor) which feature some amount of ephemeral SSD storage. When working with standard images, by default this ephemeral SSD storage is wasted and not utilized.
When deploying a LAMP stack onto such VMs, what are some obvious ways to utilize ephemeral SSD storage?
An obvious example is to put the swapfile and /tmp on the ephemeral.
What else is low-hanging fruit? Things so obvious that only an incompetent sysadmin would miss?
/tmp and swap are indeed the obvious low-hanging fruit.
Anything else I can think of, I suggest, would be pretty much application specific.
Either that, or you and I are both comparably incompetent sysadmins, since we are both overlooking something obvious.
Ephemeral storage is free and fast, and survives a user-initiated instance reboot, so really, anything that's ultimately "disposable" could be (automatically) staged there from elsewhere (perhaps cloned from a code repository or extracted from a tarball stored in S3) when an instance is launched or otherwise derived from its origin.
When you are fully "thinking cloud" then many would argue that essentially everything on many or most servers should be disposable... I would suggest that many or most of us recognize this trend are but only on our way there -- we haven't fully arrived.
If your syslogs are being collected remotely, your local syslogs arguably could go to an ephemeral disk. The same goes for web server or proxy logs, when the content of the logs is not considered particularly valuable or you're collecting them primarily just because you can.
Speaking of "just because you can," in one case, I have a legacy server with a SAN array in a physical data center, with a large pool of static assets that are eventually going to be migrated to S3. Until then, in addition to scheduled backups, the files are also synced to ephemeral drives on some instances where the ephemeral drives don't have any particularly clear use. These serve as online standby copies and would be much faster to go live than restoring from backup in the event of something catastrophic.
We have an application that builds a substantial SOLR index entirely from scratch (from other sources) twice a day, then pushes it to the master server. This is not "temp" space in the classic sense, but yes, that's built on an ephemeral disk.
One of my staging database server setups comes to mind as an application-specific example... it is only used for testing code against a clone of the production database. The entire MySQL backing store is on an ephemeral disk. I've customized the initscript so "sudo service mysql resync" stops the MySQL Server daemon, moves the current directory out of the way (renames it with date and time in the filename), copies (from EBS) the backing store of a fresh MySQL install, symlinks /usr/local/mysql/data to the new ephemeral directory, starts MySQL, fetches a live copy of the production database, loads it... and the developer now has an identical clone of the production db... which is, of course, disposable since it's immediately "stale" and only used for testing code against. If you launch a new one of these from an AMI, it wakes up realizing it has no database, and grabs a new copy of the master db right out of the box.
Another scenario might be a clustered database, where all nodes have a copy of all data and operate as a quorum (like MariaDB Galera Cluster). Such clusters, particularly when geographically distributed, need an appropriately selected (usually odd) number of nodes under normal operation, because the entire cluster will become unavailable, as a protective measure, in an isolation event (partitioning) unless a single partition still exists that contains more than half the number of nodes that were online before the split occurred. A 2-node cluster or 4-node cluster becomes useless when split down the middle, since no majority remains. This is sometimes addressed with an "arbiter" node, which votes in the quorum but does not actually have a copy of the data. Its entire existence is to keep the cluster happy. Go one step further and make good use of the ephemeral store on that node, making it a full node, giving it a full copy of the data instead of just making it an arbiter.
A potentially interesting idea would involve combining an ephemeral volume with an EBS volume in a RAID-1 configuration. Depending on who you believe, there's a potential for near-doubling of read I/O when reading multiple files concurrently.
I fear I have digressed somewhat heavily into DBA land with this answer, but these are the kinds of things I use the ephemeral volumes for in my world... aside from the obvious, which you have already identified.
