Block devices as a computing model is not designed for access from more than one device. The EBS abstraction of this hardware model is not capable of changing the rules of the game because the file system drivers in the overlying computing instances are still the same. They can only do magic like snapshotting because the read access in the underlying layer doesn't interfere with what the software on the system expects to be going on on a block devices. If some system other than the one EC2 instance the volume is connected to tried to change the bits on your disks directly, the file system would self destruct.
The only thing you can do that is special with EBS is use snapshots to clone drives and attach each device clone to a separate instance. This would be useful if you had a relatively static data set with only periodic updates and needed fast local access to eat from many instances.
You will need to move your sharing architecture up one level to the filesystem. There are lots of tools to do this, including shared file systems such as
nfs. Of course your performance will be limited to that of the EC2 instance you connect the device to and use as the file server.
If you require something more subtle than those two approaches, you will need to look into on of the varous distributed, replicating or cluster file systems. Also as you mentioned there are lower level synchronization tools like DRDB, but I suggest you are more likely to need a filesystem level than block level synchronization system.
For extra credit: check out some of the talk going on these days about whether block devices are ever the right model to use such as this article: Magical Block Store: When Abstractions Fail Us.