If you would like to read the other parts in this article series please go to:
- Microsoft + AWS: A Winning Combo (Part 1)
- Microsoft + AWS: A Winning Combo (Part 3)
- Microsoft + AWS: A Winning Combo (Part 4)
- Microsoft + AWS: A Winning Combo (Part 5)
Introduction
In Part 1 of this series, we took a look at how Amazon’s AWS provides a solid cloud platform for running any of the currently supported versions of Windows Server, and a wide variety of Microsoft server applications that can be migrated from your on-premises data center to the Amazon cloud. .
Windows on AWS data storage options
Whichever Microsoft applications you might be running on Windows Server in an AWS EC2 instance, it will most likely generate some type of data that you’ll need to store. You have a few different options when it comes to storing your data within the AWS cloud.
Specifically, you can use Amazon Elastic Block Storage (EBS), which we mentioned in Part 1 of this series, you can use the Amazon EC2 Instance Store, and you can also use the Amazon Simple Storage Service (S3). The instance store is not available with some types of instances (smaller sized instances). You can also store archived or backup data for your Windows instances on Amazon’s Glacier service.
Instances can be backed by either an instance store or an EBS volume. The former uses the instance store as the root device and the latter uses an EBS volume as the root device. The root device volume is where the AMI that boots the instance is stored.
The instance store
The instance store is available with larger sized instances, not with T1 and T2 instances. The instance store is for temporary block-level storage and is mapped automatically when you launch the AMI. Instance stores can contain more than one volume and you must format and map them before they’re usable. Unlike EBS volumes, instance stores are permanently attached to a particular instance and can’t be moved to another one.
The size of a default instance store is dependent on the type of instance. Sizes range from two 16 GB SSD volumes to eight 800 GB SSD volumes (total of 6400 GB).
The data in an instance store will still be available after the instance is rebooted, but if you stop an EBS backed instance, the data in its instance store will be lost. Instance stores are not intended for long term storage. For that purpose, you should use EBS or S3 storage. Instance stores should be used for things like caches, buffers and other temporary data. They can also be used for data that is replicated across multiple instances.
Because the data in the instance store is not persistent, if the instance store is the root device, the image used to boot the instance will be copied from S3 storage to the instance store and then the instance is launched from the copied image.
Elastic Block Storage (EBS)
In most cases, your best bet is to store your data in EBS volumes. This is block level storage that is provided for your EC2 instances, which you can think of as virtual hard disks that are attached to your virtual servers in an instance that’s running. You’re not limited to just one volume per instance, either. You can attach multiple volumes to the same instance. There are limits set by your AWS account, just as there are limits on the number of instances you can run at the same time. Each volume can only be attached to one EC2 instance at a time, but you can detach a volume from one instance and attach it to another instance.
An important thing to remember about EBS volumes is each volume is created in a particular Availability Zone and you can only attach it to instances that are in the same Availability Zone.
EBS characteristics
EBS volumes are persistent and highly reliable. This is the best storage option for your normal day-to-day data that’s created in the file system and for databases and other types of data that need to be updated frequently. EBS volumes can range in size anywhere from 1 GB to 1 TB. Your data is stored on SSD physical drives and those can be general purpose volumes or higher performance Provisioned IOPS volumes that are capable of up to 4000 input/output operations per second, depending on the volume size. General purpose volumes are capable of bursting performance, similar to the bursting CPU performance available with T2 instances that we discussed in Part 1.
An EBS volume can be used like a hard drive. That is, you can format them with whatever file system you want and mount the drive and then access it as you would a hard drive. You manage the EBS volume through the Disk Management utility in Windows just like a physical hard drive. As with any drive, you’ll need to initialize the new disk before you can use it.
EBS data security and encryption
If you’re concerned about data security but you don’t want to have to manage a PKI of your own, you can use the simplified data encryption feature of EBS. This lets you launch the EBS volumes as encrypted volumes that use AWS Key Management Services (AWS KMS). The encryption is also used when snapshots of your encrypted volumes are made. You can use the default AWS master key for EBS encryption or if you prefer to create your own customer master key using the AWS KMS, you can do that.
For the best security, you will want to create your own customer master key because then you can define access controls and audit the encryption keys that are used to encrypt your data. You can create, enable and disable keys and use them to encrypt, decrypt and re-encrypt your data. You can also set key usage policies and create key aliases. Whenever you encrypt an EBS volume, you can select to use the default key or a customer key that you created. You can use AWS CloudTrail to audit the usage of encryption keys.
We will discuss how the AWS KMS works in more detail in a later article.
Simple Storage Service (S3)
You can use S3 storage in conjunction with the EBS storage to create and keep backup copies of your data. To do this, you make a snapshot of the EBS volume and it is stored in the S3 system. If you want that same data to be available to a different EC2 instance, that’s easy to do, too. You create a new EBS volume from that snapshot and it can be attached to any of your instances that are in the same Availability Zone.
S3 provides a place for you to store data that can be accessed from anywhere on the Internet, using the management console in a web interface, and can be used with EC2 instances. In addition to being integrated with EBS, S3 is also integrated with other AWS services such as Glacier (for low cost data archiving and backup).
S3 consists of a root account where you create buckets, which are like root directories into which you put folders and files. There are numerous file management utilities for S3, many of which are free. You can use these tools to organize the data stored in S3.
Amazon Glacier
Data that doesn’t need to be accessed frequently or quickly can be stored at low cost in Glacier, and you can access it using EC2. This is for archived or backup data, as it can take from three to five hours to retrieve data from Glacier. The data stored in Glacier is encrypted and you can also use the AWS Identity and Access Management (AWS IAM) service to control access to Glacier-stored data.
You can transfer data between EC2 instances and Amazon Glacier within the same region at no charge; if you transfer it across other regions, the Internet Data Transfer charges apply. You can also automatically migrate S3 objects in a particular S3 bucket to Glacier after a specified period of time. You do this by creating lifecycle rules that specify the objects in the bucket should be transferred to Glacier storage after X number of days.
Summary
Computing – cloud or otherwise – isn’t really about the processing power and memory, or the operating system, or the applications; it’s about the data that you collect, create, and manipulate with those applications. The data that you create and/or use in the applications that you run on your EC2 Windows servers must be stored in a manner that protects it from compromise and makes it accessible when you need it. AWS offers several different options for storing data, and we explored them in this, Part 2 of this series on how Microsoft and AWS can be a winning combination for your cloud computing needs.
In Part 3, we’ll continue that discussion as we start to take a look at how to deploy popular Microsoft server applications such as Exchange and SharePoint on your Windows instances running on AWS.
If you would like to read the other parts in this article series please go to:
