When I was a kid, my dad built a sandbox in the backyard for my brother and me to play in. We used it for a lot of things, like devising desert combat strategies for our green army men, and then finding creative ways to sacrifice them to our Return of the Jedi sand pit monster (with a bug in a jar as a stand-in for a Sarlacc). It was a fun space where we could imagine new worlds and try out the latest in sand-moving contraptions.
Likewise, a technology “sandbox” can be a creative space for your employees. Using cloud platforms like AWS, it’s possible to set up disposable, low cost, temporary environments that can be centrally managed and are easy for employees to use. An AWS sandbox can be a great option if your employees need a safe space to perform riskier activities, or if they just need a place to explore some technology without cluttering or impacting more sensitive systems. When the work is done, hit the delete button and it’s all cleaned up!
Consider this:
The IT Team needs to check out a dodgy link from a phishing email? Use your sandbox!
The Security Team wants to install malware and see what happens? Use your sandbox!
The Sys Admins want to mess around with Windows Registry settings? Use your sandbox!
In practical terms, a sandbox is just a pre-configured cloud platform account where you’ve made it easy for employees to create OS instances, databases, or whatever other resources they need temporarily to do their work. All it takes is a little forethought on how you configure and manage the account, plus some clear documentation for your employees on how to use it. You want your employees to be able to get running in the sandbox as quickly as possible to do their work, without having to do a lot of research on how to use the cloud platform itself.
If you don’t already have a sandbox, you should be asking yourself – where are all your employees doing their risky work? If you don’t know, it’s probably on their laptops and your infrastructure devices. Time for a better solution!
If you build it, they will come
You may be thinking that it’s already fairly easy for anyone to create their own personal cloud hosting account and just start up whatever they need for testing. For example, if you already know your way around AWS, you can get a free account set up and a starter environment with a couple of Windows or Linux instances running in a couple minutes. Why not just have your employees do that when they need a sandbox for testing?
Simple answer – friction.
You could use individual accounts, but it is a hassle to deal with the setup, and most people won’t go to the trouble if they haven’t done it before. Plus, individual accounts make it more difficult to collaborate with teammates on projects. Things can get messy too if they’re not very diligent about keeping an eye on costs and end up with a large monthly bill – nobody likes filling out expense reports!
The better approach is to centrally manage this administrative overhead. This way, you can establish reasonable rules on how it’s used and manage your costs. When you reduce the friction, the managed AWS sandbox will become their easy, go-to choice for performing certain risky tasks.
There are many ways to build a shared AWS sandbox, so if your organization already has a Cloud Ops team with the expertise to build and manage this, it’s best to partner with them so it isn’t seen as a “Shadow IT” project. For this article though, we’ll assume you don’t have those internal resources and need to chart your own course. We’ll show the high-level steps to do this in AWS, but this can be adopted for any cloud platform. It’s assumed that the reader has some basic knowledge of AWS, but most concepts are easily Googled if unfamiliar.
Get Organized
Before you create the AWS account for your sandbox, it’s a good idea to first create a separate “parent” account for management functions. The costs incurred by the child sandbox account will roll up to the management account for billing and payment. You could just use a single account for everything, but it will be easier to expand and manage multiple independent sandboxes later on if needed if you first establish a management account.
Setup checklist:
Create or request two new corporate email addresses (or aliases), one for the AWS management account and one for the sandbox account. These addresses will be associated with the AWS root user for each account and will receive important account emails.
Create the AWS management account (aws.amazon.com, “Create an AWS Account” button)
Use a very strong password
You will have to enter a credit card number
Once logged into the new account as the root user,
in “My Security Credentials”, enable MFA for the root user
In IAM, create a new admin user with a very strong password and “AdministratorAccess” permissions.
Enable MFA for the new admin user.
Log out as root user
Now, lock away your root user credentials in a safe place and never use them again (except for emergencies). All work from here on out should be done with the new admin user instead.
Once created, use your management admin user to access AWS Billing and set up some basic alerts under “Budgets” to warn you about excessive monthly charges. You don’t want any nasty surprises at the end of the month!
For now, you’re just going to use the Management account only for consolidated billing but doing this has other benefits too. You can use this account to centralize logging and monitoring, create global policies, and use other organizational features. Do not use the management account to run any compute resources though! It’s a best practice to only use it for managing other AWS accounts.
Create the AWS Sandbox
Time to create the actual sandbox!
Still logged into the management account as the admin user, go to AWS Organizations and select “Add an AWS account”, and then “Create an AWS account”. All you have to supply is a name for the new sandbox account and the second email address (you can’t use the same email address for both accounts). It may take several minutes for AWS to fully configure the new account.
You’ll probably want to log into your new account now with the root user, right? Not so fast, because you don’t know the password! For reasons that aren’t entirely clear, AWS automatically creates a password for the root user when you create child accounts using AWS Organizations, but they won’t tell you what it is! Seems strange, but there’s an easy workaround – just select the “forgot password” option to get a reset link sent to your inbox.
Now, do the right thing and take a minute to create a second admin user for the sandbox and set up MFA, just like you did for the management account. Likewise, you should now log out the root user from the sandbox and use the admin user for everything going forward.
It’s worth noting that AWS lets you do everything shown so far for free. You don’t incur any charges until you start using compute resources (EC2, S3, RDS, etc.) – and even then there is usually a free tier that will let you explore the service before you have to start paying. For small organizations with limited sandboxing needs, you can do this entirely free of charge for a year!
Rules of the Road
At this point, you should have a pristine sandbox with a default VPC network and no compute resources. But once you let people in, it will never be this clean again! Your employees will make a mess of it right away if you don’t establish some rules. So, make sure everyone understands and follows these principles:
Play nice – the golden rule for any sandbox! Make sure that all users understand that the sandbox can only function if people are careful about following the house rules and don’t accidentally disrupt other users’ work.
Nothing is permanent – just like a real sandbox, this is not the place to build something that needs to stick around. Establish reasonable limits on how long components can be deployed, particularly as they start incurring significant monthly usage fees. You do not want the sandbox to become the place where projects get parked because employees don’t want to follow the normal process your company already has to approve hosted infrastructure projects.
Nothing is secure – no one should ever assume that the sandbox is secure. By design, this is a fast-and-loose experimental environment. Make it extremely clear that users are NOT allowed to bring any confidential or sensitive company data to the sandbox, EVER!
Don’t take more than you need – everything bigger and faster costs more. It may seem obvious to you, but will need to let users know they should not select a 64 vCPU instance type when a 2 vCPU might be good enough for their project.
Clean up after yourself – users must understand that it is their responsibility to put everything back like they found it when they’re done working on their project. Some services like EC2 charge a fee for each hour the OS is running and a fee for the instance’s storage, even if the OS is turned off. So, it’s important for users to stop the OS if not in use for a short time (overnight or weekends), but it’s also important not to let it sit around for an extended period of time if it’s no longer needed, even if it’s turned off.
Control Your Costs
If you’re not careful, letting your employees run wild in your sandbox will likely result in a long list of unexpected charges at the end of the month. A short, carefully managed project with a couple small EC2 instances might only cost a couple of dollars, but one with multiple oversized instances, excessive storage, and left running for weeks could cost hundreds of dollars or more, so you need to be careful.
The challenge here is that AWS doesn’t make it easy for your occasional sandbox user to see what costs they’re incurring. As manager of the environment, you’ll have some visibility into that using AWS Billing and other cost-management tools, but still you’ll get into a mess if you don’t give your users some guidance in advance.
Take a moment to consider your typical use cases and design some cost-effective recommended configurations for your users. For example, if you anticipate that your users may need to create small Windows servers that are just powerful enough to run a browser, then using a t2.medium (2 vCPU, 4 Gb RAM) at about 6 cents per hour of runtime is an economical choice, and you don’t have to get too concerned if they leave it running a little longer than they should have. Other use cases may require more powerful virtual hardware and larger storage that has to be carefully managed, so present options and help your users understand how they can control the costs.
AWS’s current EC2 on-demand pricing chart can be found here: https://aws.amazon.com/ec2/pricing/on-demand/
Be sure to also consider other commonly used services, like S3 for storage and RDS for databases, and help your users understand the prices associated with them. You will need to look up the usage rates for each service independently.
AWS has a dizzying array of services, and a sandbox can be a great place to explore and test them out. It’s not practical though to examine the cost structure of each service and provide usage guidance to everyone, so you really don’t want your users playing around too much with exotic services and racking up unexpected costs. Seriously consider restricting your users’ accounts to only use approved services, and review any one-off requests to use other services independently.
Ultimately, it’s up to you how much freedom you want to give your users to spend money in the environment. If the costs are generally small, then just educating your users so they don’t accidentally spend too much is probably enough. But if you have a large user base with complicated projects, you may need them to run their project by you first so you can do a basic cost analysis.
Special note about MacOS in your AWS Sandbox
If you’ve ever provisioned an EC2 instance, you may have noticed that you can choose MacOS for your Operating System, but MacOS doesn’t show up in the on-demand pricing chart link provided above. For that, you need to look here: https://aws.amazon.com/ec2/instance-types/mac/
Look closely and you’ll see that the MacOS option is far more expensive at over one dollar per hour than the simple 6 cents per hour Windows option mentioned earlier.
So, if you accidentally leave a simple Windows server running for a week, you’re only out $10, but with the Mac it’s $181 … be careful with Macs!
Documenting your AWS Sandbox
The most important thing you can do to ensure that your users behave in the sandbox is to write down all the rules, guidelines, and usage advice.
Your documentation can take whatever form that works for your situation, but try to include these key topics:
Description & Use Cases – What is the purpose of this sandbox and how can it be used?
Golden Rules – all of your “play nice” guidelines
How to access the sandbox – link to your login page
User Security – expectations for securing user logins (password requirements, MFA, etc.)
Allowed Services – details on what services users are allowed to use with first asking for permission.
Configuration Baselines – details on how you want people to configure certain services. For example, you may want people to use a naming convention with their EC2 instances to make it clear who owns it, or you may want to restrict Internet access.
Cost Controls – details on how you want your users to manage the costs of their service deployments. Provide price-optimized configurations for common services like EC2.
Usage Tips – provide help for common tasks that may be difficult to figure out or remember for casual sandbox users. For example, how to create and connect to a new Windows instance.
Click here and sign up for our newsletter to download an example usage guide. Or you can download it from the form at the bottom of the page.
If you know who is going to use your sandbox, you can now create their user logins in AWS IAM. You will probably want to restrict their access based on your “Allowed Services” list . Explore the pre-configured policies, especially the “Job Function” ones to see if they will meet your needs. AWS’s user policies are also highly customizable, but can sometimes be very tricky to get just right – best to get some help if this is new to you.
Congratulations! You’re now open for business and ready to share the logins and user guide with your employees!
Continued Management of your AWS Sandbox
Your sandbox is going to require some attention occasionally – particularly to manage your costs – so don’t expect it all to run on autopilot. Watch it carefully, examining your usage patterns, and be sure to create billing alerts to prevent unexpected costs. Once a month, do an audit of your IAM users and make sure that you don’t have any lingering accounts that should be removed. Over time, if the account just becomes too unmanageable, you always have the option of deleting it and starting fresh with a new sandbox.
Be sure to review and update your user documentation frequently. You’ll learn more as you go about managing costs and providing usage advice to your community. Very likely, your users will figure out many tips and tricks on their own – add their notes and checklists to the documentation too.
With your sandbox in place, you can now relax knowing that your users have a space to perform their risky-but-necessary activities and to experiment with new technologies without endangering other more important systems and environments. And as long as you make sure your users play nice, clean up after themselves, and share their green army men, it should be a great resource for everyone. Just watch out for that Sarlacc!
Sign up for our monthly newsletter, Tales from the Click , to download an AWS sandbox usage guide with all of this information filled in and ready-to-go!
