...
- See above details about the general S3 scenario.
- The platform grants access to the data by updating the bucket policy for the dataset to which the user would like access.
- Users will + need AWS accounts.
- The platform has a custom solution for collecting payment from users to pay for their usage.
...
- We would want to ensure that buckets contain the right granularity of data to which we want to provide access since its all or none of the bucket. Therefore, we might have a separate bucket for each data set.
- The repository service grants access by adding the users AWS account number to the bucket policy for the desired dataset.
- The repository service vends S3 URLs.
- Users will need to sign those S3 URLs with their AWS credentials using the usual toolkit provided by Amazon. TODO try this to understand the user experience, if stuff just shows up in the AWS console, that would be ideal
Pros:
- It will be useful if we want to grant access to an entire institution. For example, we may add ISB's AWS account to have read access to one or more S3 buckets of Sage data layers.
- From the S3 logs we will be able to see who downloaded the data and compute charge backs for our custom solution.
Cons:
- This mechanism will not scale to grant access for tens of thousands of individuals therefore it will not be sufficient for "unrestricted data". It may scale sufficiently for "embargoed data" and "restricted data".
...
This is the newest mechanism for access control and is under heavy development in 2011 to expand its features. With IAM a group of users (as opposed to AWS accounts) can be granted access to S3 resources. We decide who those users are. We hand credentials to them for those resources. All activity is rolled up to a single bill.
...
- See above details about the general S3 scenario.
- The platform grants access to the data by creating a new IAM user and adding them to the group that has access to the dataset.
- Users will + need+ AWS accounts. TODO confirm
- The platform has a custom solution for collecting payment from users to pay for their usage.
...
- This will be helpful for managing access Sage system administrators and Sage employees.
Cons:
- This may be confusing for users. They will likely have their own AWS credentials plus separate credentials for each data set to which we have granted them access??? TODO confirm
- This is currently limited to 1,000 users. We may be able to ask Deepak to raise that limit for us. The limit will be raised within a year as AWS rolls out expanded support for federated access to AWS resources.
...
Cloud Front supports the notion of private content. Cloud front urls URLs can be created with access policies such as an expires time and an IP mask. This is ruled out since S3 provides a similar feature and we do not need a CDN for any of the usual reasons one wants to use a CDN.
...
- This would work for the download of protected content use cases.
Cons:
- Note that this is likely a bad solution for the EC2/EMR use cases because Cloud Front sits outside of AWS and users will incur the inbound bandwidth charges when they pull the data down to EC2/EMR.
- There is an additional charge on top of the S3 hosting costs.
...
- full flexibility
- we can accurately track who has downloaded what when
Cons:
- we have another service fleet to administer
- we are now the scalability bottleneck
...
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.
...