> however, try creating an EC2 instance without a publicly addressable IP. You can't access S3 at all from your VPC, which makes S3 not usable in many use cases.
I don't see the problem with this. Either give your EC2 instance in your VPC a dedicated public IP and configure the security group to disallow all inbound connections, or use a public IP that routes all traffic for your VPC and again, secure it with a security group.
We do this right now with our environment, as our application is heavily EC2<->S3 dependent. It works without issue.
My use case is different. I want to put data into S3, but want it only accessible on my instances in the VPC, none of which I want to have access to the outside world.
I realize many people probably don't have this particular need, however, I don't think it's completely unreasonable. Instead, I'm just mounting an EBS volume on an instance and running nginx to serve files.
> My use case is different. I want to put data into S3, but want it only accessible on my instances in the VPC, none of which I want to have access to the outside world.
Which you can still do, by using bucket policies/permissions in S3 (specifically EC2 IAM roles in this scenario).
I think we're arguing different use cases though. If your content is only used or getting served from one machine, EBS volumes. If you need to have it served to the world, available to multiple instances, etc, S3.
I don't see the problem with this. Either give your EC2 instance in your VPC a dedicated public IP and configure the security group to disallow all inbound connections, or use a public IP that routes all traffic for your VPC and again, secure it with a security group.
We do this right now with our environment, as our application is heavily EC2<->S3 dependent. It works without issue.