How To Commission Your First Virtual Machine In AWS: A Primer

If you need a compute resource quickly, but you don't have any experience with Amazon Web Services (AWS), this primer will help you get started.

Charles Babcock, Editor at Large, Cloud

September 15, 2016

10 Min Read
<p align="left">(Image: baranozdemir/iStockphoto)</p>

8 Steps To A Successful DevOps Transition

8 Steps To A Successful DevOps Transition

8 Steps To A Successful DevOps Transition (Click image for larger view and slideshow.)

Have you been asked to commission your first virtual machine in the cloud? If not, be aware that reliance on the cloud is becoming so commonplace that your turn will come soon. Fear not. If you need a compute resource quickly, and you don't have any experience with Amazon Web Services (AWS), we've got you covered. This primer will help you get started.

The guidance below is meant as one jumping-off point for you. There is, of course, more than one path into the cloud, but whichever one you take, "make sure you have done your homework," said Lynn Monson, principal and CTO of consulting firm ProHakr, in an interview with InformationWeek.

Monson created a six-module course for Pluralsight, an online technical education service, on Adopting AWS: Watch This First, The program was added to Pluralsight in August. Topics include "Thinking Like a Cloud" and "Securing Your Account."

Much has been written about the ready availability of the cloud. Still, Amazon has always laid a certain amount of responsibility on its users to know what they're doing. If you don't know, then it requires you to learn the Amazon way of doing things.

[Want to see how to get a database running on AWS? Read AWS Expands Database Migration, Adds Replication.]

As a new user, the first thing you need to do is decide whether you're more comfortable launching a Linux or Windows virtual server in the cloud.

Much enterprise use of the cloud is based on Linux servers, given the Linux expertise on staff and a small cost advantage that accrues over time. But there's no reason why a Windows user in a small business -- or in, say, the marketing department of a large enterprise -- should try to provision a Linux server the first time out.

Windows, said Monson, "is a first-class citizen" in the AWS cloud, and you'll be able to invoke the same cloud services you would with Linux. The Windows virtual machines on AWS can make use of Active Directory for identity purposes, either in the cloud or on-premises, if such integration is set up at the start.

"If you're looking for a quick success, and your corporate environment is Windows, there's no need to entertain a platform shift," said Monson. "There's no good reason to."

The list of instance types is formidable on AWS. T2, M3, and M4 are among the typical general-purpose beginner picks. Chances are, you already have in mind an application you want to run. Finding an instance type that's a rough match for the part of a server you're using on-premises for some comparable purpose will help reduce your pain.

Your next step in getting ready to do business is simple: Create an account name and password, and enter a credit card number.

From there, you'll find yourself in the AWS Management Console and able to provision a server. The best part about Amazon is that, once you know how to indicate your preferences, wizards take over in constructing the Amazon Machine Image (AMI) that will be your virtual server. It will be given its own IP address from a repository of addresses maintained by AWS.

Then it's up to you to make some decisions about how much to lock it down. If you've heard security is good on Amazon, that's true. But AWS itself says it's a joint contract. They'll keep the infrastructure secure, but it's the user's responsibility to keep the application code, the connection point, and the communications lines secure.

The default configuration on EC2 is a server whose address is exposed to everything on the web. You can select a security group, which sets up a firewall, and then select options that will only admit traffic from certain sources. For example, if you're primarily using your instance to meet internal purposes, you may choose to admit only a single corporate IP address, with the firewall eliminating other would-be entrants, Monson said in the interview.

The management console also gives the first-time user the option of closing ports on the virtual server. Again, this is a good idea if the intent is only to make use of the virtual server for internal purposes. Close all ports except the one you've designated for your own traffic.

To launch an application, the process is much the same as loading software onto an on-premises server. "You can run Power Shell scripts. You can Remote Desktop to it," Monson said. "It's not fundamentally different on Amazon. It's just another server with a different IP address."

Once the system is up and running, it's a good idea to designate storage, and store a second copy of the AMI. This gives you a reference copy and a backup in case the original virtual machine fails. Another trap for first timers: With no stored copy, your carefully built AMI will disappear the first time it's shut down, and you'll need to rebuild it next time you want to use it.

To communicate securely with a system intended for internal use, you need to know how to establish an Amazon Virtual Private Cloud (VPC). A VPC puts an Amazon instance on a virtual private network (VPN) segment, where all communications are encrypted. Both Monson's Pluralsight course and AWS's site documentation offer guidance on how to set up the VPC.

