Amazon EBS Volume Types

There are five types of Amazon EBS volumes that can be provisioned as of this writing. Table 6.1 details the various Amazon EBS volume types.

The most visible difference between types is whether they are SSD or magnetic Hard Disk Drives (HDD). Do not assume that SSD is always the best performance choice for your Amazon EC2 instances. If you will be using Amazon EBS, you must decide which Amazon EBS volume type is the best for your business value.

For the certification exam, it is important to align the volume type’s characteristics to the values and desired outcome presented in the question. If you are looking for the lowest-cost option, provisioned IOPS volumes are almost always the wrong choice. If maximum throughput is the need, you should avoid choosing default magnetic drives.

Provisioning Amazon EBS

When provisioning Amazon EBS volumes, the systems operator declares the following:

• Volume type
• Size
• Availability Zone
• IOPS (only if io1)
• Snapshot ID (if this volume is a copy of a saved snapshot)
• Encryption options (including AWS Key Management Service [AWS KMS] key ID)

Once a drive is provisioned, the values are not editable. If you want to change a volume from gp2 to io1, you must take a snapshot of the original gp2 volume and create a new io1 volume based on that snapshot ID (decommissioning the original gp2 drive as it is no longer needed).

The same process applies to any of the other properties not on the list that you would want to change (such as volume encryption or volume size). Changing these properties requires taking a snapshot, creating a new volume, and then deleting the old one.

Mounting Amazon EBS Volumes

Amazon EBS volumes operate independently from Amazon EC2 instances. Although they can be created at launch time by the AMI and can be terminated simultaneously as well, it is important to remember from an operations perspective that Amazon EBS and Amazon EC2 are separate services. A key benefit is that Amazon EC2 enables the resizing of instances (as mentioned in Chapter 4). Amazon EBS volumes persist when an instance is stopped, so the instance type can be changed.

When Amazon EC2 instance types are changed, the underlying hardware is always swapped out. Amazon EBS persistence makes this changing of infrastructure seamless to the operator.

To mount an Amazon EBS volume, use the following commands:

aws ec2 attach-volume --volume-id vol-1234567890abcdef0
--instance-id i-abc1234 --device /dev/sdf

Amazon EBS volumes can only attach to one Amazon EC2 instance at a time. Although there is no limit to how many instances a volume may have been attached to, there is no concurrent attachment option. For use cases such as shared volumes where multiple instances must communicate with a single volume, the best architecture is to use Amazon Elastic File System (Amazon EFS), which is discussed later in this chapter.

Amazon EBS Snapshots

Amazon EBS volumes are redundant arrays and can withstand the loss of individual drives without loss of data. As previously mentioned, however, Amazon EBS volumes live in one—and only one—Availability Zone. If data durability is important, systems operations teams should include volume snapshots as part of their regular operational configuration.

Snapshots create permanent images of the volume and store them at the regional level (across multiple Availability Zones) in Amazon S3. It is important to realize that the snapshots are not stored as Amazon S3 objects and cannot be viewed using the Amazon S3 Console or APIs. They are unique Amazon EBS images and can only be accessed through the Amazon EC2 service.

Because they are not true Amazon S3 objects, snapshots only store the sectors that have changed (the delta) from the previous snapshot, allowing the total volume of data stored (and thus billed) to be dramatically reduced.

Snapshots for data volumes do not require the volume to be stopped (or quiesced), but choosing to hold writes to the volume will provide a much more accurate dataset. Boot volumes must be stopped before they can be snapped—another key reason to keep boot and data volumes separate.

Snapshots are locked to the region where they were created. If your operational policy requires keeping copies of data in different regions, you must initiate a copy of that image to the target region. The new snapshot will have a new ID. This fact is important when creating automated deployment methods because new volumes cannot be created from image IDs that are not in the region where the new volume is being created. Figure 6.4 demonstrates the AWS CLI command used to create the snapshots.

Creating an AMI from a Snapshot

A snapshot of a root volume has most of the pieces needed to create an AMI. What is left is to put the additional metadata pieces in the system and register the snapshot as an AMI. Using the register-image command in the AWS CLI, you can identify which snapshot you want to use, along with the new name for the AMI.

Deregistration will cause the image to no longer be available as an AMI. Figure 6.5 demonstrates the AWS CLI used to describe your snapshots.

Securing Amazon EBS

All Amazon EBS volumes are automatically locked to the account that created them and the Availability Zone where they were created. Unless the volume owner makes a snapshot and shares the snapshot with another account, there is no way for an instance in another account to have direct access to any data on the original Amazon EBS volume.

Customers who want additional security on their volumes can encrypt the data at either the client level or the volume level. Client-level encryption is done in the operating system of the instance to which the volume is currently attached. Because this is controlled by the operating system of the Amazon EC2 instance, AWS has no access or visibility into what keys or algorithms are being used. From an operational perspective, this means that customers using client-side encryption must be responsible for maintaining availability and durability for all keys in use.

AWS offers volume-level encryption as well. In the case of volume-level encryption, all data is encrypted at rest and in transit between the instance and the volumes. With Amazon EBS volume-level encryption, each volume gets a unique encryption key only used by that volume or other volumes created from snapshots of that volume. AWS uses the industry-standard Advanced Encryption Standard (AES)-256 algorithm to encrypt data and the volume keys. For greater security, customers can choose to use AWS KMS for the volume key management, which can be combined with AWS Identity and Access Management (IAM) permissions and AWS CloudTrail logging to provide greater protection and visibility.

Monitoring Amazon EBS

Basic volume monitoring (included with all volumes) happens in five-minute intervals. The metrics cover the fundamental pieces of disk management: number of bytes (read/write), I/O per second (read/write), idle time, queue length, and so on.

For volumes with provisioned IOPS, an additional metric of throughput percentage is also available. Throughput percentage is a critical metric because it shows a percentage of actual throughput used compared to provisioned. For cost analysis, this number must be closely regulated to ensure that you are not overpaying for IOPS.

For gp2, st1, and sc1 volumes, burst balance is also available. This feature provides visibility into burst bucket credits that are available to the volume.

Decommissioning Amazon EBS

Amazon EBS volumes are designed for persistence—as such, they can survive the termination of associated Amazon EC2 instances or even be directly detached from instances (as long as they are not the root volume). Detaching a volume does not change the billing for the volume, and it continues to count toward the storage limit for the account that owns the volume. A detached volume can be reattached to any other Amazon EC2 instance in the same Availability Zone of the same account.

Instance Store vs. Amazon EBS

Amazon EBS is designed for persistence, whereas instance store is designed for comparatively inexpensive, disposable, usually high-speed communication. Instance store lives on the same hardware as the Amazon EC2 instance itself and is included in the hourly cost of the instance. This also means that there is no external network overhead that must be factored into communication potential.

The primary consideration is also a potential benefit: The fact that the storage is on the same hardware as the instance means that the storage does not have any persistence beyond the life of the Amazon EC2 instance. If the instance is stopped and started, all data on the instance store volume is lost.

Root volumes can run on Amazon EBS or instance store, but if the root volume is on instance store, there is no “stop” option, as a stop will terminate the instance.

Provisioning Instance Store

Unlike Amazon EBS, instance store is not flexible when considering volume size, media type, or throughput. Each instance type has a single specific storage option, if instance storage is available for that instance—some instances only support Amazon EBS for volume types and do not have instance storage options. Check the Amazon EC2 documentation for current instance storage options for each instance type.

Instance store-backed volumes are only available on creation of the Amazon EC2 instance. If an instance is launched without the volumes, they cannot be added later.

Instance Store Security

Security concerns are simplified to some degree when using instance store. The data never leaves the hardware, so encryption in transit is not a consideration. The instance cannot be detached and reattached to another instance. All encryption must be done at the operating system level.

These considerations mean that all security controls are managed at the operating system and above, hence it’s your responsibility to secure. Refer to the shared responsibility model described in Chapter 3, “Security and AWS Identity and Access Management (IAM),” for more information.

AMIs on Instance Store

To create an instance store-backed AMI, start from an instance that you have launched from an existing instance store-backed Linux AMI. Customize the instance to suit your needs, then bundle the volume and register a new AMI. Figure 6.6 summarizes the process of creating an AMI from an instance store-backed instance.

The bundling step is different compared to Amazon EBS, with which you can create an AMI directly from an instance or a snapshot.

Once an instance store AMI is created, all root volumes will be built on the instance store when using that AMI.

The bundling process is a multi-step function that we are not going to cover in this book, as it falls outside the scope of the exam. Nevertheless, you should look up the online documentation and practice making an instance store-backed AMI to understand the process.

Amazon EFS vs. Amazon EBS

When comparing the two options, it is important to look closely at the primary use cases. Amazon EFS is designed to provide regional, durable, multi-user file systems. Amazon EBS is designed for single Amazon EC2 volumes.

Because of its design, Amazon EBS is significantly cheaper when looking at per-GB cost of storage. If there is no need for multiple instances to attach to the storage, Amazon EBS will likely be a good place to start your operation.

Once you have multiple users, however, Amazon EFS will often be a much less expensive option. Cost savings are more apparent once you consider the regional redundancy and durability that is rolled into Amazon EFS, bypassing the need to build your own highly available, regionally redundant file system. This becomes even more important when you consider the maintenance overhead that you avoid when using Amazon EFS over a DIY solution.

Provisioning Amazon EFS

After creating Amazon EFS using the Create API, you create endpoints in your Amazon Virtual Private Cloud (Amazon VPC) called “mount targets.” When mounting from an Amazon EC2 instance, you provide the Amazon EFS Domain Name System (DNS) name in your mount command. The DNS resolves to the mount target’s IP address. If your instance has access to the mount target in the VPC, you will then be able to access the file system.

This will be the same mount target that peered Amazon VPC instances or on-premises instances will use. They are granted access to the host VPC through the networking methods, and that will complete their ability to connect to the file system as well.

Instances then connect to the system with an NFSv4.1 client. See Figure 6.7 for the AWS CLI command to create an Amazon EFS.

Securing Amazon EFS

The mount target you created when you provisioned the file system can use Amazon VPC security groups (the same ones that you use to secure access to Amazon EC2). All of the same rules of ingress and egress control can then be managed in detail with that toolset.

The mount targets are also specifically assigned to subnets (which by extension means that you should include mount points in a subnet in each Availability Zone in which you intend to run connected instances). This means that network Access Control List (ACL) control would also apply at the subnet level, if needed, for additional controls over an instance connecting from outside the subnet where the mount targets exist.

Encryption is not yet available natively on Amazon EFS as of this writing.

File access inside the system is controlled with standard UNIX-style read/write/execute permissions based on the user and group ID asserted by the mounting NFSv4.1 client.

Durability vs. Availability

One of the big engineered benefits of Amazon S3 is that it is designed to provide eleven 9s of durability for content. In other words, 99.999999999 percent durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001 percent of objects.

To run the numbers in a more specific example, if you store 10,000 objects in Amazon S3, you can, on average, expect to incur a loss of a single object once every 10,000,000 years.

As a systems operator, do not confuse the durability numbers with availability numbers. Amazon S3 Standard is designed to deliver up to four 9’s (99.99 percent) of availability. AWS even provides a Service Level Agreement (SLA) with penalties if availability drops below 99.9 percent on any given month of service (which translates to approximately 44 minutes of time in a month).

To understand the difference between durability and availability, think in terms of the question each is trying to answer. Availability addresses the question, “Can I reach my content?” While AWS is very proud of our track record on availability, there are many factors that control access and are taken into account in the engineering profile. Durability addresses the question, “Does my content still exist?” From an enterprise survivability perspective, this is a much more critical question. Most businesses could survive the unfortunate loss of service for a few minutes a year; few businesses would be well positioned if their data was lost.

Durability is the primary reason that AWS recommends that all Amazon EBS volumes that contain mission-critical data be saved as snapshots into Amazon S3. Availability can always be restored as long as the data survives.

Accessing Amazon S3

Amazon S3 is accessed using APIs. Amazon S3 objects can also be accessed directly through HTTP calls with the right permissions.

Permissions to content (or buckets) are granted through IAM, or they can be granted directly to the operator through object-level permissions. Either approach is sufficient to grant access.

IAM policy documents and Amazon S3 bucket policies appear almost identical. The key difference between them is that the bucket policies include an account number. The account number is used to explicitly authorize users (or roles) from that account.

Amazon S3 – Reduced Redundancy Storage (Amazon S3-RRS)

Amazon S3 is designed to deliver eleven 9s of durability, four 9s of availability, and low-cost throughput, which solves most architectural storage needs. In some cases, however, the business need does not require durability.

For example, you have an application that manages high-definition imagery and uses a front end with a thumbnail browser. The high-definition images are best stored in Amazon S3 because they are mission-critical assets, but the thumbnails are all derivatives of the original image. In this scenario, there is very little damage to the business if a thumbnail is lost, because it can be detected and regenerated quickly from the original. Because durability is not as critical for the thumbnails, it doesn’t make sense to pay for the massive redundancies and durability of regular Amazon S3 to store them.

