Instance Types

With Amazon EC2, you choose your hardware resources from a broad set of preconfigured options by selecting a specific instance type and instance size. For example, your instance has a number of virtual CPUs (vCPUs) and a specific amount of RAM. The instance type is rated for a certain level of network throughput. Some instance types also include other hardware resources such as high-performance local disks, graphics cards, or even field-programmable gate arrays (FPGAs). The details of how the instance accesses the host resources, such as the specific hypervisor in use, also depend on the instance type that you select.

Even though AWS presets the hardware allocation for an instance type, a wide variety of instance types and sizes are available so that you can select the right level of resources for your application. For example, a t2.nano instance type allocates a fraction of a virtual CPU and 0.5 GiB of RAM to your instance. On the other end of the size spectrum, an x1e.32xlarge instance type provides 128 virtual CPUs and 3,904 GiB of RAM.

Instance types are also grouped into instance families to help you choose the appropriate instance for your application. Instances within a given family share similar characteristics, such as the ratio of vCPU to RAM or access to different types of storage options.

For an overview of the different instance families and their use cases, see Table 2.1.

When you select an instance, choose a size that is appropriate for your current workload because Amazon EC2 instances are resizable. To change the hardware allocation, stop the instance, modify the instance type attribute, and then start the instance again.

Storage

Your instance requires storage volumes for both the root volume and any additional storage volumes that you want to configure. You can create persistent storage volumes with the Amazon Elastic Block Store (Amazon EBS) service to provide block storage devices for Amazon EC2 instances. Certain instance types enable you to mount volumes based on an instance store, which is temporary storage local to the host machine.

For an overview of the relationship between Amazon EBS volumes, instance store volumes, and the Amazon EC2 instance, see Figure 2.1.

Software Images

When the server first boots, it requires an operating system (OS) and the configuration of the attached storage volumes. An Amazon Machine Image (AMI) provides the template for the OS and applications on the root volume of your instance. AMIs also provide a block device mapping that can specify additional volumes to mount when an instance launches, as shown in Figure 2.2.

AWS provides a variety of AMIs. Paid AMIs are available through the AWS Marketplace.

You can create your own AMIs from an Amazon EC2 instance that you have previously customized or by importing your own virtual machine (VM) images. Each AWS Region maintains its own listing of AMIs. Any AMIs that you create are available only within a specific region unless you copy them to other regions. You can share AMIs between AWS accounts. To control which AWS accounts can use your AMIs, define the launch permissions for your AMI.

Depending on the source of the AMI and the type of software license required, the cost of the software licensing may be included in the hourly rate of the instance (such as Windows Server). For instances from the AWS Marketplace, charges are incurred for software licensing in addition to the Amazon EC2 infrastructure.

Network Interfaces

Virtual network interfaces called elastic network interfaces provide networking for your Amazon EC2 instances. Elastic network interfaces are associated with a software-defined network provided by Amazon VPC. Each Amazon EC2 instance is assigned a primary network interface that is associated with a subnet within an Amazon VPC. By default, if you omit the network configuration, Amazon EC2 assigns the instance to one of the subnets within the default VPC. The instance receives both a private IP address to communicate with instances inside the Amazon VPC and a public IP address to communicate with the internet. A security group protects the traffic entering and exiting the network interface. Security groups act as a stateful firewall. To make network connections to your instance, you must set security group rules to allow the connection.

You can attach additional network interfaces to an EC2 instance. Each network interface has its own MAC addresses and IP address associations. Unlike the primary network interface, you can detach secondary network interfaces from one Amazon EC2 instance and then attach it to another instance.

The number of network interfaces that you can attach to an instance and the network throughput depends on the specific instance type and size that you select. The number of network interfaces that you attach does not affect the network throughput of the instance; the bandwidth available to the instance depends on the instance type and size, not the number of network interfaces.

Accessing Instances

By default, Linux Amazon EC2 instances provide remote access through SSH, and Windows Amazon EC2 instances provide remote access through the Remote Desktop Protocol (RDP). To connect to these services, you must have the appropriate inbound rules on the security group for the instance.

Depending on the operating system and AMI that you use to launch the instance, a default administrator is provided for your initial sign-in. To acquire the credentials needed to sign in as the default user, you must specify an Amazon EC2 key pair when you launch the instance. After you sign in, you can create additional users with the appropriate Linux or Windows tools.

