It is not possible to share a single EBS volume between multiple EC2 instances.
Your diagram is offloading the data to a shared server. However, this shared server is simply another single-point-of-failure. So you're not saving yourself anything: if the AZ of that server goes down, then you've lost the data, even if the web server/VisualSVN server in another AZ is still running.
You should split your server between it's two separate functions into two separate servers/clusters so they can be handled independently of each other:
- web server, and
- VisualSVN server
For the web server, do you really need to mirror the volume in a multi-instance scenario, or can you keep your instances anytime-terminatable without data loss? Ideally, you would not save any data locally to the instance. Instead, you would save all data off-server to a database or to Amazon S3. This way, the data is available to all instances, all the time. If the server is lost, none of the data is. Make your "master" AMI and create all instances in an auto-scaling group from that master AMI. When your web server code changes, deploy a new AMI, terminate the old instances and create new ones from the new AMI.
For the VisualSVN server, the question to ask is whether VisualSVN can handle volume data changing on it without the running process caring about it. For example, if the running process caches some data in RAM, what happens if some hard drive sync process comes along behind it's back and changes the hard drive on it? It could be that the VisualSVN server simply is not able to handle a multi-instance scenario. Depending on the answer to that, you may not be able to cluster the VisualSVN server. It's possible that VisualSVN server has it's own clustering feature. If so, then you should investigate that.