Chapter 3. Using virtual servers: EC2
- Launching a virtual server with Linux
- Controlling a virtual server remotely via SSH
- Monitoring and debugging a virtual server
- Reducing costs for virtual servers
It’s impressive what you can achieve with the computing power of the smartphone in your pocket or the laptop in your bag. But if your task requires massive computing power or high network traffic or needs to run reliably 24/7, a virtual server is a better fit. With a virtual server, you’ll get a part of a server located in a data center. On AWS, virtual servers are offered by the service called Elastic Compute Cloud (EC2).
3.1. Exploring a virtual server
A virtual server is part of a physical server that’s isolated by software from other virtual servers on the same physical server; it consists of CPUs, memory, networking interfaces, and storage. The physical server is also called the host server, and the virtual servers running on it are called guests. A hypervisor is responsible for isolating the guests from each other and for scheduling requests to the hardware. Figure 3.1 shows these layers of server virtualization.
Figure 3.1. Layers of server virtualization
The examples in this chapter are not all covered by the Free Tier. A special warning message appears when an example incurs costs. As long as you don’t run all other examples longer than a few days, you won’t pay anything for them. Keep in mind that this applies only if you created a fresh AWS account for this book and nothing else is going on in your AWS account. Try to complete the examples of the chapter within a few days; you’ll clean up your account at the end of each example.
Typical use cases for a virtual server are as follows:
- Hosting a web application
- Executing enterprise applications
- Transforming or analyzing data
3.1.1. Launching a virtual server
It takes only a few clicks to launch a virtual server:
1. Open the AWS Management Console at https://console.aws.amazon.com.
2. Make sure you’re in the N. Virginia (US East) region (see figure 3.2), because we optimized our examples for this region.
Figure 3.2. Making sure you’re in the correct region
3. Find the EC2 service in the navigation bar under Services and click it. You’ll see a page like the one shown in figure 3.3.
Figure 3.3. Overview of the EC2 service for virtual servers, with the Launch Instance button
4. To start the wizard for launching a virtual server, click Launch Instance.
The wizard will guide you through the following steps:
1. Selecting an OS
2. Choosing the size of your virtual server
3. Configuring details
4. Reviewing your input and selecting a key pair for SSH
Selecting an OS
The first step is to choose a bundle of an OS and preinstalled software for your virtual server, called an Amazon Machine Image (AMI). Select Ubuntu Server 14.04 LTS (HVM) for your virtual server, as shown in figure 3.4.
Figure 3.4. Choosing an OS for the virtual server
An AMI is the basis your virtual server starts from. AMIs are offered by AWS, by third-party providers, and by the community. AWS offers the Amazon Linux AMI, which includes a Red Hat Enterprise Linux derivative optimized for use with EC2. You’ll also find popular Linux distributions and AMIs with Microsoft Windows Server. In addition, the AWS Marketplace offers AMIs with preinstalled third-party software.
A virtual appliance is an image containing an OS and preconfigured software that can be run on a hypervisor. It’s the hypervisor’s job to run one or more virtual appliances. Because a virtual appliance contains a fixed state, every time you start the virtual appliance, you’ll get exactly the same result. You can reproduce virtual appliances as often as needed, so you can use them to eliminate the cost of installing and configuring complex stacks of software. Virtual appliances are used by virtualization tools from VMware, Microsoft, and Oracle and for infrastructure as a service offerings in the cloud.
The AMI is the virtual appliance image in AWS. It’s a special virtual appliance for use with the EC2 service for virtual servers. An AMI technically consists of a read-only file-system including the OS, additional software, and configuration; it doesn’t include the kernel of the OS. The kernel is loaded from an Amazon Kernel Image (AKI). You can also use AMIs for deploying software on AWS.
AWS uses Xen, an open source hypervisor, as the underlying technology for the EC2 service. The current generations of virtual servers on AWS use hardware-assisted virtualization. The technology is called Hardware Virtual Machine (HVM) and uses the Intel VT-x platform. A virtual server run by an AMI based on HVM uses a fully virtualized set of hardware and can take advantage of hardware extensions that provide fast access to the underlying hardware.
Using a 3.8+ kernel for your virtual Linux servers will provide the best performance. To do so, you should use at least Amazon Linux 13.09, Ubuntu 14.04, or RHEL7. If you’re starting new virtual servers, make sure you’re using HVM images.
Choosing the size of your virtual server
It’s now time to choose the computing power needed for your virtual server. Figure 3.5 shows the next step of the wizard. On AWS, computing power is classified into instance types. An instance type primarily describes the number of CPUs and the amount of memory.
Figure 3.5. Choose the size of the virtual server.
The names for different instance types are all structured in the same way. The instance family groups instance types for the same focus. AWS releases new instance types and families from time to time; the different versions are called and marked as generations. The instance size defines the capacity of CPU, memory, storage, and networking.
For example, the instance type t2.micro tells you the following:
1. The instance family is t. It groups small, cheap virtual servers with low baseline CPU performance but with the ability to burst significantly over baseline CPU performance for a short time.
2. You’re using generation 2 of this instance type.
3. The size is micro, indicating that the instance is very small.
Table 3.1 shows examples of instance types for different use cases. All prices in USD are valid for US East (N. Virginia) and a virtual server based on Linux on April 14, 2015.
Table 3.1. Overview of instance families and instance types
|
Instance type |
Virtual CPUs |
Memory |
Description |
Typical use case |
Hourly cost (USD) |
|---|---|---|---|---|---|
| t2.micro | 1 | 1 GB | Smallest and cheapest instance type, with moderate baseline performance and the ability to burst CPU performance above the baseline | Testing and development environments, and applications with low traffic | 0.013 |
| m3.large | 2 | 7.5 GB | Has a balanced ratio of CPU, memory, and networking performance | All kinds of applications, such as medium databases, HTTP servers, and enterprise applications | 0.140 |
| r3.large | 2 | 15 GB | Optimized for memory-intensive applications with extra memory | In-memory caches and enterprise application servers | 0.175 |
There are also instance types and families optimized for compute-intensive workloads, workloads with high networking I/O, and storage-intensive workloads. Other instance types provide access to GPUs for server-side graphics workloads. Our experience indicates that you’ll over-estimate the resource requirements for your applications. We recommend that you try to start your application with a smaller instance type than you first think you need.
Computers are getting faster and more specialized. AWS is constantly introducing new instance types and families. Some of them are improvements of existing instance families, and others are focused on specific workloads. For example, instance family d2 was introduced in March 2015. It provides instances for workloads requiring high sequential read and write access, such as some databases and log processing.
The smallest and cheapest virtual server will be enough for your first experiments. In the wizard screen shown in figure 3.5, choose the instance type t2.micro. Then click Next: Configure Instance Details to proceed.
Instance details, storage, firewall, and tags
The next four steps of the wizard are easy because you don’t need to change the defaults. You’ll learn about these settings in detail later in the book.
Figure 3.6 shows the next step of the wizard. You can change the details for your virtual server, such as the network configuration or the number of servers to launch. For now, keep the defaults, and click Next: Add Storage to proceed.
Figure 3.6. Details for the virtual server
There are different options for storing data on AWS, which we’ll cover in detail in the following chapters. Figure 3.7 shows the possibility of adding network-attached storage to your virtual server. Keep the defaults, and click Next: Tag Instance.
Figure 3.7. Add network-attached storage to your virtual server.
A tidy house indicates a tidy mind. Tags help you to organize resources on AWS. A tag is nothing more than a key-value pair. Add at least a Name tag to your resources to help you find your stuff later. Use Name as the key and myserver as the value, as figure 3.8 shows. Then click Next: Configure Security Group.
Figure 3.8. Name your virtual server with a Name tag.
A firewall helps to secure your virtual server. Figure 3.9 shows the settings for a default firewall allowing access via SSH from anywhere. This is exactly what you need, so keep the defaults and click Review and Launch.
Figure 3.9. Configuring the firewall for your virtual server
Reviewing your input and selecting a key pair for SSH
You’re almost finished. The wizard should show a review of your new virtual server (see figure 3.10). Make sure you chose Ubuntu Server 14.04 LTS (HVM) as the OS and t2.micro as the instance type. If everything is fine, click the Launch button.
Figure 3.10. Review the instance launch for the virtual server.
Last but not least, the wizard asks for your new virtual server’s key.
Logging in to your virtual server requires a key. You use a key instead of a password to authenticate yourself. A key is much more secure than a password, and using keys for SSH is enforced for virtual servers running Linux on AWS. If you skipped the creation of a key in section 1.8.3, follow these steps to create a personal key:
1. Open the AWS Management Console at https://console.aws.amazon.com. Find the EC2 service in the navigation bar under Services and click it.
2. Switch to Key Pair via the submenu.
3. Click Create Key Pair.
4. Enter mykey for Key Pair Name, and click Create. Your browser downloads the key automatically.
5. Open a terminal and switch to your download folder.
6. OS X and Linux only: change the access rights of the file mykey.pem by running chmod 400 mykey.pem in the console.
Windows only: Windows doesn’t ship a SSH client, so you need to install PuTTY. PuTTY comes with a tool called PuTTYgen that can convert the mykey.pem file into a mykey.ppk file, which you’ll need. Open PuTTYgen and select SSH-2 RSA under Type of Key to Generate. Click Load. Because PuTTYgen displays only *.pkk files, you need to switch the file extension of the File Name Input to All Files. Now you can select the mykey.pem file and click Open. Confirm the dialog box. Change Key Comment to mykey and Click Save Private Key. Ignore the warning about saving the key without a passphrase. Your .pem file is now converted to the .pkk format needed by PuTTY.
You’ll find a more detailed explanation about how to create a key in chapter 1.
Choose the option Choose an Existing Key Pair, select the key pair mykey, and click Launch Instances (see figure 3.11).
Figure 3.11. Choosing a key pair for the virtual server
Your virtual server launches. Open an overview by clicking View Instances, and wait until the server reaches the Running state. To take full control over your virtual server, you need to log in remotely.
3.1.2. Connecting to a virtual server
Installing additional software and running commands on your virtual server can be done remotely. To log in to the virtual server, you have to figure out its public IP address:
1. Click the EC2 service in the navigation bar under Services and click Instances in the submenu at left to jump to an overview of your virtual server.
2. Select the virtual server from the table by clicking it. Figure 3.12 shows the server overview and the available actions.
Figure 3.12. Overview of your virtual server with actions to control it
3. Click Connect to open the instructions for connecting to the virtual server.
4. Figure 3.13 shows the dialog with instructions to connect to the virtual server. Find the public IP address of your virtual server, such as 52.4.216.201 in our example.
Figure 3.13. Instructions for connecting to the virtual server with SSH
With the public IP address and your key, you can connect to your virtual server. Continue with the next sections, depending on your OS on your local machine.
Linux and Mac OS X
Open your terminal and type ssh -i $PathToKey/mykey.pem ubuntu@$PublicIp, replacing $PathToKey with the path to the key file you downloaded in section 1.8.3 and $PublicIp with the public IP address shown in the connect dialog in the AWS Management Console. Answer Yes to the security alert regarding the authenticity of the new host.
Windows
Follow these steps:
1. Find the mykey.ppk file you created in section 1.8.3 and open it by double-clicking.
2. PuTTY Pageant should appear in the task bar as an icon. If not, you may need to install or reinstall PuTTY as described in section 1.8.3.
3. Start PuTTY. Fill in the public IP address shown in the Connect dialog in the AWS Management Console, and click Open (see figure 3.14).
Figure 3.14. Connecting to the virtual server with PuTTY on Windows
4. Answer Yes to the security alert regarding the authenticity of the new host, and type ubuntu as the login name. Press Enter.
Login message
Whether you’re using Linux, Mac OS X, or Windows, after a successful login you should see a message like the following:
ssh -i ~/Downloads/mykey.pem [email protected] Warning: Permanently added '52.4.216.201' (RSA) to the list of known hosts. Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Wed Mar 4 07:05:42 UTC 2015 System load: 0.24 Memory usage: 5% Processes: 83 Usage of /: 9.8% of 7.74GB Swap usage: 0% Users logged in: 0 Graph this data and manage this system at: https://landscape.canonical.com/ Get cloud support with Ubuntu Advantage Cloud Guest: http://www.ubuntu.com/business/services/cloud 0 packages can be updated. 0 updates are security updates. The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ~$
You’re now connected to your virtual server and ready to run a few commands.
3.1.3. Installing and running software manually
You’ve started a virtual server with an Ubuntu OS. It’s easy to install additional software with the help of the package manager apt. To begin, you’ll install a tiny tool called linkchecker that allows you to find broken links on a website:
$ sudo apt-get install linkchecker -y
Now you’re ready to check for links pointing to websites that no longer exist. To do so, choose a website and run the following command:
$ linkchecker https://...
The output of checking the links looks something like this:
[...]
URL `http://www.linux-mag.com/blogs/fableson'
Name `Frank Ableson's Blog'
Parent URL http://manning.com/about/blogs.html, line 92, col 27
Real URL http://www.linux-mag.com/blogs/fableson
Check time 1.327 seconds
Modified 2015-07-22 09:49:39.000000Z
Result Error: 404 Not Found
URL `/catalog/dotnet'
Name `Microsoft & .NET'
Parent URL http://manning.com/wittig/, line 29, col 2
Real URL http://manning.com/catalog/dotnet/
Check time 0.163 seconds
D/L time 0.146 seconds
Size 37.55KB
Info Redirected to `http://manning.com/catalog/dotnet/'.
235 URLs parsed.
Modified 2015-07-22 01:16:35.000000Z
Warning [http-moved-permanent] HTTP 301 (moved permanent)
encountered: you should update this link.
Result Valid: 200 OK
[...]
Depending on the number of web pages, the crawler may need some time to check all of them for broken links. At the end, it lists the broken links and gives you the chance to find and fix them.
3.2. Monitoring and debugging a virtual server
If you need to find the reason for an error or misbehavior of an application, it’s important to have access to tools that can help with monitoring and debugging. AWS provides tools that let you monitor and debug your virtual servers. One approach is to examine the virtual server’s logs.
3.2.1. Showing logs from a virtual server
If you need to find out what your virtual server was doing during and after startup, there’s a simple solution. AWS allows you to show the server’s logs with the help of the Management Console (the web interface you use to start and stop virtual servers). Follow these steps to open your virtual server’s logs:
1. Open the EC2 service from the main navigation, and select Instances from the submenu.
2. Select the running virtual server by clicking the row in the table.
3. In the Actions menu, choose Instance Settings > Get System Log.
A window opens and shows you the system logs from your virtual server that would normally be displayed on a physical monitor during startup (see figure 3.15).
Figure 3.15. Debugging a virtual server with the help of logs
This is a simple and efficient way to access your server’s system logs without a SSH connection. Note that it will take several minutes for a log message to appear in the log viewer.
3.2.2. Monitoring the load of a virtual server
AWS can help you answer another question: is your virtual server close to its maximum capacity? Follow these steps to open the server’s metrics:
1. Open the EC2 service from the main navigation and select Instances from the submenu.
2. Select the running virtual server by clicking the row in the table.
3. Select the Monitoring tab at lower right.
4. Click the Network In chart to dive into the details.
You’ll see a graph that shows the virtual server’s utilization of incoming networking traffic, similar to figure 3.16. There are metrics for CPU usage, network usage, and disk usage. Unfortunately, there is no metric for memory usage. The metrics are updated every five minutes if you use basic monitoring or every minute if you enable detailed monitoring of your virtual server. Detailed monitoring incurs a cost for some of the instance types.
Figure 3.16. Gaining insight into a virtual server’s incoming network traffic with the CloudWatch metric
Metrics and logs will help you monitor and debug your virtual servers. Both tools can help ensure that you’re providing high-quality services in a cost-efficient manner.
3.3. Shutting down a virtual server
To avoid incurring charges, you should always turn off unused virtual servers. You can use the following four actions to control a virtual server’s state:
- Start —You can always start a stopped virtual server. If you want to create a completely new server, you’ll need to launch a virtual server.
- Stop —You can always stop a running virtual server. A stopped virtual server isn’t billed and can be started later. If you’re using network-attached storage, your data persists. A stopped virtual server doesn’t incur charges, except for attached resources like network-attached storage.
- Reboot —Have you tried turning it off and on again? If you need to reboot your virtual server, this action will help. You won’t lose any data when rebooting a virtual server, and all software is still installed after a reboot.
- Terminate —Terminating a virtual server means deleting it. You can’t start a virtual server that you’ve already terminated. The virtual server is deleted, together with dependencies like network-attached storage and public and private IP addresses. A terminated virtual server doesn’t incur charges.
Warning
The difference between stopping and terminating a virtual server is important. You can start a stopped virtual server. This isn’t possible with a terminated virtual server. If you terminate a virtual server, you delete it.
Figure 3.17 illustrates the difference between stopping and terminating an instance, with the help of a flowchart.
Figure 3.17. Difference between stopping and terminating a virtual server
Stopping or terminating unused virtual servers saves money and prevents an unexpected bill from AWS. If you start a virtual server for a short-term task, always create a termination reminder. After you terminate a virtual server, it’s no longer available and eventually disappears from the list of virtual servers.
Terminate the virtual server named myserver that you started at the beginning of this chapter:
1. Open the EC2 service from the main navigation and select Instances from the submenu.
2. Select the running virtual server by clicking the row in the table.
3. In the Actions menu, choose Instance State > Terminate.
3.4. Changing the size of a virtual server
It’s always possible to change the size of a virtual server. This is an advantage of the cloud and gives you the ability to scale vertically. If you need more computing power, increase the size of the server.
In this section, you’ll learn how to change the size of a running virtual server. To begin, follow these steps to start a small virtual server:
1. Open the AWS Management Console and choose the EC2 service.
2. Start the wizard to launch a new virtual server by clicking the Launch Instance button.
3. Select Ubuntu Server 14.04 LTS (HVM) as the AMI for your virtual server.
4. Choose the instance type t2.micro.
5. Click Review and Launch to start the virtual server.
6. Check the summary for the new virtual server and click the Launch button.
7. Choose the option Choose an Existing Key Pair, select the key pair mykey, and click Launch Instances.
8. Switch to the overview of EC2 instances and wait for the new virtual server’s state to switch to Running.
You’ve started a virtual server with the instance type t2.micro. This is one of the smallest virtual servers available on AWS.
Use SSH to connect to your server, as shown in the previous section, and execute cat /proc/cpuinfo and free -m to gain information about the server’s CPU and memory. The output should look similar to this:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x416
cpu MHz : 2500.040
cache size : 25600 KB
[...]
$ free -m
total used free shared buffers cached
Mem: 992 247 744 0 8 191
-/+ buffers/cache: 48 944
Swap: 0 0 0
Your virtual server can use a single CPU core and offers 992 MB of memory.
If you need more CPUs, more memory, or more networking capacity, there are many other sizes to choose from. You can even change the virtual server’s instance family and version. To increase the size of your virtual server, you first need to stop it:
1. Open the AWS Management Console and choose the EC2 service.
2. Click Instances in the submenu to jump to an overview of your virtual servers.
3. Select your running virtual server from the list by clicking it.
4. Choose Instance State > Stop from the Actions menu.
After waiting for the virtual server to stop, you can change the instance type:
1. Choose Change Instance Type from the Actions menu under Instance Settings. As shown in figure 3.18, a dialog opens in which you can choose the new instance type for your virtual server.
Figure 3.18. Increase the size of your virtual server by selecting m3.large for Instance Type.
2. Select m3.large for Instance Type.
3. Save your changes by clicking Apply.
You’ve now changed the size of your virtual server and are ready to start it again.
Warning
Starting a virtual server with instance type m3.large incurs charges. Go to http://aws.amazon.com/ec2/pricing if you want to find out the current on-demand hourly price for an m3.large virtual server.
To do so, select your virtual server and choose Start from the Actions menu under Instance State. Your virtual server starts with more CPUs, more memory, and more networking capabilities. The public and private IP addresses have changed. Grab the new public IP address to reconnect via SSH; you’ll find it in the virtual server’s details view.
Use SSH to connect to your server, and execute cat /proc/cpuinfo and free -m to gain information about its CPU and memory. The output should look similar to this:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x415
cpu MHz : 2494.066
cache size : 25600 KB
[...]
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x415
cpu MHz : 2494.066
cache size : 25600 KB
[...]
$ free -m
total used free shared buffers cached
Mem: 7479 143 7336 0 6 49
-/+ buffers/cache: 87 7392
Swap: 0 0 0
Your virtual server can use two CPU cores and offers 7,479 MB of memory. Compare this to a single CPU core and 992 MB of memory before you increased the server’s size.
Terminate the virtual server with instance type m3.large to stop paying for it:
1. Open the EC2 service from the main navigation and select Instances from the submenu.
2. Select the running virtual server by clicking the row in the table.
3. In the Actions menu, choose Instance State > Terminate.
3.5. Starting a virtual server in another data center
AWS offers data centers all over the world. To achieve low latency for requests over the internet, it’s important to choose the closest data center for the majority of your users. Changing a data center is simple. The Management Console always shows the current data center you’re working in, on the right side of the main navigation. So far, you’ve worked in the data center N. Virginia (US) called us-east-1. To change the data center, click N. Virginia and select Sydney from the menu. Figure 3.19 shows how to jump to the data center in Sydney called ap-southeast-2.
Figure 3.19. Changing the data center in the Management Console from N. Virginia to Sydney
AWS groups its data centers into these regions:
|
|
|
You can specify the region for most AWS services. The regions are completely independent of each other; data isn’t transferred between regions. Typically, a region is a collection of three or more data centers located in the same area. Those data centers are well connected and offer the ability to build a highly available infrastructure, as you’ll discover later in this book. Some AWS services, like the content delivery network (CDN) service and the Domain Name System (DNS) service, act globally on top of these regions and even some additional data centers.
After you change to the EC2 service in the Management Console, you may wonder why no key pair is listed in the EC2 overview. You created a key pair for SSH logins in the region N. Virginia (US). But the regions are independent, so you have to create a new key pair for the Sydney region. Follow these steps (see section 1.2 if you need more details):
1. Open the EC2 service from the main navigation and select Key Pairs from the submenu.
2. Click Create Key Pair, and type in sydney as the key pair name.
3. Download and save the key pair.
4. Windows only: Open PuTTYgen and select SSH-2 RSA under Type of Key to Generate. Click Load. Select the sydney.pem file and click Open. Confirm the dialog box. Click Save Private Key.
5. Linux and OS X only: Change the access rights of the file sydney.pem by running chmod 400 sydney.pem in the console.
You’re ready to start a virtual server in the data center in Sydney. Follow these steps to do so:
1. Open the EC2 service from the main navigation and select Instances from the submenu.
2. Click Launch Instance to start a wizard that will guide you through starting a new virtual server.
3. Select the Amazon Linux AMI (HVM) machine image.
4. Choose t2.micro as the instance type, and click Review and Launch to take the shortcut for starting a new virtual server.
5. Click Edit Security Groups to configure the firewall. Change Security Group Name to webserver and Description to HTTP and SSH. Add a rule of type SSH and another of type HTTP. Allow access to SSH and HTTP from anywhere by defining 0.0.0.0/0 as the source for both rules. Your firewall configuration should look like figure 3.20. Click Review and Launch.
Figure 3.20. Configuring the firewall for a web server in Sydney
6. Click Launch and select sydney as the existing key pair with which to launch your virtual server.
7. Click View Instances to change to the overview of virtual servers, and wait for your new virtual server to start.
You’re finished! A virtual server is running in a data center in Sydney. Let’s proceed with installing a web server on it. To do so, you have to connect to your virtual server via SSH. Grab the current public IP address of your virtual server from the details page.
Open a terminal and type ssh -i $PathToKey/sydney.pem ec2-user@$PublicIp with $PathToKey replaced by the path to the key file sydney.pem you downloaded and $PublicIp replaced by the public IP address from the details of your virtual server. Answer Yes to the security alert regarding the authenticity of the new host.
After establishing a SSH session, you can install a default web server by executing sudo yum install httpd -y. To start the web server, type sudo service httpd start and press Return to execute the command. Your web browser should show a placeholder site if you open http://$PublicIp with $PublicIp replaced by the public IP address of your virtual server.
Find the sydney.ppk file you created after downloading the new key pair and open it by double-clicking. The PuTTY Pageant should appear in the task bar as an icon. Next, start PuTTY and connect to the public IP address from the details of your virtual server. Answer Yes to the security alert regarding the authenticity of the new host, and type in ubuntu as the login name. Press Enter.
Note
You’re using two different operating systems in this chapter. You started with a virtual server based on Ubuntu at the beginning of the chapter. Now you’re using Amazon Linux, a distribution based on Red Hat Enterprise Linux. That’s why you have to execute different commands to install software. Ubuntu uses apt-get, and Amazon Linux is using yum to do so.
Next, you’ll attach a fixed public IP address to the virtual server.
3.6. Allocating a public IP address
You’ve already launched some virtual servers while reading this book. Each virtual server was connected to a public IP address automatically. But every time you launched or stopped a virtual server, the public IP address changed. If you want to host an application under a fixed IP address, this won’t work. AWS offers a service called Elastic IP addresses for allocating fixed public IP addresses.
You can allocate and associate a public IP address to a virtual web server with the following steps:
1. Open the Management Console and go to the EC2 service.
2. Choose Elastic IPs from the submenu. You’ll see an overview of public IP addresses, as shown in figure 3.21.
Figure 3.21. Overview of public IP addresses connected to your account in current region
3. Allocate a public IP address by clicking Allocate New Address.
Now you can associate the public IP address with a virtual server of your choice:
1. Select your public IP address and choose Associate Address from the Actions menu. A dialog similar to figure 3.22 appears.
Figure 3.22. Associating a public IP address with your web server
2. Enter your virtual server’s instance ID in the Instance field. Your web server is the only virtual server running at the moment, so you can begin typing i- and use auto-completion to choose the server ID.
3. Click Associate to finish the process.
Your virtual server is now accessible through the public IP address you allocated at the beginning of this section. Point your browser to this IP address, and you should see the placeholder page as you did in section 3.5.
Allocating a public IP address can be useful if you have to make sure the endpoint to your application doesn’t change, even if you have to replace the virtual server behind the scenes. For example, assume that virtual server A is running and has an associated Elastic IP address. The following steps let you replace the virtual server with a new one without interruption:
1. Start a new virtual server B to replace running server A.
2. Install and start applications and all dependencies on virtual server B.
3. Disassociate the Elastic IP from virtual server A, and associate it with virtual server B.
Requests using the Elastic IP address will now be routed to virtual server B without interruption.
You can also connect multiple public IP addresses with a virtual server by using multiple network interfaces, as described in the next section. This can be useful if you need to host different applications running on the same port or if you want to use a unique fixed public IP address for different websites.
Warning
IPv4 addresses are rare. To prevent stockpiling Elastic IP addresses, AWS will charge you for Elastic IP addresses that aren’t associated with a server. You’ll clean up the allocated IP address at the end of the next section.
3.7. Adding an additional network interface to a virtual server
In addition to managing public IP addresses, you can control your virtual server’s network interfaces. It’s possible to add multiple network interfaces to a virtual server and control the private and public IP addresses associated with those network interfaces. You use an additional network interface to connect a second public IP address to your web server.
Follow these steps to create an additional networking interface for your virtual server (see figure 3.23):
Figure 3.23. Creating an additional networking interface for your virtual server
1. Open the Management Console and go to the EC2 service.
2. Select Network Interfaces from the submenu.
3. Click Create Network Interface. A dialog opens.
4. Enter 2nd interface as the description.
5. Choose your virtual server’s subnet as the subnet for the new networking interface. You can look this up in your server’s details view from the instances overview.
6. Leave Private IP Address empty.
7. Select the Security Groups that have webserver in their description.
8. Click Yes, Create.
When the new network interface’s state changes to Available, you can attach it to your virtual server. Select the new 2nd Interface network interface, and choose Attach from the menu. A dialog opens, as shown in figure 3.24. Choose the ID of the running virtual server and click Attach.
Figure 3.24. Attaching an additional networking interface to your virtual server
You’ve attached an additional networking interface to your virtual server. Next, you’ll connect an additional public IP address to the additional networking interface. To do so, note the network interface ID of the additional network interface shown in the overview, and follow these steps:
1. Open the Management Console and go to the EC2 service.
2. Choose Elastic IPs from the submenu.
3. Click Allocate New Address to allocate a new public IP address, as you did in section 3.6.
4. Choose Associate Address from the Actions menu, and link it to the additional networking interface you just created by typing in the network interface ID under Network Interface (see figure 3.25).
Figure 3.25. Associating a public IP address with the additional networking interface
Your virtual server is now reachable under two different public IP addresses. This enables you to serve two different websites, depending on the public IP address. You need to configure the web server to answer requests depending on the public IP address.
After connecting to your virtual server via SSH and insert ifconfig into the terminal, you can see your new networking interface attached to the virtual server, as shown in the following code:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 12:C7:53:81:90:86
inet addr:172.31.1.208 Bcast:172.30.0.255 Mask:255.255.255.0
inet6 addr: fe80::10c7:53ff:fe81:9086/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:62185 errors:0 dropped:0 overruns:0 frame:0
TX packets:9179 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89644521 (85.4 MiB) TX bytes:582899 (569.2 KiB)
eth1 Link encap:Ethernet HWaddr 12:77:12:53:39:7B
inet addr:172.31.4.197 Bcast:172.30.0.255 Mask:255.255.255.0
inet6 addr: fe80::1077:12ff:fe53:397b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1256 (1.2 KiB) TX bytes:1374 (1.3 KiB)
[...]
Each network interface is connected to a private and a public IP address. You’ll need to configure the web server to deliver different websites depending on the IP address. Your virtual server doesn’t know anything about its public IP address, but you can distinguish the requests based on the private IP address.
First you need two websites. Run the following commands via SSH on your virtual server in Sydney to download two simple placeholder websites:
$ sudo -s $ mkdir /var/www/html/a $ wget -P /var/www/html/a https://raw.githubusercontent.com/AWSinAction/ code/master/chapter3/a/index.html $ mkdir /var/www/html/b $ wget -P /var/www/html/b https://raw.githubusercontent.com/AWSinAction/ code/master/chapter3/b/index.html
Next you need to configure the web server to deliver the websites depending on the called IP address. To do so, add a file named a.conf under /etc/httpd/conf.d with the following content. Change the IP address from 172.31.x.x to the IP address from the ifconfig output for the networking interface eth0:
<VirtualHost 172.31.x.x:80> DocumentRoot /var/www/html/a </VirtualHost>
Repeat the same process for a configuration file named b.conf under /etc/httpd/conf.d with the following content. Change the IP address from 172.31.y.y to the IP address from the ifconfig output for the networking interface eth1:
<VirtualHost 172.31.y.y:80> DocumentRoot /var/www/html/b </VirtualHost>
To activate the new web server configuration, execute sudo service httpd restart via SSH. Change to the Elastic IP overview in the Management Console. Copy both public IP addresses and open them with your web browser. You should get the answer “Hello A!” or a “Hello B!” depending on the public IP address you’re calling. Thus you can deliver two different websites, depending on the public IP address the user is calling. Congrats—you’re finished!
It’s time to clean up your setup:
1. Terminate the virtual server.
2. Go to Networking Interfaces and select and delete the networking interface.
3. Change to Elastic IPs, and select and release the two public IP addresses by clicking Release Addresses from the Actions menu.
That’s it. Everything is cleaned up, and you’re ready for the next section.
Warning
You switched to the AWS region in Sydney earlier. Now you need to switch back to the region US East (N. Virginia). You can do so by selecting US East (N. Virginia) from the region chooser in the main navigation of the Management Console.
3.8. Optimizing costs for virtual servers
Usually you launch virtual servers on demand in the cloud to gain maximum flexibility. You can start and stop an on-demand instance whenever you like, and you’re billed for every hour the instance (virtual server) is running. If you want to save money, you have two options: spot instances or reserved instances. Both help to reduce costs but decrease your flexibility. With a spot instance, you bid for unused capacity in an AWS data center; the price is based on supply and demand. You can use reserved instances if you need a virtual server for a year or longer; you agree to pay for the given time frame and receive a discount in advance. Table 3.2 shows the differences between these options.
Table 3.2. Differences between on-demand, spot, and reserved virtual servers
|
On-demand |
Reserved |
Spot |
|
|---|---|---|---|
| Price | High | Medium | Low |
| Flexibility | High | Low | Medium |
| Reliability | Medium | High | Low |
3.8.1. Reserve virtual servers
Reserving a virtual server means to commit to using a specific virtual server in a specific data center. You have to pay for a reserved virtual server whether it’s running or not. In return, you benefit from a price reduction of up to 60%. On AWS, you can choose one of the following options if you want to reserve a virtual server:
- No Upfront, 1-year term
- Partial Upfront, 1-year or 3-year term
- All Upfront, 1-year or 3-year term
Table 3.3 shows what this means for a virtual server with 1 CPU, 3.75 GB of memory, and a 4 GB SSD called m3.medium.
Table 3.3. Potential cost savings for a virtual server (m3.medium)
|
Monthly cost |
Upfront cost |
Effective monthly cost |
Savings vs. on-demand |
|
|---|---|---|---|---|
| On-demand | 48.91 USD | 0.00 USD | 48.91 USD | |
| No Upfront, 1-year term | 35.04 USD | 0.00 USD | 35.04 USD | 28% |
| Partial Upfront, 1-year term | 12.41 USD | 211.00 USD | 29.99 USD | 39% |
| All Upfront, 1-year term | 0.00 USD | 353.00 USD | 29.42 USD | 40% |
| Partial Upfront, 3-year term | 10.95 USD | 337.00 USD | 20.31 USD | 58% |
| All Upfront, 3-year term | 0.00 USD | 687.00 USD | 19.08 USD | 61% |
You can trade cost reductions against flexibility by reserving virtual servers on AWS. But there’s more. If you own a reservation for a virtual server (a reserved instance), the capacity for this virtual server is reserved for you in the public cloud. Why is this important? Suppose demand increases for virtual servers in a data center, perhaps because another data center broke down and many AWS customers have to launch new virtual servers to replace their broken ones. In this rare case, the orders for on-demand virtual servers will pile up, and it may become nearly impossible to start a new virtual server. If you plan to build a highly available setup across multiple data centers, you should also think about reserving the minimum capacity you’ll need to keep your applications running. We recommend that you start with on-demand servers and switch to a mix of on-demand and reserved servers later.
3.8.2. Bidding on unused virtual servers
In addition to reserved virtual servers, there’s another option for reducing costs: spot instances. With a spot instance, you bid for unused capacity in the AWS cloud. A spot market is a market where standardized products are traded for immediate delivery. The price of the products on the market depend on supply and demand. On the AWS spot market, the traded products are virtual servers, and they’re delivered by starting a virtual server.
Figure 3.26 shows the price chart for a specific instance type for a virtual server. If the current spot price is lower than your maximum price for a specific virtual server in a specific data center, your spot request will be fulfilled, and a virtual server will start. If the current spot price exceeds your bid, your virtual server will be terminated (not stopped) by AWS after two minutes.
Figure 3.26. Functionality of the spot market for virtual servers
The spot price can be more or less flexible depending on the size of the virtual servers and the data center. We’ve seen a spot price of 10% of the on-demand price and even a spot price greater than the on-demand price. As soon as the spot price exceeds your bid, your server will be terminated within two minutes. You shouldn’t use spot instances for tasks like web or mail servers, but you can use them to run asynchronous tasks like analyzing data or encoding media assets. You can even use a spot instance to check for broken links on your website, as you did in section 3.1, because this isn’t a time-critical task.
Let’s start a new virtual server that uses the price reductions of the spot market. First you have to place your order on the spot market; figure 3.27 shows the starting point for requesting virtual servers. You get there by choosing the EC2 service from the main navigation and selecting Spot Requests from the submenu. Click to open the Pricing History, where you can see the prices for virtual servers; historical prices are available for the different server sizes and different data centers.
Figure 3.27. Requesting a spot instance
In section 3.1, you started a virtual server. Requesting a spot instance is pretty much the same. Start the wizard by clicking one of the buttons labeled Request Spot Instances. Select Ubuntu Server 14.04 LTS (HVM) as the OS of your virtual server.
You’ve also seen the step shown in figure 3.28, where you choose the size for your virtual server. You can’t start a spot instance with an instance type from the t2 family, so instance types like t2.micro are disabled.
Figure 3.28. When you’re choosing the size of a spot server, AWS greys out instance types that aren’t available.
Warning
Starting a virtual server with instance type m3.medium via spot request incurs charges. The maximum price (bid) is $0.07 per hour in the following example.
Choose the smallest available virtual server class, m3.medium, and click Next: Configure Instance Details.
The next step, as shown in figure 3.29, is to configure the details of your virtual server and the spot request. Set the following parameters:
Figure 3.29. Choosing details for the virtual server and specifying a maximum hourly price
1. Set Number of Instances for the spot request to 1.
2. Choose 0.070 as the Maximum Price for the virtual server. This is the on-demand price for the server size.
3. Select the default Network, with IP address range 172.30.0.0/16.
4. Look at the Current Price section and search for the lowest price. Choose the Subnet with the same description.
Click Review and Launch to complete the wizard. You’ll see a summary of all the settings you made. Click Launch and choose your key pair with the name mykey to request the spot instance.
After you finish the wizard, your request for a virtual server is placed on the market. Clicking View Spot Requests will direct you to the overview of spot requests from which you started. You should see a spot request as shown in figure 3.30. It may take several minutes for your request to be fulfilled. Look at the Status of your request for a virtual server: because the spot market is unpredictable, it’s possible for a request to fail. If this happens, repeat the process to create another request, and choose another subnet in which to launch the virtual server.
Figure 3.30. Waiting for the spot request to be fulfilled and the virtual server to start
When the state of your requests flips to Fulfilled, a virtual server is started. You can look at it after switching to Instances via the submenu; you’ll find a running or starting instance listed in the overview of virtual servers. You’ve successfully started a virtual server that is billed as spot instance!
Terminate the virtual server with instance type m3.medium to stop paying for it:
1. Open the EC2 service from the main navigation and select Instances from the submenu.
2. Select the running virtual server by clicking the row in the table.
3. In the Actions menu, choose Instance State > Terminate.
4. Switch to the Spot Requests overview. Double-check whether your spot request was canceled. If not, select the spot request and click Cancel.
3.9. Summary
- You can choose an OS when starting a virtual server.
- Using logs and metrics can help you to monitor and debug a virtual server.
- Changing the size of your virtual server gives you the flexibility to change the number of CPUs, memory, and storage.
- You can start a virtual server in different regions, consisting of multiple data centers, all over the world.
- Allocating and associating a public IP address to your virtual server gives you the flexibility to replace a virtual server without changing the public IP address.
- You can save on costs by reserving virtual servers or bidding for unused capacity on the virtual server spot market.