Unless you are doing a lot of extra (expensive) magic, I could easily do:
1) Traffic analysis of your read/write patterns -- probably not a huge issue for many web apps, but there are enterprise apps where I could probably do some harm. You would need to do some crazy blinding to protect from this, at a directly higher S3 and bandwidth cost.
2) DoS (mainly, try to compromise the Amazon S3 credentials; or, a malicious Amazon) -- all I'd need to do is flip one bit in your bucket and your OpenPGP checksums wouldn't match...; I could also do malicious MITM attacks between S3 and the "cloudlane" box)
3) Availability attacks vs. S3 -- for a lot of users, confidentiality and integrity are important, but if I can make S3 unavailable to you at the network layer, it might kill the online performance of your application. This isn't as big a deal for archival storage, but if someone thinks using crypto for confidentiality is enough to move an otherwise-in-house app to the cloud safely, it might be fun to provide some user education.
2) DoS (mainly, try to compromise the Amazon S3 credentials; or, a malicious Amazon) -- all I'd need to do is flip one bit in your bucket and your OpenPGP checksums wouldn't match...; I could also do malicious MITM attacks between S3 and the "cloudlane" box)
3) Availability attacks vs. S3 -- for a lot of users, confidentiality and integrity are important, but if I can make S3 unavailable to you at the network layer, it might kill the online performance of your application. This isn't as big a deal for archival storage, but if someone thinks using crypto for confidentiality is enough to move an otherwise-in-house app to the cloud safely, it might be fun to provide some user education.