An AWS account is a container for your resources. Using multiple accounts gives you built-in security boundaries and separation of charges. Each AWS account is associated with a single KFS number, and all charges incurred by that account will be posted (via DIT One Bill) to that KFS number.
Some common reasons departments or researchers would want to utilize multiple AWS accounts include separation of production workloads from dev/test, providing separation of permissions, or to utilize different funding sources (KFS Numbers).
Submit an IT support request that contains the following information.
See AWS Web Console Login Instructions for detailed instructions on logging in to your AWS accounts.
UMD maintains an Enterprise Support contract with AWS which is available to all member AWS accounts. Administrators can use the Support Center portion of the AWS console to open cases directly with AWS support. More information on the features and response times of Enterprise Support can be found at the following pages.
AWS maintains a shared responsibility model, whereby AWS is responsible for the security of the cloud itself, while the customer is responsible for the security of the resources in the cloud. In simple terms, this means that AWS is responsible for ensuring that the EC2 system itself does not get hacked, but you are responsible for ensuring that your EC2 instances are not hacked.
AWS will not protect you from weak passwords, mis-configured firewalls, failure to apply patches in a timely manner, etc. For more information, see Shared Responsibility Model.
We provide 2 options for networking in AWS each with advantages and disadvantages. Please note that it is not possible to switch between these 2 models without deleting and re-creating your VPC (and all of the resources and servers hosted within it), so careful planning and consideration is required. DIT staff are available to assist in making this decision if required.
This model provides direct access between your VPC and the campus network via redundant 10G dedicated networking. Your VPC will use UMD allocated private address space and firewalls both on-prem and in AWS can be configured to allow access in either direction. We can also provide a limited number of public IP addresses which can be used for services that must be internet accessible (public web servers for example).
All traffic between in/out of your VPC will traverse the UMD network and is protected/inspected by the same suite of security tools used to protect the rest of the campus network.
This model provides several advantages such as direct access to campus resources and additional security protections including the ability to use the Campus VPN for role based access. It has the disadvantage of limiting the number of internet facing resources (public IP addresses are a very limited resource). It also requires the networking (VPC, subnets, route tables, etc.) to be configured by DIT.
This model provides no private access between your VPC and the campus network, all connectivity will traverse the public internet. You may use whatever private addressing scheme you want for your VPCs, and public connectivity will be via AWS provided IP addresses. There is no security inspection/protection between your resources and the internet.
This model has the advantages of scale and reliability, you are not dependent on the UMD campus network, and can allocate as large or as small a VPC as AWS will allow. You can also set up the VPCs without the assistance of DIT.
This model has the disadvantage that there is no private connectivity to campus (such as to access on-campus databases), and no security protections are provided by DIT.
We have a UMD AWS Billing Process article covering all things AWS billing.
Complete and submit the following ServiceNow form to initiate the transfer of your external AWS account into our Organization.
Some considerations to keep in mind when importing an existing account are:
Generally the account transfer process involves the following steps: