Database Reference
In-Depth Information
availability zone is a distinct location in a region designed to act as an autonomous
failure zone. Specifically, an availability zone does not share a physical infrastruc-
ture with other availability zones, thus limiting failures from transcending its own
boundaries. Furthermore, when a failure occurs, automated AWS processes start
moving customer application traffic away from the affected zone [6]. Consequently,
applications that run in more than one availability zone across regions can inher-
ently achieve higher availability and minimize downtime. Amazon EC2 guarantees
99.95% availability per each Region [3].
Lastly, EC2 instances that are attached to Amazon EBS volumes can attain
improved durability over EC2 instances with local stores (or the so-called ephem-
eral storage). Amazon EBS volumes are automatically replicated in the backend of
a single Availability Zone. Moreover, with Amazon EBS, point-in-time consistent
snapshots of EBS volumes can be created and reserved in Amazon S3. Amazon S3
storage is automatically replicated across multiple availability zones and not only
in a single availability zone. Amazon S3 helps maintain the durability of users'
data by quickly detecting and repairing losses. Amazon S3 is designed to provide
99.999999999% durability and 99.99% availability of data over a given year [6].
A snapshot of an EBS volume can also serve as the starting point for a new EBS
volume in case the current one fails. Therefore, with the availability of regions and
availability zones, the virtualized environment provided by Xen, and the Amazon's
EBS and S3 services, Amazon EC2 users can achieve long-term protection, failure
isolation, and reliability.
16.9.2.5 Security
Security within Amazon EC2 is provided at multiple levels. First, as pointed out ear-
lier, EC2 instances are completely controlled by users. Users have full root access or
administrative control over their instances, accounts, services, and applications. AWS
does not have any access rights to user instances and cannot log into their guest OSs
[6]. Second, Amazon EC2 provides a complete firewall solution, whereby the default
state is to deny all incoming traffic to any user instance. Users must explicitly open
ports for specific inbound traffic. Third, API calls to start/stop/terminate instances,
alter firewall configurations and perform other related functions are all signed by
the user's Amazon Secret Access Key. Without the Amazon Secret Access Key, API
calls on Amazon EC2 instances cannot be made. Fourth, the virtualized environment
provided by Xen provides a clear security separation between EC2 instances and the
hypervisor as they run at different privileged modes. Fifth, the AWS firewall is placed
within the hypervisor, between the physical network interface and the virtual inter-
faces of instances. Hence, as packet requests are all privileged, they must trap to the
hypervisor and accordingly pass through the AWS firewall. Consequently, any two
communicating instances will be treated as separate virtual machines on the Internet,
even if they are placed on the same physical machine. Finally, as Amazon EBS vol-
umes can be associated with EC2 instances, their accesses are restricted to the AWS
accounts that created the volumes. This indirectly denies all other AWS accounts (and
corresponding users) from viewing and accessing the volumes. We note, however, that
this does not impact the flexibility of sharing data on the AWS cloud platform. In par-
ticular, users can still create Amazon S3 snapshots of their Amazon EBS volumes and
Search WWH ::




Custom Search