Choosing an AMI

Decide on the AMI that you want to use. An AMI provides the information required to launch an instance. An AMI includes the following:

• A template for the root volume for the instance (perhaps an operating system, an application server, and applications)
• Launch permissions that control which AWS accounts can use the AMI to launch instances
• A block device mapping that specifies the volumes to attach to the instance when it is launched

You can obtain AMIs from one of four places:

• Provided by AWS
• AWS Marketplace
• You can create and manage your own AMIs.
• A shared AMI

With AMIs provided by AWS, you have a variety of choices of either Linux or Windows operating systems. With the Windows AMI, the cost of the operating system is included in the hourly charge for the instance.

AWS Marketplace offers a wide variety of AMIs from a number of third parties. You can choose AMIs in categories such as software infrastructure, developer tools, or business software from a number of vendors, including Juniper, Bitnami, and SAP.

AWS also gives you the ability to create and manage your own AMIs. For example, you can take an existing AWS-provided Linux AMI, modify it to meet your needs, and save that AMI. You can then use that AMI as the basis for compute infrastructure. This is the route most companies take when choosing an AMI.

A shared AMI is an AMI that a developer created and made available for other developers to use. You can create your own AMIs and share them with others. Note that you use a shared AMI at your own risk—Amazon can’t vouch for the integrity or security of AMIs shared by other Amazon EC2 users. Therefore, you should treat shared AMIs as you would any foreign code that you might consider deploying in your own datacenter and perform the appropriate due diligence. Only use an AMI from a trusted source.

Choosing an Instance Type

After choosing an AMI, you then need to choose an instance type. The instance type that you specify determines the hardware of the host computer used for your instance. Each instance type offers different compute, memory, and storage capabilities. Instance types are grouped in instance families based on these capabilities.

Amazon EC2 provides each instance with a consistent and predictable amount of CPU capacity, regardless of its underlying hardware. Amazon EC2 dedicates some resources of the host computer (for example, CPU, memory, and instance storage) to a particular instance. Amazon EC2 shares other resources of the host computer (such as the network and the disk subsystem) among instances.

The choice of the instance type affects the following attributes:

• CPU specialization
• Virtualization types
• Network features
• Storage features
• Instance limits

With CPU specialization, CPUs can be classified as being optimized in one of the following ways:

• General Purpose (T2, M4)
• Compute-Optimized (C3, C4)
• Memory-Optimized (X1, R3, R4)
• Storage-Optimized (I3, D2)
• Accelerated Computing (P2, G2, F1)

As AWS continues to introduce new instance families and new generations of instance families, the most up-to-date information can be found in the Amazon EC2 User Guide.

Each instance type supports one or both of the following types of virtualization: paravirtual or Hardware Virtual Machine (HVM). The virtualization type of your instance is determined by the AMI that you use to launch it.

For best performance, you may want to use an HVM AMI. In addition, HVM AMIs are required for enhanced networking. HVM virtualization uses hardware-assisted technology provided by the AWS platform. With HVM virtualization, the guest Virtual Machine (VM) runs as if it were on a native hardware platform, except that it still uses paravirtual network and storage drivers for improved performance.

Network features are also influenced by the instance type you choose. Network speed is primarily a function of the size of the instance. Larger instances provide greater network speed than smaller instances in the same family. Certain instance types offer support for enhanced networking. Enhanced networking uses Single Root I/O Virtualization (SR-IOV) to provide high-performance networking capabilities. There are also instance families that offer 10G connectivity. Support of jumbo frames (frames greater than 1,500 Maximum Transmission Unit [MTU] in size) is also dependent on the instance type chosen. More information about networking on AWS can be found in Chapter 5, “Networking.”

Storage features are also influenced by the instance type you choose. Some instance types support Amazon EBS volumes and instance store volumes, while other instance types support only Amazon EBS volumes. Some instances that support instance store volumes use SSDs to deliver very high random I/O performance. To obtain additional, dedicated capacity for Amazon EBS I/O, you can launch some instance types as Amazon EBS-optimized instances. Some instance types are Amazon EBS-optimized by default. Refer to Chapter 6, “Storage,” for a more comprehensive look at storage on AWS.

There is a limit on the total number of instances that you can launch in an AWS Region, and there are additional limits on some instance types. You can use the Amazon EC2 Service Limits page in the Amazon EC2 console to view the current limits for resources provided by Amazon EC2 and Amazon VPC on a per-region basis.

Other Configuration Details

Once you choose the AMI and the instance type, there are a number of other configuration details that you need to provide. These details include the following:

• Number of instances
• Purchasing options
• Amazon VPC to be used
• Subnet to be located in
• Public IP address
• AWS Identity and Access Management (IAM) role
• Shutdown behavior
• Monitoring
• Tenancy
• User data
• Storage type and volume
• Tagging
• Security groups
• Public/private key

You are able spin up as many instances as you want simultaneously, subject to the service limits mentioned.

AWS purchasing options allow you to request Spot Pricing. If you request Spot Pricing, you are sent to an additional screen where you can configure Availability Zone, maximum price, launch group (if applicable), and whether this is a persistent request. If it’s not a persistent request, you specify what time and date the request is valid to and from.

All Amazon EC2 instances need to be spun up in an Amazon VPC. You can choose the Amazon VPC in which the instance is spun up. If you have not already created an Amazon VPC, then the instance will be spun up in the default Amazon VPC. Similarly, because Amazon EC2 is an Availability Zone-based service, you need to choose the Availability Zone in which to locate the Amazon EC2 instance. The private IP addresses assigned to the Amazon EC2 instance is determined by what Amazon VPC and what subnet you locate the instance in.

You can choose to assign a public IP address to your instance. Doing so will potentially make this Amazon EC2 instance accessible from the Internet (the other requirement is that the Amazon VPC containing the Amazon EC2 instance needs to have an Internet gateway). Public IP addresses are associated with specific interfaces, so if you have multiple interfaces on your Amazon EC2 instance, you can have multiple public IP addresses. The public IP address remains attached to the interface as long as the Amazon EC2 instance is running. If the Amazon EC2 instance is rebooted, it keeps the public IP address. If the Amazon EC2 instance is turned off, the public IP address is removed. If the Amazon EC2 instance is turned back on, a new public IP address is assigned.

Both IPv4 and IPv6 are supported in Amazon EC2.

IAM roles are discussed in more details in Chapter 3, “Security and AWS Identity and Access Management (IAM).” You can assign an IAM role to an Amazon EC2 instance as part of a configuration. This IAM role would give the Amazon EC2 instance permission to access other AWS Cloud services (such as when the Amazon EC2 instance needs to access an Amazon S3 bucket).

Shutdown behavior controls the conduct of the Amazon EC2 instance after it receives a shutdown command. Amazon EC2 instances that have instance storage can only be in a running state or be terminated—they cannot be stopped. Amazon EC2 instances that have Amazon EBS storage can be running, stopped, or terminated. The default behavior of these instances is to delete the attached storage after the instance is terminated.

Termination protection, when enabled, prevents the accidental termination of instances. After termination protection is enabled, you must disable it if you wish to terminate an instance. This gives you an extra level of protection against accidental termination.

Amazon EC2’s default mode is shared tenancy. The other choices are to run as a dedicated host or a dedicated instance. Dedicated hosts allow you to use your existing per-socket, per-core, or per-VM software licenses. Rebooting a dedicated host will reboot the instance on the same physical AWS infrastructure. Dedicated instances are Amazon EC2 instances that run in an Amazon VPC on hardware that is dedicated to a single customer. Your dedicated instances are physically isolated at the host hardware level from instances that belong to other AWS accounts.

User data is that which you can pass to the instance both upon initial boot up and, if desired, in subsequent boots. User data allows you to specify parameters for configuring your instance or attach a simple script. You can also use this data to build more generic AMIs that can be modified by configuration files supplied at launch time. For example, you can change a basic AWS Linux AMI to become a web server using user data. User data is limited to 16 KB, but it can have links to locations (like an Amazon S3 bucket) to load larger files.

Different instance types will support different storage options. The three major types of storage for Amazon EC2 are instance storage, Amazon EBS, and Amazon Elastic File System (Amazon EFS).

Instance storage is where the disks are physically attached to the host computer. Instance storage provides temporary block-level storage for instances. The data on an instance store volume persists only during the life of the associated instance; if you stop or terminate an instance, any data on instance store volumes is lost. Note that not all Amazon EC2 instance types support instance storage. Instance storage cannot be modified in terms of the amount of storage. Pricing for instance storage is included in the pricing for the Amazon EC2 instance.

