concept instance in category aws

This is an excerpt from Manning's book AWS Security MEAP V03. Login to get full access to this book.

Now back to VPCs. A VPC, Virtual Private Cloud, is a private network you can create that exists within a region. A VPC allows you to create networked connections between all the AWS resources within the VPC, while blocking access from everything outside the VPC. There are various tools used to define what connections are permitted in and out of a VPC and between resources within the VPC. The primary tool is Security Groups. A security group lets you define a set of inbound and outbound rules for allowed connections. All other connections not specified will be denied. You can then apply those security group rules to an EC2 instance in a VPC by associating the instance with the security group. The last fundamental resource in a VPC is the Subnet. Subnets are the component sub-networks that make up a VPC. An individual subnet claims a block of the IP range specified in the VPC, and exists within an Availability Zone. EC2 Instances and other resources cannot be put directly into a VPC, rather they are added to one of the subnets within a VPC. There are two different types of Subnets, public and private. Public subnets have routes to an Internet Gateway, which means that they can communicate with the public internet outside of the VPC. Private subnets have no such route to the public internet. By default, two subnets (public or private) in the same VPC cannot communicate with each other, but you can create routes to link any two subnets in the same VPC together. See figure 1.5 which shows a basic configuration of these resources.

A third attack covered in this chapter is getting SSH access to a web server. When you run a website you generally open up traffic to the public internet on purpose. But when you do so, you want to make sure that you haven't exposed anything private that might be running on the same server. Many times an EC2 instance is running a web server, and the operator opens up all network traffic to the instance. This allows everyone to view the website, but it also allows everyone to send other kinds of traffic as well, like SSH connections. If you run SSH on the default port, use a default user for the operating system, and use a password for authentication rather than an SSH key, then it is only a matter of time before an attacker gains access to the server. In this chapter we'll see how you can easily create rules that allow public access to your website, but not allow other kinds of traffic like SSH.

We mentioned in 4.1 that instances are attached to subnets. This is done by first attaching an elastic network interface (ENI) to the instance, and then attaching that ENI to the subnet. The process of creating and attaching the ENI is abstracted in the process of creating an instance. When you create an instance through the AWS CLI or Console, AWS will automatically create the ENI, attach it to the new instance, and attach it to the subnet you specify. So what exactly is an elastic network interface? Elastic network interfaces are the virtual equivalent of a NIC or network card on a physical machine. These ENIs are the connection between networked resources like EC2 instances, and your virtual network. In fact, you can attach additional ENIs to your instances, and those ENIs can be in two different subnets. This creates what are called Dual-Homed instances, and can be visualized in figure 4.4.

Figure 4.4 Dual-homed instances belong to multiple subnets

In practice, you generally do not need to worry about creating ENIs. Unless you are doing some more advanced networking, ENIs will be created for you with standard settings. For example, when you create an EC2 instance, AWS automatically creates an ENI for the instance and names it eth0. This is the primary network interface for the instance. The primary network interface will be associated with the subnet that you chose when creating the EC2 instance.

Elastic Network Interfaces are also the mechanism by which IP addresses are associated with networked resources. You can associate additional IP address with a resource by attaching another elastic IP address to the ENI. The IP addresses are actually their own resource called Elastic IPs, or EIPs. Like with ENIs, you generally don't need to create Elastic IPs. When you create an EC2 instance, AWS automatically creates an EIP that is the private IP address for the instance. The EIP is attached to the ENI, which is attached to the instance. The difference with EIPs is that you do not have access to the ones created by AWS. You cannot disassociate the EIP from the network interface and reuse it somewhere else. If you terminate the instance, the EIP will be released. This is important if you want to keep a public IP address, even when an instance is terminated. To do that you would create a new Elastic IP manually, and then attach that EIP to the elastic network interface on the desired instance. Then you have the flexibility of moving the EIP around wherever you choose.

Let's go back to the network that we've been working on throughout this chapter. We want to allow public access to our instance in the public subnet. The routes and networking resources are all there, but the default security group is preventing us from connecting. One thing we could do is update the default security group to allow inbound access. However this is not ideal because the default security group is also being used by the instance in the private subnet. We don't want to modify the existing firewall rules on the instance in the private subnet. Instead we'll create a new security group and apply it to the instance in the public subnet.

$ aws ec2 create-security-group \
--vpc-id vpc-1234 \ #A
--group-name "PublicAccessSecurityGroup"
$ aws ec2 modify-instance-attribute \
--instance-id i-1234 \ #B
--groups sg-1234 sg-5678 #C

Now both the new security group and the default security group are attached to the instance. An instance can have up to five security groups. The next step is to add an inbound security group rule that allows SSH access from the public internet. The rule was shown in Table 4.5, and is repeated here.

This is an excerpt from Manning's book AWS CloudFormation in Action MEAP V02. Login to get full access to this book.

Before Infrastructure as Code (IaC) emerged as the important category of tool it is today, there was configuration management. You will see from our brief discussion of each tool below that Ansible, Puppet, SaltStack, and Chef are considered to be configuration management (CM) tools and were originally created to install and manage software on existing server instances (e.g., installation of packages, starting of services, installing and executing scripts or config files on the instance). Their functions can automate the perform of these activities against one or many environments, without the user needing to specify exact commands. They have eliminated ad-hoc scripting for many applications. Because of their power, they’ve become popular—and they’ve added features that cause them to overlap with the newer IaC tools.

Listing 2.10 Creating an instance

{
    "Resources": {
    "MyServer": {
        "Type": "AWS::EC2::Instance",    #A
        "Properties": {
            "InstanceType": "t2.micro",    #B
            "ImageId": "ami-02ccb28830b645a41"    #C
                      }
                }
                }
}

The Auto Scaling group continues to maintain a fixed number of instances by terminating an unhealthy instance and launching a new one to replace it.

After an instance is fully configured and passes the initial health checks, it is considered healthy by Amazon EC2 Auto Scaling and enters the InService state. Auto Scaling periodically performs health checks on the instances in your Auto Scaling group and identifies any instances that are unhealthy.

Auto Scaling health checks use EC2 status checks to determine the health status of an instance. If the instance is in any state other than running or if the system status is impaired, Auto Scaling considers the instance to be unhealthy and launches a replacement instance. This includes when the instance has any of the following states:

This is an excerpt from Manning's book Amazon Web Services in Action, Second Edition. Login to get full access to this book.

Now you’ll see the screen shown in figure 2.11. Select Instances under EC2 on the left to see your virtual machines. By clicking the arrow icon in the Go column, you can easily jump to the details of a single virtual machine.

$ aws ec2 describe-instances --filters "Name=instance-type,Values=t2.micro"
{
  "Reservations": []               #1
}

A layer belongs to a stack. A layer represents an application; you could also call it a service. AWS OpsWorks Stacks offers predefined layers for standard web applications like PHP and Java, but you’re free to use a custom stack for any application you can think of. Layers are responsible for configuring and deploying software to virtual machines. You can add one or multiple VMs to a layer; in this context the VMs are called instances.

An instance is the representation for a virtual machine. You can launch one or multiple instances for each layer, using different versions of Amazon Linux and Ubuntu or a custom AMI as a basis for the instances. You can specify rules for launching and terminating instances based on load or timeframes for scaling.

5.  Add an instance for each layer.

4.  Click Add instance.

Figure 5.16. Adding a new instance to the Node.js layer

You’ve added an instance to the Node.js App Server layer. Repeat these steps for the irc-server layer as well.

The overview of instances should be similar to figure 5.17. To start them, click Start for both instances. It will take some time for the virtual machines to boot and the deployment to run, so this is a good time to get some coffee or tea.

Figure 5.17. Starting the instances for the IRC web client and server

This is an excerpt from Manning's book Learn Amazon Web Services in a Month of Lunches. Login to get full access to this book.

The EBS volumes act as data volumes (like hard drives) for an instance (chapter 2).

Figure 2.4. EC2 Instance details page, which displays important information—including the instance’s public IP address—and links to instance-related resources

So where are we? In the early chapters, we played with the basics: EC2, S3, RDS, IAM, Route 53, CloudWatch, tags, and the AWS CLI. That was great. Then I introduced you to the wonders of elasticity and scalability and touched on making instances more highly available through the use of AWS availability zones.