Instance Lifecycle

An Amazon EC2 instance has three primary states: running, stopped, and terminated. Additionally, there are intermediate states of pending, stopping, and shutting down. An Amazon EC2 instance accrues charges for the compute resources only when it is in the running state. However, EBS volumes persist data even when an instance is stopped, so the charges for persistent storage from any EBS volumes accrue independently from the state of the instance.

When you first launch an instance from an AMI, it goes into the pending state until it enters the running state on a host machine.

After an instance is running, for instances with EBS-backed storage, you can stop the instance. If you stop the instance, it enters the stopping state. Any data on instance store drives on that host are erased.

When an instance is stopped, you can modify attributes that cannot be changed, such as instance type, while the instance is running. You can also start stopped instances. When you start an instance, it enters the pending state until it is running again.

Typically, each time an instance is started, it is launched on a different physical host machine than before. If the underlying physical host is impaired and requires maintenance, stopping and then starting the Amazon EC2 instance moves the instance to a healthy host.

You can also terminate an instance. It first goes through shutting down; then eventually it is terminated. The default behavior is to delete the EBS volumes associated with the instance on termination.

To view the lifecycle of an Amazon EC2 instance, see Figure 2.3.

Connecting to Amazon EC2 Instances

With EC2 instances, you have full administrative control to install software packages on your instance and create additional user accounts as needed. By default, to connect to a Linux instance, you can directly use the private key from the Amazon EC2 key pair with an SSH client, as shown in Figure 2.4.

For a Windows instance, the password for the Administrator account is encrypted with the public key. You can decrypt the password by using the associated private key, as illustrated in Figure 2.5 and Figure 2.6.

After you have decrypted the password, you can use Microsoft Remote Desktop to connect to the instance, as shown in Figure 2.7.

Customizing Software with User Data

You can connect to your instance and install any applications you want from an interactive session. However, one of the advantages of moving to the cloud is to automate previously manual steps. Instead of logging in to the instance, another way to customize the software on your instance is to provide user data as part of the request to launch the instance. For Linux instances, user data can be a shell script or a cloud-init directive. On Windows instances, depending on the version of Windows Server, either EC2Config or EC2Launch processes the user data. By default, commands supplied to user data execute only at first boot of the instance.

Here is an example of installing an Apache web server on an Amazon Linux 2 instance with a shell script that is provided as the user data:

#!/bin/bash
yum update -y
yum install httpd -y
systemctl start httpd
systemctl enable httpd
 

Discovering Instance Metadata

With the instance metadata service (IMDS), code running on an Amazon EC2 instance can discover properties about that instance. The instance metadata service exposes a special IP address, 169.254.169.254, which you can query using HTTP to perform lookups. You can query a broad range of metadata attributes, as shown in Figure 2.8 These attributes can include the instance ID and credentials derived from an Identity and Access Management (IAM) role.

With IMDS, it also possible to retrieve the user data that was used to bootstrap an instance, as shown in Figure 2.9.

Assigning AWS API Credentials

You can assign an IAM role to an Amazon EC2 instance. The AWS Software Development Kit (SDK) and AWS Command Line Interface (AWS CLI) can automatically discover these credentials through the Amazon EC2 metadata service. You can skip the task of explicitly configuring credentials files on your instances during bootstrapping.

When you assign an IAM role to an instance, it is assigned indirectly, through an instance profile, which is a container for an IAM role. You can associate a particular instance profile with many Amazon EC2 instances. However, a particular Amazon EC2 instance can be associated with one instance profile at a time, and an instance profile can be associated with only one IAM role. You can associate or disassociate Amazon EC2 instances with an instance profile at launch or even when the instances are running.

When an instance profile with an IAM role is associated with an instance, the Amazon EC2 service makes the necessary calls to the AWS Security Token Service (AWS STS) automatically to generate short-term credentials for that instance. These credentials are based on the IAM role associated with the instance profile. The credentials are exposed to the instance through the Amazon EC2 metadata service, as shown in Figure 2.10.

Serving a Custom Webpage

This example combines Amazon EC2 user data, the Amazon EC2 metadata service, and IAM roles to configure an Amazon EC2 instance. In the example, a web server displays a static webpage that shows custom information.

