As cyberx86 says, EBS volumes cannot be mounted on multiple EC2 instances (even in the same Availability Zone).
The first answer should be to store your shared assets in Amazon S3 - that way, you can deploy your code via Capistrano/Mcollective/whatever directly to both your live and standby EC2 instances, and completely offload your static content (i.e. images, media) to S3, perhaps even with CloudFront providing edge caching.
That said, S3 doesn't do cross-region replication (EU-West-1 to US-East-1), however it does offer "four nines" (99.99%) of availability within a region, so a full region-wide failure is unlikely. For a 'belt and braces' approach you may want to configure a cron'd synchronisation process between S3 buckets in two different regions - take a look at the
s3cmd documentation with the
If porting your assets to S3 is too much of a pain, and if your failover mechanism is hot-standby (i.e. you have an always-ready clone in another region and manual failover), you can configure a cron'd
rsync run to keep your non-version-controlled assets synchronised (as before, you should always release your app code to all servers.
Clustered filesystems (e.g. GlusterFS, GFS2) or block-level replication (e.g. DRBD) isn't really recommended with EC2 (or at least not unless you shell out for instances with guaranteed NIC bandwidth such as the cluster networking range). S3FS has proven to be painfully slow, due to the fact that every IO request on the filesystem has to be backed with an S3 API call - details here: (1), (2).
You can run into network congestion caused by other tenants (or even create congestion yourself) - these types of solutions are best fitted to environments where you control (or at least have influence over) the entire stack.