This is an example of the business scenarios behind Amazon S3 – Reduced Redundancy Storage (Amazon S3-RRS). Unlike standard Amazon S3, which replicates your data across at least three geographically separate facilities, Amazon S3-RRS only uses two facilities. There is no difference in the availability (99.99 percent) or the SLA between Amazon S3 and Amazon S3-RRS, but there is significant difference in the results of the durability engineering. Amazon S3 is designed for eleven 9s, whereas Amazon S3-RRS is designed for four 9s of durability.

This reduction in engineered durability means that Amazon S3-RRS can provide somewhat cheaper storage without reducing availability.

From a certification perspective, you must look at a question and determine the business value behind the content being stored. If the question refers to storing content that must be highly available and cost effective, do not immediately assume that the correct approach is to use Amazon S3-RRS. Unless the question includes some mention about the data being reproducible or the original content is stored separately, the loss of durability might be a problem.

If the question asks for the least-expensive solution as the primary goal and does not mention anything about needing durable content however, you can assume that Amazon S3-RRS would be a better choice than standard Amazon S3.

If the question specifically mentions that the data being stored can be re-created on demand, then you should absolutely look at Amazon S3-RRS as the primary candidate for your answer.

Amazon S3 Infrequent Access (Amazon S3-IA)

Amazon S3 Infrequent Access (Amazon S3-IA) solves a completely different business need. In the scenarios suited for Amazon S3-RRS, high availability and high parallel throughput were still needed, but durability was not a primary value. For Amazon S3-IA, the objects still need the massive durability of Amazon S3 and the high availability, but the throughput is not expected at all.

The example scenario in this case would be from the same imaging application mentioned previously that has an archive section for images that are more than six months old. Although they might occasionally be called up for a review, the reality is that they won’t be looked at more than once or twice a year, if ever.

For those business cases, AWS offers Amazon S3-IA. It is still Amazon S3 in terms of durability and availability, but the difference is that the way the storage is engineered for accessibility is much less expensive in general, but the cost per individual requests are notably higher. The reduced cost for availability means that Amazon S3-IA is the most cost-efficient option, as long as the objects are only retrieved infrequently.

The breakpoint for cost effectiveness in Amazon S3-IA is around two retrievals per month. If you expect more retrievals than that on average, it is cheaper to stay with standard Amazon S3.

Exam questions that specifically call out objects that are only accessed once a month or less than 20 times a year should most likely be addressed with Amazon S3-IA. As always, look for other clues that would invalidate the savings presented by Amazon S3-IA.

For example, an additional attribute of Amazon S3-IA is minimum file size (128 KB). Standard Amazon S3 has no file size minimum—a 4 KB file in Amazon S3 is only billed for the 4 KB space. The same 4 KB file stored in Amazon S3-IA would be billed at 128 KB, so even if Amazon S3-IA was normally half the cost of regular Amazon S3, in this edge case, Amazon S3-IA would be 16 times the cost of storing the same 4 KB file in Amazon S3. If the exam question specifically mentioned tiny files (less than 64 KB in size), that would be a signal not to choose Amazon S3-IA as the cost-effective answer.

The other edge case, where Amazon S3-IA is not the best answer, is when files are only stored for a few days. Amazon S3-IA has a minimum 30-day storage time. Content stored for one week is still billed for the entire month. Amazon S3-IA would normally be less expensive, but the shortened shelf life makes standard Amazon S3 a more cost-effective choice.

Versioning

The default behavior of Amazon S3 is to have a single version of an object. When the object is updated, all copies of that object are updated as well. When the object is deleted, all copies are deleted. For operational needs that require back versions to be retained, Amazon S3 versioning can be enabled.

After versioning is enabled, updates to an object do not replace the original object; rather, the new version is stored and marked as the current version of the object and the previous version is retained but no longer retrieved when the object is HTTP requested.

The previous versions are still accessible through the APIs. Operators can select those versions and mark them as the current version (restore) or delete/expire them when they are no longer needed.

Deletes in versioned buckets get divided into two operational functions. “Normal” deletes actually add another version to the stack of versions referenced by the object. In this case, it is just a marker indicating that the file does not exist. If there is an HTTP call to the object, it will return a 404 error. Deleting this 0 KB version will restore the previous version (effectively providing a “recycle bin” function).

Because normal deletes in this case only serve to add a 404 header, to actually purge the object from Amazon S3, you must perform “delete version.” This can be done version by version or wildcarded to delete the entire stack.

It is important to account for cost whenever versioning is enabled. Each object version is billed at the full Amazon S3 storage rates. Operations teams that do not have a lifecycle plan for versioning can find storage costs escalating.