The following is a bootstrapping script that enables you to configure an Amazon EC2 instance running Amazon Linux 2. At first boot of the instance, the script generates a static page that displays the instance ID, instance type, Availability Zone, and public IP address of the instance at the time the script was executed.

The first line of the script declares the type of script. Then the script installs the Apache web server and configures it to run as a service. Because the script is running as the root user, there is no requirement to preface the commands with sudo.

Next, the script makes several calls to the Amazon EC2 metadata service and saves the results into environment variables to be used later in the script.

To generate an MP3 file that speaks out the instance ID, the script makes an API call to Amazon Polly. For this API call to succeed, you must assign the instance an IAM role that allows permissions to the Amazon Polly SynthesizeSpeech action. The managed AmazonPollyReadOnlyAccess policy can grant these permissions.

Next, the script generates a static HTML page. This page references the values that were previously stored as environment variables. After this script completes, your Amazon EC2 instance can respond to HTTP requests and show the customized page. To see this page, you must verify that the Amazon EC2 instance has port 80 open in its security group and is assigned a public IP address.

#!/bin/bash
 
# Install Apache Web Server
yum update -y
yum install httpd -y
systemctl start httpd
systemctl enable httpd
 
# Discover configuration using the EC2 metadata service
ID=$(curl 169.254.169.254/latest/meta-data/instance-id)
TYPE=$(curl 169.254.169.254/latest/meta-data/instance-type)
AZ=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone)
IPV4=$(curl -f 169.254.169.254/latest/meta-data/public-ipv4)
 
# Set up the Web Site
cd /var/www/html
 
## Make AWS Cloud API calls to generate an audio file
VOICE=$(aws polly describe-voices --language-code en-US 
--region us-west-2 --query Voices[0].Id --output text)
aws polly synthesize-speech --region us-west-2 --voice-id $VOICE 
--text "Hello from EC2 instance $ID." --output-format mp3 instance.mp3
 
## Generate customized index.html for this instance
echo "<html>
<body><H1>Welcome to your EC2 Instance</H1><p><p>" > ./index.html
echo "<audio controls>" >> ./index.html
echo '<source src="instance.mp3" type="audio/mp3">' >> ./index.html
echo 'Here is an <a href="instance.mp3"> audio greeting.</a> ' >> ./index.html
echo "</audio><p><p>" >> ./index.html
echo "There are many other instances, but" >> ./index.html
echo "<strong>$ID</strong> is yours.<p><p>" >> ./index.html
echo "This is a <strong>$TYPE</strong> instance" >> ./index.html
echo " in <strong>$AZ</strong>. <p><p>" >> ./index.html
if [ "$IPV4" ];
then
   echo "The public IP is <strong>$IPV4</strong>.<p><p>" >> ./index.html
else
   echo "This instance does <strong>NOT</strong> have" >> ./index.html
   echo "a public IP address.<p><p>" >> ./index.html
fi
echo "--Audio provided by the $VOICE voice.<p><p>" >> ./index.html
echo "</body></html>" >> ./index.html

Monitoring Instances

Now that you have an application running on your instance, you may be interested in understanding how that application performs, or if it is still running at all. Amazon EC2 performs automated status checks of the software and hardware of the underlying host machine every minute. These status checks are to verify that the instance can connect to the network and can run successfully on the host machine. If the status checks find no underlying issues, they return the status OK. If an issue is detected that prevents normal operation of the Amazon EC2 instance, the status checks return the status as impaired. The results of these status checks are available in Amazon CloudWatch.

For each of your instances, the Amazon EC2 service automatically collects metrics related to CPU utilization, disk reads and writes, and network utilization and makes them available in CloudWatch. You can supplement these built-in metrics with data from the guest operating system on your instance, such as memory utilization and logs from your application, by installing and configuring the CloudWatch agent on the instance.

Using CloudWatch, you can automate actions based on a metric through CloudWatch alarms. For example, you can configure an CloudWatch alarm that applies the recover instance action if status checks show that the host running the instance is impaired.

Amazon Virtual Private Cloud

Amazon Virtual Private Cloud (Amazon VPC) provides logically isolated networks within your AWS account. These networks are software defined and can span all of the Availability Zones within a specific AWS Region. For each VPC, you have full control over whether the Amazon VPC is connected to the internet, to a private on-premises network, or to other Amazon VPCs. Until you explicitly create these connections, instances in your VPC are able to communicate with other instances in the same VPC only.

You define an Amazon VPC with one or more blocks of addresses specified in the Classless Inter-Domain Routing (CIDR) notation. If, for example, you specified 10.0.0.0/16 as the block for a VPC, this means that the VPC includes IP addresses in the range from 10.0.0.0 through 10.0.255.255. For an example of an Amazon VPC spanning multiple Availability Zones in a region, see Figure 2.11.

Connecting to Other Networks

By default, an Amazon VPC is an isolated network. Instances within an Amazon VPC cannot communicate with the internet or other networks until you explicitly create connections. Table 2.2 provides an overview of various types of connections that you can establish between an Amazon VPC and other networks.

For an example of an Amazon VPC with a connection to an internet gateway and a VPN connection to an on-premises network provided by a virtual private gateway, see Figure 2.12.

IP Addresses

When working with Amazon VPC, all instances placed within a particular VPC are assigned one or more IP addresses. There are four different types of IP addresses available for use with Amazon VPC. Primarily, these IP addresses are based on IPv4; however, you can enable support for IPv6.

Subnets

Within an Amazon VPC, you define one or more subnets. A subnet is associated with a specific Availability Zone within the region containing the Amazon VPC. Each subnet has its own block of private IP addresses defined using CIDR notation. This block is a subset of the overall IP address range assigned to the Amazon VPC and does not overlap with any other subnet in the same Amazon VPC.

For example, a subnet may be assigned the CIDR block range 10.0.0.0/24, which would include addresses in the range 10.0.0.0–10.0.0.255. Out of the 256 possible addresses, Amazon VPC reserves the first four IP addresses and the last IP address in the range, leaving 251 IP addresses in the subnet.

When you launch an Amazon EC2 instance into a subnet, its primary network interface assigns a private IPv4 address automatically from the CIDR range assigned to the subnet.

Typically, you create at least two types of configurations for subnets in a VPC. The first is for subnets in which you place instances that you want to reach directly from the internet. This could be an instance running as a web server, for example. Subnets of this type are known as public subnets.

The second type of configuration is usually a subnet that backend instances use that must be accessible to your other instances but should not be directly accessible from the internet. Subnets of this type are known as private subnets. For example, if you had an instance that was dedicated to running a database, such as MySQL, you could place that instance in a private subnet. It would be accessible from the web server in the public subnet, but it would not accept traffic from the internet.

For an example of an Amazon VPC with a public and a private subnet, see Figure 2.13.

In addition to Amazon EC2 instances, many AWS managed services, such as Amazon Relational Database Service (Amazon RDS) or Amazon ElastiCache, also enable you to expose your resources in specific subnets and, in particular, into private subnets. You can create these resources and access them privately from instances within your Amazon VPC.

Route Tables

Network traffic exiting a subnet is controlled with routes that are defined in a route table. Routes define how the implicit router in the Amazon VPC routes IP traffic from a subnet to destinations outside that subnet. Each route table includes a rule called the local route. This rule or route is what allows traffic from instances in one subnet within the Amazon VPC to send traffic to instances in any other subnets within the same Amazon VPC. A route is composed of two parts: a destination and a target for the network traffic.

Unless explicitly associated with a specific route table, subnets associate with a default route table called the main route table. By default, the main route table includes only the local route. This means that subnets that are associated with the default route table have no connection to the internet. They can route traffic privately only within the Amazon VPC. However, you can modify this table or define additional route tables and rules as required.

For an example of the main route table for an Amazon VPC, see Table 2.3.

Route tables and the configured rules differentiate public subnets from private subnets. For example, you might create a public subnet by associating the subnet with a route table that includes a rule to route internet-bound traffic through an internet gateway. To represent any IP address on the internet in the rule, you can use the 0.0.0.0/0 CIDR block. Table 2.4 is an example of a route table that contains the defined rules.

When you launch an Amazon EC2 instance into a public subnet, assign a public IP address to the instance. Even though the subnet has a route to an internet gateway, the instance is not able to communicate with the internet without a public IP address. Route table rules are evaluated in order of specificity.

To review a diagram of an Amazon VPC that has a public and a private subnet configured with the route table rules, see Figure 2.14.

Security Groups

Security groups act as a stateful firewall for your Amazon EC2 instances. When you define security group rules, you specify the source or destination of the network traffic in addition to the protocols and ports that you allow. If you change the security group rules, that change propagates to any instances associated with that security group.

