The normal cloud architecture doctrine would say that you should pull data off to a separate tier - S3 for blobs, SimpleDB for non-relational data, RDS for relational data, etc. - and that the scaling front ends should not have data on them.
EBSes and snapshots are also an option, it depends how frequently you're going to be changing the files. If users are contributing the data/files, you almost certainly need to go to a shared repo per the above. But if it's just you, then other stuff works fine.
If you do, you have to deal with replication complexity. Via cloudinit, or a dedicated pull provisioning mechanisms like chef or puppet, you can do a pull sync. The issue here is that when you want to change the content, you have to push it to all the servers as well (or rely on scheduled pulls). Which for static Web content is probably fine; once you want to manage apps across servers too it gets touchier, and also depends on whether you're changing the files about every month or about every five minutes.
We use an orchestration mechanism combined with push sync. When a new server comes up it registers and gets an immediate push of current content; then when we push new content we push it to all active servers. This has the benefit of using the same channel for initial seeding at provisioning time and later changes. Some folks hack chef/puppet to do similar (or augment them with a dedicated push mechanism like capistrano).