As such, versioning only makes sense on the exam when the questions are concerned with object survivability in the event of intentional or accidental deletes or overwrites. If those are not concerns, then for price considerations, versioning is likely not the best choice.

Amazon S3 Security Options

Amazon S3 is API driven and is a completely abstracted service. As such, there are no security groups or Amazon VPC subnets that control access to the Amazon S3 endpoints (although individual instances can certainly block themselves from accessing Amazon S3).

Assigning the correct IAM policy document to individual users, groups, and roles is the first method for granting access to Amazon S3. You can assign permissions to individual objects or to buckets.

The advantage to using group policies is that individual buckets don’t have to be named. If new buckets are created in an account, anyone with wildcarded Amazon S3 permissions will be able to access the new bucket without edits to the policy document.

Bucket policies have the advantage of being able to grant access to other accounts without needing to create a role for them in the account that owns the bucket.

Security

From a security perspective, Amazon Glacier operates in a similar manner to Amazon S3. Users can be granted IAM permissions to individual archives or vaults (which are root-level storage containers similar to Amazon S3 buckets). Object-level permission is also possible, which can allow for multi-account workflows to the vaults or archives. MFA Delete offers additional protection against accidental or intentional deletions.

In addition, Amazon Glacier offers Vault Lock for customers with specific compliance needs. For example, the United States Securities and Exchange Commission (SEC) rule 17a-4 states that all “electronic records must be preserved exclusively in a non-rewriteable and non-erasable format.”

Legal clarifications to that rule require that there be no possibility of content deletion. An operations team can store content in Amazon Glacier, make copies of that archive in vaults owned by different accounts and different regions, remove all IAM permissions, attach deny policies against the objects and the vaults, and attach different MFA devices against each copy protecting against deletion, finally locking those devices in a safe owned by an escrow company. However, without Amazon Glacier Vault Lock, they still would not be compliant with SEC rule 17a-4. That is because with the right root-level permissions on all of the accounts and the cooperation of the escrow company holding the MFA devices, the content could be deleted or altered.

Although such a complex action would be difficult to do unnoticed, it is still technically possible. Vault Lock adds an additional, immutable element to the storage engine.

Enabling Vault Lock requires two separate API requests. The first request establishes the parameters of the Vault Lock in terms of duration. The second API (which must be executed within 24 hours of the first) confirms the Vault Lock option.

Once Vault Lock is confirmed, any content stored in the vault enters a locked state until that duration period passes. For example, if a duration of one year is put on a vault, content placed in the vault on January 1, 2020 would not be capable of being deleted until January 1, 2021. It does not mean that it will be deleted on that day, but under no conditions can it be deleted or altered during the year 2020.

What if the company changes its mind? The company can change its mind all it wants; however, until the duration expires for any content under Vault Lock, there is no way for the company to delete the content. What if the company’s account is delinquent? In those cases, under the AWS Terms and Conditions, AWS will continue to honor the Vault Lock conditions and not delete the content, although access to the content may be denied until the account is made current.

The only way to “disable” a Vault Lock is to delete the vault after all archives in the vault have outlived their duration protection. Given the irrevocable nature of the Vault Lock feature, it is considered a best practice not to use Vault Lock unless a company is under specific compliance language that provides no other interpretation.

A final security note on Vault Lock is that the option does not provide read-lock. Users with permissions may still download copies of the content, so sensitive material will still need proper governance models to protect against unauthorized downloads.

Lifecycle Policies

An important aspect of the relationship between Amazon S3 and Amazon Glacier is the ability to set lifecycle policies that automatically manage the transitions of content and their expiry.

For example, a company might have content that needs accessibility for the first 90 days followed by occasional usage for the next two years, at which point the records must be retained but would only be accessed in the event of an audit. Finally, the content must be deleted after a total of seven years for compliance. To accommodate this, systems operators can create a lifecycle policy on the original bucket:

1. On object creation plus 90 days, change attribute of content to Amazon S3-IA.
2. The next part of the lifecycle policy statement reads: At object creation plus two years, copy the content to an Amazon Glacier vault, and delete the content from the Amazon S3-IA bucket.
3. The final policy is on the Amazon Glacier vault where creation date plus five years deletes the object (the five years in Amazon Glacier, plus the two years in Amazon S3, results in a seven-year total object lifecycle).