By using inbound security group rules, you can control the source, protocols, and ports of allowed network traffic. For example, you could allow TCP connections that originate from the IPv4 address of your home network so that you can administer an Amazon EC2 instance using SSH.

Outbound rules enable you to control destination, protocols, and ports of allowed network traffic. Security groups include a default outbound rule that allows all outbound requests on all protocols and ports to all destinations. To control outbound requests more tightly, you can remove this default rule and add specific outbound rules in its place.

When you specify a source or destination for a security group rule, you can use IPv4 or IPv6 address ranges. Alternatively, you can use an identifier for a security group as a source or destination.

Assume that you have two EC2 instances—one instance is running a web server, and a second instance is running a database application. To allow network connections to these instances, you create two security groups: a security group for your web server instances called websg and a second security group for your database instances called databasesg.

For websg, you set inbound rules that allow web requests from anywhere. You also allow inbound SSH but only from a specific IP address that your administrator uses. You have not yet modified the default outbound rule for websg, so all outgoing connections are allowed.

For databasesg, you write an inbound rule that allows incoming traffic on TCP port 3306 originating from websg. Remove the default outbound rule and instead add rules to allow outbound connections to download software updates over HTTP and HTTPS. All other outbound connections from databasesg will be blocked.

To view the diagram of the security groups and rules for this scenario, see Figure 2.15. Also, see Table 2.5, Table 2.6, Table 2.7, and Table 2.8 for the corresponding inbound and outbound rules for these security groups.

If you specify an inbound rule, replies to that incoming connection are permitted. Similarly, if you specify an outbound rule, the replies to the outbound request are permitted. In the previous example, when a web server instance makes a connection to a database, only the outbound rule for the web server and the inbound rule for the database must allow the flow. The inbound rule for the web server and the outbound rule for the database will not be evaluated for this flow.

Security groups only support rules to allow traffic. Therefore, if you assign multiple security groups to your instance, the security group rules combine in the most permissive way; each group contributes to opening up more access to the instance.

If you fail to specify a security group when you launch the Amazon EC2 instance, the instance associates with the default security group for the Amazon VPC. If your Amazon EC2 instance has more than one network interface, you can manage the security groups for each network interface independently from the others.

Network Access Control Lists

In addition to routes, network access control lists (network ACLs) allow an administrator to control traffic that enters and leaves a subnet. A network ACL consists of inbound and outbound rules that you can associate with multiple subnets within a specific Amazon VPC. Network ACLs act as a stateless firewall for traffic to or from a specific subnet. Whereas security group rules provide only the capability to allow traffic, network ACL rules support the ability to allow specific types of traffic and to deny specific traffic.

However, unlike security groups, network ACLs are stateless and do not track connections and their replies. This means that to allow for a particular traffic flow, both inbound and outbound rules must allow it for that network ACL. For inbound rules, you can specify the protocol, port range, and source IP address range. For outbound rules, you specify the protocol, port range, and destination IP address range. For each rule, you also choose whether the rule allows or denies traffic. Rules in a network ACL are numbered and evaluated in order from the smallest to largest rule number.

If you do not specify a network ACL, the subnet is associated with the default network ACL for the Amazon VPC. This network ACL comes with rules that allow all inbound and outbound traffic. Table 2.9 shows an example of the inbound rules for a default network ACL. The final rule for the network ACL, rule 100, is a universal rule that explicitly denies traffic that does not match any other rule. Because there is a rule to allow all traffic and rules are evaluated in order, this universal rule has no effect. However, if you remove or modify rule 100, then the final rule would apply to any traffic that did not match any of the other rules.

Table 2.10 shows an example of the outbound rules for the default network ACL for an Amazon VPC. As before, the final rule is a universal rule that denies traffic unless it has been explicitly allowed by a preceding rule.

Figure 2.16 shows an example of an Amazon VPC with security groups protecting Amazon EC2 instances and network ACLs protecting subnets.

Figure 2.17 shows the same Amazon VPC, represented in a different way to highlight the features that control network traffic within an Amazon VPC.

Table 2.11 summarizes key aspects of security groups and network ACLs.

Network Address Translation