"The subnet is not internet-facing. It controls who can access the machines that are isolated on it," Monson said. He acknowledged first-time users without IT experience may not understand all the instructions for a VPC or a VPN. To help, Amazon has published a whitepaper, "Overview of Security Processes," which offers a straightforward presentation of the concepts. It also has a security best practices whitepaper.

If you're trying to meet compliance requirements with your cloud instance, be sure to consult the whitepapers. You may also need to tap whatever security expertise is available in your central IT organization, according to Monson.

"I wish security was a simple topic," he said. "With Amazon, it's a shared responsibility."

Using a sliding scale matched to the sensitivity of your application is the best way to evaluate the level of security you need. When starting out, Monson advised, adopt a "least privilege" model. This means limiting the number of users, outside applications, and processes that can access the cloud server to only those with a known direct interest or need to do so.

When it comes to providing a database service to the cloud server, it's possible to link an on-premises system. You'll need a VPN link to protect private data en route to the application over the internet. By connecting to the cloud server over a VPN, you're effectively creating a protected hole in your firewall.

It's also become much easier that it once was to move an on-premises database into the cloud. Such a database service could be located on a subnet, with policies limiting which IP addresses might launch queries or updates to it.

Amazon's database migration service will move an existing database system into the cloud. It can also be used to convert an existing system into Amazon's Aurora database service. Several options from among open source relational systems, including MySQL, MariaDB, and PostgreSQL, are also available.

As you get your initial project up and running, you're "almost certainly going to end up with more than one account," said Monson. In some cases, an initial account is a single application with several (or several dozen) authorized users. With more advanced use, such as accounts governed by central IT, you will want to group your various accounts under the headings production, staging, and development/testing.

If your organization is DevOps-oriented, you'll tend to have one team provide supervision for development and testing, staging, and production. Accounts are typically organized around teams managing certain applications or application sets. Amazon allows these accounts to be tagged, although the number of tags is limited by the level of business you're doing with the service.

Even if your organization uses a central IT approach, tagging is still worthwhile. Here's why. Many first-time users will ignore the billing aspect. For the initial server, charges are low, and there isn't much need to know the details. As the size of the server grows, and the number of servers increases, the cost increases as well. Eventually, someone from finance will stick a bill under your nose demanding to know why costs went up so much last month.

Whether you take a central IT or DevOps approach, tagging the accounts allows you to read your bill much more effectively. Without tagging, it's hard to interpret which team, or which set of users, ran up those extra charges.

"That's a frustrating moment," Monson said. "Make yourself aware of the bill from the start. As usage goes up, you may be able to spot how you're not using Amazon effectively."

For example, a server that could be shut down during the night may be left running 24 hours a day, much like in the enterprise data center. The cloud affords a cost saving if such servers are identified and put on a clock. Other servers, while not set to shut down entirely, might be able to shrink from a pricey type into a cheaper type as usage for the day goes down.

Billing can be handled from the same AWS management console as the one where you provision a server. You can enter an amount you expect to spend in a given month, and set an alert for when you've reached a percentage of that total. An email message will tell you whether or not you're on track to stay within your budget goal.

There's also a "more billing details" option. This collects operational data and dumps it as a CSV file into a Simple Storage bucket. From there, you can download the information and drop it into an Excel spreadsheet. All the activity will still be rolled into a single Amazon bill for the company, but this enables the person responsible for the account to see where the usage is occurring.

If you end up successfully launching what you need on AWS, and you're becoming more dependent on it by the day, be warned that Amazon doesn't guarantee continuous availability. On the contrary, if the server your application is running on in EC2 fails -- "poof!" There goes your application and its data.

There's no stored backup copy unless you make one. There's no failover to some other available machine unless you set that up in advance. The software running on top of the AWS data center servers runs continuously – with rare exceptions -- but not so every physical server beneath it.

After you gain the level of proficiency outlined above, there are new topics to address and modes of operation in the cloud to conquer. For example, getting the lower-priced instances -- such Reserved Instances or Spot Instances -- is a good way to save money. But this requires a more advanced level of expertise to make the right choices for your organization.

No matter what, "talk to [your] central IT guys," said Monson. "Let them know what you're doing. Things will just go much smoother that way."

About the Author(s)

Charles Babcock

Editor at Large, Cloud

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive Week. He is a graduate of Syracuse University where he obtained a bachelor's degree in journalism. He joined the publication in 2003.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights