AWS Certified Solutions Architect Study Guide. David Higby Clinton

Читать онлайн.
Название AWS Certified Solutions Architect Study Guide
Автор произведения David Higby Clinton
Жанр Зарубежная компьютерная литература
Серия
Издательство Зарубежная компьютерная литература
Год выпуска 0
isbn 9781119713104



Скачать книгу

You'll generally want to launch an EC2 instance in the region that's physically closest to the majority of your customers or, if you're working with data that's subject to legal restrictions, within a jurisdiction that meets your compliance needs.

      EC2 resources can be managed only when you're “located within” their region. You set the active region in the console through the drop‐down menu at the top of the page and through default configuration values in the AWS CLI or your SDK. You can update your CLI configuration by running aws configure.

      Bear in mind that the costs and even functionality of services and features might vary between regions. It's always a good idea to consult the most up‐to‐date official documentation.

      VPCs

Schematic illustration of a multi-VPC infrastructure for a development environment.

      Adding a simple VPC that doesn't incorporate a network address translation (NAT) gateway (docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html) or VPN access (docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) won't cost you anything. You'll learn much more about all this in Chapter 4, “Amazon Virtual Private Cloud.”

      Tenancy

      When launching an EC2 instance, you'll have the opportunity to choose a tenancy model. The default setting is shared tenancy, where your instance will run as a virtual machine on a physical server that's concurrently hosting other instances. Those other instances might well be owned and operated by other AWS customers, although the possibility of any kind of insecure interaction between instances is remote.

      Naturally, dedicated instances and dedicated hosts will cost you more than instances using shared tenancy.

      Launch an EC2 Linux Instance and Log in Using SSH

      1 From the EC2 Dashboard, click to launch a new instance and select a Linux AMI and instance type. Remember, the t2.micro is Free Tier–eligible if your AWS account is still within its first year.

      2 Explore the Configure Instance Details, Add Storage, and Add Tags pages—although the default settings should work fine.

      3 On the Configure Security Group page, make sure there's a rule permitting incoming SSH (port 22) traffic. It should be there by default.

      4 Before letting you launch the instance, AWS will require you to select—or create—a key pair. Follow the instructions.

      5 Once the instance is launched, you can return to the Instances Dashboard to wait a minute or two until everything is running properly.

      6 Click the Actions pull‐down and then the Connect item for instructions on how to connect to the instance from your local machine. Then connect and take a look at your virtual cloud server.

      Assess the Free Capacity of a Running Instance and Change Its Instance Type

      1 With an instance running, open the Instances Dashboard in the EC2 console. Select the instance you're interested in and click the Monitoring tab in the bottom half of the screen. That's a good place to see what percentage of compute and network resources you've been using over the past hours or weeks.Now pretend that your instance is nearly maxed out and change the instance type as follows.

      2 Stop the instance. (Remember, your public IP address might be different when you start up again.)

      3 From the Actions drop‐down, click Instance Settings and then Change Instance Type. Select a new type.

      4 Restart the instance and confirm that it's running properly.

      Configuring Instance Behavior

      You can optionally tell EC2 to execute commands on your instance as it boots by pointing to user data in your instance configuration (this is sometimes known as bootstrapping). Whether you specify the data during the console configuration process or by using the ‐‐user‐data value with the AWS CLI, you can have script files bring your instance to any desired state.

      User data can consist of a few simple commands to install a web server and populate its web root, or it can be a sophisticated script setting up the instance as a working node within a Puppet Enterprise–driven platform.

      Placement Groups

      By default AWS will attempt to spread your instances across their infrastructure to create a profile that will be optimal for most use cases. But the specific demands of your operation might require a different setup. EC2 placement groups give you the power to define nonstandard profiles to better meet your needs. There are, at this time, three kinds of placement groups:

       Cluster groups launch each associated instance into a single availability zone within close physical proximity to each other. This provides low‐latency network interconnectivity and can be useful for high‐performance computing (HPC) applications, for instance.

       Spread groups separate instances physically across distinct hardware racks and even availability zones to reduce the risk of failure‐related data or service loss. Such a setup can be valuable when you're running hosts that can't tolerate multiple concurrent failures. If you're familiar with VMware's Distributed Resource Scheduler (DRS), this is similar to that.

       Partition groups let you associate some instances with each other, placing them in a single “partition.” But the instances within that single partition can be kept physically separated from instances within other partitions. This differs from spread groups where no two instances will ever share physical hardware.

      Instance Pricing

      You can purchase the use of EC2 instances through one of three models.

      For