The amount of time it takes EC2 to build a snapshot is directly proportional to the number of modified blocks that volume has seen since the last snapshot. In the case of your journal, that sees a lot of write/delete operations, so it's not surprising that it would take a long time to snap.
Keep in mind that these are truly block devices. They know nothing about your filesystem. It may be true that the journal volume only has 100GB used at the moment, but since the last snapshot, every single one of its blocks may have been modified. Some of those files that occupied those blocks have been deleted, so they don't appear "used" to your filesystem, but the block device itself knows nothing about that, so it has to snap all of that data. (As an aside, this is the same reason why AWS can't report on how much data is being stored in EBS volumes without a server-side agent that can query the storage at a filesystem level.)
To mitigate, you can try and take more frequent snapshots.
One question, though...why do you care how long it takes? Once the API call returns from your snap create request, you are free to continue using the volume, and any subsequent modifications to the block device will not be included in the snapshot.