Network address translation (NAT) allows for instances in a private subnet to make outbound requests to the internet without exposing those instances to inbound connections from internet users. To provide NAT for outbound requests from private subnets, you can use an Amazon EC2 instance configured to perform NAT or a NAT gateway. The instances in the private subnet maintain their own private IP addresses and effectively share the public IP address of the NAT when making internet requests.

For the NAT to perform its job, you must place the NAT instance or a NAT gateway in a correctly configured public subnet to forward traffic to the internet. Make sure that the public subnet has a route to an internet gateway, as previously shown in Table 2.4. To support outbound network requests, you can associate the private subnet with a route table, similar to the one shown in Table 2.12.

For the Amazon VPC configuration example, Figure 2.18 shows the corresponding route tables for the public and private subnets using the NAT gateway.

Internet-bound requests route to the NAT gateway through the route table of the private subnet. The NAT, located in a public subnet, then makes a corresponding request out to the internet. This second outbound request appears to have originated from the public IP address of the NAT when the external website received it. When the website responds, NAT receives the reply and forwards it to the instance that initiated the original request. Figure 2.19 shows the network flow.

Using an Amazon EC2 instance for NAT instead of a NAT gateway requires you to disable the source/destination check setting for the NAT instance.

This setting protects Amazon EC2 instances by requiring that the instance be the source or destination of any network traffic it receives. In the case of the NAT instance, while the packets are routed to the instance via a route table, they are addressed to destinations on the internet rather than the NAT. Disabling this setting allows the network traffic to be delivered to the NAT instance.

DHCP Option Sets

The Dynamic Host Configuration Protocol (DHCP) provides a standard for passing configuration information to hosts on a TCP/IP network. The options field of a DHCP message contains the configuration parameters.

Some of those parameters are the address of domain name servers (DNS), the domain names of the instances, and the addresses of Network Time Protocol (NTP) servers. By default, the Amazon VPC uses the DNS that AWS provides. However, you can override these settings by specifying a custom set of DHCP options.

Monitoring Amazon VPC Network Traffic

You can monitor the network flows within your Amazon VPC by enabling Amazon VPC Flow Logs. You can then publish these logs to Amazon CloudWatch Logs or store them as log files in Amazon Simple Storage Service (Amazon S3). Enable Amazon VPC Flow Logs on a particular Amazon VPC, on a subnet, or on a specific elastic network interface, such as for an Amazon EC2 instance.

For each network session, the Flow Logs capture metadata, such as the source, destination, protocol, port, packet count, byte count, and time interval. The log entry specifies whether the traffic was accepted or rejected. This information helps you debug the network configuration.

Shared Responsibility Security Model

AWS is responsible for the security of the cloud. This involves securing physical access to the underlying infrastructure, such as the AWS Regions and Availability Zones. This responsibility includes procedures for restricting access to the servers, physical networks, and decommissioning of hardware that is no longer useful. As part of securing the cloud infrastructure, AWS is also responsible for maintaining the underlying software for each service provided.

As the AWS customer, you are responsible for security on the cloud. This responsibility includes making secure choices when configuring your infrastructure and developing your applications. These responsibilities can include configuring the relevant encryption options and configuring your firewall rules. Even though this is your responsibility, you can simplify this task by taking advantage of AWS tools for encryption, defining firewall rules, and managing access and authorization to your AWS resources. For a summary of AWS and customer responsibilities, see Figure 2.20.

For example, with Amazon EC2, AWS is responsible for the software on the physical host machines up through maintaining the virtualization layer. However, beyond that, it is your responsibility to ensure that the guest operating system and everything running on it are secured. Your responsibilities include the following tasks:

• Making sure that any sensitive data is secured
• Making sure that the guest operating system is patched regularly
• Managing the guest operating system’s user accounts
• Securing any applications that are installed on that instance

AWS provides tools to help you manage these concerns. For example, use AWS Systems Manager to automate the patching of instances on your behalf. You can also use network controls, such as security groups, to restrict access to the instance. However, it is your responsibility to configure these features in a way that meets the security requirements for your specific application.

Comparing Managed and Unmanaged Services

Even though services such as Amazon EC2 provide many low-level customizations, other AWS services provide a managed experience. When you use AWS managed services, you may find that you have less responsibility. For example, for Amazon RDS, AWS manages the software installed on the underlying database instance. You interact with the database using your SQL client rather than a shell session, and you do not install your own software on the database instance. In this case, parts of your operational burden for security are reduced—AWS manages the operating system and software on the database instance.