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 Workday Driver Worktag, and all charges incurred by that account will be posted (via DIT One Bill) to that Driver Worktag.
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 (Driver Worktags).
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, "Shared VPC" which is a more modern model with a number of advantages and a legacy option "AWS Native". Please note that it is not possible to switch between these 2 options 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 and a consultation is required before we will allow the use of the "AWS Native" option.
This model provides a single large VPC with DIT managed routing, connectivity, and security. The shared VPC has direct access to the campus network via redundant 10G dedicated connections. The VPC uses UMD allocated private address space and firewalls both on-prem and in AWS can be configured to allow access in either direction. Resources placed in "Public" subnets can also be allocated Amazon provided public IP addresses and are reachable directly from the internet (A public web server for example). All traffic between the VPC and the internet 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.
| Subnet Type | Accessible From The Internet | Can Access The Internet | Accessible From Campus | Can Access Campus Public (129.2.x.x, 128.8.x.x) |
Can Access Campus Private (10.x.x.x) |
Accessible From the VPN |
| Private | No | Yes | Yes | Yes | Yes | Yes* |
| Public | Yes | Yes | Yes | No | Yes | Yes* |
* VPN access defaults to deny. A Firewall Request must be submitted requesting access for a set of users ("VPN Role") to a set of IP addresses+ports
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 being able to 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:
We are unable to setup the Shared VPC networking option in an existing account.
Generally the account transfer process involves the following steps:
Before closing your AWS account, you should consider the following:
When you are ready to close the account, please contact itsupport@umd.edu an provide the AWS account number to be closed.