...
Cloud Front Private Content
Cloud Front supports the notion of private content. Cloud front urls can be created with access policies such as an expires time and an IP mask.
...
Options to have customers bear some of the costs
S3 "Requester Pays" Buckets
http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RequesterPaysBuckets.html
Dev Pay
...
Custom Proxy to S3
All files are kept completely private on S3 and we write a custom proxy that allows users with permission to download files whether to locations outside AWS or to EC2 hosts.
Pros:
- full flexibility
Cons:
- we are now the scalability bottleneck
If all else fails we can do this, but it will be more work operationally to manage a fleet of custom proxy servers.
Options to have customers bear some of the costs
S3 "Requester Pays" Buckets
Scenario:
- The platform requires that users give us their AWS account number for download use cases.
Open Questions:
- This statement from http://docs.amazonwebservices.com/AmazonS3/
...
...
Flexible Payments Service
EBS
Data is available as hard drive snaphots.
Pros:
- Its a convenient way to access data from EC2 instances.
Cons:
- This only covers our cloud compute use case, not our download use case.
EBS snapshot ACL
Open questions:
- What is the max grant number for this?
Resources
- RequesterPaysBucketConfiguration.html it sounds like this won't work with S3 Pre-Signed URLs: "Bucket owners who give out pre-signed URLs should think twice before configuring a bucket to be Requester Pays, especially if the URL has a very long expiry. The bucket owner is charged each time the requester uses pre-signed URLs that use the bucket owner's credentials."
- But on http://docs.amazonwebservices.com/AWSEC2AmazonS3/latest/APIReferencedev/index.html?ApiReference-query-ModifySnapshotAttribute.html
Custom Proxy
All files are kept completely private on S3 and we write a custom proxy that allows users with permission to download files whether to locations outside AWS or to EC2 hosts.
Pros:
- full flexibility
Cons:
- we are now the scalability bottleneck
...
- ObjectsinRequesterPaysBuckets.html is says "For signed URLs, include x-amz-request-payer=requester in the request". So is it correct that the bucket owner cannot make signed urls for other payers because the credentials won't match?
Resources:
- In general, bucket owners pay for all Amazon S3 storage and data transfer costs associated with their bucket. A bucket owner, however, can configure a bucket to be a Requester Pays bucket. With Requester Pays buckets, the requester instead of the bucket owner pays the cost of the request and the data download from the bucket. The bucket owner always pays the cost of storing data.
- Typically, you configure buckets to be Requester Pays when you want to share data but not incur charges associated with others accessing the data. You might, for example, use Requester Pays buckets when making available large data sets, such as zip code directories, reference data, geospatial information, or web crawling data.
- Important: If you enable Requester Pays on a bucket, anonymous access to that bucket is not allowed.
- You must authenticate all requests involving Requester Pays buckets. The request authentication enables Amazon S3 to identify and charge the requester for their use of the Requester Pays bucket.
- After you configure a bucket to be a Requester Pays bucket, requesters must include x-amz-request-payer in their requests either in the header, for POST and GET requests, or as a parameter in a REST request to show that they understand that they will be charged for the request and the data download.
- Requester Pays buckets do not support the following.
- Anonymous requests
- BitTorrent
- SOAP requests
- You cannot use a Requester Pays bucket as the target bucket for end user logging, or vice versa. However, you can turn on end user logging on a Requester Pays bucket where the target bucket is a non Requester Pays bucket.
- http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RequesterPaysBuckets.html
Dev Pay
The Requester Pays feature (used alone) lets you give other Amazon S3 users access to your data, but you can't make a profit; you can only avoid paying data transfer and request costs.
DevPay (used alone) lets you give access to your data to anyone who is signed up for your product (regardless if they're Amazon S3 users). But because the DevPay bucket isn't a Requester Pays bucket, you (as the owner of the bucket) still pay for data transfer and requests (at the DevPay product's price).
You need to use DevPay together with a Requester Pays bucket if you want to charge people a premium to download your data (the overall process is described in Selling Your Data). Note that because you're using DevPay, your customers don't have to be Amazon S3 users.
When you use DevPay with your Requester Pays bucket, your customers download your data to a location outside Amazon S3. They don't copy the data from your bucket to theirs.
This is for the cloud compute use case?
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/dev/index.html?UsingDevPay.html
Dev Pay + S3 Requester Pays
This is for the download use case.
Resources
Flexible Payments Service, PayPal, etc.
We can use general services for billing customers. It would be up to us to determine what is a transaction, how much to charge, etc.
We may need to keep out own transaction ledger and issue bills. We would definitely let another company deal with credit card operations.
EBS
Data is available as hard drive snaphots.
Pros:
- Its a convenient way to access data from EC2 instances.
Cons:
- This only covers our cloud compute use case, not our download use case.
Recommendation: focus on S3 for now since it can meet all our use cases. Work on this later if customers ask for it due to its convenience in a cloud computing environment.
EBS snapshot ACL
Open questions:
- What is the max grant number for this?
Resources
File Organization and Format
...
The Pacific Northwest Gigapop is the point of presence for the Internet2/Abilene network in the Pacific Northwest. The PNWGP is connected to the Abilene backbone via a 10 GbE link. In turn, the Abilene Seattle node is connected via OC-192 192 links to both Sunnyvale, California and Denver, Colorado.
PNWPG offers two types of Internet2/Abilene interconnects: Internet2/Abilene transit services and Internet2/Abilene peering at Pacific Wave International Peering Exchange. See Participant Services for more information.
...