Amazon EBS provides block-level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are highly available and reliable storage volumes that can be attached to any running instance that is in the same Availability Zone. Amazon EBS volumes that are attached to an Amazon EC2 instance are exposed as storage volumes that persist independently from the life of the instance. Amazon EBS volumes can be in a variety of media (magnetic or SSD), can be in a variety of sizes, can be encrypted, and have specified I/O speeds (with Provisioned IOPS). Because Amazon EBS exists as a separate service, it is priced independently of the Amazon EC2 instance to which it is attached.

Amazon EBS is recommended when data must be quickly accessible and requires long-term persistence. Amazon EBS volumes are particularly well-suited for use as the primary storage for file systems, databases, or for any applications that require fine granular updates and access to raw, unformatted, block-level storage. Amazon EBS is well suited to both database-style applications that rely on random reads and writes and to throughput-intensive applications that perform long, continuous reads and writes.

Another key difference between instance store-backed Amazon EC2 instances and Amazon EBS-backed Amazon EC2 instances is the ability to stop and start the Amazon EC2 instance. With Amazon EBS-backed Amazon EC2 instances, you can stop and start the Amazon EC2 instance. With instance store-backed Amazon EC2 instances, you can only delete the instance. Figure 4.1 illustrates the differences between an instance store-backed Amazon EC2 instance and an Amazon EBS-backed Amazon EC2 instance.

Amazon EFS provides scalable file storage for use with Amazon EC2. You can create an Amazon EFS file system and configure your instances to mount the file system. You can use an Amazon EFS file system as a common data source for workloads and applications running on multiple instances. Because Amazon EFS exists as a separate service, it is priced independently of the Amazon EC2 instance to which it is attached. It is important to note that Amazon EFS can only be used with Linux-based Amazon EC2 instances.

Tags enable you to categorize your Amazon EC2 instances in different ways (for example, by purpose, owner, or environment). This is useful when you have many resources of the same type—you can quickly identify a specific resource based on the tags you have assigned to it. Each tag consists of a key and a value, both of which you define. You can work with tags using the AWS Management Console, the AWS Command Line Interface (AWS CLI), and the Amazon EC2 Application Programming Interface (API).

Security groups are applied to the interface of an Amazon EC2 instance. Security groups allow access via port, protocol, and source. A source can be an IP address, a range of IP addresses, or another security group. You cannot set up a security group with a deny rule. Security groups control both inbound and outbound access, but the recommended practice is to use them mostly to control inbound access. By default, security groups allow all outbound access. In addition, security groups are stateful; if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. You must attach a security group with either Secure Shell (SSH) or Remote Desktop Protocol (RDP) access if you intend to be able to log in to the guest operating system.

In order to protect your Amazon EC2 instance, Amazon EC2 uses public-key cryptography to encrypt and decrypt login information. To log in to your instance, you must create a key pair, specify the name of the key pair when you launch the instance, and provide the private key when you connect to the instance. Linux instances have no password, and you use a key pair to log in using SSH. With Windows instances, you use a key pair to obtain the administrator password and then log in using RDP. You can use Amazon EC2 to create your key pair, or you could use a third-party tool and then import the public key to Amazon EC2.

Snapshots

You can back up the data on your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. This minimizes the time required to create the snapshot and saves on storage costs. When you delete a snapshot, only the data unique to that snapshot is removed. Active snapshots contain all of the information needed to restore your data (from the time the snapshot was taken) to a new Amazon EBS volume.

Monitoring the Status of Your AWS Cloud Services

AWS provides two dashboards that show the status of AWS Cloud services. The first is the AWS Service Health Dashboard. The dashboard displays service health across the entire AWS infrastructure, and you can personalize it to track your AWS Cloud services. With the AWS Service Health Dashboard, you can view the service health for all services across all regions (with the exception of the AWS GovCloud [US] Region and China [Beijing] Region). You are also able to subscribe to RSS feeds for chosen services across regions. In addition, you can view past system statuses for all services in all regions (again with the exception of the AWS GovCloud [US] Region and China [Beijing] Region).

The second dashboard is the AWS Personal Health Dashboard. The AWS Personal Health Dashboard provides information about AWS health events that can affect your account. The information is presented in two ways: a dashboard that shows recent and upcoming events organized by category and a full event log that shows all events from the past 90 days. AWS Personal Health Dashboard uses the Health API, which you can use to create your own health dashboards or feed into any current management systems you may have.

Monitoring with Amazon CloudWatch

Amazon CloudWatch monitoring is turned on by default for Amazon EC2 instances. Basic monitoring, which collects metrics every five minutes, is provided by default. You can enable detailed metrics that would collect metrics every minute. Amazon CloudWatch monitors the following metrics for Amazon EC2:

• CPU utilization
• Disk reads
• Disk writes
• Network in
• Network out
• Instance status check
• System status check
• CPU credit usage (T2 instances only)
• CPU credit balance (T2 instances only)

You can view Amazon CloudWatch metrics based on a particular instance, a particular image, membership in an Auto Scaling group, or as an aggregate. Amazon CloudWatch can be used to trigger an alarm that can stop, terminate, reboot, or recover an Amazon EC2 instance.

Using AWS CloudTrail

You can use AWS CloudTrail to get a history of AWS API calls and related events for your account. This includes calls made using the AWS Management Console, AWS Software Development Kits (SDKs), command-line tools, and higher-level AWS Cloud services. When AWS CloudTrail logging is enabled, calls made to Amazon EC2 are tracked in log files, along with any other AWS Cloud service records. AWS CloudTrail determines when to create and write to a new file based on a specified time period and file size. All of the Amazon EC2 actions are logged. Every log entry contains information about who generated the request. The user identity information in the log helps you determine whether the request was made with root or IAM user credentials, with temporary security credentials for a role or federated user, or by another AWS Cloud service.

Amazon EC2 Systems Manager

Amazon EC2 Systems Manager is a management service that helps you automatically collect software inventory, apply operating system patches, create system images, and configure Windows and Linux operating systems. Amazon EC2 Systems Manager can be used for both Amazon EC2 instances and for compute instances located in your own datacenters. These capabilities help you define and track system configurations, prevent drift, and maintain software compliance of your Amazon EC2 and on-premises configurations.

IP Addresses

When an Amazon EC2 instance is spun up, a private IP address is assigned to the interface of that Amazon EC2 instance. What private IP address is used for this assignment is determined by what Amazon VPC and what subnet the Amazon EC2 instance is spun up in. The private IP address will be assigned from that subnet block. That private IP address remains assigned to that interface, and it is only released once the Amazon EC2 instance is deleted. Stopping the instance will have no effect on the private IP address. Public and Elastic IP addresses behave differently. Both are also assigned to an interface and can be assigned to only one interface (though an interface can have multiple public and Elastic IP addresses assigned to it). When an Amazon EC2 instance with a public IP address assigned to it is deleted, the public IP is returned to AWS so it can be reassigned to another Amazon EC2 instance (most likely in another AWS account). In contrast, when an Amazon EC2 instance with an Elastic IP address is deleted, the Elastic IP address is not returned to AWS; it is kept by the account, available for reassignment within that particular AWS account.

Purchasing Options

There are a number of options for purchasing Amazon EC2 instances: On-Demand, Reserved, or Spot. On-Demand is straightforward—you pay for the Amazon EC2 instance as you use it. There are no up-front costs or commitments, the minimum billing increment is one hour, and you do not pay for Amazon EC2 instances that are stopped.

Reserved instances provide you with a significant discount compared to On-Demand instance pricing. Reserved instances are not physical instances; they are a billing discount applied to the use of On-Demand instances in your account. With Reserved instances, you make a commitment for a specific family of instances in a specific region or Availability Zone. You can pay for Reserved instances monthly (like On-Demand), or you can prepay the full or partial amount.

Spot instances enable you to bid on unused Amazon EC2 instances, which can lower your Amazon EC2 costs significantly. The hourly price for a Spot instance (of each instance type in each Availability Zone) is set by Amazon EC2, and it fluctuates depending on the supply of and demand for Spot instances. Your Spot instance runs whenever your bid exceeds the current market price. Spot instances are a cost-effective choice if you can be flexible about when your applications run and if your applications can be interrupted.

Estimating Costs

AWS provides two tools for estimating costs: the AWS Simple Monthly Calculator and the AWS Total Cost of Ownership (TCO) Calculator. The AWS Simple Monthly Calculator incorporates a wide array of pricing calculations across all AWS Cloud services in all AWS Regions. It also shows the breakdown of features for each service in each region. The AWS Simple Monthly Calculator has a mechanism to select a service in a particular region and add it to the total bill.

The AWS TCO Calculator allows you to estimate the cost savings when using AWS and provides a detailed set of reports that can be used in executive presentations. The AWS TCO Calculator also gives you the option to modify assumptions that best meet your business needs.

Tracking Costs

AWS provides AWS Trusted Advisor and My Billing Dashboard for managing and tracking costs. The tools can be found in the AWS Management Console. AWS Trusted Advisor gives you recommendations on how to potentially reduce your spending with AWS. The My Billing Dashboard is specifically dedicated to your charges and bills. With My Billing Dashboard, you can view and download bills, explore your bills (graph, visualize, and analyze), create budgets, and receive notifications based on those budgets. You can also create Cost Allocation Tags, which allow you to associate costs with resources that you create.

Creating Your Own AMIs

As discussed in the implementation section, you can use your own AMIs when choosing an AMI. The process of creating an AMI is different depending on whether the AMI you are creating is an instance store-backed AMI or if it is an Amazon EBS-backed AMI.

To create an instance store-backed AMI, first launch an instance from an AMI that is similar to the AMI that you would like to create. You can connect to your instance and customize it. When the instance is set up the way you want it, you can bundle it. It takes several minutes for the bundling process to complete. After the process completes, you have a bundle, which consists of an image manifest (image.manifest.xml) and files (image.part.xx) that contain a template for the root volume. Upload the bundle to your Amazon S3 bucket and then register your AMI.

To create an Amazon EBS-backed AMI, first launch an instance from an AMI that is similar to the AMI that you would like to create. You can connect to your instance and customize it. After the instance is configured correctly, stop the instance (stopping the instance ensures data integrity of the instance; a snapshot will be taken of the instance). Next create the image. When you create an Amazon EBS-backed AMI, AWS automatically registers it for you.

Once you have created an AMI, you can control who has access to it. You can share the AMI among AWS accounts, and you can copy the AMI to other AWS Regions. Note that if the AMI is encrypted, you are not able to share it.

Placement Groups

A placement group is a logical grouping of instances in a single Availability Zone. Placement groups are recommended for applications that benefit from low network latency, high network throughput, or both. High Performance Computing (HPC) is an example of an application that would potentially benefit from being in a placement group. Because all instances are within a single Availability Zone, Amazon EC2 instances in the same placement group cannot, by definition, be either in different Availability Zones or in different regions. Amazon EC2 instances that are in the same placement group communicate with each other via either the private IPv4 address or the IPv6 address.

Controlling Network Access

AWS provides a number of tools regarding network access: placement of the Amazon EC2 instance in an Amazon VPC (Amazon VPC security was discussed in Chapter 3) and security groups to control access on a specific interface. With administrative access, you again can control access with placement of Amazon EC2 instances in an Amazon VPC, the use of security groups, and the use of public/private key pairs both to encrypt traffic and control access.

Controlling Administrative Access

AWS provides a number of tools to manage the security of your instances. These tools include the following:

• IAM
• AWS Trusted Advisor
• AWS Service Catalog
• Amazon Inspector

IAM allows you to create policies that control access to APIs and apply those policies to users, groups, and roles.

AWS Trusted Advisor, which comes as part of AWS Support, looks at things like open ports on security groups and level of access allowed to Amazon EC2 instances, and it makes recommendations to improve the security of your AWS infrastructure.

AWS Service Catalog allows IT administrators to create, manage, and distribute portfolios of approved products to end users who can then access the products they need in a personalized portal. AWS Service Catalog allows organizations to manage commonly deployed IT services centrally, and it helps organizations achieve consistent governance and meet compliance requirements while enabling users to deploy quickly only the approved IT services they need within the constraints the organization sets.

Amazon Inspector is a security vulnerability assessment service that helps improve the security and compliance of your AWS resources. Amazon Inspector automatically assesses resources for vulnerabilities or deviations from best practices and then produces a detailed list of security findings prioritized by level of severity.

Deploying a Container

To deploy a container, you need to do the following:

1. Define a task. This is where you assign the name, provide the image name (important for locating the correct image), and decide on the amount of memory and CPU needed.
2. Define the service. In this step, you decide how many instances of the task you want to run in the cluster and any Elastic Load Balancing load balancers that you want to register the instances with.
3. Create the Amazon ECS cluster. This is where the cluster is created and also where you specify the number of instances to run. The cluster can run across multiple Availability Zones.
4. Create the stack. A stack of instances is created based on the configuration information provided. You can monitor the creation of the stack in the AWS Management Console. Creation of the stack is usually completed in less than five minutes.

Monitoring Amazon ECS

The primary tool used for monitoring your Amazon ECS clusters is Amazon CloudWatch. Amazon CloudWatch collects Amazon ECS metric data in one-minute periods and sends them to Amazon CloudWatch. Amazon CloudWatch stores these metrics for a period of two weeks. You can monitor the CPU and memory reservation and utilization across your cluster as a whole and the CPU and memory utilization on the services in your cluster. You can use Amazon CloudWatch to trigger alarms, set notifications, and create dashboards to monitor the services.

Once it’s set up, you can view Amazon CloudWatch metrics in both the Amazon ECS console and the Amazon CloudWatch console. The Amazon ECS console provides a maximum 24-hour view while the Amazon CloudWatch console provides a fine-grained and customizable view of running services.

The other tool available is AWS CloudTrail, which will log all Amazon ECS API calls.

AWS Trusted Advisor is another source for monitoring all of your AWS resources, including Amazon ECS, to improve performance, reliability, and security.

There is no additional cost for using Amazon ECS. The only charges are for the Amazon EC2 instances or AWS Lambda requests and compute time.

Implementation

There are a number of tools that you can use to create and manage the AWS Elastic Beanstalk environment. These tools are as follows:

• AWS Management Console
• AWS Elastic Beanstalk CLI
• AWS SDK for Java
• AWS Toolkit for Eclipse
• AWS SDK for .NET
• AWS Toolkit for Visual Studio
• AWS SDK for Node.js
• AWS SDK for PHP (requires PHP 5.2 or later)
• Boto (AWS SDK for Python)
• AWS SDK for Ruby

You deploy a new application on AWS Elastic Beanstalk by uploading a source bundle. This source bundle can be a ZIP or a WAR file (you can include multiple WAR files inside of your ZIP file). This source bundle cannot be larger than 512 MB.

Making Changes in Your AWS Elastic Beanstalk Environment

It is recommended to use the AWS Elastic Beanstalk console and CLI when making changes to your AWS Elastic Beanstalk environments and configuration. Although it is possible to modify your AWS Elastic Beanstalk environment using other service consoles, CLI commands, or AWS SDKs, those changes will not be reflected in the AWS Elastic Beanstalk console and you will not be able to monitor, change, or save your environment. It will also cause issues when you attempt to terminate your environment without using the AWS Elastic Beanstalk console.

Monitoring Your AWS Elastic Beanstalk Environment

You can monitor the overall health of your environment using either the basic health reporting or enhanced health reporting and monitoring systems. Basic health reporting gives an overall status (via color key) of the environment. It does not publish any metrics to Amazon CloudWatch. Enhanced health reporting and monitoring not only provides status via color key, but it also provides a descriptor that helps indicate the severity and cause of the problem. You can also configure enhanced health reporting and monitoring to publish metrics to Amazon CloudWatch as custom metrics.

You can retrieve log files from the individual instances or have those log files uploaded to an Amazon S3 bucket for more permanent storage.

How AWS Lambda Functions Are Invoked

AWS Lambda functions can be invoked either synchronously or asynchronously. If you are using AWS Cloud services to invoke AWS Lambda functions, those AWS Cloud services control whether the function is invoked synchronously or asynchronously. For example, if Amazon S3 invokes an AWS Lambda function, it does so asynchronously. In contrast, Amazon Cognito invokes an AWS Lambda function synchronously.

AWS Lambda functions are invoked by the following:

Push event model Some event sources can publish events to AWS Lambda and directly invoke your AWS Lambda function. The push model applies to Amazon S3, Amazon SNS, Amazon Cognito, Amazon Echo, and user applications, where each event triggers the AWS Lambda function.

Pull event model Some event sources publish events, but AWS Lambda must poll the event source and invoke your AWS Lambda function when events occur. This model applies when AWS Lambda is used with streaming event sources such as Amazon Kinesis and Amazon DynamoDB Streams. For example, AWS Lambda polls your Amazon Kinesis stream, or Amazon DynamoDB Stream, and it invokes your AWS Lambda function when it detects new records on the stream.

Direct invocation model This invocation type causes AWS Lambda to execute the function synchronously and returns the response immediately to the calling application. This invocation type is available for custom applications.

OS Choices

The operating system choices for Amazon Lightsail are Amazon Linux or Ubuntu.

Applications and Developer Stack Choices

The following are application choices for Amazon Lightsail:

• Drupal
• Joomla
• Redmine
• GitLab
• WordPress
• Magneto
• Nginx

The following are the developer stacks choices for Amazon Lightsail:

• LAMP
• LEMP
• MEAN
• Node.js

After choosing an application or developer stack, you pick your instance plan, which determines the number of Virtual CPUs (vCPUs), amount of RAM, amount of disk space, and expected data transfer amounts. Assign a unique name (the name needs to be unique within your account), decide on the number of instances you want to spin up (the maximum is 20), and create your instance.

Your Amazon Lightsail instance is spun up in its own Amazon VPC.

Available Metrics

Metrics provides you with information on the following:

• CPU utilization
• Network in
• Network out
• Status check failed instance (indicates if the specific instance is failing)
• Status check failed system (indicates if the underlying AWS hardware is failing)

All of these metrics are offered in one-hour, six-hour, one-day, one-week, and two-week increments.

Networking

Networking gives you information on your IP addresses, both the publicly accessible IP address (the address accessible from the Internet) and the private IP address (the address accessible internally). You can change the public IP to become a static IP address. Networking also lists the ports open on the firewall and provides the ability to open or close ports as needed, giving you control over who has access to your instance.

Snapshots is where you create and store snapshots. This is also where you can create new instances based on snapshots. There is no limit to the number of snapshots you can take and store. Note that you are charged for storing snapshots.

History lists when an instance was created, stopped, and rebooted; provides information on snapshots taken; and provides information on attached or detached static IP addresses.

With Amazon Lightsail, you can keep the public IP address assigned to the instance, assign a static public IP address, or create a DNS zone. Public IP addresses in Amazon Lightsail behave very similarly to public IP addresses in Amazon EC2; when you stop an Amazon Lightsail instance, the public IP address is removed; when you restart that instance, a new IP address is assigned. If you need IP address persistence, you should assign a static public IP address to the instance. A DNS zone supports A, CNAME, MX, and TXT records. You can use Amazon Route 53 to register your domain.

Costs

Costing for Amazon Lightsail is done on an hourly basis, with the minimum billing increment being one hour. While there is a monthly maximum for each different instance size, it is possible to have additional charges based on the following:

1. Storage costs of any snapshots that you take and keep
2. Charges for data transfer in excess of the amount allocated
3. Any public IP addresses that are not assigned to an instance

Changing Instance Size

Changing the instance size for Amazon Lightsail involves taking a snapshot of the existing instance and spinning up a new instance in the larger size. It is not possible to modify the number of vCPUs, RAM, or SSD size of an individual instance.

Implementing an AWS Batch Job

Steps to implementing a batch job are as follows:

1. Define a job.
2. Configure the compute environment.
3. Configure the job queue.
4. Submit a job.

Once a job is submitted it will go through the following states:

Submitted Submitted to the queue but has not yet been evaluated by the scheduler.

Pending Submitted to the queue and evaluated but not yet running due to a dependency on another job or resource.

Runnable In the queue with no outstanding dependencies and is ready to be scheduled.

Starting Scheduled to a host and container initiation operations are underway.

Running The job is running.

Succeeded The job has finished successfully.

Failed The job has failed all available attempts.

If a job fails, you can automate retry attempts up to 10 times.

Monitoring

You can monitor your AWS Batch environment either via the CLI or the AWS Batch dashboard. Logs for your jobs (for example, STDERR and STDOUT) are available in the AWS Management Console and can be written to Amazon CloudWatch Logs. You can use SSH to access the Amazon EC2 instances that have been spun up to process your AWS Batch job.

Costs

There are no additional costs for AWS Batch. The only costs are for the Amazon EC2 resources or the AWS Lambda resources used. It is possible to use Spot pricing for all of your compute instances in order to minimize costs.