When creating a lifecycle policy, it is the responsibility of the systems operator to ensure that only the correct content is affected by the scope of the policy. To clarify, if you have a deletion policy on an Amazon Glacier vault, you should only place content in that vault if that content has the same lifecycle rules. Failure to do so will result in content being purged unexpectedly.

Reporter

The reporter uses a word processor for all of her work. This implies a heavy read/write workload best served by Amazon EBS at first glance. However, given the fact that editors are involved and story creation is a collaborative effort, a better operational solution would be to use Amazon EFS as a mounted volume for the word processor application.

Using Amazon EFS would provide immediate shared storage for all content in the creation and editing phases of the workflow without any additional operational overhead.

After the content is fully edited and ready for publication, you could serve the content on the website from the Amazon EFS (or Amazon EBS) volume. A more scalable solution would be to load the document into Amazon S3 and have the web page call the story directly from Amazon S3, which is a more cost-efficient and scalable publishing option.

The final concern for reporters is their story notes, which are not intended for the public but must be retained for verification in the event of legal challenges to the story. Amazon Glacier becomes the ideal solution for these documents because retrieval needs are rarely immediate and storage costs are the lowest.

Photo Editor

The photographer will often shoot hundreds of photos or hours of video for a single shot or clip that will end up in the publication. The outtakes can often be mined years later for important details that seemed insignificant during the shoot. After photo selection is complete, storing the outtakes in Amazon Glacier again provides the most cost-effective solution for a deep archive.

For media that is marked for production, you can store the raw files in Amazon S3 and serve them directly from their bucket to internal production applications or to the public websites.

If the publication needs pre-rendered thumbnails or mobile-sized versions of the media, they can be stored in Amazon S3-RRS as a way of saving costs, so that those versions can be re-created on demand from the originals if they are lost.

Production and Archive

By storing the content (text and media) in Amazon S3 (or Amazon S3-RRS), the CMS is already positioned with the most cost-effective, scalable option to deliver the content.

At some point, the content will be determined to be out of date. In the case of a news website, it may take months before consumers stop searching for or clicking on old stories, but eventually all content will reach a point of diminishing results. When the content reaches that point, automated processes can transition the content to Amazon S3-IA. Why not Amazon Glacier? Because in the case of a news archive, even if consumers don’t care about the old story for years, once someone is doing research and wants to open that file (or video), odds are they don’t want to wait five hours for the content to be available. By using Amazon S3-IA, the archive is still cost effective but immediately available and searchable.

AWS Storage Gateway Options

The first option is called the file interface. This enables you to use Amazon S3 with your on-premises workflows by accessing the Amazon S3 bucket through a Network File System (NFS) mount point. This allows customers to migrate their files into Amazon S3 through object-based workloads while maintaining their on-premises investments.

The second option is the volume interface. In this case, you are presented with an iSCSI block storage endpoint. Data is accessed on the local volumes, which is then stored on AWS in the form of Amazon EBS snapshots.

There are two configuration modes using the volume interface. The cached mode is designed to extend your local storage. All content is saved in AWS, and only the frequently accessed data is cached locally. This is an excellent operational solution for on-premises storage solutions that are exceeding their local capacity limits. The other mode is the stored mode, which is a one-to-one backup of all local content on AWS. This is a primary solution when durable and inexpensive off-site backups are needed. This becomes an excellent start to a hybrid disaster recovery plan.

The third option for AWS Storage Gateway is the tape interface. In this configuration, you connect to your existing backup application using an iSCSI Virtual Tape Library (VTL). These virtual tapes are then asynchronously stored in Amazon S3 or Amazon Glacier if less expensive, longer-term storage is needed.

AWS Snowball with AWS Greengrass

As AWS Snowball has increased in popularity, AWS has added additional functionality, including the ability to access APIs run on the device by leveraging AWS Greengrass technology. Those APIs allow the AWS Snowball appliance to act as if it was an Amazon S3 endpoint itself, even when disconnected from the Internet.

AWS Snowmobile

Some companies have dataset transfer needs that range in the exabyte scale. For those unique transfers, AWS can deploy 45-foot-long shipping containers called AWS Snowmobiles. Pulled by tractor trailers, each container can transfer up to 100 PB of data.

For security, AWS Snowmobile uses dedicated security personnel, GPS tracking, alarm monitoring, 24/7 video surveillance, AWS KMS encryption, and an optional escort security vehicle while in transit. For more information on AWS KMS, refer to Chapter 3.

Like AWS Snowball, AWS Snowmobile can deliver multiple containers to a single location, providing exabytes of capacity where needed.