You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

Answers to questions about AWS that we often see at Cornell.


 

Billing

What is the AWS Data Egress Waiver?

AWS offers a Data Egress Waiver that mostly eliminates Data Transfer charges for Cornell. See the AWS blog post about it for more details.

How much are Data Transfer Charges for Cornell? Are we close to the 15% cap for the AWS Data Egress Waiver?

This chart of recent billing data shows that Cornell is not near the 15% cap of the Data Egress Waiver.

How come my AWS bill contains charges for EC2 when I haven't used EC2 at all?

In most cases, the EC2 charge you are seeing is a result of the standard configuration we use in your VPC. The private subnets in your Cornell standard VPC are connected to the world (for outgoing traffic) by a NAT instance. That NAT instance is really a small EC2 instance, though it won't appear in your EC2 instance list in the AWS Console. You can see the NAT instance(s) configured for your account here: https://console.aws.amazon.com/vpc/home?region=us-east-1#NatGateways:sort=desc:createTime

The NAT instance gives EC2 instances in your private subnets access to the world for things like Linux repos, Windows update servers. We do have some AWS account owners that do not find the $1/day cost of the NAT to be worthwhile and turn it off. However, we caution  about this because, with it off, your instances will not be able to do something as basic and critical as running "yum update" or "apt-get update" or get Windows updates.

Contact the Cloud Team if you'd rather not have the NAT deployed for that VPC.

See NAT Gateway pricing info here: https://aws.amazon.com/vpc/pricing/.

When will direct billing (though KFS) based on "Cost Center" tags be released?

This is still a work in progress and we expect to release this Cornell KFS feature in Spring 2017.  In the meantime, you should strive to add "Cost Center" tags to your AWS resources as soon as possible. See Standard Tagging for details.

Until direct billing is turned on, you can use CloudCheckr or our billing API to sub-total the resource costs in your account (based on tag) and re-allocate those costs with the help of your unit Business Service Center.

When I purchase a reserved EC2 instance with upfront payment, how is billing handled for that?

If your AWS account is part of the AWS consolidated billing scheme, the purchase of a reserved instance triggers an invoice from AWS to Cornell. Please send details of the purchase and the Cornell account to be charged to cloud-support@cornel.edu, and we will ensure that the invoice is charged appropriately.

Licensing

Does the Cornell Microsoft Agreement cover Microsoft software in AWS?

In most cases, no. See Microsoft Licensing within AWS.

Users, Policies and Roles

How can I give Cornell users access and privileges to my AWS account?

You can create custom IAM roles that integrate with the Cornell Shibboleth so that access to those roles is granted according membership in an AD group. See Creating Custom Roles to use With Shibboleth.

Can I use a DOC (delegation of control) account or a Holding ID to login to AWS?

No. Our Shibboleth implementation does not work with DOC accounts or Holding IDs. (More info about various Cornell account types: https://it.cornell.edu/cornellad/terms-and-conditions-cornellad)

Can a user with only a Guest ID login to AWS via Shibboleth and the signin.aws.cornell.edu login page?

No. Cornell's Shibboleth implementation does not support Guest IDs and thus users with Guest IDs cannot use the AWS-Cornell Shibboleth integration to authenticate to AWS. Please contact cloud-support@cornell.edu to discuss other options.

Networking

I deleted my "default" AWS VPC. How do I get it back?

You can create a new one. See https://aws.amazon.com/about-aws/whats-new/2017/07/create-a-new-default-vpc-using-aws-console-or-cli/.

Will AWS designate an existing VPC as the "default" VPC?

Direct from AWS tech support, here's what they have to say about this (as of 2017-02-08):

...existing VPC's can not be assigned as the default and we can only create a new Default VPC for you.

Please note that when we create a default VPC, we do the following to set it up for you:

  • Create a default subnet in each Availability Zone.
  • Create an Internet gateway and connect it to your default VPC.
  • Create a main route table for your default VPC with a rule that sends all traffic destined for the Internet to the Internet gateway.
  • Create a default security group and associate it with your default VPC.
  • Create a default network access control list (ACL) and associate it with your default VPC.
  • Associate the default DHCP options set for your AWS account with your default VPC.

What is AWS Direct Connect and how does Cornell use it?

See AWS Direct Connect for Cornell.

What is the Cornell Standard VPC?

See The Cornell “Standard” AWS VPC.

Why can't I connect to my EC2 instance?

You might want to look at the diagrams on AWS Direct Connect Routing Diagrams

Can I coordinate VPC Availability Zones between AWS accounts?

In practice, no.  To ensure distribution of load across their infrastructure, AWS creates an independent mapping of Availability Zone designations (ie: "us-east-1a", "us-east-1d") for each account.  Within the same Region, there is no way to guarantee the Availability Zone that you see as "zone A" lives in the same back-end environment as "zone A" seen from a different AWS account.  For more information, see the AWS documentation on Regions and Availability Zones.

How can I request a cucloud.net subdomain for use in Route 53?

The process for creating a cucloud.net Hosted Zone in your AWS account and requesting DNS delegation can be found in Route 53 Subdomain Delegation.

Working with Data

When should I use Direct Connect and when should I use the public internet to transfer data?

Direct Connect is mostly useful when a reliable latency is needed to be maintained between systems on campus and in AWS. Another use case could be that you are required to use a private network due to some policy, or you must access a system on campus that will not allow access via the public internet due to firewall rules that cannot be changed or because the system is only in campus 10-Space.

In the majority of other scenarios, the Cloud Team recommends using the public internet to transfer all data and updating firewall configurations to allow access to/from the internet with trusted systems that you run in AWS. The available bandwidth is much greater than when using the thin 1Gbps Direct Connect that is shared among many units at Cornell.

We also recommend using end-to-end encryption whenever transferring data over the internet. If you are using AWS provided CLI or SDKs (or 3rd party tools that utilize these) to transfer data to AWS, your connections will be encrypted by default.

How do I transfer a large file (>1GB) to Amazon S3?

Amazon S3 supports individual objects up to 5TB in size. However, when uploading large files, you run the risk of that transfer being interrupted and having to start over. Each individual connection to S3 also only gets 100Mbps from AWS.  

We recommend using the AWS CLI or a 3rd party tool to utilize "multipart uploads" when transferring large files. Most tools also multithread when uploading the parts of your file, so you will be able to utilize the full bandwidth of your machine (usually 1Gbps on campus).

The following tools support multipart uploads:

Other Amazon Services

Can I use Mechanical Turk with my Cornell AWS account?

Mechanical Turk requestor accounts can use the same email address and password as AWS root accounts. However, in order to keep these concerns seperate, we recommend using different accounts for each of AWS, Amazon store, and Mechanical Turk. 

RDS

How is the OS hosting my RDS patched?

RDS is a fully-managed service at Amazon, meaning you do not have access to the underlying operating system. Patching to the database engine or underlying operating system is handled as a scheduled maintenance event:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html

Maintenance to RDS can happen "immediately" or in a regularly-scheduled 30-minute window. An RDS instance can also be configured to automatically apply "minor" updates during the standing maintenance window without prior approval. For instances supported by the CIT DBA team, they can likely give you the details on your current configuration(s); the Cloud Team can also help fill in gaps if needed.

It is certainly likely that this activity will result in a brief outage. Use of a Multi-AZ deployment for RDS helps mitigate that for most activities since AWS will first perform maintenance on the standby instance, promote that to primary, then perform maintenance on the "old primary/new standby". Emphasis is on "most" because some major changes, like modifying the database engine, may require updating both primary and standby at the same time. Multi-AZ also gives you increased availability in the case of an Availability Zone going offline. Keep in mind that Multi-AZ deployments come with additional cost. You will need to find the balance between desired availability and total monthly spend.

Web Hosting

What are my options for hosting a web site in AWS?

While we can help you setup almost any type of web site in AWS, your best bet may be to start with the CIT Custom Web Development team, which brokers a varierty of web site hosting options. See Hosting Comparison Chart for options. In short the options are:

Basic
Static Web Hosting

Content Management Systems
CampusPress (WordPress)
Pantheon (WordPress and Drupal)
Acquia (Drupal)

Highly Customizable
Media3 (ColdFusion, LAMP)
Amazon Web Services (AWS) (CIT Cloud Services)
Managed Server

 

  • No labels