This is a very good suggestion! However as soemone who has looked into this technology, there are a few pitfalls to be aware of.
The tos can be easily violated closing down the whole school or installation or incurring extra bandwidth costs if someone breaches the cloud providers tos by loading viruses, opening a file drop or distribution drop site, proxy, game server or such. You can also risk these events if you plan to demonstrate programming methods that could have a bug that suddenly consumes excess bandwidth or someone interacts, by accident with the vm host causing a crash.
Since you are dealing with kids who test boundaries as a group --someone is bound to do something far more clever then you plan for. Get your plan ready to respond to such events before they occur if you go the cloud route make certain that one bad apple cant incur extra costs or cause a site wide outage. So talk to the cloud provider and find out how and when your site can incur extra costs or violate the tos due to student behavior.
Have the project administrator set firewall rules to only allow incoming SSH from the public Internet, and a then allow network communications between the VMs in the project.
Don't worry about consuming "extra" bandwidth between VMs. Google's internal network can handle anything the students throw at it. Ingress and egress network traffic within the same zone is free. See GCE pricing.
Also, don't worry about the VM hosts going down due to anything that happens in the guest. If a high school kid somehow figures out a way to bring one down, we'd like to talk to him about a possible career in virtualization and security. And we've been known to pay out rewards for that sort of thing.
There are a lot of good answers here to your direct question, but I'd like to step back and look into solutions that are recently available for the more general problem you are facing.
I have to wonder what it's costing the school district to acquire and maintain the hardware to run your classes. On top of that, you're having to worry about the overhead of securing/patching and maintaining backups.
(Disclaimer: I work for Google on Compute Engine.)
Have you evaluated whether an IaaS service like Google Compute Engine would be more convenient and cost-effective? Security, backups, and persistent storage are all taken care of for you. Google's base VMs are 13.2 cents per hour. For a class of 30, that's about $4 per class session. There are about 180 days in a school year, so that's $720 per class for the entire year. If you have 4 classes a day, that's about $3,000 for the entire year, assuming your VMs are all running the entire time every class session. In practice, if I were teaching the class, I'd lecture for 3 days a week and have VM time 2 days a week, with the option of the students being able to access their VMs outside of class from home, so the actual cost will probably be lower.
As far as hardware is concerned, Chromebooks are $250 each. I bet you're spending significantly more than that per machine in your labs. You can use the terminal tab in ChromeOS to SSH into the VM instances.
Have you considered an IaaS provider? If not, I'm curious to hear how the current offerings out there in the market fall short of the solution you're looking into now.
but again, it would be performance with the data encryption, compared to non-encrypting EBS.
This is what RightScale, an early Google Compute Engine customer, had to say regarding encryption and performance: http://blog.rightscale.com/2012/06/28/rightscale-joins-google-compute-engine-for-launch-day/
One very aggressive innovation that Google Compute Engine brings to cloud computing is encryption of data at rest, both for local ephemeral drives as well as for network attached drives. In the case of the network attached disks the encryption happens on the host before it is put on the network, so it’s also encrypted in transit. The encryption is on a per-project basis (Google’s term for an account). This is a big deal for security conscious organizations, especially those having regulatory or other mandates to encrypt all data at rest. On other clouds one solution is to run a loop-back crypto driver, but that eats into the VM’s performance. I’ve been benchmarking the Google Compute Engine disk performance (more on that in a future post) and the encryption doesn’t seem to have a noticeable impact on performance. Pretty awesome.
It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?
The Google Compute Engine FAQ sheds some light on these details: https://developers.google.com/compute/docs/faq#disks
Can I retrieve ephemeral disk data if I have lost it?
No. All data written to ephemeral disk is encrypted with a key that is unique to the VM instance. By design, once a virtual machine terminates, all data on the ephemeral disk is lost.