Caden Shokat commited on
Commit
49a5af2
·
1 Parent(s): 14b9485

dataset chunking & processing

Browse files
.gitignore CHANGED
@@ -205,3 +205,5 @@ cython_debug/
205
  marimo/_static/
206
  marimo/_lsp/
207
  __marimo__/
 
 
 
205
  marimo/_static/
206
  marimo/_lsp/
207
  __marimo__/
208
+
209
+ data/
dataset/chunks/batch_chunks.json ADDED
@@ -0,0 +1,21 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "AWS Batch User Guide What is AWS Batch? AWS Batch helps you to run batch computing workloads on the AWS Cloud. Batch computing is a common way for developers, scientists, and engineers to access large amounts of compute resources. AWS Batch removes the undifferentiated heavy lifting of configuring and managing the required infrastructure, similar to traditional batch computing software. This service can efficiently provision resources in response to jobs submitted in order to eliminate capacity constraints, reduce compute costs, and deliver results quickly. As a fully managed service, AWS Batch helps you to run batch computing workloads of any scale. AWS Batch automatically provisions compute resources and optimizes the workload distribution based on the quantity and scale of the workloads. With AWS Batch, there's no need to install or manage batch computing software, so you can focus your time on analyzing results and solving problems. 1 AWS Batch User Guide AWS Batch provides all of the necessary functionality to run high-scale, compute-intensive workloads on top of AWS managed container orchestration services, Amazon ECS and Amazon EKS. AWS Batch is able to scale compute capacity on Amazon EC2 instances and Fargate resources. AWS Batch provides a fully managed service for batch workloads, and delivers the operational capabilities to optimize these types of workloads for throughput, speed, resource efficiency, and cost. AWS Batch also enables SageMaker Training job queuing, allowing data scientists and ML engineers to submit Training jobs with priorities to configurable queues. This capability ensures that ML workloads run automatically as soon as resources become available, eliminating the need for manual coordination and improving resource utilization. For machine learning workloads, AWS Batch provides queuing capabilities for SageMaker Training jobs. You can configure queues with specific policies to optimize cost, performance, and resource allocation for your ML Training workloads. This provides",
3
+ "policies to optimize cost, performance, and resource allocation for your ML Training workloads. This provides a shared responsibility model where administrators set up the infrastructure and permissions, while data scientists can focus on submitting and monitoring their ML training workloads. Jobs are automatically queued and executed based on configured priorities and resource availability. 2 AWS Batch User Guide Are you a first-time AWS Batch user? If you are a first-time user of AWS Batch, we recommend that you begin by reading the following sections: • Components of AWS Batch • Create IAM account and administrative user • Setting up AWS Batch • Getting started with AWS Batch tutorials • Getting started with AWS Batch on SageMaker AI Related services AWS Batch is a fully managed batch computing service that plans, schedules, and runs your containerized batch ML, simulation, and analytics workloads across the full range of AWS compute offerings, such as Amazon ECS, Amazon EKS, AWS Fargate, and Spot or On-Demand Instances. For more information about each managed compute service, see: • Amazon EC2 User Guide • AWS Fargate Developer Guide • Amazon EKS User Guide • Amazon SageMaker AI Developer Guide Accessing AWS Batch You can access AWS Batch using the following: AWS Batch console The web interface where you create and manage resources. AWS Command Line Interface Interact with AWS services using commands in your command line shell. The AWS Command Line Interface is supported on Windows, macOS, and Linux. For more information about the AWS CLI, see AWS Command Line Interface User Guide. You can find the AWS Batch commands in the AWS CLI Command Reference. Are you a first-time AWS Batch user? 3 AWS Batch User Guide AWS SDKs If you prefer to build applications using language-specific APIs instead of submitting a request over HTTP or",
4
+ "prefer to build applications using language-specific APIs instead of submitting a request over HTTP or HTTPS, use the libraries, sample code, tutorials, and other resources provided by AWS. These libraries provide basic functions that automate tasks, such as cryptographically signing your requests, retrying requests, and handling error responses. These functions make it more efficient for you to get started. For more information, see Tools to Build on AWS. Components of AWS Batch AWS Batch simplifies running batch jobs across multiple Availability Zones within a Region. You can create AWS Batch compute environments within a new or existing VPC. After a compute environment is up and associated with a job queue, you can define job definitions that specify which Docker container images to run your jobs. Container images are stored in and pulled from container registries, which may exist within or outside of your AWS infrastructure. Compute environment A compute environment is a set of managed or unmanaged compute resources that are used to run jobs. With managed compute environments, you can specify desired compute type (Fargate or EC2) at several levels of detail. You can set up compute environments that use a particular type of EC2 instance, a particular model such as c5.2xlarge or m5.10xlarge. Or, you can choose only to specify that you want to use the newest instance types. You can also specify the minimum, desired, and maximum number of vCPUs for the environment, along with the amount that you're Components of AWS Batch 4 AWS Batch User Guide willing to pay for a Spot Instance as a percentage of the On-Demand Instance price and a target set of VPC subnets. AWS Batch efficiently launches, manages, and terminates compute types as needed. You can also manage your own compute environments. As such, you're responsible for setting up and",
5
+ "can also manage your own compute environments. As such, you're responsible for setting up and scaling the instances in an Amazon ECS cluster that AWS Batch creates for you. For more information, see Compute environments for AWS Batch. Job queues When you submit an AWS Batch job, you submit it to a particular job queue, where the job resides until it's scheduled onto a compute environment. You associate one or more compute environments with a job queue. You can also assign priority values for these compute environments and even across job queues themselves. For example, you can have a high priority queue that you submit time-sensitive jobs to, and a low priority queue for jobs that can run anytime when compute resources are cheaper. For more information, see Job queues. Job definitions A job definition specifies how jobs are to be run. You can think of a job definition as a blueprint for the resources in your job. You can supply your job with an IAM role to provide access to other AWS resources. You also specify both memory and CPU requirements. The job definition can also control container properties, environment variables, and mount points for persistent storage. Many of the specifications in a job definition can be overridden by specifying new values when submitting individual Jobs. For more information, see Job definitions Jobs A unit of work (such as a shell script, a Linux executable, or a Docker container image) that you submit to AWS Batch. It has a name, and runs as a containerized application on AWS Fargate or Amazon EC2 resources in your compute environment, using parameters that you specify in a job definition. Jobs can reference other jobs by name or by ID, and can be dependent on the successful completion of other jobs or the",
6
+ "by ID, and can be dependent on the successful completion of other jobs or the availability of resources you specify. For more information, see Jobs. Scheduling policy You can use scheduling policies to configure how compute resources in a job queue are allocated between users or workloads. Using fair-share scheduling policies, you can assign different share identifiers to workloads or users. The AWS Batch job scheduler defaults to a first-in, first-out (FIFO) strategy. For more information, see Fair-share scheduling policies. Job queues 5 AWS Batch User Guide Consumable resources A consumable resource is a resource that is needed to run your jobs, such as a 3rd party license token, database access bandwidth, the need to throttle calls to a third-party API, and so on. You specify the consumable resources which are needed for a job to run, and Batch takes these resource dependencies into account when it schedules a job. You can reduce the under-utilization of compute resources by allocating only the jobs that have all the required resources available. For more information, see Resource-aware scheduling . Service Environment A Service Environment define how AWS Batch integrates with SageMaker for job execution. Service Environments enable AWS Batch to submit and manage jobs on SageMaker while providing the queuing, scheduling, and priority management capabilities of AWS Batch. Service Environments define capacity limits for specific service types such as SageMaker Training jobs. The capacity limits control the maximum resources that can be used by service jobs in the environment. For more information, see Service environments for AWS Batch. Service job A service job is a unit of work that you submit to AWS Batch to run on a service environment. Service jobs leverage AWS Batch's queuing and scheduling capabilities while delegating actual execution to the external service. For example, SageMaker Training jobs",
7
+ "scheduling capabilities while delegating actual execution to the external service. For example, SageMaker Training jobs submitted as service jobs are queued and prioritized by AWS Batch, but the SageMaker Training job execution occurs within SageMaker AI infrastructure. This integration enables data scientists and ML engineers to benefit from AWS Batch's automated workload management, and priority queuing, for their SageMaker AI Training workloads. Service jobs can reference other jobs by name or ID and support job dependencies. For more information, see Service jobs in AWS Batch. Consumable resources 6 AWS Batch User Guide Setting up AWS Batch If you've already signed up for Amazon Web Services (AWS) and are using Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Elastic Container Service (Amazon ECS), you can soon use AWS Batch. The setup process for these services is similar. This is because AWS Batch uses Amazon ECS container instances in its compute environments. To use the AWS CLI with AWS Batch, you must use a version of the AWS CLI that supports the latest AWS Batch features. If you don't see support for an AWS Batch feature in the AWS CLI, upgrade to the latest version. For more information, see http://aws.amazon.com/cli/. Note Because AWS Batch uses components of Amazon EC2, you use the Amazon EC2 console for many of these steps. Complete the following tasks to get set up for AWS Batch. Topics • Create IAM account and administrative user • Create IAM roles for your compute environments and container instances • Create a key pair for your instances • Create a VPC • Create a security group • Install the AWS CLI Create IAM account and administrative user To get started, you need to create an AWS account and a single user that is typically granted administrative rights. To accomplish this, complete",
8
+ "account and a single user that is typically granted administrative rights. To accomplish this, complete the following tutorials: Sign up for an AWS account If you do not have an AWS account, complete the following steps to create one. Create IAM account and administrative user 7 AWS Batch User Guide To sign up for an AWS account 1. Open https://portal.aws.amazon.com/billing/signup. 2. Follow the online instructions. Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad. When you sign up for an AWS account, an AWS account root user is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform tasks that require root user access. AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to https://aws.amazon.com/ and choosing My Account. Create a user with administrative access After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks. Secure your AWS account root user 1. Sign in to the AWS Management Console as the account owner by choosing Root user and entering your AWS account email address. On the next page, enter your password. For help signing in by using root user, see Signing in as the root user in the AWS Sign-In User Guide. 2. Turn on multi-factor authentication (MFA) for your root user. For instructions, see Enable a virtual MFA device for your AWS account root user (console) in the",
9
+ "see Enable a virtual MFA device for your AWS account root user (console) in the IAM User Guide. Create a user with administrative access 1. Enable IAM Identity Center. Create a user with administrative access 8 AWS Batch User Guide For instructions, see Enabling AWS IAM Identity Center in the AWS IAM Identity Center User Guide. 2. In IAM Identity Center, grant administrative access to a user. For a tutorial about using the IAM Identity Center directory as your identity source, see Configure user access with the default IAM Identity Center directory in the AWS IAM Identity Center User Guide. Sign in as the user with administrative access • To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user. For help signing in using an IAM Identity Center user, see Signing in to the AWS access portal in the AWS Sign-In User Guide. Assign access to additional users 1. In IAM Identity Center, create a permission set that follows the best practice of applying leastprivilege permissions. For instructions, see Create a permission set in the AWS IAM Identity Center User Guide. 2. Assign users to a group, and then assign single sign-on access to the group. For instructions, see Add groups in the AWS IAM Identity Center User Guide. Create IAM roles for your compute environments and container instances Your AWS Batch compute environments and container instances require AWS account credentials to make calls to other AWS APIs on your behalf. Create an AWS Identity and Access Management role that provides these credentials to your compute environments and container instances, then associate that role with your compute environments. Create IAM roles 9 AWS Batch User Guide Note To verify that your AWS",
10
+ "environments. Create IAM roles 9 AWS Batch User Guide Note To verify that your AWS account has the required permissions, see Initial IAM service set up for your account. The AWS Batch compute environment and container instance roles are automatically created for you in the console first-run experience. So, if you intend to use the AWS Batch console, you can move ahead to the next section. If you plan to use the AWS CLI instead, complete the procedures in Using service-linked roles for AWS Batch, Amazon ECS instance role, and Tutorial: Create the IAM execution role before creating your first compute environment. Create a key pair for your instances AWS uses public-key cryptography to secure the login information for your instance. A Linux instance, such as an AWS Batch compute environment container instance, has no password to use for SSH access. You use a key pair to log in to your instance securely. You specify the name of the key pair when you create your compute environment, then provide the private key when you log in using SSH. If you didn't create a key pair already, you can create one using the Amazon EC2 console. Note that, if you plan to launch instances in multiple AWS Regions, create a key pair in each Region. For more information about Regions, see Regions and Availability Zones in the Amazon EC2 User Guide. To create a key pair 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. From the navigation bar, select an AWS Region for the key pair. You can select any Region that's available to you, regardless of your location: however, key pairs are specific to a Region. For example, if you plan to launch an instance in the US West (Oregon) Region, create a key pair for the instance in",
11
+ "instance in the US West (Oregon) Region, create a key pair for the instance in the same Region. 3. In the navigation pane, choose Key Pairs, Create Key Pair. 4. In the Create Key Pair dialog box, for Key pair name, enter a name for the new key pair , and choose Create. Choose a name that you can remember, such as your user name, followed by key-pair, plus the Region name. For example, me-key-pair-uswest2. Create a key pair 10 AWS Batch 5. User Guide The private key file is automatically downloaded by your browser. The base file name is the name that you specified as the name of your key pair, and the file name extension is .pem. Save the private key file in a safe place. Important This is the only chance for you to save the private key file. You need to provide the name of your key pair when you launch an instance and the corresponding private key each time that you connect to the instance. 6. If you use an SSH client on a Mac or Linux computer to connect to your Linux instance, use the following command to set the permissions of your private key file. That way, only you can read it. $ chmod 400 your_user_name-key-pair-region_name.pem For more information, see Amazon EC2 Key Pairs in the Amazon EC2 User Guide. To connect to your instance using your key pair To connect to your Linux instance from a computer running Mac or Linux, specify the .pem file to your SSH client with the -i option and the path to your private key. To connect to your Linux instance from a computer running Windows, use either MindTerm or PuTTY. If you plan to use PuTTY, install it and use the following procedure to convert the",
12
+ "you plan to use PuTTY, install it and use the following procedure to convert the .pem file to a .ppk file. (Optional) To prepare to connect to a Linux instance from Windows using PuTTY 1. Download and install PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/. Be sure to install the entire suite. 2. Start PuTTYgen (for example, from the Start menu, choose All Programs, PuTTY, and PuTTYgen). 3. Under Type of key to generate, choose RSA. If you're using an earlier version of PuTTYgen, choose SSH-2 RSA. Create a key pair 11 AWS Batch 4. User Guide Choose Load. By default, PuTTYgen displays only files with the extension .ppk. To locate your .pem file, choose the option to display files of all types. 5. Select the private key file that you created in the previous procedure and choose Open. Choose OK to dismiss the confirmation dialog box. 6. Choose Save private key. PuTTYgen displays a warning about saving the key without a passphrase. Choose Yes. 7. Specify the same name for the key that you used for the key pair. PuTTY automatically adds the .ppk file extension. Create a VPC With Amazon Virtual Private Cloud (Amazon VPC), you can launch AWS resources into a virtual network that you've defined. We strongly recommend that you launch your container instances in a VPC. If you have a default VPC, you also can skip this section and move to the next task Create a security group. To determine whether you have a default VPC, see Supported Platforms in the Amazon EC2 Console in the Amazon EC2 User Guide For information about how to create an Amazon VPC, see Create a VPC only in the Amazon VPC User Guide. Refer to the following table to determine what options to select. Option Value Resources to create VPC only Name",
13
+ "table to determine what options to select. Option Value Resources to create VPC only Name Optionally provide a name for your VPC. IPv4 CIDR block IPv4 CIDR manual input The CIDR block size must have a size between /16 and /28. Create a VPC 12 AWS Batch User Guide Option Value IPv6 CIDR block No IPv6 CIDR block Tenancy Default For more information about Amazon VPC, see What is Amazon VPC? in the Amazon VPC User Guide. Create a security group Security groups act as a firewall for associated compute environment container instances, controlling both inbound and outbound traffic at the container instance level. A security group can be used only in the VPC for which it is created. You can add rules to a security group that enable you to connect to your container instance from your IP address using SSH. You can also add rules that allow inbound and outbound HTTP and HTTPS access from anywhere. Add any rules to open ports that are required by your tasks. Note that if you plan to launch container instances in multiple Regions, you need to create a security group in each Region. For more information, see Regions and Availability Zones in the Amazon EC2 User Guide. Note You need the public IP address of your local computer, which you can get using a service. For example, we provide the following service: http://checkip.amazonaws.com/ or https:// checkip.amazonaws.com/. To locate another service that provides your IP address, use the search phrase \"what is my IP address.\" If you're connecting through an Internet service provider (ISP) or from behind a firewall without a static IP address, find out the range of IP addresses that are used by client computers. To create a security group using the console 1. Open the Amazon VPC console at",
14
+ "To create a security group using the console 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. In the navigation pane, choose Security Groups. 3. Choose Create security group. Create a security group 13 AWS Batch 4. User Guide Enter a name and description for the security group. You cannot change the name and description of a security group after it is created. 5. From VPC, choose the VPC. 6. (Optional) By default, new security groups start with only an outbound rule that allows all traffic to leave the resource. You must add rules to enable any inbound traffic or to restrict the outbound traffic. AWS Batch container instances don't require any inbound ports to be open. However, you might want to add an SSH rule. That way, you can log into the container instance and examine the containers in jobs with Docker commands. If you want your container instance to host a job that runs a web server, you can also add rules for HTTP. Complete the following steps to add these optional security group rules. On the Inbound tab, create the following rules and choose Create: • Choose Add Rule. For Type, choose HTTP. For Source, choose Anywhere (0.0.0.0/0). • Choose Add Rule. For Type, choose SSH. For Source, choose Custom IP, and specify the public IP address of your computer or network in Classless Inter-Domain Routing (CIDR) notation. If your company allocates addresses from a range, specify the entire range, such as 203.0.113.0/24. To specify an individual IP address in CIDR notation, choose My IP. This adds the routing prefix /32 to the public IP address. Note For security reasons, we don't recommend that you allow SSH access from all IP addresses (0.0.0.0/0) to your instance but only for testing purposes and only for a short time.",
15
+ "(0.0.0.0/0) to your instance but only for testing purposes and only for a short time. 7. You can add tags now, or you can add them later. To add a tag, choose Add new tag and enter the tag key and value. 8. Choose Create security group. To create a security group using the command line, see create-security-group (AWS CLI) For more information about security groups, see Work with security groups. Create a security group 14 AWS Batch User Guide Install the AWS CLI To use the AWS CLI with AWS Batch, install the latest AWS CLI version. For information about installing the AWS CLI or upgrading it to the latest version, see Installing the AWS Command Line Interface in the AWS Command Line Interface User Guide. Install the AWS CLI 15 AWS Batch User Guide Getting started with AWS Batch tutorials You can use the AWS Batch first-run wizard to get started quickly with AWS Batch. After you complete the Prerequisites, you can use the first-run wizard to create a compute environment, a job definition, and a job queue. You can also submit a sample \"Hello World\" job using the AWS Batch first-run wizard to test your configuration. If you already have a Docker image that you want to launch in AWS Batch, you can use that image to create a job definition. Afterward, you can use the AWS Batch first-run wizard to create a compute environment, job queue, and submit a sample Hello World job. Getting started with Amazon EC2 orchestration using the Wizard Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS Cloud. Using Amazon EC2 eliminates your need to invest in hardware up front, so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or",
16
+ "develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. Amazon EC2 enables you to scale up or down to handle changes in requirements or spikes in popularity, reducing your need to forecast traffic. Overview This tutorial demonstrates how to setup AWS Batch with the Wizard to configure Amazon EC2 and run Hello World. Intended Audience This tutorial is designed for system administrators and developers responsible for setting up, testing, and deploying AWS Batch. Features Used This tutorial shows you how to use the AWS Batch console wizard to: • Create and configure an Amazon EC2 compute environment • Create a job queue. Getting started with Amazon EC2 using the Wizard 16 AWS Batch User Guide • Create a job definition • Create and submit a job to run • View the output of the job in CloudWatch Time Required It should take about 10–15 minutes to complete this tutorial. Regional Restrictions There are no country or regional restrictions associated with using this solution. Resource Usage Costs There's no charge for creating an AWS account. However, by implementing this solution, you might incur some or all of the costs that are listed in the following table. Description Cost (US dollars) Amazon EC2 instance You pay for each Amazon EC2 instance that is created. For more information about pricing, see Amazon EC2 Pricing. Prerequisites Before you begin: • Create an AWS account if you don't have one. • Create the ecsInstanceRole Instance role. Step 1: Create a compute environment Important To get started as simply and quickly as possible, this tutorial includes steps with default settings. Before creating for production use, we recommend that you familiarize yourself with all settings and deploy",
17
+ "creating for production use, we recommend that you familiarize yourself with all settings and deploy with the settings that meet your requirements. To create a compute environment for an Amazon EC2 orchestration, do the following: Prerequisites 17 AWS Batch User Guide 1. Open the AWS Batch console first-run wizard. 2. For Configure job and orchestration type, choose Amazon Elastic Compute Cloud(Amazon EC2). 3. Choose Next. 4. In the Compute environment configuration section for Name, specify a unique name for your compute environment. The name can be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers, hyphens (-), and underscores (_). 5. For Instance role, choose an existing instance role that has the required IAM permissions attached. This instance role allows the Amazon ECS container instances in your compute environment to make calls to the required AWS API operations. For more information, see Amazon ECS instance role. The default name of the Instance role is ecsInstanceRole. 6. For Instance configuration you can leave the default settings. 7. For Network configuration use your default VPC for the AWS Region. 8. Choose Next. Step 2: Create a job queue A job queue stores your submitted jobs until the AWS Batch Scheduler runs the job on a resource in your compute environment. For more information, see Job queues To create a job queue for an Amazon EC2 orchestration, do the following: 1. For Job queue configuration for Name, specify a unique name for your job queue. The name can be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers, hyphens (-), and underscores (_). 2. For all other configuration options you can leave the default value. 3. Choose Next. Step 3: Create a job definition AWS Batch job definitions specify how jobs are to",
18
+ "Step 3: Create a job definition AWS Batch job definitions specify how jobs are to be run. Even though each job must reference a job definition, many of the parameters that are specified in the job definition can be overridden at runtime. Step 2: Create a job queue 18 AWS Batch User Guide To create the job definition: 1. For Create a job definition a. for Name, specify a unique name for your job queue. The name can be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers, hyphens (-), and underscores (_). b. For Command - optional you can change hello world to a custom message or leave it as is. 2. For all other configuration options you can leave the default value. 3. Choose Next. Step 4: Create a job To create a job, do the following: 1. In the Job configuration section for Name, specify a unique name for the job. The name can be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers, hyphens (-), and underscores (_). 2. For all other configuration options you can leave the default value. 3. Choose Next. Step 5: Review and create On the Review and create page, review the configuration steps. If you need to make changes, choose Edit. When you're finished, choose Create resources. 1. For Review and create choose Create resources. 2. A window opens as AWS Batch starts to allocate your resources. Once complete choose Go to dashboard. On the dashboard you should see all of your allocated resources and that the job is in the Runnable state. Your job is scheduled to run and should complete in 2–3 minuets. Step 6: View the Job's output To view the Job's output, do the following: Step 4:",
19
+ "6: View the Job's output To view the Job's output, do the following: Step 4: Create a job 19 AWS Batch User Guide 1. In the navigation pane choose Jobs. 2. In the Job queue drop down choose the Job queue you created for the tutorial. 3. The Jobs table lists all of your Jobs and what their current status is. Once the Job's Status is Succeeded choose the Name of the Job to view the Job's details. 4. In the Details pane choose Log stream name. The CloudWatch console for the Job will open and there should be one event with the Message of hello world or your custom message. Step 7: Clean up your tutorial resources You are charged for the Amazon EC2 instance while it is enabled. You can delete the instance to stop incurring charges. To delete the resources you created, do the following: 1. In the navigation pane choose Job queue. 2. In the Job queue table choose the Job queue you created for the tutorial. 3. Choose Disable. Once the Job queue State is Disabled you can choose Delete. 4. Once the Job queue is deleted, in the navigation pane choose Compute environments. 5. Choose the compute environment you created for this tutorial and then choose Disable. It may take 1–2 minuets for the compute environment to complete being disabled. 6. Once the compute environment’s State is Disabled, choose Delete. It may take 1–2 minuets for the compute environment to be deleted. Additional resources After you complete the tutorial, you might want to explore the following topics:: • Explore the AWS Batch core components. For more information, see Components of AWS Batch. • Learn more about the different Compute Environments available in AWS Batch. • Learn more about Job queues and their different scheduling",
20
+ "Environments available in AWS Batch. • Learn more about Job queues and their different scheduling options. • Learn more about Job definitions and the different configuration options. • Learn more about the different types of Jobs. Step 7: Clean up your tutorial resources 20"
21
+ ]
dataset/chunks/beanstalk_chunks.json ADDED
@@ -0,0 +1,14 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "AWS Elastic Beanstalk Developer Guide What is AWS Elastic Beanstalk? With Elastic Beanstalk you can deploy web applications into the AWS Cloud on a variety of supported platforms. You build and deploy your applications. Elastic Beanstalk provisions Amazon EC2 instances, configures load balancing, sets up health monitoring, and dynamically scales your environment. In addition to web server environments, Elastic Beanstalk also provides worker environments which you can use to process messages from an Amazon SQS queue, useful for asynchronous or longrunning tasks. For more information, see Elastic Beanstalk worker environments. 1 AWS Elastic Beanstalk Developer Guide Supported platforms Elastic Beanstalk supports applications developed in Go, Java, .NET, Node.js, PHP, Python, and Ruby. Elastic Beanstalk also supports Docker containers, where you can choose your own programming language and application dependencies. When you deploy your application, Elastic Supported platforms 2 AWS Elastic Beanstalk Developer Guide Beanstalk builds the selected supported platform version and provisions one or more AWS resources, such as Amazon EC2 instances, in your AWS account to run your application. You can interact with Elastic Beanstalk through the Elastic Beanstalk console, the AWS Command Line Interface (AWS CLI), or the EB CLI, a high-level command line tool designed specifically for Elastic Beanstalk. You can perform most deployment tasks, such as changing the size of your fleet of Amazon EC2 instances or monitoring your application, directly from the Elastic Beanstalk web interface (console). To learn more about how to deploy a sample web application using Elastic Beanstalk, see Learn how to get started with Elastic Beanstalk. Application deploy workflow To use Elastic Beanstalk, you create an application, then upload your application source bundle to Elastic Beanstalk. Next, you provide information about the application, and Elastic Beanstalk automatically launches an environment and creates and configures the AWS resources needed to run your",
3
+ "automatically launches an environment and creates and configures the AWS resources needed to run your code. After you create and deploy your application and your environment is launched, you can manage your environment and deploy new application versions. Information about the application— including metrics, events, and environment status—is made available through the Elastic Beanstalk console, APIs, and Command Line Interfaces. The following diagram illustrates Elastic Beanstalk workflow: Pricing There is no additional charge for Elastic Beanstalk. You pay only for the underlying AWS resources that your application consumes. For details about pricing, see the Elastic Beanstalk service detail page. Application deploy workflow 3 AWS Elastic Beanstalk Developer Guide Next steps We recommend the tutorial, Getting started tutorial, to start using Elastic Beanstalk. The tutorial steps you through creating, viewing, and updating a sample Elastic Beanstalk application. Next steps 4 AWS Elastic Beanstalk Developer Guide Learn how to get started with Elastic Beanstalk With Elastic Beanstalk you can deploy, monitor, and scale web applications and services. Typically, you will develop your code locally then deploy it to Amazon EC2 server instances. Theses instances, also called environments, run on platforms that can be upgraded through the AWS console or the command line. To get started, we recommend deploying a pre-built sample application directly from the console. Then, you can learn how to develop locally and deploy from the command line in the the section called “QuickStart for PHP”. There is no cost for using Elastic Beanstalk, but standard fees do apply to AWS resources that you create during the course of this tutorial until you delete them at the end. The total charges are typically less than a dollar. For information about how to minimize charges, see AWS free tier. After completing this tutorial, you will understand the basics of creating, configuring,",
4
+ "AWS free tier. After completing this tutorial, you will understand the basics of creating, configuring, deploying, updating, and monitoring an Elastic Beanstalk application with environments running on Amazon EC2 instances. Estimated duration: 35-45 minutes 5 AWS Elastic Beanstalk Developer Guide 6 AWS Elastic Beanstalk Developer Guide What you will build Your first Elastic Beanstalk application will consist of a single Amazon EC2 environment running the PHP sample on a PHP managed platform. Elastic Beanstalk application An Elastic Beanstalk application is a container for Elastic Beanstalk components, including environments where your application code runs on platforms provided and managed by Elastic Beanstalk, or in custom containers that you provide. Environment An Elastic Beanstalk environment is a collection of AWS resources running together including an Amazon EC2 instance. When you create an environment, Elastic Beanstalk provisions the necessary resources into your AWS account. Platform A platform is a combination of an operating system, programming language runtime, web server, application server, and additional Elastic Beanstalk components. Elastic Beanstalk provides manged platforms, or you can provide your own platform in a container. Elastic Beanstalk supports platforms for different programming languages, application servers, and Docker containers. When you create an environment, you must choose the platform. You can upgrade the platform, but you cannot change the platform for an environment. Switching platforms If you need to change programming languages, you must create and switch to a new environment on a different platform. Step 1 - Create an application To create your example application, you'll use the Create application console wizard. It creates an Elastic Beanstalk application and launches an environment within it. Reminder: an environment is a collection of AWS resources required to run your application code. What you will build 7 AWS Elastic Beanstalk Developer Guide To create an application 1. Open the Elastic",
5
+ "build 7 AWS Elastic Beanstalk Developer Guide To create an application 1. Open the Elastic Beanstalk console. 2. Choose Create application. 3. For Application name enter getting-started-app. The console provides a six step process for creating an application and configuring an environment. For this quick start, you'll only need to focus on the first two steps, then you can skip ahead to review and create your application and environment. To configure an environment 1. In Environment information, for Environment name enter: gs-app-web-env. 2. For Platform, choose the PHP platform. 3. For Application code and Presets, accept the defaults (Sample application and Single instance), then choose Next. To configure service access Next, you need two roles. A service role allows Elastic Beanstalk to monitor your EC2 instances and upgrade you environment’s platform. An EC2 instance profile role permits tasks such as writing logs and interacting with other services. To create the Service role 1. For Service role, choose Create role. 2. For Trusted entity type, choose AWS service. Step 1 - Create an application 8 AWS Elastic Beanstalk 3. For Use case, choose Elastic Beanstalk – Environment. 4. Choose Next. 5. Verify that Permissions policies include the following, then choose Next: Developer Guide • AWSElasticBeanstalkEnhancedHealth • AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy 6. Choose Create role. 7. Return to the Configure service access tab, refresh the list, then select the newly created service role. To create the EC2 instance profile 1. Choose Create role. 2. For Trusted entity type, choose AWS service. 3. For Use case, choose Elastic Beanstalk – Compute. 4. Choose Next. 5. Verify that Permissions policies include the following, then choose Next: • AWSElasticBeanstalkWebTier • AWSElasticBeanstalkWorkerTier • AWSElasticBeanstalkMulticontainerDocker 6. Choose Create role. 7. Return to the Configure service access tab, refresh the list, then select the newly created EC2 instance profile. To finish",
6
+ "access tab, refresh the list, then select the newly created EC2 instance profile. To finish configuring and creating your application 1. Skip over EC2 key pair. We'll show you other ways to connect to your Amazon EC2 instances through the Console. 2. Choose Skip to Review to move over several optional steps. Optional steps: networking, databases, scaling parameters, advanced configuration for updates, monitoring, and logging. 3. On the Review page which shows a summary of your choices, choose Submit. Step 1 - Create an application 9 AWS Elastic Beanstalk Developer Guide Congratulations! You have created an application and configured an environment! Now you need to wait for the resources to deploy. Step 2 - Deploy your application When you create an application, Elastic Beanstalk sets up the environments for you. You just need to sit back and wait. The initial deploy can take up to five minutes to create the resources. Updates will take less time because only changes will be deployed to your stack. When you create the example application, Elastic Beanstalk creates the following resources: • EC2 instance – An Amazon EC2 virtual machine configured to run web apps on the platform you selected. Every platform runs a different set of software, configuration files, and scripts to support a specific language version, framework, web container, or combination thereof. Most platforms use either Apache or nginx as a reverse proxy to forward web traffic to your web app, serve static assets, and generate access and error logs. You can connect to your Amazon EC2 instances to view configuration and logs. Step 2 - Deploy your application 10 AWS Elastic Beanstalk Developer Guide • Instance security group – An Amazon EC2 security group will be created to allow incoming requests on port 80, so inbound traffic on a load balancer",
7
+ "created to allow incoming requests on port 80, so inbound traffic on a load balancer can reach your web app. • Amazon S3 bucket – A storage location for your source code, logs, and other artifacts. • Amazon CloudWatch alarms – Two CloudWatch alarms are created to monitor the load on your instances and scale them up or down as needed. • AWS CloudFormation stack – Elastic Beanstalk uses AWS CloudFormation to deploy the resources in your environment and make configuration changes. You can view the resource definition template in the AWS CloudFormation console. • Domain name – A domain name that routes to your web app in the form : subdomain.region.elasticbeanstalk.com. Elastic Beanstalk creates your application, launches an environment, makes an application version, then deploys your code into the environment. During the process, the console tracks progress and displays event status in the Events tab. Step 2 - Deploy your application 11 AWS Elastic Beanstalk Developer Guide After all of the resources are deployed, the environment's health should change to Ok. Step 2 - Deploy your application 12 AWS Elastic Beanstalk Developer Guide Your application is ready! After you see your application health change to Ok, you can browse to your web application's website. Step 3 - Explore the Elastic Beanstalk environment You'll start exploring your deployed application environment from the Environment overview page in the console. To view the environment and your application 1. Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region. 2. In the navigation pane, choose Environments, and then choose the name of your environment from the list. 3. Choose Go to environment to browse your application! (You can also choose the URL link listed for Domain to browse your application.) The connection will be HTTP (not HTTPS), so you",
8
+ "for Domain to browse your application.) The connection will be HTTP (not HTTPS), so you might see a warning in your browser. Step 3 - Explore the environment 13 AWS Elastic Beanstalk Developer Guide Back in the Elastic Beanstalk console, the upper portion shows the Environment overview with top level information about your environment, including name, domain URL, current health status, running version, and the platform that the application is running on. The running version and platform are essential for troubleshooting your currently deployed application. After the overview pane, you will see recent environment activity in the Events tab. Step 3 - Explore the environment 14 AWS Elastic Beanstalk Developer Guide While Elastic Beanstalk creates your AWS resources and launches your application, the environment is in a Pending state. Status messages about launch events are continuously added to the list of Events . The environment's Domain is the URL for your deployed web application. In the left navigation pane, Go to environment also takes you to your domain. Similarly, the left navigation pane has links that correspond to the various tabs. Take note of the Configuration link in the left navigation pane. which displays a summary of environment configuration option values, grouped by category. Environment configuration settings Take note of the Configuration link in the left navigation pane. You can view and edit detailed environment settings, such as service roles, networking, database, scaling, managed platform updates, memory, health monitoring, rolling deployment, logging, and more! The various tabs contain detailed information about your environment: Step 3 - Explore the environment 15 AWS Elastic Beanstalk Developer Guide • Events – View an updating list of information and error messages from the Elastic Beanstalk service and other services for resources in your environment. • Health – View status and detailed health information for",
9
+ "for resources in your environment. • Health – View status and detailed health information for the Amazon EC2 instances running your application. • Logs – Retrieve and download logs from the Amazon EC2 in your environment. You can retrieve full logs or recent activity. The retrieved logs are available for 15 minutes. • Monitoring – View statistics for the environment, such as average latency and CPU utilization. • Alarms – View and edit alarms that are configured for environment metrics. • Managed updates – View information about upcoming and completed managed platform updates and instance replacement. • Tags – View and edit key-value pairs that are applied to your environment. Note Links in the console navigation pane will display the corresponding tab. Troubleshooting with logs For troubleshooting unexpected behaviors or debugging deployments, you might want to check the logs in your environments. You can request 100 lines of all the log files under the Logs tab in the Elastic Beanstalk console. Alternatively, you can connect directly to the Amazon EC2 instance and tail the logs in realtime. To request the logs (Elastic Beanstalk console) 1. Navigate to your environment in the Elastic Beanstalk console. 2. Choose the Logs tab or left-nav, then choose Request logs. 3. Select Last 100 lines. 4. After the logs are created, choose the Download link to view the logs in the browser. In the logs, find the log and note the directory for the nginx access log. Troubleshooting with logs 16 AWS Elastic Beanstalk Developer Guide Add a policy to enable connections to Amazon EC2 Before you can connect, you must add a policy that enables connections to Amazon EC2 with Session Manager. 1. Navigate to the IAM console. 2. Find and select the aws-elasticbeanstalk-ec2-role role. 3. Choose Add permission, then Attach policies. 4. Search",
10
+ "Find and select the aws-elasticbeanstalk-ec2-role role. 3. Choose Add permission, then Attach policies. 4. Search for a default policy that begins with the following text: AmazonSSMManagedEC2Instance, then add it to the role. To connect to your Amazon EC2 with Session Manager 1. Navigate to the Amazon EC2 console. 2. Choose Instances, then select your gs-app-web-env instance. 3. Choose Connect, then Session Manager. 4. Choose Connect. After connecting to the instance, start a bash shell and tail the logs: 1. Run the command bash. 2. Run the command cd /var/log/nginx. 3. Run the command tail -f access.log. 4. In your browser, go to the application domain URL. Refresh. Congratulations, you're connected! You should see log entries in your instance update every time you refresh the page. Connect button not working? If the connect button is not available, go back to IAM and verify that you added the necessary policy to the role. Troubleshooting with logs 17 AWS Elastic Beanstalk Developer Guide Step 4 - Update your application Eventually, you will want to update your application. You can deploy a new version at any time, as long as no other update operations are in progress on your environment. The application version that you started this tutorial with is called Sample Application. To update your application version 1. Download the following PHP sample application: PHP – php-v2.zip 2. Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region. 3. In the navigation pane, choose Environments, and then choose the name of your environment from the list. 4. On the environment overview page, choose Upload and deploy. 5. Select Choose file, and then upload the sample application source bundle that you downloaded. The console automatically fills in the Version label with a new unique label, automatically incrementing a trailing integer.",
11
+ "fills in the Version label with a new unique label, automatically incrementing a trailing integer. If you choose your own version label, ensure that it's unique. Step 4 - Update your application 18 AWS Elastic Beanstalk 6. Developer Guide Choose Deploy. While Elastic Beanstalk deploys your file to your Amazon EC2 instances, you can view the deployment status on the Environment overview page. While the application version is updated, the environment Health status is gray. When the deployment is complete, Elastic Beanstalk performs an application health check. When the application responds to the health check, it's considered healthy and the status returns to green. The environment overview shows the new Running Version—the name you provided as the Version label. Elastic Beanstalk also uploads your new application version and adds it to the table of application versions. To view the table, choose Application versions under getting-started-app on the navigation pane. Update success! You should see an updated \"v2\" message after refreshing your browser. If you want to edit the source yourself, unzip, edit, then re-zip the source bundle. On macOS, use the following command from inside your php directory with the -X to exclude extra file attributes: zip -X -r ../php-v2.zip . Step 5 - Scale your application You can configure your environment to better suit your application. For example, if you have a compute-intensive application, you can change the type of Amazon Elastic Compute Cloud (Amazon EC2) instance that is running your application. To apply configuration changes, Elastic Beanstalk performs an environment update. Some configuration changes are simple and happen quickly. Some changes require deleting and recreating AWS resources, which can take several minutes. When you change configuration settings, Elastic Beanstalk warns you about potential application downtime. Step 5 - Scale your application 19 AWS Elastic Beanstalk Developer Guide Increase",
12
+ "application downtime. Step 5 - Scale your application 19 AWS Elastic Beanstalk Developer Guide Increase capacity settings In this example of a configuration change, you edit your environment's capacity settings. You configure a load-balanced, scalable environment that has between two and four Amazon EC2 instances in its Auto Scaling group, and then you verify that the change occurred. Elastic Beanstalk creates an additional Amazon EC2 instance, adding to the single instance that it created initially. Then, Elastic Beanstalk associates both instances with the environment's load balancer. As a result, your application's responsiveness is improved and its availability is increased. To change your environment's capacity 1. Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region. 2. In the navigation pane, choose Environments, and then choose the name of your environment from the list. 3. In the navigation pane, choose Configuration. 4. In the Instance traffic and scaling configuration category, choose Edit. 5. Collapse the Instances section, so you can more easily see the Capacity section. Under Auto Scaling group change Environment type to Load balanced. 6. In the Instances row, change Min to 2 and Max to 4. Increase capacity settings 20 AWS Elastic Beanstalk 7. Developer Guide To save the changes choose Apply at the bottom of the page. If you are warned that the update will replace all of your current instances. Choose Confirm. The environment update can take a few minutes. You should see several updates in the list of events. Watch for the event Successfully deployed new configuration to environment. Verify increased capacity After the environment update is complete and the environment is ready, Elastic Beanstalk automatically launched a second instance to meet your new minimum capacity setting. To verify the increased capacity 1. Choose Health from either the tab list or",
13
+ "setting. To verify the increased capacity 1. Choose Health from either the tab list or left navigation pane. 2. Review the Enhanced instance health section. You just scaled up! With two Amazon EC2 instances, your environment capacity has doubled, and it only took a few minutes. Cleaning up your Elastic Beanstalk environment To ensure that you're not charged for any services you aren't using, delete all application versions and terminate environments, which also deletes the AWS resources that the environment created for you. Verify increased capacity 21"
14
+ ]
dataset/chunks/ec2_chunks.json ADDED
@@ -0,0 +1,20 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "Amazon Elastic Compute Cloud User Guide What is Amazon EC2? Amazon Elastic Compute Cloud (Amazon EC2) provides on-demand, scalable computing capacity in the Amazon Web Services (AWS) Cloud. Using Amazon EC2 reduces hardware costs so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. You can add capacity (scale up) to handle compute-heavy tasks, such as monthly or yearly processes, or spikes in website traffic. When usage decreases, you can reduce capacity (scale down) again. An EC2 instance is a virtual server in the AWS Cloud. When you launch an EC2 instance, the instance type that you specify determines the hardware available to your instance. Each instance type offers a different balance of compute, memory, network, and storage resources. For more information, see the Amazon EC2 Instance Types Guide. Features of Amazon EC2 Amazon EC2 provides the following high-level features: Instances Virtual servers. Amazon Machine Images (AMIs) Preconfigured templates for your instances that package the components you need for your server (including the operating system and additional software). Instance types Various configurations of CPU, memory, storage, networking capacity, and graphics hardware for your instances. Features 1 Amazon Elastic Compute Cloud User Guide Amazon EBS volumes Persistent storage volumes for your data using Amazon Elastic Block Store (Amazon EBS). Instance store volumes Storage volumes for temporary data that is deleted when you stop, hibernate, or terminate your instance. Key pairs Secure login information for your instances. AWS stores the public key and you store the private key in a secure place. Security groups A virtual firewall that allows you to specify the protocols, ports, and source IP ranges that can reach your instances, and the destination IP ranges to",
3
+ "and source IP ranges that can reach your instances, and the destination IP ranges to which your instances can connect. Amazon EC2 supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS). For more information about PCI DSS, including how to request a copy of the AWS PCI Compliance Package, see PCI DSS Level 1. Related services Services to use with Amazon EC2 You can use other AWS services with the instances that you deploy using Amazon EC2. Amazon EC2 Auto Scaling Helps ensure you have the correct number of Amazon EC2 instances available to handle the load for your application. AWS Backup Automate backing up your Amazon EC2 instances and the Amazon EBS volumes attached to them. Amazon CloudWatch Monitor your instances and Amazon EBS volumes. Related services 2 Amazon Elastic Compute Cloud User Guide Elastic Load Balancing Automatically distribute incoming application traffic across multiple instances. Amazon GuardDuty Detect potentially unauthorized or malicious use of your EC2 instances. EC2 Image Builder Automate the creation, management, and deployment of customized, secure, and up-to-date server images. AWS Launch Wizard Size, configure, and deploy AWS resources for third-party applications without having to manually identify and provision individual AWS resources. AWS Systems Manager Perform operations at scale on EC2 instances with this secure end-to-end management solution. Additional compute services You can launch instances using another AWS compute service instead of using Amazon EC2. Amazon Lightsail Build websites or web applications using Amazon Lightsail, a cloud platform that provides the resources that you need to deploy your project quickly, for a low, predictable monthly price. To compare Amazon EC2 and Lightsail, see Amazon Lightsail or Amazon EC2. Amazon Elastic Container Service (Amazon",
4
+ "Amazon EC2 and Lightsail, see Amazon Lightsail or Amazon EC2. Amazon Elastic Container Service (Amazon ECS) Deploy, manage, and scale containerized applications on a cluster of EC2 instances. For more information, see Choosing an AWS container service. Amazon Elastic Kubernetes Service (Amazon EKS) Run your Kubernetes applications on AWS. For more information, see Choosing an AWS container service. Related services 3 Amazon Elastic Compute Cloud User Guide Access Amazon EC2 You can create and manage your Amazon EC2 instances using the following interfaces: Amazon EC2 console A simple web interface to create and manage Amazon EC2 instances and resources. If you've signed up for an AWS account, you can access the Amazon EC2 console by signing into the AWS Management Console and selecting EC2 from the console home page. AWS Command Line Interface Enables you to interact with AWS services using commands in your command-line shell. It is supported on Windows, Mac, and Linux. For more information about the AWS CLI , see AWS Command Line Interface User Guide. You can find the Amazon EC2 commands in the AWS CLI Command Reference. AWS CloudFormation Amazon EC2 supports creating resources using AWS CloudFormation. You create a template, in JSON or YAML format, that describes your AWS resources, and AWS CloudFormation provisions and configures those resources for you. You can reuse your CloudFormation templates to provision the same resources multiple times, whether in the same Region and account or in multiple Regions and accounts. For more information about supported resource types and properties for Amazon EC2, see EC2 resource type reference in the AWS CloudFormation User Guide. AWS SDKs If you prefer to build applications using language-specific APIs instead of submitting a request over HTTP or HTTPS, AWS provides libraries, sample code, tutorials, and other resources for software developers. These libraries provide",
5
+ "AWS provides libraries, sample code, tutorials, and other resources for software developers. These libraries provide basic functions that automate tasks such as cryptographically signing your requests, retrying requests, and handling error responses, making it easier for you to get started. For more information, see Tools to Build on AWS. AWS Tools for PowerShell A set of PowerShell modules that are built on the functionality exposed by the SDK for .NET. The Tools for PowerShell enable you to script operations on your AWS resources from the PowerShell command line. To get started, see the AWS Tools for PowerShell User Guide. You can find the cmdlets for Amazon EC2, in the AWS Tools for PowerShell Cmdlet Reference. Access EC2 4 Amazon Elastic Compute Cloud User Guide Query API Amazon EC2 provides a Query API. These requests are HTTP or HTTPS requests that use the HTTP verbs GET or POST and a Query parameter named Action. For more information about the API actions for Amazon EC2, see Actions in the Amazon EC2 API Reference. Pricing for Amazon EC2 Amazon EC2 provides the following pricing options: Free Tier You can get started with Amazon EC2 for free. To explore the Free Tier options, see AWS Free Tier. On-Demand Instances Pay for the instances that you use by the second, with a minimum of 60 seconds, with no longterm commitments or upfront payments. Savings Plans You can reduce your Amazon EC2 costs by making a commitment to a consistent amount of usage, in USD per hour, for a term of 1 or 3 years. Reserved Instances You can reduce your Amazon EC2 costs by making a commitment to a specific instance configuration, including instance type and Region, for a term of 1 or 3 years. Spot Instances Request unused EC2 instances, which can reduce your",
6
+ "of 1 or 3 years. Spot Instances Request unused EC2 instances, which can reduce your Amazon EC2 costs significantly. Dedicated Hosts Reduce costs by using a physical EC2 server that is fully dedicated for your use, either OnDemand or as part of a Savings Plan. You can use your existing server-bound software licenses and get help meeting compliance requirements. On-Demand Capacity Reservations Reserve compute capacity for your EC2 instances in a specific Availability Zone for any duration of time. Pricing 5 Amazon Elastic Compute Cloud User Guide Per-second billing Removes the cost of unused minutes and seconds from your bill. For a complete list of charges and prices for Amazon EC2 and more information about the purchase models, see Amazon EC2 pricing. Estimates, billing, and cost optimization To create estimates for your AWS use cases, use the AWS Pricing Calculator. To estimate the cost of transforming Microsoft workloads to a modern architecture that uses open source and cloud-native services deployed on AWS, use the AWS Modernization Calculator for Microsoft Workloads. To see your bill, go to the Billing and Cost Management Dashboard in the AWS Billing and Cost Management console. Your bill contains links to usage reports that provide details about your bill. To learn more about AWS account billing, see AWS Billing and Cost Management User Guide. If you have questions concerning AWS billing, accounts, and events, contact AWS Support. To calculate the cost of a sample provisioned environment, see Cloud Economics Center. When calculating the cost of a provisioned environment, remember to include incidental costs such as snapshot storage for EBS volumes. You can optimize the cost, security, and performance of your AWS environment using AWS Trusted Advisor. You can use AWS Cost Explorer to analyze the cost and usage of your EC2 instances. You can view data",
7
+ "Explorer to analyze the cost and usage of your EC2 instances. You can view data up to the last 13 months, and forecast how much you are likely to spend for the next 12 months. For more information, see Analyzing your costs and usage with AWS Cost Explorer in the AWS Cost Management User Guide. Resources • Amazon EC2 features • AWS re:Post • AWS Skill Builder • AWS Support Estimates, billing, and cost optimization 6 Amazon Elastic Compute Cloud User Guide • Hands-on Tutorials • Web Hosting • Windows on AWS Resources 7 Amazon Elastic Compute Cloud User Guide Get started with Amazon EC2 Use this tutorial to get started with Amazon Elastic Compute Cloud (Amazon EC2). You'll learn how to launch and connect to an EC2 instance. An instance is a virtual server in the AWS Cloud. With Amazon EC2, you can set up and configure the operating system and applications that run on your instance. Overview The following diagram shows the key components that you'll use in this tutorial: • An image – A template that contains the software to run on your instance, such as the operating system. • A key pair – A set of security credentials that you use to prove your identity when connecting to your instance. The public key is on your instance and the private key is on your computer. • A network – A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. To help you get started quickly, your account comes with a default VPC in each AWS Region, and each default VPC has a default subnet in each Availability Zone. • A security group – Acts as a virtual firewall to control inbound and outbound traffic. • An EBS volume – We require a",
8
+ "firewall to control inbound and outbound traffic. • An EBS volume – We require a root volume for the image. You can optionally add data volumes. 8 Amazon Elastic Compute Cloud User Guide Cost for this tutorial When you create your AWS account, you can get started with Amazon EC2 for free using the AWS Free Tier. If you created your AWS account before July 15, 2025, it's less than 12 months old, and you haven't already exceeded the Free Tier benefits for Amazon EC2, it won't cost you anything to complete this tutorial, because we help you select options that are within the Free Tier benefits. Otherwise, you'll incur the standard Amazon EC2 usage fees from the time that you launch the instance (even if it remains idle) until you terminate it. If you created your AWS account on or after July 15, 2025, it's less than 6 months old, and you haven't used up all your credits, it won't cost you anything to complete this tutorial, because we help you select options that are within the Free Tier benefits. For information on how to determine whether you are eligible for the Free Tier, see the section called “Track your Free Tier usage”. Tasks • Step 1: Launch an instance • Step 2: Connect to your instance • Step 3: Clean up your instance 9 Amazon Elastic Compute Cloud User Guide • Next steps Step 1: Launch an instance You can launch an EC2 instance using the AWS Management Console as described in the following procedure. This tutorial is intended to help you quickly launch your first instance, so it doesn't cover all possible options. To launch an instance 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. In the navigation bar at the top of the screen, we",
9
+ "console at https://console.aws.amazon.com/ec2/. 2. In the navigation bar at the top of the screen, we display the current AWS Region — for example, Ohio. You can use the selected Region, or optionally select a Region that is closer to you. 3. From the EC2 console dashboard, in the Launch instance pane, choose Launch instance. 4. Under Name and tags, for Name, enter a descriptive name for your instance. 5. Under Application and OS Images (Amazon Machine Image), do the following: a. Choose Quick Start, and then choose the operating system (OS) for your instance. For your first Linux instance, we recommend that you choose Amazon Linux. b. From Amazon Machine Image (AMI), select an AMI that is marked Free Tier eligible. 6. Under Instance type, for Instance type, select an instance type that is marked Free Tier eligible. 7. Under Key pair (login), for Key pair name, choose an existing key pair or choose Create new key pair to create your first key pair. Warning If you choose Proceed without a key pair (Not recommended), you won't be able to connect to your instance using the methods described in this tutorial. 8. Under Network settings, notice that we selected your default VPC, selected the option to use the default subnet in an Availability Zone that we choose for you, and configured a security group with a rule that allows connections to your instance from anywhere (0.0.0.0.0/0). Step 1: Launch an instance 10 Amazon Elastic Compute Cloud User Guide Warning If you specify 0.0.0.0/0, you are enabling traffic from any IP addresses in the world. For the SSH and RDP protocols, you might consider this acceptable for a short time in a test environment, but it's unsafe for production environments. In production, be sure to authorize access only from the appropriate",
10
+ "unsafe for production environments. In production, be sure to authorize access only from the appropriate individual IP address or range of addresses. For your first instance, we recommend that you use the default settings. Otherwise, you can update your network settings as follows: 9. • (Optional) To use a specific default subnet, choose Edit and then choose a subnet. • (Optional) To use a different VPC, choose Edit and then choose an existing VPC. If the VPC isn't configured for public internet access, you won't be able to connect to your instance. • (Optional) To restrict inbound connection traffic to a specific network, choose Custom instead of Anywhere, and enter the CIDR block for your network. • (Optional) To use a different security group, choose Select existing security group and choose an existing security group. If the security group does not have a rule that allows connection traffic from your network, you won't be able to connect to your instance. For a Linux instance, you must allow SSH traffic. For a Windows instance, you must allow RDP traffic. Under Configure storage, notice that we configured a root volume but no data volumes. This is sufficient for test purposes. 10. Review a summary of your instance configuration in the Summary panel, and when you're ready, choose Launch instance. 11. If the launch is successful, choose the ID of the instance from the Success notification to open the Instances page and monitor the status of the launch. 12. Select the checkbox for the instance. The initial instance state is pending. After the instance starts, its state changes to running. Choose the Status and alarms tab. After your instance passes its status checks, it is ready to receive connection requests. Step 1: Launch an instance 11 Amazon Elastic Compute Cloud User Guide Step",
11
+ "connection requests. Step 1: Launch an instance 11 Amazon Elastic Compute Cloud User Guide Step 2: Connect to your instance The procedure that you use depends on the operating system of the instance. If you can't connect to your instance, see Troubleshoot issues connecting to your Amazon EC2 Linux instance for assistance. Linux instances You can connect to your Linux instance using any SSH client. If you are running Windows on your computer, open a terminal and run the ssh command to verify that you have an SSH client installed. If the command is not found, install OpenSSH for Windows. To connect to your instance using SSH 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. In the navigation pane, choose Instances. 3. Select the instance and then choose Connect. 4. On the Connect to instance page, choose the SSH client tab. 5. (Optional) If you created a key pair when you launched the instance and downloaded the private key (.pem file) to a computer running Linux or macOS, run the example chmod command to set the permissions for your private key. 6. Copy the example SSH command. The following is an example, where key-pair-name.pem is the name of your private key file, ec2-user is the username associated with the image, and the string after the @ symbol is the public DNS name of the instance. ssh -i key-pair-name.pem ec2-user@ec2-198-51-100-1.us-east-2.compute.amazonaws.com 7. In a terminal window on your computer, run the ssh command that you saved in the previous step. If the private key file is not in the current directory, you must specify the fully-qualified path to the key file in this command. The following is an example response: The authenticity of host 'ec2-198-51-100-1.us-east-2.compute.amazonaws.com (198-51-100-1)' can't be established. ECDSA key fingerprint is l4UB/neBad9tvkgJf1QZWxheQmR59WgrgzEimCG6kZY. Are you sure you want to continue",
12
+ "can't be established. ECDSA key fingerprint is l4UB/neBad9tvkgJf1QZWxheQmR59WgrgzEimCG6kZY. Are you sure you want to continue connecting (yes/no)? Step 2: Connect to your instance 12 Amazon Elastic Compute Cloud 8. User Guide (Optional) Verify that the fingerprint in the security alert matches the instance fingerprint contained in the console output when you first start an instance. To get the console output, choose Actions, Monitor and troubleshoot, Get system log. If the fingerprints don't match, someone might be attempting a man-in-the-middle attack. If they match, continue to the next step. 9. Enter yes. The following is an example response: Warning: Permanently added 'ec2-198-51-100-1.useast-2.compute.amazonaws.com' (ECDSA) to the list of known hosts. Windows instances To connect to a Windows instance using RDP, you must retrieve the initial administrator password and then enter this password when you connect to your instance. It takes a few minutes after instance launch before this password is available. Your account must have permission to call the GetPasswordData action. For more information, see Example policies to control access the Amazon EC2 API. The default username for the Administrator account depends on the language of the operating system (OS) contained in the AMI. To determine the correct username, identify the language of the OS, and then choose the corresponding username. For example, for an English OS, the username is Administrator, for a French OS it's Administrateur, and for a Portuguese OS it's Administrador. If a language version of the OS does not have a username in the same language, choose the username Administrator (Other). For more information, see Localized Names for Administrator Account in Windows in the Microsoft website. To retrieve the initial administrator password 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. In the navigation pane, choose Instances. 3. Select the instance and then choose Connect. 4. On the",
13
+ "navigation pane, choose Instances. 3. Select the instance and then choose Connect. 4. On the Connect to instance page, choose the RDP client tab. 5. For Username, choose the default username for the Administrator account. The username you choose must match the language of the operating system (OS) contained in the AMI that you Step 2: Connect to your instance 13 Amazon Elastic Compute Cloud User Guide used to launch your instance. If there is no username in the same language as your OS, choose Administrator (Other). 6. Choose Get password. 7. On the Get Windows password page, do the following: a. Choose Upload private key file and navigate to the private key (.pem) file that you specified when you launched the instance. Select the file and choose Open to copy the entire contents of the file to this window. b. Choose Decrypt password. The Get Windows password page closes, and the default administrator password for the instance appears under Password, replacing the Get password link shown previously. c. Copy the password and save it in a safe place. This password is required to connect to the instance. The following procedure uses the Remote Desktop Connection client for Windows (MSTSC). If you're using a different RDP client, download the RDP file and then see the documentation for the RDP client for the steps to establish the RDP connection. To connect to a Windows instance using an RDP client 1. On the Connect to instance page, choose Download remote desktop file. When the file download is finished, choose Cancel to return to the Instances page. The RDP file is downloaded to your Downloads folder. 2. Run mstsc.exe to open the RDP client. 3. Expand Show options, choose Open, and select the .rdp file from your Downloads folder. 4. By default, Computer",
14
+ "choose Open, and select the .rdp file from your Downloads folder. 4. By default, Computer is the public IPv4 DNS name of the instance and User name is the administrator account. To connect to the instance using IPv6 instead, replace the public IPv4 DNS name of the instance with its IPv6 address. Review the default settings and change them as needed. 5. Choose Connect. If you receive a warning that the publisher of the remote connection is unknown, choose Connect to continue. 6. Enter the password that you saved previously, and then choose OK. 7. Due to the nature of self-signed certificates, you might get a warning that the security certificate could not be authenticated. Do one of the following: • If you trust the certificate, choose Yes to connect to your instance. Step 2: Connect to your instance 14 Amazon Elastic Compute Cloud • User Guide [Windows] Before you proceed, compare the thumbprint of the certificate with the value in the system log to confirm the identity of the remote computer. Choose View certificate and then choose Thumbprint from the Details tab. Compare this value to the value of RDPCERTIFICATE-THUMBPRINT in Actions, Monitor and troubleshoot, Get system log. • [Mac OS X] Before you proceed, compare the fingerprint of the certificate with the value in the system log to confirm the identity of the remote computer. Choose Show Certificate, expand Details, and choose SHA1 Fingerprints. Compare this value to the value of RDPCERTIFICATE-THUMBPRINT in Actions, Monitor and troubleshoot, Get system log. 8. If the RDP connection is successful, the RDP client displays the Windows login screen and then the Windows desktop. If you receive an error message instead, see the section called “Remote Desktop can't connect to the remote computer”. When you are finished with the RDP connection, you",
15
+ "can't connect to the remote computer”. When you are finished with the RDP connection, you can close the RDP client. Step 3: Clean up your instance After you've finished with the instance that you created for this tutorial, you should clean up by terminating the instance. If you want to do more with this instance before you clean up, see Next steps. Important Terminating an instance effectively deletes it; you can't reconnect to an instance after you've terminated it. You'll stop incurring charges for that instance or usage that counts against your Free Tier limits as soon as the instance status changes to shutting down or terminated. To keep your instance for later, but not incur charges or usage that counts against your Free Tier limits, you can stop the instance now and then start it again later. For more information, see Stop and start Amazon EC2 instances. To terminate your instance 1. In the navigation pane, choose Instances. In the list of instances, select the instance. 2. Choose Instance state, Terminate (delete) instance. Step 3: Clean up your instance 15 Amazon Elastic Compute Cloud 3. User Guide Choose Terminate (delete) when prompted for confirmation. Amazon EC2 shuts down and terminates your instance. After your instance is terminated, it remains visible on the console for a short while, and then the entry is automatically deleted. You cannot remove the terminated instance from the console display yourself. Next steps After you start your instance, you might want to explore the following next steps: • Explore the Amazon EC2 core concepts with the introductory tutorials. For more information, see Tutorials for launching EC2 instances. • Learn how to track your Amazon EC2 Free Tier usage using the console. For more information, see the section called “Track your Free Tier usage”. • Configure",
16
+ "console. For more information, see the section called “Track your Free Tier usage”. • Configure a CloudWatch alarm to notify you if your usage exceeds the Free Tier (for accounts created before July 15, 2025). For more information, see Tracking your AWS Free Tier usage in the AWS Billing User Guide. • Add an EBS volume. For more information, see Create an Amazon EBS volume in the Amazon EBS User Guide. • Learn how to remotely manage your EC2 instance using the Run command. For more information, see AWS Systems Manager Run Command in the AWS Systems Manager User Guide. • Learn about instance purchasing options. For more information, see Amazon EC2 billing and purchasing options. • Get advice about instance types. For more information, see Get recommendations from EC2 instance type finder. Next steps 16 Amazon Elastic Compute Cloud User Guide Best practices for Amazon EC2 To ensure the maximum benefit from Amazon EC2, we recommend that you perform the following best practices. Security • Manage access to AWS resources and APIs using identity federation with an identity provider and IAM roles whenever possible. For more information, see Creating IAM policies in the IAM User Guide. • Implement the least permissive rules for your security group. • Regularly patch, update, and secure the operating system and applications on your instance. For more information, see Update management. For guidelines specific to Windows operating systems, see Security best practices for Windows instances. • Use Amazon Inspector to automatically discover and scan Amazon EC2 instances for software vulnerabilities and unintended network exposure. For more information, see the Amazon Inspector User Guide. • Use AWS Security Hub controls to monitor your Amazon EC2 resources against security best practices and security standards. For more information about using Security Hub, see Amazon Elastic Compute Cloud",
17
+ "and security standards. For more information about using Security Hub, see Amazon Elastic Compute Cloud controls in the AWS Security Hub User Guide. Storage • Understand the implications of the root device type for data persistence, backup, and recovery. For more information, see Root device type. • Use separate Amazon EBS volumes for the operating system versus your data. Ensure that the volume with your data persists after instance termination. For more information, see Preserve data when an instance is terminated. • Use the instance store available for your instance to store temporary data. Remember that the data stored in instance store is deleted when you stop, hibernate, or terminate your instance. If you use instance store for database storage, ensure that you have a cluster with a replication factor that ensures fault tolerance. • Encrypt EBS volumes and snapshots. For more information, see Amazon EBS encryption in the Amazon EBS User Guide. 17 Amazon Elastic Compute Cloud User Guide Resource management • Use instance metadata and custom resource tags to track and identify your AWS resources. For more information, see Use instance metadata to manage your EC2 instance and Tag your Amazon EC2 resources. • View your current limits for Amazon EC2. Plan to request any limit increases in advance of the time that you'll need them. For more information, see Amazon EC2 service quotas. • Use AWS Trusted Advisor to inspect your AWS environment, and then make recommendations when opportunities exist to save money, improve system availability and performance, or help close security gaps. For more information, see AWS Trusted Advisor in the AWS Support User Guide. Backup and recovery • Regularly back up your EBS volumes using Amazon EBS snapshots, and create an Amazon Machine Image (AMI) from your instance to save the configuration as a template",
18
+ "an Amazon Machine Image (AMI) from your instance to save the configuration as a template for launching future instances. For more information about AWS services that help achieve this use case, see AWS Backup and Amazon Data Lifecycle Manager. • Deploy critical components of your application across multiple Availability Zones, and replicate your data appropriately. • Design your applications to handle dynamic IP addressing when your instance restarts. For more information, see Amazon EC2 instance IP addressing. • Monitor and respond to events. For more information, see Monitor Amazon EC2 resources. • Ensure that you are prepared to handle failover. For a basic solution, you can manually attach a network interface or Elastic IP address to a replacement instance. For more information, see Elastic network interfaces. For an automated solution, you can use Amazon EC2 Auto Scaling. For more information, see the Amazon EC2 Auto Scaling User Guide. • Regularly test the process of recovering your instances and Amazon EBS volumes to ensure data and services are restored successfully. Networking • Set the time-to-live (TTL) value for your applications to 255, for IPv4 and IPv6. If you use a smaller value, there is a risk that the TTL will expire while application traffic is in transit, causing reachability issues for your instances. 18 Amazon Elastic Compute Cloud User Guide Amazon Machine Images in Amazon EC2 An Amazon Machine Image (AMI) is an image that provides the software that is required to set up and boot an Amazon EC2 instance. Each AMI also contains a block device mapping that specifies the block devices to attach to the instances that you launch. You must specify an AMI when you launch an instance. The AMI must be compatible with the instance type that you chose for your instance. You can use an AMI",
19
+ "with the instance type that you chose for your instance. You can use an AMI provided by AWS, a public AMI, an AMI that someone else shared with you, or an AMI that you purchased from the AWS Marketplace. An AMI is specific to the following: • Region • Operating system • Processor architecture • Root device type • Virtualization type You can launch multiple instances from a single AMI when you require multiple instances with the same configuration. You can use different AMIs to launch instances when you require instances with different configurations, as shown in the following diagram. 19 Amazon Elastic Compute Cloud User Guide You can create an AMI from your Amazon EC2 instances and then use it to launch instances with the same configuration. You can copy an AMI to another AWS Region, and then use it to launch instances in that Region. You can also share an AMI that you created with other accounts so that they can launch instances with the same configuration. You can sell your AMI using the AWS Marketplace. Contents • AMI types and characteristics in Amazon EC2 • Find an AMI that meets the requirements for your EC2 instance • Paid AMIs in the AWS Marketplace for Amazon EC2 instances • Amazon EC2 AMI lifecycle • Instance launch behavior with Amazon EC2 boot modes • Use encryption with EBS-backed AMIs • Understand shared AMI usage in Amazon EC2 • Monitor AMI events using Amazon EventBridge • Understand AMI billing information • AMI quotas in Amazon EC2 20"
20
+ ]
dataset/chunks/ecs-dg_chunks.json ADDED
@@ -0,0 +1,20 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "Amazon Elastic Container Service Developer Guide What is Amazon Elastic Container Service? Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications. As a fully managed service, Amazon ECS comes with AWS configuration and operational best practices built-in. It's integrated with both AWS tools, such as Amazon Elastic Container Registry, and third-party tools, such as Docker. This integration makes it easier for teams to focus on building the applications, not the environment. You can run and scale your container workloads across AWS Regions in the cloud, and on-premises, without the complexity of managing a control plane. Terminology and components There are three layers in Amazon ECS: • Capacity - The infrastructure where your containers run • Controller - Deploy and manage your applications that run on the containers • Provisioning - The tools that you can use to interface with the scheduler to deploy and manage your applications and containers The following diagram shows the Amazon ECS layers. Terminology and components 1 Amazon Elastic Container Service Developer Guide The capacity is the infrastructure where your containers run. The following is an overview of the capacity options: • Amazon EC2 instances in the AWS cloud You choose the instance type, the number of instances, and manage the capacity. • Serverless (AWS Fargate) in the AWS cloud Fargate is a serverless, pay-as-you-go compute engine. With Fargate you don't need to manage servers, handle capacity planning, or isolate container workloads for security. • On-premises virtual machines (VM) or servers Amazon ECS Anywhere provides support for registering an external instance such as an onpremises server or virtual machine (VM), to your Amazon ECS cluster. The Amazon ECS scheduler is the software that manages your applications. Terminology and components 2 Amazon Elastic",
3
+ "ECS scheduler is the software that manages your applications. Terminology and components 2 Amazon Elastic Container Service Developer Guide Features Amazon ECS provides the following high-level features: Task definition The blueprint for the application. Cluster The infrastructure your application runs on. Task An application such as a batch job that performs work, and then stops. Service A long running stateless application. Account Setting Allows access to features. Cluster Auto Scaling Amazon ECS manages the scaling of Amazon EC2 instances that are registered to your cluster. Service Auto Scaling Amazon ECS increases or decreases the desired number of tasks in your service automatically. Provisioning There are multiple options for provisioning Amazon ECS: • AWS Management Console — Provides a web interface that you can use to access your Amazon ECS resources. • AWS Command Line Interface (AWS CLI) — Provides commands for a broad set of AWS services, including Amazon ECS. It's supported on Windows, Mac, and Linux. For more information, see AWS Command Line Interface. • AWS SDKs — Provides language-specific APIs and takes care of many of the connection details. These include calculating signatures, handling request retries, and error handling. For more information, see AWS SDKs. Features 3 Amazon Elastic Container Service Developer Guide • AWS CDK — Provides an open-source software development framework that you can use to model and provision your cloud application resources using familiar programming languages. The AWS CDK provisions your resources in a safe, repeatable manner through AWS CloudFormation. Pricing Amazon ECS pricing depends on the capacity option you choose for your containers. • Amazon ECS pricing – Pricing information for Amazon ECS. • AWS Fargate pricing – Pricing information for Fargate. Related services Services to use with Amazon ECS You can use other AWS services to help you deploy yours tasks and services",
4
+ "ECS You can use other AWS services to help you deploy yours tasks and services on Amazon ECS. Amazon EC2 Auto Scaling Helps ensure you have the correct number of Amazon EC2 instances available to handle the load for your application. Amazon CloudWatch Monitor your services and tasks. Amazon Elastic Container Registry Store and manage container images. Elastic Load Balancing Automatically distribute incoming service traffic. Amazon GuardDuty Detect potentially unauthorized or malicious use of your container instances and workloads. Pricing 4 Amazon Elastic Container Service Developer Guide Learn how to create and use Amazon ECS resources The following guides provide an introduction to the tools available to access Amazon ECS and introductory procedures to run containers. Docker basics takes you through the basic steps to create a Docker container image and upload it to an Amazon ECR private repository. The getting started guides walk you through using the AWS Copilot command line interface and the AWS Management Console to complete the common tasks to run your containers on Amazon ECS and AWS Fargate. Contents • Set up to use Amazon ECS • Creating a container image for use on Amazon ECS • Learn how to create an Amazon ECS Linux task for the Fargate launch type • Learn how to create an Amazon ECS Windows task for the Fargate launch type • Learn how to create an Amazon ECS Windows task for the EC2 launch type • Creating Amazon ECS resources using the AWS CDK • Creating Amazon ECS resources using the AWS Copilot command line interface Set up to use Amazon ECS If you've already signed up for Amazon Web Services (AWS) and have been using Amazon Elastic Compute Cloud (Amazon EC2), you are close to being able to use Amazon ECS. The set-up process for the two services",
5
+ "close to being able to use Amazon ECS. The set-up process for the two services is similar. The following guide prepares you for launching your first Amazon ECS cluster. Complete the following tasks to get set up for Amazon ECS. AWS Management Console The AWS Management Console is a browser-based interface for managing Amazon ECS resources. The console provides a visual overview of the service, making it easy to explore Amazon ECS features and functions without needing to use additional tools. Many related tutorials and walkthroughs are available that can guide you through use of the console. For a tutorial that guides you through the console, see Learn how to create and use Amazon ECS resources. Set up 5 Amazon Elastic Container Service Developer Guide When starting out, many customers prefer using the console because it provides instant visual feedback on whether the actions they take succeed. AWS customers that are familiar with the AWS Management Console, can easily manage related resources such as load balancers and Amazon EC2 instances. Start with the AWS Management Console. Sign up for an AWS account If you do not have an AWS account, complete the following steps to create one. To sign up for an AWS account 1. Open https://portal.aws.amazon.com/billing/signup. 2. Follow the online instructions. Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad. When you sign up for an AWS account, an AWS account root user is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform tasks that require root user access. AWS sends you a confirmation email after the sign-up process is complete.",
6
+ "root user access. AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to https://aws.amazon.com/ and choosing My Account. Create a user with administrative access After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks. Secure your AWS account root user 1. Sign in to the AWS Management Console as the account owner by choosing Root user and entering your AWS account email address. On the next page, enter your password. For help signing in by using root user, see Signing in as the root user in the AWS Sign-In User Guide. Sign up for an AWS account 6 Amazon Elastic Container Service 2. Developer Guide Turn on multi-factor authentication (MFA) for your root user. For instructions, see Enable a virtual MFA device for your AWS account root user (console) in the IAM User Guide. Create a user with administrative access 1. Enable IAM Identity Center. For instructions, see Enabling AWS IAM Identity Center in the AWS IAM Identity Center User Guide. 2. In IAM Identity Center, grant administrative access to a user. For a tutorial about using the IAM Identity Center directory as your identity source, see Configure user access with the default IAM Identity Center directory in the AWS IAM Identity Center User Guide. Sign in as the user with administrative access • To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user. For help signing in using an IAM Identity Center user, see Signing in to",
7
+ "user. For help signing in using an IAM Identity Center user, see Signing in to the AWS access portal in the AWS Sign-In User Guide. Assign access to additional users 1. In IAM Identity Center, create a permission set that follows the best practice of applying leastprivilege permissions. For instructions, see Create a permission set in the AWS IAM Identity Center User Guide. 2. Assign users to a group, and then assign single sign-on access to the group. For instructions, see Add groups in the AWS IAM Identity Center User Guide. Create a user with administrative access 7 Amazon Elastic Container Service Developer Guide Create a virtual private cloud You can use Amazon Virtual Private Cloud (Amazon VPC) to launch AWS resources into a virtual network that you've defined. We strongly suggest that you launch your container instances in a VPC. If you have a default VPC, you can skip this section and move to the next task, Create a security group. To determine whether you have a default VPC, see Work with your default VPC and default subnets in the Amazon VPC User Guide. Otherwise, you can create a nondefault VPC in your account using the steps below. For information about how to create a VPC, see Create a VPC in the Amazon VPC User Guide, and use the following table to determine what options to select. Option Value Resources to create VPC only Name Optionally provide a name for your VPC. IPv4 CIDR block IPv4 CIDR manual input The CIDR block size must have a size between /16 and /28. IPv6 CIDR block No IPv6 CIDR block Tenancy Default For more information about Amazon VPC, see What is Amazon VPC? in the Amazon VPC User Guide. Create a security group Security groups act as a firewall for associated",
8
+ "VPC User Guide. Create a security group Security groups act as a firewall for associated container instances, controlling both inbound and outbound traffic at the container instance level. You can add rules to a security group that enable you to connect to your container instance from your IP address using SSH. You can also add Create a virtual private cloud 8 Amazon Elastic Container Service Developer Guide rules that allow inbound and outbound HTTP and HTTPS access from anywhere. Add any rules to open ports that are required by your tasks. Container instances require external network access to communicate with the Amazon ECS service endpoint. If you plan to launch container instances in multiple Regions, you need to create a security group in each Region. For more information, see Regions and Availability Zones in the Amazon EC2 User Guide. Tip You need the public IP address of your local computer, which you can get using a service. For example, we provide the following service: http://checkip.amazonaws.com/ or https:// checkip.amazonaws.com/. To locate another service that provides your IP address, use the search phrase \"what is my IP address.\" If you are connecting through an internet service provider (ISP) or from behind a firewall without a static IP address, you must find out the range of IP addresses used by client computers. For information about how to create a security group, see Create a security group for your Amazon EC2 instance in the Amazon EC2 User Guide and use the following table to determine what options to select. Option Value Region The same Region in which you created your key pair. Name A name that is easy for you to remember, such as ecs-insta nces-default-cluster. VPC The default VPC (marked with \"(default)\"). Note If your account supports Amazon EC2 Classic, select the VPC",
9
+ "VPC (marked with \"(default)\"). Note If your account supports Amazon EC2 Classic, select the VPC Create a security group 9 Amazon Elastic Container Service Option Developer Guide Value that you created in the previous task. For information about the outbound rules to add for your use cases, see Security group rules for different use cases in the Amazon EC2 User Guide. Amazon ECS container instances do not require any inbound ports to be open. However, you might want to add an SSH rule so you can log into the container instance and examine the tasks with Docker commands. You can also add rules for HTTP and HTTPS if you want your container instance to host a task that runs a web server. Container instances do require external network access to communicate with the Amazon ECS service endpoint. Complete the following steps to add these optional security group rules. Add the following three inbound rules to your security group.For information about how to create a security group, see Configure security group rules in the Amazon EC2 User Guide. Option Value HTTP rule Type: HTTP Source: Anywhere (0.0.0.0/0 ) This option automatically adds the 0.0.0.0/0 IPv4 CIDR block as the source. This is acceptable for a short time in a test environment, but it's unsafe in production environments. In production, authorize only a specific IP address or range of addresses to access your instance. HTTPS rule Create a security group Type: HTTPS 10 Amazon Elastic Container Service Option Developer Guide Value Source: Anywhere (0.0.0.0/0 ) This is acceptable for a short time in a test environment, but it's unsafe in productio n environments. In productio n, authorize only a specific IP address or range of addresses to access your instance. Create a security group 11 Amazon Elastic Container Service Developer Guide Option",
10
+ "access your instance. Create a security group 11 Amazon Elastic Container Service Developer Guide Option Value SSH rule Type: SSH Source: Custom, specify the public IP address of your computer or network in CIDR notation. To specify an individual IP address in CIDR notation, add the routing prefix /32. For example, if your IP address is 203.0.113 .25 , specify 203.0.113 .25/32 . If your company allocates addresses from a range, specify the entire range, such as 203.0.113 .0/24 . Important For security reasons, we don't recommend that you allow SSH access from all IP addresses (0.0.0.0/0 ) to your instance, except for testing purposes and only for a short time. Create the credentials to connect to your EC2 instance For Amazon ECS, a key pair is only needed if you intend on using the EC2 launch type. Create the credentials to connect to your EC2 instance 12 Amazon Elastic Container Service Developer Guide AWS uses public-key cryptography to secure the login information for your instance. A Linux instance, such as an Amazon ECS container instance, has no password to use for SSH access. You use a key pair to log in to your instance securely. You specify the name of the key pair when you launch your container instance, then provide the private key when you log in using SSH. If you haven't created a key pair already, you can create one using the Amazon EC2 console. If you plan to launch instances in multiple regions, you'll need to create a key pair in each region. For more information about regions, see Regions and Availability Zones in the Amazon EC2 User Guide. To create a key pair • Use the Amazon EC2 console to create a key pair. For more information about creating a key pair, see Create a",
11
+ "create a key pair. For more information about creating a key pair, see Create a key pair in the Amazon EC2 User Guide. For information about how to connect to your instance, see Connect to your Linux instance in the Amazon EC2 User Guide. Install the AWS CLI The AWS Management Console can be used to manage all operations manually with Amazon ECS. However, you can install the AWS CLI on your local desktop or a developer box so that you can build scripts that can automate common management tasks in Amazon ECS. To use the AWS CLI with Amazon ECS, install the latest AWS CLI version. For information about installing the AWS CLI or upgrading it to the latest version, see Installing or updating to the latest version of the AWS CLI in the AWS Command Line Interface User Guide. The AWS Command Line Interface (AWS CLI) is a unified tool that you can use to manage your AWS services. With this one tool alone, you can both control multiple AWS services and automate these services through scripts. The Amazon ECS commands in the AWS CLI are a reflection of the Amazon ECS API. The AWS CLI is suitable for customers who prefer and are used to scripting and interfacing with a command line tool and know exactly which actions they want to perform on their Amazon ECS resources. The AWS CLI is also helpful to customers who want to familiarize themselves with the Amazon ECS APIs. Customers can use the AWS CLI to perform a number of operations on Amazon ECS resources, including Create, Read, Update, and Delete operations, directly from the command line interface. Install the AWS CLI 13 Amazon Elastic Container Service Developer Guide Use the AWS CLI if you are or want to become familiar",
12
+ "Service Developer Guide Use the AWS CLI if you are or want to become familiar with the Amazon ECS APIs and corresponding CLI commands and want to write automated scripts and perform specific actions on Amazon ECS resources. AWS also provides the command line tools AWS Tools for Windows PowerShell. For more information, see the AWS Tools for Windows PowerShell User Guide. Next steps for using Amazon ECS After installing the AWS CLI, there are many different tools you can utilize as you continue to use Amazon ECS. The following links explain what some of those tools are and give examples of how to use them with Amazon ECS. • Create your first container image with Docker and push it to Amazon ECR for use in your Amazon ECS task definitions. • Learn how to create an Amazon ECS Linux task for the Fargate launch type. • Learn how to create an Amazon ECS Windows task for the Fargate launch type. • Learn how to create an Amazon ECS Windows task for the EC2 launch type. • Using your preferred programming language, define infrastructure or architecture as code with the Creating Amazon ECS resources using the AWS CDK. • Define and manage all AWS resources in your environment with automated deployment using Using Amazon ECS with AWS CloudFormation. • Use the complete Creating Amazon ECS resources using the AWS Copilot command line interface end-to-end developer workflow to create, release, and operate container applications that comply with AWS best practices for infrastructure. Creating a container image for use on Amazon ECS Amazon ECS uses Docker images in task definitions to launch containers. Docker is a technology that provides the tools for you to build, run, test, and deploy distributed applications in containers. Amazon ECS schedules containerized applications on to container instances",
13
+ "and deploy distributed applications in containers. Amazon ECS schedules containerized applications on to container instances or on to AWS Fargate. Containerized applications are packaged as container images. This example creates a container image for a web server. You can create your first Docker image, and then push that image to Amazon ECR, which is a container registry, for use in your Amazon ECS task definitions. This walkthrough assumes that you Next steps for using Amazon ECS 14 Amazon Elastic Container Service Developer Guide possess a basic understanding of what Docker is and how it works. For more information about Docker, see What is Docker? and the Docker documentation. Prerequisites Before you begin, ensure the following prerequisites are met. • Ensure you have completed the Amazon ECR setup steps. For more information, see Moving an image through its lifecycle in Amazon ECR in the Amazon Elastic Container Registry User Guide. • Your user has the required IAM permissions to access and use the Amazon ECR service. For more information, see Amazon ECR managed policies. • You have Docker installed. For Docker installation steps for Amazon Linux 2023, see Installing Docker on AL2023. For all other operating systems, see the Docker documentation at Docker Desktop overview. • You have the AWS CLI installed and configured. For more information, see Installing or updating to the latest version of the AWS CLI in the AWS Command Line Interface User Guide. If you don't have or need a local development environment and you prefer to use an Amazon EC2 instance to use Docker, we provide the following steps to launch an Amazon EC2 instance using Amazon Linux 2023 and install Docker Engine and the Docker CLI. Installing Docker on AL2023 Docker is available on many different operating systems, including most modern Linux distributions, like Ubuntu,",
14
+ "Docker is available on many different operating systems, including most modern Linux distributions, like Ubuntu, and even macOS and Windows. For more information about how to install Docker on your particular operating system, go to the Docker installation guide. You do not need a local development system to use Docker. If you are using Amazon EC2 already, you can launch an Amazon Linux 2023 instance and install Docker to get started. If you already have Docker installed, skip to Create a Docker image. To install Docker on an Amazon EC2 instance using an Amazon Linux 2023 AMI 1. Launch an instance with the latest Amazon Linux 2023 AMI. For more information, see Launch an EC2 instance using the launch instance wizard in the console in the Amazon EC2 User Guide. 2. Connect to your instance. For more information, see Connect to your EC2 instance in the Amazon EC2 User Guide. 3. Update the installed packages and package cache on your instance. Prerequisites 15 Amazon Elastic Container Service Developer Guide sudo yum update -y 4. Install the most recent Docker Community Edition package. sudo yum install docker 5. Start the Docker service. sudo service docker start 6. Add the ec2-user to the docker group so you can execute Docker commands without using sudo. sudo usermod -a -G docker ec2-user 7. Log out and log back in again to pick up the new docker group permissions. You can accomplish this by closing your current SSH terminal window and reconnecting to your instance in a new one. Your new SSH session will have the appropriate docker group permissions. 8. Verify that the ec2-user can run Docker commands without sudo. docker info Note In some cases, you may need to reboot your instance to provide permissions for the ec2-user to access the Docker daemon.",
15
+ "to reboot your instance to provide permissions for the ec2-user to access the Docker daemon. Try rebooting your instance if you see the following error: Cannot connect to the Docker daemon. Is the docker daemon running on this host? Create a Docker image Amazon ECS task definitions use container images to launch containers on the container instances in your clusters. In this section, you create a Docker image of a simple web application, and test Create a Docker image 16 Amazon Elastic Container Service Developer Guide it on your local system or Amazon EC2 instance, and then push the image to the Amazon ECR container registry so you can use it in an Amazon ECS task definition. To create a Docker image of a simple web application 1. Create a file called Dockerfile. A Dockerfile is a manifest that describes the base image to use for your Docker image and what you want installed and running on it. For more information about Dockerfiles, go to the Dockerfile Reference. touch Dockerfile 2. Edit the Dockerfile you just created and add the following content. FROM public.ecr.aws/amazonlinux/amazonlinux:latest # Update installed packages and install Apache RUN yum update -y && \\ yum install -y httpd # Write hello world message RUN echo 'Hello World!' > /var/www/html/index.html # Configure Apache RUN echo 'mkdir -p /var/run/httpd' >> /root/run_apache.sh && \\ echo 'mkdir -p /var/lock/httpd' >> /root/run_apache.sh && \\ echo '/usr/sbin/httpd -D FOREGROUND' >> /root/run_apache.sh && \\ chmod 755 /root/run_apache.sh EXPOSE 80 CMD /root/run_apache.sh This Dockerfile uses the public Amazon Linux 2023 image hosted on Amazon ECR Public. The RUN instructions update the package caches, installs some software packages for the web server, and then write the \"Hello World!\" content to the web servers document root. The EXPOSE instruction means that port 80 on the container is",
16
+ "web servers document root. The EXPOSE instruction means that port 80 on the container is the one that is listening, and the CMD instruction starts the web server. 3. Build the Docker image from your Dockerfile. Create a Docker image 17 Amazon Elastic Container Service Developer Guide Note Some versions of Docker may require the full path to your Dockerfile in the following command, instead of the relative path shown below. If you run the command an ARM based system, such as Apple Silicon, use the -platform option \"--platform linux/amd64\". docker build -t hello-world . 4. List your container image. docker images --filter reference=hello-world Output: REPOSITORY SIZE hello-world 194MB 5. TAG IMAGE ID CREATED latest e9ffedc8c286 4 minutes ago Run the newly built image. The -p 80:80 option maps the exposed port 80 on the container to port 80 on the host system. docker run -t -i -p 80:80 hello-world Note Output from the Apache web server is displayed in the terminal window. You can ignore the \"Could not reliably determine the fully qualified domain name\" message. 6. Open a browser and point to the server that is running Docker and hosting your container. • If you are using an EC2 instance, this is the Public DNS value for the server, which is the same address you use to connect to the instance with SSH. Make sure that the security group for your instance allows inbound traffic on port 80. Create a Docker image 18 Amazon Elastic Container Service Developer Guide • If you are running Docker locally, point your browser to http://localhost/. You should see a web page with your \"Hello World!\" statement. 7. Stop the Docker container by typing Ctrl + c. Push your image to Amazon Elastic Container Registry Amazon ECR is a managed AWS managed image",
17
+ "your image to Amazon Elastic Container Registry Amazon ECR is a managed AWS managed image registry service. You can use the Docker CLI to push, pull, and manage images in your Amazon ECR repositories. For Amazon ECR product details, featured customer case studies, and FAQs, see the Amazon Elastic Container Registry product detail pages. To tag your image and push it to Amazon ECR 1. Create an Amazon ECR repository to store your hello-world image. Note the repositoryUri in the output. Substitute region, with your AWS Region, for example, us-east-1. aws ecr create-repository --repository-name hello-repository --region region Output: { \"repository\": { \"registryId\": \"aws_account_id\", \"repositoryName\": \"hello-repository\", \"repositoryArn\": \"arn:aws:ecr:region:aws_account_id:repository/hellorepository\", \"createdAt\": 1505337806.0, \"repositoryUri\": \"aws_account_id.dkr.ecr.region.amazonaws.com/hellorepository\" } } 2. Tag the hello-world image with the repositoryUri value from the previous step. docker tag hello-world aws_account_id.dkr.ecr.region.amazonaws.com/hello-repository Push your image to Amazon Elastic Container Registry 19 Amazon Elastic Container Service 3. Developer Guide Run the aws ecr get-login-password command. Specify the registry URI you want to authenticate to. For more information, see Registry Authentication in the Amazon Elastic Container Registry User Guide. aws ecr get-login-password --region region | docker login --username AWS -password-stdin aws_account_id.dkr.ecr.region.amazonaws.com Output: Login Succeeded Important If you receive an error, install or upgrade to the latest version of the AWS CLI. For more information, see Installing or updating to the latest version of the AWS CLI in the AWS Command Line Interface User Guide. 4. Push the image to Amazon ECR with the repositoryUri value from the earlier step. docker push aws_account_id.dkr.ecr.region.amazonaws.com/hello-repository Clean up To continue on with creating an Amazon ECS task definition and launching a task with your container image, skip to the Next steps. When you are done experimenting with your Amazon ECR image, you can delete the repository so you are not charged for image storage. aws ecr delete-repository --repository-name",
18
+ "delete the repository so you are not charged for image storage. aws ecr delete-repository --repository-name hello-repository --region region --force Next steps Your task definitions require a task execution role. For more information, see Amazon ECS task execution IAM role. After you have created and pushed your container image to Amazon ECR, you can use that image in a task definition. For more information, see one of the following: • the section called “Learn how to create a Linux task for the Fargate launch type” Clean up 20 Amazon Elastic Container Service Developer Guide • the section called “Learn how to create a Windows task for the Fargate launch type” • Creating an Amazon ECS Linux task for the Fargate launch type with the AWS CLI Learn how to create an Amazon ECS Linux task for the Fargate launch type Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage your containers. You can host your containers on a serverless infrastructure that is managed by Amazon ECS by launching your services or tasks on AWS Fargate. For more information on Fargate, see AWS Fargate for Amazon ECS. Get started with Amazon ECS on AWS Fargate by using the Fargate launch type for your tasks in the Regions where Amazon ECS supports AWS Fargate. Complete the following steps to get started with Amazon ECS on AWS Fargate. Prerequisites Before you begin, complete the steps in Set up to use Amazon ECS and that your IAM user has the permissions specified in the AdministratorAccess IAM policy example. The console attempts to automatically create the task execution IAM role, which is required for Fargate tasks. To ensure that the console is able to create this IAM role, one of the following",
19
+ "ensure that the console is able to create this IAM role, one of the following must be true: • Your user has administrator access. For more information, see Set up to use Amazon ECS. • Your user has the IAM permissions to create a service role. For more information, see Creating a Role to Delegate Permissions to an AWS Service. • A user with administrator access has manually created the task execution role so that it is available on the account to be used. For more information, see Amazon ECS task execution IAM role. Important The security group you select when creating a service with your task definition must have port 80 open for inbound traffic. Add the following inbound rule to your security group. Learn how to create a Linux task for the Fargate launch type 21"
20
+ ]
dataset/chunks/eks-ug_chunks.json ADDED
@@ -0,0 +1,38 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "Amazon EKS User Guide What is Amazon EKS? Amazon EKS: Simplified Kubernetes Management Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters. With EKS, you can: • Deploy applications faster with less operational overhead • Scale seamlessly to meet changing workload demands • Improve security through AWS integration and automated updates • Choose between standard EKS or fully automated EKS Auto Mode Amazon Elastic Kubernetes Service (Amazon EKS) is the premiere platform for running Kubernetes clusters, both in the Amazon Web Services (AWS) cloud and in your own data centers (EKS Anywhere and Amazon EKS Hybrid Nodes). Amazon EKS simplifies building, securing, and maintaining Kubernetes clusters. It can be more cost effective at providing enough resources to meet peak demand than maintaining your own data centers. Two of the main approaches to using Amazon EKS are as follows: • EKS standard: AWS manages the Kubernetes control plane when you create a cluster with EKS. Components that manage nodes, schedule workloads, integrate with the AWS cloud, and store and scale control plane information to keep your clusters up and running, are handled for you automatically. • EKS Auto Mode: Using the EKS Auto Mode feature, EKS extends its control to manage Nodes (Kubernetes data plane) as well. It simplifies Kubernetes management by automatically provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources, continuously optimizing costs, patching operating systems, and integrating with AWS security services. The following diagram illustrates how Amazon EKS integrates your Kubernetes clusters with the AWS cloud, depending on which method of cluster creation you choose: Amazon EKS: Simplified Kubernetes Management 1 Amazon EKS User Guide Amazon EKS helps you accelerate time to production, improve performance, availability and resiliency, and enhance system security. For more information, see Amazon Elastic",
3
+ "improve performance, availability and resiliency, and enhance system security. For more information, see Amazon Elastic Kubernetes Service. Features of Amazon EKS Amazon EKS provides the following high-level features: Management interfaces EKS offers multiple interfaces to provision, manage, and maintain clusters, including AWS Management Console, Amazon EKS API/SDKs, CDK, AWS CLI, eksctl CLI, AWS CloudFormation, and Terraform. For more information, see Get started and Configure clusters. Features of Amazon EKS 2 Amazon EKS User Guide Access control tools EKS relies on both Kubernetes and AWS Identity and Access Management (AWS IAM) features to manage access from users and workloads. For more information, see the section called “Kubernetes API access” and the section called “Workload access to AWS ”. Compute resources For compute resources, EKS allows the full range of Amazon EC2 instance types and AWS innovations such as Nitro and Graviton with Amazon EKS for you to optimize the compute for your workloads. For more information, see Manage compute. Storage EKS Auto Mode automatically creates storage classes using EBS volumes. Using Container Storage Interface (CSI) drivers, you can also use Amazon S3, Amazon EFS, Amazon FSX, and Amazon File Cache for your application storage needs. For more information, see App data storage. Security The shared responsibility model is employed as it relates to Security in Amazon EKS. For more information, see Security best practices, Infrastructure security, and Kubernetes security. Monitoring tools Use the observability dashboard to monitor Amazon EKS clusters. Monitoring tools include Prometheus, CloudWatch, Cloudtrail, and ADOT Operator. For more information on dashboards, metrics servers, and other tools, see EKS cluster costs and Kubernetes Metrics Server. Kubernetes compatibility and support Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins. EKS offers both standard support and eks/latest/userguide/kubernetes-versions-extended.html[extended support,type=\"documentation\"] for Kubernetes.",
4
+ "Kubernetes community tooling and plugins. EKS offers both standard support and eks/latest/userguide/kubernetes-versions-extended.html[extended support,type=\"documentation\"] for Kubernetes. For more information, see eks/latest/ userguide/kubernetes-versions.html[Understand the Kubernetes version lifecycle on EKS,type=\"documentation\"]. Related services Services to use with Amazon EKS Related services 3 Amazon EKS User Guide You can use other AWS services with the clusters that you deploy using Amazon EKS: Amazon EC2 Obtain on-demand, scalable compute capacity with Amazon EC2. Amazon EBS Attach scalable, high-performance block storage resources with Amazon EBS. Amazon ECR Store container images securely with Amazon ECR. Amazon CloudWatch Monitor AWS resources and applications in real time with Amazon CloudWatch. Amazon Prometheus Track metrics for containerized applications with Amazon Managed Service for Prometheus. Elastic Load Balancing Distribute incoming traffic across multiple targets with Elastic Load Balancing. Amazon GuardDuty Detect threats to EKS clusters with Amazon GuardDuty. AWS Resilience Hub Assess EKS cluster resiliency with AWS Resilience Hub. Amazon EKS Pricing Amazon EKS has per cluster pricing based on Kubernetes cluster version support, pricing for Amazon EKS Auto Mode, and per vCPU pricing for Amazon EKS Hybrid Nodes. When using Amazon EKS, you pay separately for the AWS resources you use to run your applications on Kubernetes worker nodes. For example, if you are running Kubernetes worker nodes as Amazon EC2 instances with Amazon EBS volumes and public IPv4 addresses, you are charged for the instance capacity through Amazon EC2, the volume capacity through Amazon EBS, and the IPv4 address through Amazon VPC. Amazon EKS Pricing 4 Amazon EKS User Guide Visit the respective pricing pages of the AWS services you are using with your Kubernetes applications for detailed pricing information. • For Amazon EKS cluster, Amazon EKS Auto Mode, and Amazon EKS Hybrid Nodes pricing, see Amazon EKS Pricing. • For Amazon EC2 pricing, see Amazon EC2 On-Demand Pricing and",
5
+ "see Amazon EKS Pricing. • For Amazon EC2 pricing, see Amazon EC2 On-Demand Pricing and Amazon EC2 Spot Pricing. • For AWS Fargate pricing, see AWS Fargate Pricing. • You can use your savings plans for compute used in Amazon EKS clusters. For more information, see Pricing with Savings Plans. Common use cases in Amazon EKS Amazon EKS offers robust managed Kubernetes services on AWS, designed to optimize containerized applications. The following are a few of the most common use cases of Amazon EKS, helping you leverage its strengths for your specific needs. Deploying high-availability applications Using Elastic Load Balancing, you can make sure that your applications are highly available across multiple Availability Zones. Building microservices architectures Use Kubernetes service discovery features with AWS Cloud Map or Amazon VPC Lattice to build resilient systems. Automating software release process Manage continuous integration and continuous deployment (CICD) pipelines that simplify the process of automated building, testing, and deployment of applications. Running serverless applications Use AWS Fargate with Amazon EKS to run serverless applications. This means you can focus solely on application development, while Amazon EKS and Fargate handle the underlying infrastructure. Executing machine learning workloads Amazon EKS is compatible with popular machine learning frameworks such as TensorFlow, MXNet, and PyTorch. With GPU support, you can handle even complex machine learning tasks effectively. Common use cases 5 Amazon EKS User Guide Deploying consistently on premises and in the cloud To simplify running Kubernetes in on-premises environments, you can use the same Amazon EKS clusters, features, and tools to run self-managed nodes on AWS Outposts or can use Amazon EKS Hybrid Nodes with your own infrastructure. For self-contained, air-gapped environments, you can use Amazon EKS Anywhere to automate Kubernetes cluster lifecycle management on your own infrastructure. Running cost-effective batch processing and big data workloads",
6
+ "cluster lifecycle management on your own infrastructure. Running cost-effective batch processing and big data workloads Utilize Spot Instances to run your batch processing and big data workloads such as Apache Hadoop and Spark, at a fraction of the cost. This lets you take advantage of unused Amazon EC2 capacity at discounted prices. Securing application and ensuring compliance Implement strong security practices and maintain compliance with Amazon EKS, which integrates with AWS security services such as AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (Amazon VPC), and AWS Key Management Service (AWS KMS). This ensures data privacy and protection as per industry standards. Amazon EKS architecture Amazon EKS aligns with the general cluster architecture of Kubernetes. For more information, see Kubernetes Components in the Kubernetes documentation. The following sections summarize some extra architecture details for Amazon EKS. Control plane Amazon EKS ensures every cluster has its own unique Kubernetes control plane. This design keeps each cluster’s infrastructure separate, with no overlaps between clusters or AWS accounts. The setup includes: Distributed components The control plane positions at least two API server instances and three etcd instances across three AWS Availability Zones within an AWS Region. Optimal performance Amazon EKS actively monitors and adjusts control plane instances to maintain peak performance. Architecture 6 Amazon EKS User Guide Resilience If a control plane instance falters, Amazon EKS quickly replaces it, using different Availability Zone if needed. Consistent uptime By running clusters across multiple Availability Zones, a reliable API server endpoint availability Service Level Agreement (SLA) is achieved. Amazon EKS uses Amazon Virtual Private Cloud (Amazon VPC) to limit traffic between control plane components within a single cluster. Cluster components can’t view or receive communication from other clusters or AWS accounts, except when authorized by Kubernetes role-based access control (RBAC) policies. Compute In",
7
+ "or AWS accounts, except when authorized by Kubernetes role-based access control (RBAC) policies. Compute In addition to the control plane, an Amazon EKS cluster has a set of worker machines called nodes. Selecting the appropriate Amazon EKS cluster node type is crucial for meeting your specific requirements and optimizing resource utilization. Amazon EKS offers the following primary node types: EKS Auto Mode EKS Auto Mode extends AWS management beyond the control plane to include the data plane, automating cluster infrastructure management. It integrates core Kubernetes capabilities as built-in components, including compute autoscaling, networking, load balancing, DNS, storage, and GPU support. EKS Auto Mode dynamically manages nodes based on workload demands, using immutable AMIs with enhanced security features. It automates updates and upgrades while respecting Pod Disruption Budgets, and includes managed components that would otherwise require add-on management. This option is ideal for users who want to leverage AWS expertise for day-to-day operations, minimize operational overhead, and focus on application development rather than infrastructure management. AWS Fargate Fargate is a serverless compute engine for containers that eliminates the need to manage the underlying instances. With Fargate, you specify your application’s resource needs, and AWS automatically provisions, scales, and maintains the infrastructure. This option is ideal for users who prioritize ease-of-use and want to concentrate on application development and deployment rather than managing infrastructure. Compute 7 Amazon EKS User Guide Karpenter Karpenter is a flexible, high-performance Kubernetes cluster autoscaler that helps improve application availability and cluster efficiency. Karpenter launches right-sized compute resources in response to changing application load. This option can provision just-in-time compute resources that meet the requirements of your workload. Managed node groups Managed node groups are a blend of automation and customization for managing a collection of Amazon EC2 instances within an Amazon EKS cluster. AWS takes care of",
8
+ "a collection of Amazon EC2 instances within an Amazon EKS cluster. AWS takes care of tasks like patching, updating, and scaling nodes, easing operational aspects. In parallel, custom kubelet arguments are supported, opening up possibilities for advanced CPU and memory management policies. Moreover, they enhance security via AWS Identity and Access Management (IAM) roles for service accounts, while curbing the need for separate permissions per cluster. Self-managed nodes Self-managed nodes offer full control over your Amazon EC2 instances within an Amazon EKS cluster. You are in charge of managing, scaling, and maintaining the nodes, giving you total control over the underlying infrastructure. This option is suitable for users who need granular control and customization of their nodes and are ready to invest time in managing and maintaining their infrastructure. Amazon EKS Hybrid Nodes With Amazon EKS Hybrid Nodes, you can use your on-premises and edge infrastructure as nodes in Amazon EKS clusters. Amazon EKS Hybrid Nodes unifies Kubernetes management across environments and offloads Kubernetes control plane management to AWS for your onpremises and edge applications. Kubernetes concepts Amazon Elastic Kubernetes Service (Amazon EKS) is an AWS managed service based on the open source Kubernetes project. While there are things you need to know about how the Amazon EKS service integrates with AWS Cloud (particularly when you first create an Amazon EKS cluster), once it’s up and running, you use your Amazon EKS cluster in much that same way as you would any other Kubernetes cluster. So to begin managing Kubernetes clusters and deploying workloads, you need at least a basic understanding of Kubernetes concepts. Kubernetes concepts 8 Amazon EKS User Guide This page divides Kubernetes concepts into three sections: the section called “Why Kubernetes?”, the section called “Clusters”, and the section called “Workloads”. The first section describes the value of",
9
+ "section called “Clusters”, and the section called “Workloads”. The first section describes the value of running a Kubernetes service, in particular as a managed service like Amazon EKS. The Workloads section covers how Kubernetes applications are built, stored, run, and managed. The Clusters section lays out the different components that make up Kubernetes clusters and what your responsibilities are for creating and maintaining Kubernetes clusters. Topics • Why Kubernetes? • Clusters • Workloads • Next steps As you go through this content, links will lead you to further descriptions of Kubernetes concepts in both Amazon EKS and Kubernetes documentation, in case you want to take deep dives into any of the topics we cover here. For details about how Amazon EKS implements Kubernetes control plane and compute features, see the section called “Architecture”. Why Kubernetes? Kubernetes was designed to improve availability and scalability when running mission-critical, production-quality containerized applications. Rather than just running Kubernetes on a single machine (although that is possible), Kubernetes achieves those goals by allowing you to run applications across sets of computers that can expand or contract to meet demand. Kubernetes includes features that make it easier for you to: • Deploy applications on multiple machines (using containers deployed in Pods) • Monitor container health and restart failed containers • Scale containers up and down based on load • Update containers with new versions • Allocate resources between containers • Balance traffic across machines Having Kubernetes automate these types of complex tasks allows an application developer to focus on building and improving their application workloads, rather than worrying about Why Kubernetes? 9 Amazon EKS User Guide infrastructure. The developer typically creates configuration files, formatted as YAML files, that describe the desired state of the application. This could include which containers to run, resource limits, number of",
10
+ "state of the application. This could include which containers to run, resource limits, number of Pod replicas, CPU/memory allocation, affinity rules, and more. Attributes of Kubernetes To achieve its goals, Kubernetes has the following attributes: • Containerized — Kubernetes is a container orchestration tool. To use Kubernetes, you must first have your applications containerized. Depending on the type of application, this could be as a set of microservices, as batch jobs or in other forms. Then, your applications can take advantage of a Kubernetes workflow that encompasses a huge ecosystem of tools, where containers can be stored as images in a container registry, deployed to a Kubernetes cluster, and run on an available node. You can build and test individual containers on your local computer with Docker or another container runtime, before deploying them to your Kubernetes cluster. • Scalable — If the demand for your applications exceeds the capacity of the running instances of those applications, Kubernetes is able to scale up. As needed, Kubernetes can tell if applications require more CPU or memory and respond by either automatically expanding available capacity or using more of existing capacity. Scaling can be done at the Pod level, if there is enough compute available to just run more instances of the application (horizontal Pod autoscaling), or at the node level, if more nodes need to be brought up to handle the increased capacity (Cluster Autoscaler or Karpenter). As capacity is no longer needed, these services can delete unnecessary Pods and shut down unneeded nodes. • Available — If an application or node becomes unhealthy or unavailable, Kubernetes can move running workloads to another available node. You can force the issue by simply deleting a running instance of a workload or node that’s running your workloads. The bottom line here is that",
11
+ "of a workload or node that’s running your workloads. The bottom line here is that workloads can be brought up in other locations if they can no longer run where they are. • Declarative — Kubernetes uses active reconciliation to constantly check that the state that you declare for your cluster matches the actual state. By applying Kubernetes objects to a cluster, typically through YAML-formatted configuration files, you can, for example, ask to start up the workloads you want to run on your cluster. You can later change the configurations to do something like use a later version of a container or allocate more memory. Kubernetes will do what it needs to do to establish the desired state. This can include bringing nodes up or down, stopping and restarting workloads, or pulling updated containers. • Composable — Because an application typically consists of multiple components, you want to be able to manage a set of these components (often represented by multiple containers) together. While Docker Compose offers a way to do this directly with Docker, the Kubernetes Why Kubernetes? 10 Amazon EKS User Guide Kompose command can help you do that with Kubernetes. See Translate a Docker Compose File to Kubernetes Resources for an example of how to do this. • Extensible — Unlike proprietary software, the open source Kubernetes project is designed to be open to you extending Kubernetes any way that you like to meet your needs. APIs and configuration files are open to direct modifications. Third-parties are encouraged to write their own Controllers, to extend both infrastructure and end-user Kubernetes features. Webhooks let you set up cluster rules to enforce policies and adapt to changing conditions. For more ideas on how to extend Kubernetes clusters, see Extending Kubernetes. • Portable — Many organizations have standardized their operations",
12
+ "extend Kubernetes clusters, see Extending Kubernetes. • Portable — Many organizations have standardized their operations on Kubernetes because it allows them to manage all of their application needs in the same way. Developers can use the same pipelines to build and store containerized applications. Those applications can then be deployed to Kubernetes clusters running on-premises, in clouds, on point-of-sales terminals in restaurants, or on IOT devices dispersed across company’s remote sites. Its open source nature makes it possible for people to develop these special Kubernetes distributions, along will tools needed to manage them. Managing Kubernetes Kubernetes source code is freely available, so with your own equipment you could install and manage Kubernetes yourself. However, self-managing Kubernetes requires deep operational expertise and takes time and effort to maintain. For those reasons, most people deploying production workloads choose a cloud provider (such as Amazon EKS) or on-premises provider (such as Amazon EKS Anywhere) with its own tested Kubernetes distribution and support of Kubernetes experts. This allows you to offload much of the undifferentiated heavy lifting needed to maintain your clusters, including: • Hardware — If you don’t have hardware available to run Kubernetes per your requirements, a cloud provider such as AWS Amazon EKS can save you on upfront costs. With Amazon EKS, this means that you can consume the best cloud resources offered by AWS, including computer instances (Amazon Elastic Compute Cloud), your own private environment (Amazon VPC), central identity and permissions management (IAM), and storage (Amazon EBS). AWS manages the computers, networks, data centers, and all the other physical components needed to run Kubernetes. Likewise, you don’t have to plan your datacenter to handle the maximum capacity on your highest-demand days. For Amazon EKS Anywhere, or other on premises Kubernetes clusters, you are responsible for managing the infrastructure used in",
13
+ "or other on premises Kubernetes clusters, you are responsible for managing the infrastructure used in your Kubernetes deployments, but you can still rely on AWS to help you keep Kubernetes up to date. Why Kubernetes? 11 Amazon EKS User Guide • Control plane management — Amazon EKS manages the security and availability of the AWShosted Kubernetes control plane, which is responsible for scheduling containers, managing the availability of applications, and other key tasks, so you can focus on your application workloads. If your cluster breaks, AWS should have the means to restore your cluster to a running state. For Amazon EKS Anywhere, you would manage the control plane yourself. • Tested upgrades — When you upgrade your clusters, you can rely on Amazon EKS or Amazon EKS Anywhere to provide tested versions of their Kubernetes distributions. • Add-ons — There are hundreds of projects built to extend and work with Kubernetes that you can add to your cluster’s infrastructure or use to aid the running of your workloads. Instead of building and managing those add-ons yourself, AWS provides the section called “Amazon EKS add-ons” that you can use with your clusters. Amazon EKS Anywhere provides Curated Packages that include builds of many popular open source projects. So you don’t have to build the software yourself or manage critical security patches, bug fixes, or upgrades. Likewise, if the defaults meet your needs, it’s typical for very little configuration of those add-ons to be needed. See the section called “Extend Clusters” for details on extending your cluster with add-ons. Kubernetes in action The following diagram shows key activities you would do as a Kubernetes Admin or Application Developer to create and use a Kubernetes cluster. In the process, it illustrates how Kubernetes components interact with each other, using the AWS cloud as",
14
+ "process, it illustrates how Kubernetes components interact with each other, using the AWS cloud as the example of the underlying cloud provider. Why Kubernetes? 12 Amazon EKS User Guide A Kubernetes Admin creates the Kubernetes cluster using a tool specific to the type of provider on which the cluster will be built. This example uses the AWS cloud as the provider, which offers the managed Kubernetes service called Amazon EKS. The managed service automatically allocates the resources needed to create the cluster, including creating two new Virtual Private Clouds (Amazon VPCs) for the cluster, setting up networking, and mapping Kubernetes permissions directly into the new VPCs for cloud asset management. The managed service also sees that the control plane services have places to run and allocates zero or more Amazon EC2 instances as Kubernetes nodes for running workloads. AWS manages one Amazon VPC itself for the control plane, while the other Amazon VPC contains the customer nodes that run workloads. Many of the Kubernetes Admin’s tasks going forward are done using Kubernetes tools such as kubectl. That tool makes requests for services directly to the cluster’s control plane. The ways that queries and changes are made to the cluster are then very similar to the ways you would do them on any Kubernetes cluster. An application developer wanting to deploy workloads to this cluster can perform several tasks. The developer needs to build the application into one or more container images, then push those images to a container registry that is accessible to the Kubernetes cluster. AWS offers the Amazon Elastic Container Registry (Amazon ECR) for that purpose. Why Kubernetes? 13 Amazon EKS User Guide To run the application, the developer can create YAML-formatted configuration files that tell the cluster how to run the application, including which containers to pull",
15
+ "files that tell the cluster how to run the application, including which containers to pull from the registry and how to wrap those containers in Pods. The control plane (scheduler) schedules the containers to one or more nodes and the container runtime on each node actually pulls and runs the needed containers. The developer can also set up an application load balancer to balance traffic to available containers running on each node and expose the application so it is available on a public network to the outside world. With that all done, someone wanting to use the application can connect to the application endpoint to access it. The following sections go through details of each of these features, from the perspective of Kubernetes Clusters and Workloads. Clusters If your job is to start and manage Kubernetes clusters, you should know how Kubernetes clusters are created, enhanced, managed, and deleted. You should also know what the components are that make up a cluster and what you need to do to maintain those components. Tools for managing clusters handle the overlap between the Kubernetes services and the underlying hardware provider. For that reason, automation of these tasks tend to be done by the Kubernetes provider (such as Amazon EKS or Amazon EKS Anywhere) using tools that are specific to the provider. For example, to start an Amazon EKS cluster you can use eksctl create cluster, while for Amazon EKS Anywhere you can use eksctl anywhere create cluster. Note that while these commands create a Kubernetes cluster, they are specific to the provider and are not part of the Kubernetes project itself. Cluster creation and management tools The Kubernetes project offers tools for creating a Kubernetes cluster manually. So if you want to install Kubernetes on a single machine, or run the control",
16
+ "So if you want to install Kubernetes on a single machine, or run the control plane on a machine and add nodes manually, you can use CLI tools like kind, minikube, or kubeadm that are listed under Kubernetes Install Tools. To simplify and automate the full lifecycle of cluster creation and management, it is much easier to use tools supported by an established Kubernetes provider, such as Amazon EKS or Amazon EKS Anywhere. In AWS Cloud, you can create Amazon EKS clusters using CLI tools, such as eksctl, or more declarative tools, such as Terraform (see Amazon EKS Blueprints for Terraform). You can also create a cluster from the AWS Management Console. See Amazon EKS features for a list what you get with Amazon EKS. Kubernetes responsibilities that Amazon EKS takes on for you include: Clusters 14 Amazon EKS User Guide • Managed control plane — AWS makes sure that the Amazon EKS cluster is available and scalable because it manages the control plane for you and makes it available across AWS Availability Zones. • Node management — Instead of manually adding nodes, you can have Amazon EKS create nodes automatically as needed, using Managed Node Groups (see the section called “Managed node groups”) or Karpenter. Managed Node Groups have integrations with Kubernetes Cluster Autoscaling. Using node management tools, you can take advantage of cost savings, with things like Spot Instances and node consolidation, and availability, using Scheduling features to set how workloads are deployed and nodes are selected. • Cluster networking — Using CloudFormation templates, eksctl sets up networking between control plane and data plane (node) components in the Kubernetes cluster. It also sets up endpoints through which internal and external communications can take place. See Demystifying cluster networking for Amazon EKS worker nodes for details. Communications between Pods",
17
+ "place. See Demystifying cluster networking for Amazon EKS worker nodes for details. Communications between Pods in Amazon EKS is done using Amazon EKS Pod Identities (see the section called “Pod Identity”), which provides a means of letting Pods tap into AWS cloud methods of managing credentials and permissions. • Add-Ons — Amazon EKS saves you from having to build and add software components that are commonly used to support Kubernetes clusters. For example, when you create an Amazon EKS cluster from the AWS Management Console, it automatically adds the Amazon EKS kube-proxy (the section called “kube-proxy”), Amazon VPC CNI plugin for Kubernetes (the section called “Amazon VPC CNI”), and CoreDNS (the section called “CoreDNS”) add-ons. See the section called “Amazon EKS add-ons” for more on these add-ons, including a list of which are available. To run your clusters on your own on-premises computers and networks, Amazon offers Amazon EKS Anywhere. Instead of the AWS Cloud being the provider, you have the choice of running Amazon EKS Anywhere on VMWare vSphere, bare metal (Tinkerbell provider), Snow, CloudStack, or Nutanix platforms using your own equipment. Amazon EKS Anywhere is based on the same Amazon EKS Distro software that is used by Amazon EKS. However, Amazon EKS Anywhere relies on different implementations of the Kubernetes Cluster API (CAPI) interface to manage the full lifecycle of the machines in an Amazon EKS Anywhere cluster (such as CAPV for vSphere and CAPC for CloudStack). Because the entire cluster is running on your equipment, you take on the added responsibility of managing the control plane and backing up its data (see etcd later in this document). Clusters 15 Amazon EKS User Guide Cluster components Kubernetes cluster components are divided into two major areas: control plane and worker nodes. Control Plane Components manage the cluster and provide",
18
+ "major areas: control plane and worker nodes. Control Plane Components manage the cluster and provide access to its APIs. Worker nodes (sometimes just referred to as Nodes) provide the places where the actual workloads are run. Node Components consist of services that run on each node to communicate with the control plane and run containers. The set of worker nodes for your cluster is referred to as the Data Plane. Control plane The control plane consists of a set of services that manage the cluster. These services may all be running on a single computer or may be spread across multiple computers. Internally, these are referred to as Control Plane Instances (CPIs). How CPIs are run depends on the size of the cluster and requirements for high availability. As demand increase in the cluster, a control plane service can scale to provide more instances of that service, with requests being load balanced between the instances. Tasks that components of the Kubernetes control plane performs include: • Communicating with cluster components (API server) — The API server (kube-apiserver) exposes the Kubernetes API so requests to the cluster can be made from both inside and outside of the cluster. In other words, requests to add or change a cluster’s objects (Pods, Services, Nodes, and so on) can come from outside commands, such as requests from kubectl to run a Pod. Likewise, requests can be made from the API server to components within the cluster, such as a query to the kubelet service for the status of a Pod. • Store data about the cluster (etcd key value store) — The etcd service provides the critical role of keeping track of the current state of the cluster. If the etcd service became inaccessible, you would be unable to update or query the status",
19
+ "the etcd service became inaccessible, you would be unable to update or query the status of the cluster, though workloads would continue to run for a while. For that reason, critical clusters typically have multiple, loadbalanced instances of the etcd service running at a time and do periodic backups of the etcd key value store in case of data loss or corruption. Keep in mind that, in Amazon EKS, this is all handled for you automatically by default. Amazon EKS Anywhere provides instruction for etcd backup and restore. See the etcd Data Model to learn how etcd manages data. • Schedule Pods to nodes (Scheduler) — Requests to start or stop a Pod in Kubernetes are directed to the Kubernetes Scheduler (kube-scheduler). Because a cluster could have multiple nodes that are capable of running the Pod, it is up to the Scheduler to choose which node (or nodes, in the case of replicas) the Pod should run on. If there is not enough available capacity to run the requested Pod on an existing node, the request will fail, unless you have made other Clusters 16 Amazon EKS User Guide provisions. Those provisions could include enabling services such as Managed Node Groups (the section called “Managed node groups”) or Karpenter that can automatically start up new nodes to handle the workloads. • Keep components in desired state (Controller Manager) — The Kubernetes Controller Manager runs as a daemon process (kube-controller-manager) to watch the state of the cluster and make changes to the cluster to reestablish the expected states. In particular, there are several controllers that watch over different Kubernetes objects, which includes a statefulsetcontroller, endpoint-controller, cronjob-controller, node-controller, and others. • Manage cloud resources (Cloud Controller Manager) — Interactions between Kubernetes and the cloud provider that carries out requests for the underlying",
20
+ "— Interactions between Kubernetes and the cloud provider that carries out requests for the underlying data center resources are handled by the Cloud Controller Manager (cloud-controller-manager). Controllers managed by the Cloud Controller Manager can include a route controller (for setting up cloud network routes), service controller (for using cloud load balancing services), and node lifecycle controller (to keep nodes in sync with Kubernetes throughout their lifecycles). Worker Nodes (data plane) For a single-node Kubernetes cluster, workloads run on the same machine as the control plane. However, a more standard configuration is to have one or more separate computer systems (Nodes) that are dedicated to running Kubernetes workloads. When you first create a Kubernetes cluster, some cluster creation tools allow you to configure a certain number nodes to be added to the cluster (either by identifying existing computer systems or by having the provider create new ones). Before any workloads are added to those systems, services are added to each node to implement these features: • Manage each node (kubelet) — The API server communicates with the kubelet service running on each node to make sure that the node is properly registered and Pods requested by the Scheduler are running. The kubelet can read the Pod manifests and set up storage volumes or other features needed by the Pods on the local system. It can also check on the health of the locally running containers. • Run containers on a node (container runtime) — The Container Runtime on each node manages the containers requested for each Pod assigned to the node. That means that it can pull container images from the appropriate registry, run the container, stop it, and responds to queries about the container. The default container runtime is containerd. As of Kubernetes 1.24, the special integration of Docker (dockershim)",
21
+ "default container runtime is containerd. As of Kubernetes 1.24, the special integration of Docker (dockershim) that could be used as the container runtime was Clusters 17 Amazon EKS User Guide dropped from Kubernetes. While you can still use Docker to test and run containers on your local system, to use Docker with Kubernetes you would now have to Install Docker Engine on each node to use it with Kubernetes. • Manage networking between containers (kube-proxy) — To be able to support communication between Pods, Kubernetes uses a feature referred to as a Service to set up Pod networks that track IP addresses and ports associated with those Pods. The kube-proxy service runs on every node to allow that communication between Pods to take place. Extend Clusters There are some services you can add to Kubernetes to support the cluster, but are not run in the control plane. These services often run directly on nodes in the kube-system namespace or in its own namespace (as is often done with third-party service providers). A common example is the CoreDNS service, which provides DNS services to the cluster. Refer to Discovering builtin services for information on how to see which cluster services are running in kube-system on your cluster. There are different types of add-ons you can consider adding to your clusters. To keep your clusters healthy, you can add observability features (see Monitor clusters) that allow you to do things like logging, auditing, and metrics. With this information, you can troubleshoot problems that occur, often through the same observability interfaces. Examples of these types of services include Amazon GuardDuty, CloudWatch (see the section called “Amazon CloudWatch”), AWS Distro for OpenTelemetry, Amazon VPC CNI plugin for Kubernetes (see the section called “Amazon VPC CNI”), and Grafana Kubernetes Monitoring. For storage (see App data",
22
+ "the section called “Amazon VPC CNI”), and Grafana Kubernetes Monitoring. For storage (see App data storage), add-ons to Amazon EKS include Amazon Elastic Block Store CSI Driver (see the section called “Amazon EBS”), Amazon Elastic File System CSI Driver (see the section called “Amazon EFS”), and several third-party storage add-ons such as Amazon FSx for NetApp ONTAP CSI driver the section called “Amazon FSx for NetApp ONTAP”). For a more complete list of available Amazon EKS add-ons, see the section called “Amazon EKS add-ons”. Workloads Kubernetes defines a Workload as \"an application running on Kubernetes.\" That application can consist of a set of microservices run as Containers in Pods, or could be run as a batch job or other type of applications. The job of Kubernetes is to make sure that the requests that you make for those objects to be set up or deployed are carried out. As someone deploying applications, you Workloads 18 Amazon EKS User Guide should learn about how containers are built, how Pods are defined, and what methods you can use for deploying them. Containers The most basic element of an application workload that you deploy and manage in Kubernetes is a Pod . A Pod represents a way of holding the components of an application as well as defining specifications that describe the Pod’s attributes. Contrast this to something like an RPM or Deb package, which packages together software for a Linux system, but does not itself run as an entity. Because the Pod is the smallest deployable unit, it typically holds a single container. However, multiple containers can be in a Pod in cases where the containers are tightly coupled. For example, a web server container might be packaged in a Pod with a sidecar type of container that may provide logging, monitoring,",
23
+ "packaged in a Pod with a sidecar type of container that may provide logging, monitoring, or other service that is closely tied to the web server container. In this case, being in the same Pod ensures that for each running instance of the Pod, both containers always run on the same node. Likewise, all containers in a Pod share the same environment, with the containers in a Pod running as though they are in the same isolated host. The effect of this is that the containers share a single IP address that provides access to the Pod and the containers can communicate with each other as though they were running on their own localhost. Pod specifications (PodSpec) define the desired state of the Pod. You can deploy an individual Pod or multiple Pods by using workload resources to manage Pod Templates. Workload resources include Deployments (to manage multiple Pod Replicas), StatefulSets (to deploy Pods that need to be unique, such as database Pods), and DaemonSets (where a Pod needs to run continuously on every node). More on those later. While a Pod is the smallest unit you deploy, a container is the smallest unit that you build and manage. Building Containers The Pod is really just a structure around one or more containers, with each container itself holding the file system, executables, configuration files, libraries, and other components to actually run the application. Because a company called Docker Inc. first popularized containers, some people refer to containers as Docker Containers. However, the Open Container Initiative has since defined container runtimes, images, and distribution methods for the industry. Add to that the fact that containers were created from many existing Linux features, others often refer to containers as OCI Containers, Linux Containers, or just Containers. Workloads 19 Amazon EKS User Guide",
24
+ "containers as OCI Containers, Linux Containers, or just Containers. Workloads 19 Amazon EKS User Guide When you build a container, you typically start with a Dockerfile (literally named that). Inside that Dockerfile, you identify: • A base image — A base container image is a container that is typically built from either a minimal version of an operating system’s file system (such as Red Hat Enterprise Linux or Ubuntu) or a minimal system that is enhanced to provide software to run specific types of applications (such as a nodejs or python apps). • Application software — You can add your application software to your container in much the same way you would add it to a Linux system. For example, in your Dockerfile you can run npm and yarn to install a Java application or yum and dnf to install RPM packages. In other words, using a RUN command in a Dockerfile, you can run any command that is available in the file system of your base image to install software or configure software inside of the resulting container image. • Instructions — The Dockerfile reference describes the instructions you can add to a Dockerfile when you configure it. These include instructions used to build what is in the container itself (ADD or COPY files from the local system), identify commands to execute when the container is run (CMD or ENTRYPOINT), and connect the container to the system it runs on (by identifying the USER to run as, a local VOLUME to mount, or the ports to EXPOSE). While the docker command and service have traditionally been used to build containers (docker build), other tools that are available to build container images include podman and nerdctl. See Building Better Container Images or Overview of Docker Build to learn about building",
25
+ "nerdctl. See Building Better Container Images or Overview of Docker Build to learn about building containers. Storing Containers Once you’ve built your container image, you can store it in a container distribution registry on your workstation or on a public container registry. Running a private container registry on your workstation allows you to store container images locally, making them readily available to you. To store container images in a more public manner, you can push them to a public container registry. Public container registries provide a central location for storing and distributing container images. Examples of public container registries include the Amazon Elastic Container Registry, Red Hat Quay registry, and Docker Hub registry. When running containerized workloads on Amazon Elastic Kubernetes Service (Amazon EKS) we recommend pulling copies of Docker Official Images that are stored in Amazon Elastic Container Registry. Amazon ECR has been storing these images since 2021. You can search for popular Workloads 20 Amazon EKS User Guide container images in the Amazon ECR Public Gallery, and specifically for the Docker Hub images, you can search the Amazon ECR Docker Gallery. Running containers Because containers are built in a standard format, a container can run on any machine that can run a container runtime (such as Docker) and whose contents match the local machine’s architecture (such as x86_64 or arm). To test a container or just run it on your local desktop, you can use docker run or podman run commands to start up a container on the localhost. For Kubernetes, however, each worker node has a container runtime deployed and it is up to Kubernetes to request that a node run a container. Once a container has been assigned to run on a node, the node looks to see if the requested version of the container image",
26
+ "a node, the node looks to see if the requested version of the container image already exists on the node. If it doesn’t, Kubernetes tells the container runtime to pull that container from the appropriate container registry, then run that container locally. Keep in mind that a container image refers to the software package that is moved around between your laptop, the container registry, and Kubernetes nodes. A container refers to a running instance of that image. Pods Once your containers are ready, working with Pods includes configuring, deploying, and making the Pods accessible. Configuring Pods When you define a Pod, you assign a set of attributes to it. Those attributes must include at least the Pod name and the container image to run. However, there are many other things you want to configure with your Pod definitions as well (see the PodSpec page for details on what can go into a Pod). These include: • Storage — When a running container is stopped and deleted, data storage in that container will disappear, unless you set up more permanent storage. Kubernetes supports many different storage types and abstracts them under the umbrella of Volumes. Storage types include CephFS, NFS, iSCSI, and others. You can even use a local block device from the local computer. With one of those storage types available from your cluster, you can mount the storage volume to a selected mount point in your container’s file system. A Persistent Volume is one that continues to exist after the Pod is deleted, while an Ephemeral Volume is deleted when the Pod is deleted. If your cluster administrator created different storage classes for your cluster, you might have the Workloads 21 Amazon EKS User Guide option for choosing the attributes of the storage you use, such as whether the",
27
+ "Guide option for choosing the attributes of the storage you use, such as whether the volume is deleted or reclaimed after use, whether it will expand if more space is needed, and even whether it meets certain performance requirements. • Secrets — By making Secrets available to containers in Pod specs, you can provide the permissions those containers need to access file systems, data bases, or other protected assets. Keys, passwords, and tokens are among the items that can be stored as secrets. Using secrets makes it so you don’t have to store this information in container images, but need only make the secrets available to running containers. Similar to Secrets are ConfigMaps. A ConfigMap tends to hold less critical information, such as key-value pairs for configuring a service. • Container resources — Objects for further configuring containers can take the form of resource configuration. For each container, you can request the amount of memory and CPU that it can use, as well as place limits of the total amount of those resources that the container can use. See Resource Management for Pods and Containers for examples. • Disruptions — Pods can be disrupted involuntarily (a node goes down) or voluntarily (an upgrade is desired). By configuring a Pod disruption budget, you can exert some control over how available your application remains when disruptions occur. See Specifying a Disruption Budget for your application for examples. • Namespaces — Kubernetes provides different ways to isolate Kubernetes components and workloads from each other. Running all the Pods for a particular application in the same Namespace is a common way to secure and manage those Pods together. You can create your own namespaces to use or choose to not indicate a namespace (which causes Kubernetes to use the default namespace). Kubernetes control plane",
28
+ "not indicate a namespace (which causes Kubernetes to use the default namespace). Kubernetes control plane components typically run in the kubesystem namespace. The configuration just described is typically gathered together in a YAML file to be applied to the Kubernetes cluster. For personal Kubernetes clusters, you might just store these YAML files on your local system. However, with more critical clusters and workloads, GitOps is a popular way to automate storage and updates to both workload and Kubernetes infrastructure resources. The objects used to gather together and deploy Pod information is defined by one of the following deployment methods. Deploying Pods The method you would choose for deploying Pods depends on the type of application you plan to run with those Pods. Here are some of your choices: Workloads 22 Amazon EKS User Guide • Stateless applications — A stateless application doesn’t save a client’s session data, so another session doesn’t need to refer back to what happened to a previous session. This makes it easier to just replace Pods with new ones if they become unhealthy or move them around without saving state. If you are running a stateless application (such as a web server), you can use a Deployment to deploy Podsand ReplicaSets. A ReplicaSet defines how many instances of a Pod that you want running concurrently. Although you can run a ReplicaSet directly, it is common to run replicas directly within a Deployment, to define how many replicas of a Pod should be running at a time. • Stateful applications — A stateful application is one where the identity of the Pod and the order in which Pods are launched are important. These applications need persistent storage that is stable and need to be deployed and scaled in a consistent manner. To deploy a stateful application in",
29
+ "to be deployed and scaled in a consistent manner. To deploy a stateful application in Kubernetes, you can use StatefulSets. An example of an application that is typically run as a StatefulSet is a database. Within a StatefulSet, you could define replicas, the Pod and its containers, storage volumes to mount, and locations in the container where data are stored. See Run a Replicated Stateful Application for an example of a database being deployed as a ReplicaSet. • Per-node applications — There are times when you want to run an application on every node in your Kubernetes cluster. For example, your data center might require that every computer run a monitoring application or a particular remote access service. For Kubernetes, you can use a DaemonSet to ensure that the selected application runs on every node in your cluster. • Applications run to completion — There are some applications you want to run to complete a particular task. This could include one that runs monthly status reports or cleans out old data. A Job object can be used to set up an application to start up and run, then exit when the task is done. A CronJob object lets you set up an application to run at a specific hour, minute, day of the month, month, or day of the week, using a structure defined by the Linux crontab format. Making applications accessible from the network With applications often deployed as a set of microservices that moved around to different places, Kubernetes needed a way for those microservices to be able to find each other. Also, for others to access an application outside of the Kubernetes cluster, Kubernetes needed a way to expose that application on outside addresses and ports. These networking-related features are done with Service and Ingress objects, respectively:",
30
+ "outside addresses and ports. These networking-related features are done with Service and Ingress objects, respectively: • Services — Because a Pod can move around to different nodes and addresses, another Pod that needs to communicate with the first Pod could find it difficult to locate where it is. To solve Workloads 23 Amazon EKS User Guide this problem, Kubernetes lets you represent an application as a Service. With a Service, you can identify a Pod or set of Pods with a particular name, then indicate what port exposes that application’s service from the Pod and what ports another application could use to contact that service. Another Pod within a cluster can simply request a Service by name and Kubernetes will direct that request to the proper port for an instance of the Pod running that service. • Ingress — Ingress is what can make applications represented by Kubernetes Services available to clients that are outside of the cluster. Basic features of Ingress include a load balancer (managed by Ingress), the Ingress controller, and rules for routing requests from the controller to the Service. There are several Ingress Controllers that you can choose from with Kubernetes. Next steps Understanding basic Kubernetes concepts and how they relate to Amazon EKS will help you navigate both the Amazon EKS documentation and Kubernetes documentation to find the information you need to manage Amazon EKS clusters and deploy workloads to those clusters. To begin using Amazon EKS, choose from the following: • the section called “Create cluster (eksctl)” • the section called “Create a cluster” • the section called “Sample deployment (Linux)” • Cluster management Deploy Amazon EKS clusters across cloud and on-premises environments Understand Amazon EKS deployment options Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service that enables you to",
31
+ "Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service that enables you to run Kubernetes seamlessly in the cloud and in your on-premises environments. In the cloud, Amazon EKS automates Kubernetes cluster infrastructure management for the Kubernetes control plane and nodes. This is essential for scheduling containers, managing application availability, dynamically scaling resources, optimizing compute, storing cluster data, and performing other critical functions. With Amazon EKS, you get the robust performance, scalability, reliability, and availability of AWS infrastructure, along with native integrations with AWS networking, security, storage, and observability services. Next steps 24 Amazon EKS User Guide To simplify running Kubernetes in your on-premises environments, you can use the same Amazon EKS clusters, features, and tools to the section called “Nodes” or Amazon EKS Hybrid Nodes on your own infrastructure, or you can use Amazon EKS Anywhere for self-contained air-gapped environments. Amazon EKS in the cloud You can use Amazon EKS with compute in AWS Regions, AWS Local Zones, and AWS Wavelength Zones. With Amazon EKS in the cloud, the security, scalability, and availability of the Kubernetes control plane is fully managed by AWS in the AWS Region. When running applications with compute in AWS Regions, you get the full breadth of AWS and Amazon EKS features, including Amazon EKS Auto Mode, which fully automates Kubernetes cluster infrastructure management for compute, storage, and networking on AWS with a single click. When running applications with compute in AWS Local Zones and AWS Wavelength Zones, you can use Amazon EKS self-managed nodes to connect Amazon EC2 instances for your cluster compute and can use the other available AWS services in AWS Local Zones and AWS Wavelength Zones. For more information see AWS Local Zones features and AWS Wavelength Zones features. Amazon EKS in AWS Regions Amazon EKS in Local/Wav elength",
32
+ "and AWS Wavelength Zones features. Amazon EKS in AWS Regions Amazon EKS in Local/Wav elength Zones Kuberenetes control plane management AWS-managed AWS-managed Kubernetes control plane location AWS Regions AWS Regions Kubernetes data plane • Amazon EKS Auto Mode • Amazon EKS Managed Node Groups • Amazon EKS Managed Node Groups (Local Zones only) • Amazon EC2 self-managed nodes • Amazon EC2 self-managed nodes • AWS Fargate Kubernetes data plane location Amazon EKS in the cloud AWS Regions AWS Local or Wavelength Zones 25 Amazon EKS User Guide Amazon EKS in your data center or edge environments If you need to run applications in your own data centers or edge environments, you can use Amazon EKS on AWS Outposts or Amazon EKS Hybrid Nodes. You can use self-managed nodes with Amazon EC2 instances on AWS Outposts for your cluster compute, or you can use Amazon EKS Hybrid Nodes with your own on-premises or edge infrastructure for your cluster compute. AWS Outposts is AWS-managed infrastructure that you run in your data centers or co-location facilities, whereas Amazon EKS Hybrid Nodes runs on your physical or virtual machines that you manage in your on-premises or edge environments. Amazon EKS on AWS Outposts and Amazon EKS Hybrid Nodes require a reliable connection from your on-premises environments to an AWS Region, and you can use the same Amazon EKS clusters, features, and tools you use to run applications in the cloud. When running on AWS Outposts, you can alternatively deploy the entire Kubernetes cluster on AWS Outposts with Amazon EKS local clusters on AWS Outposts. Amazon EKS Hybrid Nodes Amazon EKS on AWS Outposts Kuberenetes control plane management AWS-managed AWS-managed Kubernetes control plane location AWS Regions AWS Regions or AWS Outposts Kubernetes data plane Customer-managed physical or virtual machines Amazon EC2 self-managed nodes Kubernetes data",
33
+ "Outposts Kubernetes data plane Customer-managed physical or virtual machines Amazon EC2 self-managed nodes Kubernetes data plane location Customer data center or edge environment Customer data center or edge environment Amazon EKS Anywhere for air-gapped environments Amazon EKS Anywhere simplifies Kubernetes cluster management through the automation of undifferentiated heavy lifting such as infrastructure setup and Kubernetes cluster lifecycle operations in on-premises and edge environments. Unlike Amazon EKS, Amazon EKS Anywhere is a customer-managed product and customers are responsible for cluster lifecycle operations and maintenance of Amazon EKS Anywhere clusters. Amazon EKS Anywhere is built on the Kubernetes sub-project Cluster API (CAPI) and supports a range of infrastructure including VMware vSphere, Amazon EKS in your data center or edge environments 26 Amazon EKS User Guide bare metal, Nutanix, Apache CloudStack, and AWS Snow. Amazon EKS Anywhere can be run in airgapped environments and offers optional integrations with regional AWS services for observability and identity management. To receive support for Amazon EKS Anywhere and access to AWSvended Kubernetes add-ons, you can purchase Amazon EKS Anywhere Enterprise Subscriptions. Amazon EKS Anywhere Kuberenetes control plane management Customer-managed Kubernetes control plane location Customer data center or edge environment Kubernetes data plane Customer-managed physical or virtual machines Kubernetes data plane location Customer data center or edge environment Amazon EKS tooling You can use the Amazon EKS Connector to register and connect any conformant Kubernetes cluster to AWS and view it in the Amazon EKS console. After a cluster is connected, you can see the status, configuration, and workloads for that cluster in the Amazon EKS console. You can use this feature to view connected clusters in Amazon EKS console, but the Amazon EKS Connector does not enable management or mutating operations for your connected clusters through the Amazon EKS console. Amazon EKS Distro is the AWS distribution",
34
+ "your connected clusters through the Amazon EKS console. Amazon EKS Distro is the AWS distribution of the underlying Kubernetes components that power all Amazon EKS offerings. It includes the core components required for a functioning Kubernetes cluster such as Kubernetes control plane components (etcd, kube-apiserver, kube-scheduler, kubecontroller-manager) and networking components (CoreDNS, kube-proxy, CNI plugins). Amazon EKS Distro can be used to self-manage Kubernetes clusters with your choice of tooling. Amazon EKS Distro deployments are not covered by AWS Support Plans. Amazon EKS tooling 27 Amazon EKS User Guide Set up to use Amazon EKS To prepare for the command-line management of your Amazon EKS clusters, you need to install several tools. Use the following to set up credentials, create and modify clusters, and work with clusters once they are running: • Set up AWS CLI – Get the AWS CLI to set up and manage the services you need to work with Amazon EKS clusters. In particular, you need AWS CLI to configure credentials, but you also need it with other AWS services. • Set up kubectl and eksctl – The eksctl CLI interacts with AWS to create, modify, and delete Amazon EKS clusters. Once a cluster is up, use the open source kubectl command to manage Kubernetes objects within your Amazon EKS clusters. • Set up a development environment (optional)– Consider adding the following tools: • Local deployment tool – If you’re new to Kubernetes, consider installing a local deployment tool like minikube or kind. These tools allow you to have an Amazon EKS cluster on your local machine for testing applications. • Package manager – helm is a popular package manager for Kubernetes that simplifies the installation and management of complex packages. With Helm, it’s easier to install and manage packages like the AWS Load Balancer Controller on",
35
+ "Helm, it’s easier to install and manage packages like the AWS Load Balancer Controller on your Amazon EKS cluster. Next steps • Set up AWS CLI • Set up kubectl and eksctl • Quickstart: Deploy a web app and store data Set up AWS CLI The AWS CLI is a command line tool for working with AWS services, including Amazon EKS. It is also used to authenticate IAM users or roles for access to the Amazon EKS cluster and other AWS resources from your local machine. To provision resources in AWS from the command line, you need to obtain an AWS access key ID and secret key to use in the command line. Then you need to configure these credentials in the AWS CLI. If you haven’t already installed the AWS CLI, see Install or update the latest version of the AWS CLI in the AWS Command Line Interface User Guide. Next steps 28 Amazon EKS User Guide To create an access key 1. Sign into the AWS Management Console. 2. For single-user or multiple-user accounts: • Single-user account –:: In the top right, choose your AWS user name to open the navigation menu. For example, choose webadmin . • Multiple-user account –:: Choose IAM from the list of services. From the IAM Dashboard, select Users, and choose the name of the user. 3. Choose Security credentials. 4. Under Access keys, choose Create access key. 5. Choose Command Line Interface (CLI), then choose Next. 6. Choose Create access key. 7. Choose Download .csv file. To configure the AWS CLI After installing the AWS CLI, do the following steps to configure it. For more information, see Configure the AWS CLI in the AWS Command Line Interface User Guide. 1. In a terminal window, enter the following command: aws configure Optionally, you",
36
+ "User Guide. 1. In a terminal window, enter the following command: aws configure Optionally, you can configure a named profile, such as --profile cluster-admin. If you configure a named profile in the AWS CLI, you must always pass this flag in subsequent commands. 2. Enter your AWS credentials. For example: Access Key ID [None]: AKIAIOSFODNN7EXAMPLE Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: region-code Default output format [None]: json To create an access key 29 Amazon EKS User Guide To get a security token If needed, run the following command to get a new security token for the AWS CLI. For more information, see get-session-token in the AWS CLI Command Reference. By default, the token is valid for 15 minutes. To change the default session timeout, pass the -duration-seconds flag. For example: aws sts get-session-token --duration-seconds 3600 This command returns the temporary security credentials for an AWS CLI session. You should see the following response output: { \"Credentials\": { \"AccessKeyId\": \"ASIA5FTRU3LOEXAMPLE\", \"SecretAccessKey\": \"JnKgvwfqUD9mNsPoi9IbxAYEXAMPLE\", \"SessionToken\": \"VERYLONGSESSIONTOKENSTRING\", \"Expiration\": \"2023-02-17T03:14:24+00:00\" } } To verify the user identity If needed, run the following command to verify the AWS credentials for your IAM user identity (such as ClusterAdmin) for the terminal session. aws sts get-caller-identity This command returns the Amazon Resource Name (ARN) of the IAM entity that’s configured for the AWS CLI. You should see the following example response output: { \"UserId\": \"AKIAIOSFODNN7EXAMPLE\", \"Account\": \"01234567890\", \"Arn\": \"arn:aws:iam::01234567890:user/ClusterAdmin\" } To get a security token 30 Amazon EKS User Guide Next steps • Set up kubectl and eksctl • Quickstart: Deploy a web app and store data Set up kubectl and eksctl Once the AWS CLI is installed, there are two other tools you should install to create and manage your Kubernetes clusters: • kubectl: The kubectl command line tool is the main tool you",
37
+ "your Kubernetes clusters: • kubectl: The kubectl command line tool is the main tool you will use to manage resources within your Kubernetes cluster. This page describes how to download and set up the kubectl binary that matches the version of your Kubernetes cluster. See Install or update kubectl. • eksctl: The eksctl command line tool is made for creating EKS clusters in the AWS cloud or on-premises (with EKS Anywhere), as well as modifying and deleting those clusters. See Install eksctl. Install or update kubectl This topic helps you to download and install, or update, the kubectl binary on your device. The binary is identical to the upstream community versions. The binary is not unique to Amazon EKS or AWS. Use the steps below to get the specific version of kubectl that you need, although many builders simply run brew install kubectl to install it. Note You must use a kubectl version that is within one minor version difference of your Amazon EKS cluster control plane. For example, a 1.32 kubectl client works with Kubernetes 1.31, 1.32, and 1.33 clusters. Step 1: Check if kubectl is installed Determine whether you already have kubectl installed on your device. kubectl version --client Next steps 31"
38
+ ]
dataset/chunks/fargate_chunks.json ADDED
@@ -0,0 +1,17 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "Amazon Elastic Container Service Developer Guide AWS Fargate for Amazon ECS AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing. When you run your tasks and services with the Fargate launch type, you package your application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task. You configure your task definitions for Fargate by setting the requiresCompatibilities task definition parameter to FARGATE. For more information, see Launch types. Fargate offers platform versions for Amazon Linux 2 (platform version 1.3.0), Bottlerocket operating system (platform version 1.4.0), and Microsoft Windows 2019 Server Full and Core editions.Unless otherwise specified, the information on this page applies to all Fargate platforms. This topic describes the different components of Fargate tasks and services, and calls out special considerations for using Fargate with Amazon ECS. For information about the Regions that support Linux containers on Fargate, see the section called “Linux containers on AWS Fargate”. For information about the Regions that support Windows containers on Fargate, see the section called “Windows containers on AWS Fargate”. Walkthroughs For information about how to get started using the console, see: • Learn how to create an Amazon ECS Linux task for the Fargate launch type • Learn how to create an Amazon ECS Windows task for the Fargate launch type For information about",
3
+ "to create an Amazon ECS Windows task for the Fargate launch type For information about how to get started using the AWS CLI, see: • Creating an Amazon ECS Linux task for the Fargate launch type with the AWS CLI Walkthroughs 167 Amazon Elastic Container Service Developer Guide • Creating an Amazon ECS Windows task for the Fargate launch type with the AWS CLI Capacity providers The following capacity providers are available: • Fargate • Fargate Spot - Run interruption tolerant Amazon ECS tasks at a discounted rate compared to the AWS Fargate price. Fargate Spot runs tasks on spare compute capacity. When AWS needs the capacity back, your tasks will be interrupted with a two-minute warning. For more information, see Amazon ECS clusters for Fargate. Task definitions Tasks that use the Fargate launch type don't support all of the Amazon ECS task definition parameters that are available. Some parameters aren't supported at all, and others behave differently for Fargate tasks. For more information, see Task CPU and memory. Platform versions AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate task infrastructure. It is a combination of the kernel and container runtime versions. You select a platform version when you run a task or when you create a service to maintain a number of identical tasks. New revisions of platform versions are released as the runtime environment evolves, for example, if there are kernel or operating system updates, new features, bug fixes, or security updates. A Fargate platform version is updated by making a new platform version revision. Each task runs on one platform version revision during its lifecycle. If you want to use the latest platform version revision, then you must start a new task. A new task that runs on Fargate always",
4
+ "then you must start a new task. A new task that runs on Fargate always runs on the latest revision of a platform version, ensuring that tasks are always started on secure and patched infrastructure. If a security issue is found that affects an existing platform version, AWS creates a new patched revision of the platform version and retires tasks running on the vulnerable revision. In some cases, you may be notified that your tasks on Fargate have been scheduled for retirement. For more information, see Task retirement and maintenance for AWS Fargate on Amazon ECS . Capacity providers 168 Amazon Elastic Container Service Developer Guide For more information see Fargate platform versions for Amazon ECS. Service load balancing Your Amazon ECS service on AWS Fargate can optionally be configured to use Elastic Load Balancing to distribute traffic evenly across the tasks in your service. Amazon ECS services on AWS Fargate support the Application Load Balancer, Network Load Balancer, and load balancer types. Application Load Balancers are used to route HTTP/HTTPS (or layer 7) traffic. Network Load Balancers are used to route TCP or UDP (or layer 4) traffic. For more information, see Use load balancing to distribute Amazon ECS service traffic. When you create a target group for these services, you must choose ip as the target type, not instance. This is because tasks that use the awsvpc network mode are associated with an elastic network interface, not an Amazon EC2 instance. For more information, see Use load balancing to distribute Amazon ECS service traffic. Using a Network Load Balancer to route UDP traffic to your Amazon ECS on AWS Fargate tasks is only supported when using platform version 1.4 or later. Usage metrics You can use CloudWatch usage metrics to provide visibility into your accounts usage of resources.",
5
+ "You can use CloudWatch usage metrics to provide visibility into your accounts usage of resources. Use these metrics to visualize your current service usage on CloudWatch graphs and dashboards. AWS Fargate usage metrics correspond to AWS service quotas. You can configure alarms that alert you when your usage approaches a service quota. For more information about AWS Fargate service quotas, Amazon ECS endpoints and quotas in the Amazon Web Services General Reference.. For more information about AWS Fargate usage metrics, see AWS Fargate usage metrics. Amazon ECS security considerations for when to use the Fargate launch type We recommend that customers looking for strong isolation for their tasks use Fargate. Fargate runs each task in a hardware virtualization environment. This ensures that these containerized workloads do not share network interfaces, Fargate ephemeral storage, CPU, or memory with other tasks. For more information, see Security Overview of AWS Fargate. Service load balancing 169 Amazon Elastic Container Service Developer Guide Fargate security best practices in Amazon ECS We recommend that you take into account the following best practices when you use AWS Fargate. For additional guidance, see Security overview of AWS Fargate. Use AWS KMS to encrypt ephemeral storage for Fargate You should have your ephemeral storage encrypted by either AWS KMS or your own customer managed keys. For tasks that are hosted on Fargate using platform version 1.4.0 or later, each task receives 20 GiB of ephemeral storage. For more information, see customer managed key (CMK). You can increase the total amount of ephemeral storage, up to a maximum of 200 GiB, by specifying the ephemeralStorage parameter in your task definition. For such tasks that were launched on May 28, 2020 or later, the ephemeral storage is encrypted with an AES-256 encryption algorithm using an encryption key managed by Fargate. For",
6
+ "is encrypted with an AES-256 encryption algorithm using an encryption key managed by Fargate. For more information, see Storage options for Amazon ECS tasks. Example: Launching an task on Fargate platform version 1.4.0 with ephemeral storage encryption The following command will launch a task on Fargate platform version 1.4. Because this task is launched as part of the cluster, it uses the 20 GiB of ephemeral storage that's automatically encrypted. aws ecs run-task --cluster clustername \\ --task-definition taskdefinition:version \\ --count 1 --launch-type \"FARGATE\" \\ --platform-version 1.4.0 \\ --network-configuration \"awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}\" \\ --region region SYS_PTRACE capability for kernel syscall tracing with Fargate The default configuration of Linux capabilities that are added or removed from your container are provided by Docker. Tasks that are launched on Fargate only support adding the SYS_PTRACE kernel capability. The following video shows how to use this feature through the Sysdig Falco project. Fargate security best practices 170 Amazon Elastic Container Service Developer Guide #ContainersFromTheCouch - Troubleshooting your Fargate Task using SYS_PTRACE capability The code discussed in the previous video can be found on GitHub here. Use Amazon GuardDuty with Fargate Runtime Monitoring Amazon GuardDuty is a threat detection service that helps protect your accounts, containers, workloads, and the data within your AWS environment. Using machine learning (ML) models, and anomaly and threat detection capabilities, GuardDuty continuously monitors different log sources and runtime activity to identify and prioritize potential security risks and malicious activities in your environment. Runtime Monitoring in GuardDuty protects workloads running on Fargate by continuously monitoring AWS log and networking activity to identify malicious or unauthorized behavior. Runtime Monitoring uses a lightweight, fully managed GuardDuty security agent that analyzes onhost behavior, such as file access, process execution, and network connections. This covers issues including escalation of privileges, use of exposed credentials, or communication with malicious",
7
+ "This covers issues including escalation of privileges, use of exposed credentials, or communication with malicious IP addresses, domains, and the presence of malware on your Amazon EC2 instances and container workloads. For more information, see GuardDuty Runtime Monitoring in the GuardDuty User Guide. Fargate security considerations for Amazon ECS Each task has a dedicated infrastructure capacity because Fargate runs each workload on an isolated virtual environment. Workloads that run on Fargate do not share network interfaces, ephemeral storage, CPU, or memory with other tasks. You can run multiple containers within a task including application containers and sidecar containers, or simply sidecars. A sidecar is a container that runs alongside an application container in an Amazon ECS task. While the application container runs core application code, processes running in sidecars can augment the application. Sidecars help you segregate application functions into dedicated containers, making it easier for you to update parts of your application. Containers that are part of the same task share resources for the Fargate launch type because these containers will always run on the same host and share compute resources. These containers also share the ephemeral storage provided by Fargate. Linux containers in a task share network namespaces, including the IP address and network ports. Inside a task, containers that belong to the task can inter-communicate over localhost. The runtime environment in Fargate prevents you from using certain controller features that are supported on EC2 instances. Consider the following when you architect workloads that run on Fargate: Use Amazon GuardDuty with Fargate Runtime Monitoring 171 Amazon Elastic Container Service Developer Guide • No privileged containers or access - Features such as privileged containers or access are currently unavailable on Fargate. This will affect uses cases such as running Docker in Docker. • Limited access to Linux capabilities -",
8
+ "uses cases such as running Docker in Docker. • Limited access to Linux capabilities - The environment in which containers run on Fargate is locked down. Additional Linux capabilities, such as CAP_SYS_ADMIN and CAP_NET_ADMIN, are restricted to prevent a privilege escalation. Fargate supports adding the CAP_SYS_PTRACE Linux capability to tasks to allow observability and security tools deployed within the task to monitor the containerized application. • No access to the underlying host - Neither customers nor AWS operators can connect to a host running customer workloads. You can use ECS exec to run commands in or get a shell to a container running on Fargate. You can use ECS exec to help collect diagnostic information for debugging. Fargate also prevents containers from accessing the underlying host’s resources, such as the file system, devices, networking, and container runtime. • Networking - You can use security groups and network ACLs to control inbound and outbound traffic. Fargate tasks receive an IP address from the configured subnet in your VPC. Fargate platform versions for Amazon ECS AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate task infrastructure. It is a combination of the kernel and container runtime versions. You select a platform version when you run a task or when you create a service to maintain a number of identical tasks. New revisions of platform versions are released as the runtime environment evolves, for example, if there are kernel or operating system updates, new features, bug fixes, or security updates. A Fargate platform version is updated by making a new platform version revision. Each task runs on one platform version revision during its lifecycle. If you want to use the latest platform version revision, then you must start a new task. A new task that runs on",
9
+ "version revision, then you must start a new task. A new task that runs on Fargate always runs on the latest revision of a platform version, ensuring that tasks are always started on secure and patched infrastructure. If a security issue is found that affects an existing platform version, AWS creates a new patched revision of the platform version and retires tasks running on the vulnerable revision. In some cases, you may be notified that your tasks on Fargate have been scheduled for retirement. For more information, see Task retirement and maintenance for AWS Fargate on Amazon ECS . You specify the platform version when you run a task, or deploy a service. Fargate platform versions 172 Amazon Elastic Container Service Developer Guide Consider the following when specifying a platform version: • You can specify a a specific version number, for example 1.4.0, or LATEST. The LATEST Linux platform version is 1.4.0. The LATEST Windows platform version is 1.0.0. • If you want to update the platform version for a service, create a deployment. For example, assume that you have a service that runs tasks on the Linux platform version 1.3.0. To change the service to run tasks on the Linux platform version 1.4.0, you update your service and specify a new platform version. Your tasks are redeployed with the latest platform version and the latest platform version revision. For more information about deployments, see Amazon ECS services. • If your service is scaled up without updating the platform version, those tasks receive the platform version that was specified on the service's current deployment. For example, assume that you have a service that runs tasks on the Linux platform version 1.3.0. If you increase the desired count of the service, the service scheduler starts the new tasks using the latest",
10
+ "desired count of the service, the service scheduler starts the new tasks using the latest platform version revision of platform version 1.3.0. • New tasks always run on the latest revision of a platform version. This ensures tasks are always on secured and patched infrastructure. • The platform version numbers for Linux containers and Windows containers on Fargate are independent. For example, the behavior, features, and software used in platform version 1.0.0 for Windows containers on Fargate aren't comparable to those of platform version 1.0.0 for Linux containers on Fargate. • The following applies to Fargate Windows platform versions. Microsoft Windows Server container images must be created from a specific version of Windows Server. You must select the same version of Windows Server in the platformFamily when you run a task or create a service that matches the Windows Server container image. Additionally, you can provide a matching operatingSystemFamily in the task definition to prevent tasks from being run on the wrong Windows version. For more information, see Matching container host version with container image versions on the Microsoft Learn website. Fargate platform versions 173 Amazon Elastic Container Service Developer Guide Migrating to Linux platform version 1.4.0 on Amazon ECS Consider the following when migrating your Amazon ECS on Fargate tasks from platform version 1.0.0, 1.1.0, 1.2.0, or 1.3.0 to platform version 1.4.0. It is best practice to confirm your task works properly on platform version 1.4.0 before you migrate the tasks. • The network traffic behavior to and from tasks has been updated. Starting with platform version 1.4.0, all Amazon ECS on Fargate tasks receive a single elastic network interface (referred to as the task ENI) and all network traffic flows through that ENI within your VPC. The traffic is visible to you through your VPC flow logs. For",
11
+ "within your VPC. The traffic is visible to you through your VPC flow logs. For more information see Amazon ECS task networking options for the Fargate launch type. • If you use interface VPC endpoints, consider the following. • For container images hosted with Amazon ECR, you need the following endpoints. For more information, see Amazon ECR interface VPC endpoints (AWS PrivateLink) in the Amazon Elastic Container Registry User Guide. • com.amazonaws.region.ecr.dkr Amazon ECR VPC endpoint • com.amazonaws.region.ecr.api Amazon ECR VPC endpoint • Amazon S3 gateway endpoint • When your task definition references Secrets Manager secrets to retrieve sensitive data for your containers, you must create the interface VPC endpoints for Secrets Manager. For more information, see Using Secrets Manager with VPC Endpoints in the AWS Secrets Manager User Guide. • When your task definition references Systems Manager Parameter Store parameters to retrieve sensitive data for your containers, you must create the interface VPC endpoints for Systems Manager. For more information, see Improve the security of EC2 instances by using VPC endpoints for Systems Manager in the AWS Systems Manager User Guide. • The security group for the Elastic Network Interface (ENI) associated with your task needs the security group rules to allow traffic between the task and the VPC endpoints. Fargate Linux platform version change log The following are the available Linux platform versions. For information about platform version deprecation, see AWS Fargate Linux platform version deprecation. Migrating to Linux platform version 1.4.0 174 Amazon Elastic Container Service Developer Guide 1.4.0 The following is the changelog for platform version 1.4.0. • Beginning on November 5, 2020, any new Amazon ECS task launched on Fargate using platform version 1.4.0 will be able to use the following features: • When using Secrets Manager to store sensitive data, you can inject a",
12
+ "following features: • When using Secrets Manager to store sensitive data, you can inject a specific JSON key or a specific version of a secret as an environment variable or in a log configuration. For more information, see Pass sensitive data to an Amazon ECS container. • Specify environment variables in bulk using the environmentFiles container definition parameter. For more information, see Pass an individual environment variable to an Amazon ECS container. • Tasks run in a VPC and subnet enabled for IPv6 will be assigned both a private IPv4 address and an IPv6 address. For more information, see Amazon ECS task networking options for the Fargate launch type. • The task metadata endpoint version 4 provides additional metadata about your task and container including the task launch type, the Amazon Resource Name (ARN) of the container, and the log driver and log driver options used. When querying the /stats endpoint you also receive network rate stats for your containers. For more information, see Task metadata endpoint version 4. • Beginning on July 30, 2020, any new Amazon ECS task launched on Fargate using platform version 1.4.0 will be able to route UDP traffic using a Network Load Balancer to their Amazon ECS on Fargate tasks. For more information, see Use load balancing to distribute Amazon ECS service traffic. • Beginning on May 28, 2020, any new Amazon ECS task launched on Fargate using platform version 1.4.0 will have its ephemeral storage encrypted with an AES-256 encryption algorithm using an AWS owned encryption key. For more information, see Fargate task ephemeral storage for Amazon ECS and Storage options for Amazon ECS tasks. • Added support for using Amazon EFS file system volumes for persistent task storage. For more information, see Use Amazon EFS volumes with Amazon ECS. • The ephemeral",
13
+ "storage. For more information, see Use Amazon EFS volumes with Amazon ECS. • The ephemeral task storage has been increased to a minimum of 20 GB for each task. For more information, see Fargate task ephemeral storage for Amazon ECS. • The network traffic behavior to and from tasks has been updated. Starting with platform version 1.4.0, all Fargate tasks receive a single elastic network interface (referred to as the task ENI) and all network traffic flows through that ENI within your VPC and will be visible to you through Linux Platform version change log 175 Amazon Elastic Container Service Developer Guide your VPC flow logs. For more information about networking for the Amazon EC2 launch type, see Amazon ECS task networking options for the EC2 launch type. For more information about networking for the Fargate launch type, see Amazon ECS task networking options for the Fargate launch type. • Task ENIs add support for jumbo frames. Network interfaces are configured with a maximum transmission unit (MTU), which is the size of the largest payload that fits within a single frame. The larger the MTU, the more application payload can fit within a single frame, which reduces per-frame overhead and increases efficiency. Supporting jumbo frames will reduce overhead when the network path between your task and the destination supports jumbo frames, such as all traffic that remains within your VPC. • CloudWatch Container Insights will include network performance metrics for Fargate tasks. For more information, see Monitor Amazon ECS containers using Container Insights with enhanced observability. • Added support for the task metadata endpoint version 4 which provides additional information for your Fargate tasks, including network stats for the task and which Availability Zone the task is running in. For more information, see Amazon ECS task metadata endpoint version 4",
14
+ "task is running in. For more information, see Amazon ECS task metadata endpoint version 4 and Amazon ECS task metadata endpoint version 4 for tasks on Fargate. • Added support for the SYS_PTRACE Linux parameter in container definitions. For more information, see Linux parameters. • The Fargate container agent replaces the use of the Amazon ECS container agent for all Fargate tasks. Usually, this change does not have an effect on how your tasks run. • The container runtime is now using Containerd instead of Docker. Most likely, this change does not have an effect on how your tasks run. You will notice that some error messages that originate with the container runtime changes from mentioning Docker to more general errors. For more information, see Amazon ECS stopped task error messages. • Based on Amazon Linux 2. 1.3.0 The following is the changelog for platform version 1.3.0. • Beginning on Sept 30, 2019, any new Fargate task that is launched supports the awsfirelens log driver. Configure the FireLens for Amazon ECS to use task definition parameters to route logs to an AWS service or AWS Partner Network (APN) destination for log storage and analytics. For more information, see Send Amazon ECS logs to an AWS service or AWS Partner. Linux Platform version change log 176 Amazon Elastic Container Service Developer Guide • Added task recycling for Fargate tasks, which is the process of refreshing tasks that are a part of an Amazon ECS service. For more information, Task retirement and maintenance for AWS Fargate on Amazon ECS. • Beginning on March 27, 2019, any new Fargate task that is launched can use additional task definition parameters that you use to define a proxy configuration, dependencies for container startup and shutdown as well as a per-container start and stop timeout value.",
15
+ "for container startup and shutdown as well as a per-container start and stop timeout value. For more information, see Proxy configuration, Container dependency, and Container timeouts. • Beginning on April 2, 2019, any new Fargate task that is launched supports injecting sensitive data into your containers by storing your sensitive data in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store parameters and then referencing them in your container definition. For more information, see Pass sensitive data to an Amazon ECS container. • Beginning on May 1, 2019, any new Fargate task that is launched supports referencing sensitive data in the log configuration of a container using the secretOptions container definition parameter. For more information, see Pass sensitive data to an Amazon ECS container. • Beginning on May 1, 2019, any new Fargate task that is launched supports the splunk log driver in addition to the awslogs log driver. For more information, see Storage and logging. • Beginning on July 9, 2019, any new Fargate tasks that is launched supports CloudWatch Container Insights. For more information, see Monitor Amazon ECS containers using Container Insights with enhanced observability. • Beginning on December 3, 2019, the Fargate Spot capacity provider is supported. For more information, see Amazon ECS clusters for Fargate. • Based on Amazon Linux 2. AWS Fargate Linux platform version deprecation This page lists Linux platform versions that AWS Fargate has deprecated or have been scheduled for deprecation. These platform versions remain available until the published deprecation date. A force update date is provided for each platform version scheduled for deprecation. On the force update date, any service using the LATEST platform version that is pointed to a platform version that is scheduled for deprecation will be updated using the force new deployment option. When the service is",
16
+ "for deprecation will be updated using the force new deployment option. When the service is updated using the force new deployment option, all tasks running on a platform version scheduled for deprecation are stopped and new tasks are launched using the platform version that the LATEST tag points to at that time. Standalone tasks or services with an explicit platform version set are not affected by the force update date. Linux platform version deprecation 177"
17
+ ]
dataset/chunks/lambda-dg_chunks.json ADDED
@@ -0,0 +1,23 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "AWS Lambda Developer Guide What is AWS Lambda? You can use AWS Lambda to run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure and manages all the computing resources, including server and operating system maintenance, capacity provisioning, automatic scaling, and logging. You organize your code into Lambda functions. The Lambda service runs your function only when needed and scales automatically. For pricing information, see AWS Lambda Pricing for details. When using Lambda, you are responsible only for your code. Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources to run your code. Because Lambda manages these resources, you cannot log in to compute instances or customize the operating system on provided runtimes. When to use Lambda Lambda is an ideal compute service for application scenarios that need to scale up rapidly, and scale down to zero when not in demand. For example, you can use Lambda for: • Stream processing: Use Lambda and Amazon Kinesis to process real-time streaming data for application activity tracking, transaction order processing, clickstream analysis, data cleansing, log filtering, indexing, social media analysis, Internet of Things (IoT) device data telemetry, and metering. • Web applications: Combine Lambda with other AWS services to build powerful web applications that automatically scale up and down and run in a highly available configuration across multiple data centers. To build web applications with AWS services, developers can use infrastructure as code (IaC) and orchestration tools such as AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), AWS Serverless Application Model, or coordinate complex workflows using AWS Step Functions. • Mobile backends: Build backends using Lambda and Amazon API Gateway to authenticate and process API requests. Use AWS Amplify to easily integrate with your iOS, Android, Web, and React",
3
+ "API requests. Use AWS Amplify to easily integrate with your iOS, Android, Web, and React Native frontends. • IoT backends: Build serverless backends using Lambda to handle web, mobile, IoT, and thirdparty API requests. • File processing: Use Amazon Simple Storage Service (Amazon S3) to trigger Lambda data processing in real time after an upload. When to use Lambda 1 AWS Lambda Developer Guide • Database Operations and Integration: Use Lambda to process database interactions both reactively and proactively, from handling queue messages for Amazon RDS operations like user registrations and order submissions, to responding to DynamoDB changes for audit logging, data replication, and automated workflows. • Scheduled and Periodic Tasks: Use Lambda with EventBridge rules to execute time-based operations such as database maintenance, data archiving, report generation, and other scheduled business processes using cron-like expressions. How Lambda works Because Lambda is a serverless, event-driven compute service, it uses a different programming paradigm than traditional web applications. The following model illustrates how Lambda fundamentally works: 1. You write and organize your code in Lambda functions, which are the basic building blocks you use to create a Lambda application. 2. You control security and access through Lambda permissions, using execution roles to manage what AWS services your functions can interact with and what resource policies can interact with your code. 3. Event sources and AWS services trigger your Lambda functions, passing event data in JSON format, which your functions process (this includes event source mappings). 4. Lambda runs your code with language-specific runtimes (like Node.js and Python) in execution environments that package your runtime, layers, and extensions. Tip To learn how to build serverless solutions, check out the Serverless Developer Guide. Key features Configure, control, and deploy secure applications: • Environment variables modify application behavior without new code deployments. • Versions",
4
+ "deploy secure applications: • Environment variables modify application behavior without new code deployments. • Versions safely test new features while maintaining stable production environments. How Lambda works 2 AWS Lambda Developer Guide • Lambda layers optimize code reuse and maintenance by sharing common components across multiple functions. • Code signing enforce security compliance by ensuring only approved code reaches production systems. Scale and perform reliably: • Concurrency and scaling controls precisely manage application responsiveness and resource utilization during traffic spikes. • Lambda SnapStart significantly reduce cold start times. Lambda SnapStart can provide as low as sub-second startup performance, typically with no changes to your function code. • Response streaming optimize function performance by delivering large payloads incrementally for real-time processing. • Container images package functions with complex dependencies using container workflows. Connect and integrate seamlessly: • VPC networks secure sensitive resources and internal services. • File system integration that shares persistent data and manage stateful operations across function invocations. • Function URLs create public-facing APIs and endpoints without additional services. • Lambda extensions augment functions with monitoring, security, and operational tools. Related information • For information on how Lambda works, see How Lambda works. • To start using Lambda, see Create your first Lambda function. • For a list of example applications, see Getting started with example applications and patterns. How Lambda works Lambda functions are the basic building blocks you use to build Lambda applications. To write functions, it's essential to understand the core concepts and components that make up the Lambda Related information 3 AWS Lambda Developer Guide programming model. This section will guide you through the fundamental elements you need to know to start building serverless applications with Lambda. • Lambda functions and function handlers - A Lambda function is a small block of code that runs",
5
+ "and function handlers - A Lambda function is a small block of code that runs in response to events. functions are the basic building blocks you use to build applications. Function handlers are the entry point for event objects that your Lambda function code processes. • Lambda execution environment and runtimes - Lambda execution environments manage the resources required to run your function. Run times are the language-specific environments your functions run in. • Events and triggers - how other AWS services invoke your functions in response to specific events. • Lambda permissions and roles - how you control who can access your functions and what other AWS services your functions can interact with. Tip If you want to start by understanding serverless development more generally, see Understanding the difference between traditional and serverless development in the AWS Serverless Developer Guide. Lambda functions and function handlers In Lambda, functions are the fundamental building blocks you use to create applications. A Lambda function is a piece of code that runs in response to events, such as a user clicking a button on a website or a file being uploaded to an Amazon Simple Storage Service (Amazon S3) bucket. You can think of a function as a kind of self-contained program with the following properties. A Lambda function handler is the method in your function code that processes events. When a function runs in response to an event, Lambda runs the function handler. Data about the event that caused the function to run is passed directly to the handler. While the code in a Lambda function can contain more than one method or function, Lambda functions can only have one handler. To create a Lambda function, you bundle your function code and its dependencies in a deployment package. Lambda supports two types",
6
+ "bundle your function code and its dependencies in a deployment package. Lambda supports two types of deployment package, .zip file archives and container images. Lambda functions and function handlers 4 AWS Lambda Developer Guide • A function has one specific job or purpose • They run only when needed in response to specific events • They automatically stop running when finished Lambda execution environment and runtimes Lambda functions run inside a secure, isolated execution environment which Lambda manages for you. This execution environment manages the processes and resources that are needed to run your function. When a function is first invoked, Lambda creates a new execution environment for the function to run in. After the function has finished running, Lambda doesn't stop the execution environment right away; if the function is invoked again, Lambda can re-use the existing execution environment. The Lambda execution environment also contains a runtime, a language-specific environment that relays event information and responses between Lambda and your function. Lambda provides a number of managed runtimes for the most popular programming languages, or you can create your own. For managed runtimes, Lambda automatically applies security updates and patches to functions using the runtime. Events and triggers You can also invoke a Lambda function directly by using the Lambda console, AWS CLI, or one of the AWS Software Development Kits (SDKs). It's more usual in a production application for your function to be invoked by another AWS service in response to a particular event. For example, you might want a function to run whenever an item is added to an Amazon DynamoDB table. To make your function respond to events, you set up a trigger. A trigger connects your function to an event source, and your function can have multiple triggers. When an event occurs, Lambda receives event",
7
+ "source, and your function can have multiple triggers. When an event occurs, Lambda receives event data as a JSON document and converts it into an object that your code can process. You might define the following JSON format for your event and the Lambda runtime converts this JSON to an object before passing it to your function's handler. Example custom Lambda event { \"Location\": \"SEA\", \"WeatherData\":{ Lambda execution environment and runtimes 5 AWS Lambda Developer Guide \"TemperaturesF\":{ \"MinTempF\": 22, \"MaxTempF\": 78 }, \"PressuresHPa\":{ \"MinPressureHPa\": 1015, \"MaxPressureHPa\": 1027 } } } Stream and queue services like Amazon Kinesis or Amazon SQS, Lambda use an event source mapping instead of a standard trigger. Event source mappings poll the source for new data, batch records together, and then invoke your function with the batched events. For more information, see How event source mappings differ from direct triggers. To understand how a trigger works, start by completing the Use an Amazon S3 trigger tutorial, or for a general overview of using triggers and instructions on creating a trigger using the Lambda console, see Integrating other services. Lambda permissions and roles For Lambda, there are two main types of permissions that you need to configure: • Permissions that your function needs to access other AWS services • Permissions that other users and AWS services need to access your function The following sections describe both of these permission types and discuss best practices for applying least-privilege permissions. Permissions for functions to access other AWS resources Lambda functions often need to access other AWS resources and perform actions on them. For example, a function might read items from a DynamoDB table, store an object in an S3 bucket, or write to an Amazon SQS queue. To give functions the permissions they need to perform these actions, you",
8
+ "Amazon SQS queue. To give functions the permissions they need to perform these actions, you use an execution role. A Lambda execution role is a special kind of AWS Identity and Access Management (IAM) role, an identity you create in your account that has specific permissions associated with it defined in a policy. Lambda permissions and roles 6 AWS Lambda Developer Guide Every Lambda function must have an execution role, and a single role can be used by more than one function. When a function is invoked, Lambda assumes the function's execution role and is granted permission to take the actions defined in the role's policy. When you create a function in the Lambda console, Lambda automatically creates an execution role for your function. The role's policy gives your function basic permissions to write log outputs to Amazon CloudWatch Logs. To give your function permission to perform actions on other AWS resources, you need to edit the role to add the extra permissions. The easiest way to add permissions is to use an AWS managed policy. Managed policies are created and administered by AWS and provide permissions for many common use cases. For example, if your function performs CRUD operations on a DynamoDB table, you can add the AmazonDynamoDBFullAccess policy to your role. Permissions for other users and resources to access your function To grant other AWS service permission to access your Lambda function, you use a resourcebased policy. In IAM, resource-based policies are attached to a resource (in this case, your Lambda function) and define who can access the resource and what actions they are allowed to take. For another AWS service to invoke your function through a trigger, your function's resource-based policy must grant that service permission to use the lambda:InvokeFunction action. If you create the trigger using",
9
+ "grant that service permission to use the lambda:InvokeFunction action. If you create the trigger using the console, Lambda automatically adds this permission for you. To grant permission to other AWS users to access your function, you can define this in your function's resource-based policy in exactly the same way as for another AWS service or resource. You can also use an identity-based policy that's associated with the user. Best practices for Lambda permissions When you set permissions using IAM policies, security best practice is to grant only the permissions required to perform a task. This is known as the principle of least privilege. To get started granting permissions for your function, you might choose to use an AWS managed policy. Managed policies can be the quickest and easiest way to grant permissions to perform a task, but they might also include other permissions you don't need. As you move from early development through test and production, we recommend you reduce permissions to only those needed by defining your own customer-managed policies. The same principle applies when granting permissions to access your function using a resourcebased policy. For example, if you want to give permission to Amazon S3 to invoke your function, Lambda permissions and roles 7 AWS Lambda Developer Guide best practice is to limit access to individual buckets, or buckets in particular AWS accounts, rather than giving blanket permissions to the S3 service. Lambda permissions and roles 8 AWS Lambda Developer Guide Running code with Lambda When you write a Lambda function, you are creating code that will run in a unique serverless environment. Understanding how Lambda actually runs your code involves two key aspects: the programming model that defines how your code interacts with Lambda, and the execution environment lifecycle that determines how Lambda manages your code's runtime",
10
+ "with Lambda, and the execution environment lifecycle that determines how Lambda manages your code's runtime environment. The Lambda programming model Programming model functions as a common set of rules for how Lambda works with your code, regardless of whether you're writing in Python, Java, or any other supported language. The programming model includes your runtime and handler. 1. Lambda receives an event. 2. Lambda uses the runtime (like Python or Java) to prepare the event in a format your code can use. 3. The runtime sends the formatted event to your handler. 4. Your handler processes the event using the code you've written in your Lambda function. Essential to this model is the handler, where Lambda sends events to be processed by your code. Think of it as the entry point to your code. When Lambda receives an event, it passes this event and some context information to your handler. The handler then runs your code to process these events - for example, it might read a file when it's uploaded to Amazon S3, analyze an image, or update a database. Once your code finishes processing an event, the handler is ready to process the next one. The Lambda execution model While the programming model defines how Lambda interacts with your code, Execution environment is where Lambda actually runs your function — it's a secure, isolated compute space created specifically for your function. Each environment follows a lifecycle of three phases. 1. Initialization: Lambda creates the environment and gets everything ready to run your function. This includes setting up your chosen runtime, loading your code, and running any startup code you've written. 2. Invocation: When events arrive, Lambda uses this environment to run your function. The environment can process many events over time, one after another. As more events come",
11
+ "The environment can process many events over time, one after another. As more events come in, Running code 9 AWS Lambda Developer Guide Lambda creates additional environments to handle the increased demand. When demand drops, Lambda stops environments that are no longer needed. 3. Shutdown: Eventually, Lambda will shut down environments. Before doing this, it gives your function a chance to clean up any remaining tasks. This environment handles important aspects of running your function. It provides your function with memory and a /tmp directory for temporary storage. It maintains resources like database connections between invocations, so your function can reuse them. It offers features like provisioned concurrency, where Lambda prepares environments in advance to improve performance. Understanding the Lambda programming model Lambda provides a programming model that is common to all of the runtimes. The programming model defines the interface between your code and the Lambda system. You tell Lambda the entry point to your function by defining a handler in the function configuration. The runtime passes in objects to the handler that contain the invocation event and the context, such as the function name and request ID. When the handler finishes processing the first event, the runtime sends it another. The function's class stays in memory, so clients and variables that are declared outside of the handler method in initialization code can be reused. To save processing time on subsequent events, create reusable resources like AWS SDK clients during initialization. Once initialized, each instance of your function can process thousands of requests. Your function also has access to local storage in the /tmp directory, a transient cache that can be used for multiple invocations. For more information, see Execution environment. When AWS X-Ray tracing is enabled, the runtime records separate subsegments for initialization and execution. The runtime captures",
12
+ "tracing is enabled, the runtime records separate subsegments for initialization and execution. The runtime captures logging output from your function and sends it to Amazon CloudWatch Logs. In addition to logging your function's output, the runtime also logs entries when function invocation starts and ends. This includes a report log with the request ID, billed duration, initialization duration, and other details. If your function throws an error, the runtime returns that error to the invoker. Running code 10 AWS Lambda Developer Guide Note Logging is subject to CloudWatch Logs quotas. Log data can be lost due to throttling or, in some cases, when an instance of your function is stopped. Lambda scales your function by running additional instances of it as demand increases, and by stopping instances as demand decreases. This model leads to variations in application architecture, such as: • Unless noted otherwise, incoming requests might be processed out of order or concurrently. • Do not rely on instances of your function being long lived, instead store your application's state elsewhere. • Use local storage and class-level objects to increase performance, but keep to a minimum the size of your deployment package and the amount of data that you transfer onto the execution environment. For a hands-on introduction to the programming model in your preferred programming language, see the following chapters. • Building Lambda functions with Node.js • Building Lambda functions with Python • Building Lambda functions with Ruby • Building Lambda functions with Java • Building Lambda functions with Go • Building Lambda functions with C# • Building Lambda functions with PowerShell Understanding the Lambda execution environment lifecycle Lambda invokes your function in an execution environment, which provides a secure and isolated runtime environment. The execution environment manages the resources required to run your function. The execution environment",
13
+ "environment. The execution environment manages the resources required to run your function. The execution environment also provides lifecycle support for the function's runtime and any external extensions associated with your function. Running code 11 AWS Lambda Developer Guide The function's runtime communicates with Lambda using the Runtime API. Extensions communicate with Lambda using the Extensions API. Extensions can also receive log messages and other telemetry from the function by using the Telemetry API. When you create your Lambda function, you specify configuration information, such as the amount of memory available and the maximum execution time allowed for your function. Lambda uses this information to set up the execution environment. The function's runtime and each external extension are processes that run within the execution environment. Permissions, resources, credentials, and environment variables are shared between the function and the extensions. Topics • Lambda execution environment lifecycle • Cold starts and latency • Reducing cold starts with Provisioned Concurrency • Optimizing static initialization Lambda execution environment lifecycle Running code 12 AWS Lambda Developer Guide Each phase starts with an event that Lambda sends to the runtime and to all registered extensions. The runtime and each extension indicate completion by sending a Next API request. Lambda freezes the execution environment when the runtime and each extension have completed and there are no pending events. Topics • Init phase • Failures during the Init phase • Restore phase (Lambda SnapStart only) • Invoke phase • Failures during the invoke phase • Shutdown phase Init phase In the Init phase, Lambda performs three tasks: • Start all extensions (Extension init) • Bootstrap the runtime (Runtime init) • Run the function's static code (Function init) • Run any before-checkpoint runtime hooks (Lambda SnapStart only) The Init phase ends when the runtime and all extensions signal that they",
14
+ "SnapStart only) The Init phase ends when the runtime and all extensions signal that they are ready by sending a Next API request. The Init phase is limited to 10 seconds. If all three tasks do not complete within 10 seconds, Lambda retries the Init phase at the time of the first function invocation with the configured function timeout. When Lambda SnapStart is activated, the Init phase happens when you publish a function version. Lambda saves a snapshot of the memory and disk state of the initialized execution environment, persists the encrypted snapshot, and caches it for low-latency access. If you have a before-checkpoint runtime hook, then the code runs at the end of Init phase. Note The 10-second timeout doesn't apply to functions that are using provisioned concurrency or SnapStart. For provisioned concurrency and SnapStart functions, your initialization code Running code 13 AWS Lambda Developer Guide can run for up to 15 minutes. The time limit is 130 seconds or the configured function timeout (maximum 900 seconds), whichever is higher. When you use provisioned concurrency, Lambda initializes the execution environment when you configure the PC settings for a function. Lambda also ensures that initialized execution environments are always available in advance of invocations. You may see gaps between your function's invocation and initialization phases. Depending on your function's runtime and memory configuration, you may also see variable latency on the first invocation on an initialized execution environment. For functions using on-demand concurrency, Lambda may occasionally initialize execution environments ahead of invocation requests. When this happens, you may also observe a time gap between your function's initialization and invocation phases. We recommend you to not take a dependency on this behavior. Failures during the Init phase If a function crashes or times out during the Init phase, Lambda emits error",
15
+ "phase If a function crashes or times out during the Init phase, Lambda emits error information in the INIT_REPORT log. Example — INIT_REPORT log for timeout INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout Example — INIT_REPORT log for extension failure INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash If the Init phase is successful, Lambda doesn't emit the INIT_REPORT log unless SnapStart or provisioned concurrency is enabled. SnapStart and provisioned concurrency functions always emit INIT_REPORT. For more information, see Monitoring for Lambda SnapStart. Restore phase (Lambda SnapStart only) When you first invoke a SnapStart function and as the function scales up, Lambda resumes new execution environments from the persisted snapshot instead of initializing the function from scratch. If you have an after-restore runtime hook, the code runs at the end of the Restore phase. You are charged for the duration of after-restore runtime hooks. The runtime must load and afterRunning code 14 AWS Lambda Developer Guide restore runtime hooks must complete within the timeout limit (10 seconds). Otherwise, you'll get a SnapStartTimeoutException. When the Restore phase completes, Lambda invokes the function handler (the Invoke phase). Failures during the Restore phase If the Restore phase fails, Lambda emits error information in the RESTORE_REPORT log. Example — RESTORE_REPORT log for timeout RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout Example — RESTORE_REPORT log for runtime hook failure RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError For more information about the RESTORE_REPORT log, see Monitoring for Lambda SnapStart. Invoke phase When a Lambda function is invoked in response to a Next API request, Lambda sends an Invoke event to the runtime and to each extension. The function's timeout setting limits the duration of the entire Invoke phase. For example, if you set the function timeout as",
16
+ "duration of the entire Invoke phase. For example, if you set the function timeout as 360 seconds, the function and all extensions need to complete within 360 seconds. Note that there is no independent post-invoke phase. The duration is the sum of all invocation time (runtime + extensions) and is not calculated until the function and all extensions have finished executing. The invoke phase ends after the runtime and all extensions signal that they are done by sending a Next API request. Failures during the invoke phase If the Lambda function crashes or times out during the Invoke phase, Lambda resets the execution environment. The following diagram illustrates Lambda execution environment behavior when there's an invoke failure: Running code 15 AWS Lambda Developer Guide In the previous diagram: • The first phase is the INIT phase, which runs without errors. • The second phase is the INVOKE phase, which runs without errors. • At some point, suppose your function runs into an invoke failure (common causes include function timeouts, runtime errors, memory exhaustion, VPC connectivity issues, permission errors, concurrency limits, and various configuration problems). For a complete list of possible invocation failures, see the section called “Invocation”. The third phase, labeled INVOKE WITH ERROR , illustrates this scenario. When this happens, the Lambda service performs a reset. The reset behaves like a Shutdown event. First, Lambda shuts down the runtime, then sends a Shutdown event to each registered external extension. The event includes the reason for the shutdown. If this environment is used for a new invocation, Lambda re-initializes the extension and runtime together with the next invocation. Note that the Lambda reset does not clear the /tmp directory content prior to the next init phase. This behavior is consistent with the regular shutdown phase. Note AWS is currently implementing",
17
+ "phase. This behavior is consistent with the regular shutdown phase. Note AWS is currently implementing changes to the Lambda service. Due to these changes, you may see minor differences between the structure and content of system log messages and trace segments emitted by different Lambda functions in your AWS account. If your function's system log configuration is set to plain text, this change affects the log messages captured in CloudWatch Logs when your function experiences an invoke failure. The following examples show log outputs in both old and new formats. These changes will be implemented during the coming weeks, and all functions in all AWS Regions except the China and GovCloud regions will transition to use the newformat log messages and trace segments. Example CloudWatch Logs log output (runtime or extension crash) - old style START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason Runtime.ExitError Running code 16 AWS Lambda Developer Guide END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB Example CloudWatch Logs log output (function timeout) - old style START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST 2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms The new format for CloudWatch logs includes an additional statusfield in the REPORT line. In the case of a runtime or extension crash, the REPORT line also includes a field ErrorType. Example CloudWatch Logs log output (runtime or extension crash) - new style START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration:",
18
+ "Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError Example CloudWatch Logs log output (function timeout) - new style START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout • The fourth phase represents the INVOKE phase immediately following an invoke failure. Here, Lambda initializes the environment again by re-running the INIT phase. This is called a suppressed init. When suppressed inits occur, Lambda doesn't explicitly report an additional INIT phase in CloudWatch Logs. Instead, you may notice that the duration in the REPORT line includes an additional INIT duration + the INVOKE duration. For example, suppose you see the following logs in CloudWatch: Running code 17 AWS Lambda Developer Guide 2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 2022-12-20T01:00:02.500-08:00 END RequestId: XXX 2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB In this example, the difference between the REPORT and START timestamps is 2.5 seconds. This doesn't match the reported duration of 3022.91 millseconds, because it doesn't take into account the extra INIT (suppressed init) that Lambda performed. In this example, you can infer that the actual INVOKE phase took 2.5 seconds. For more insight into this behavior, you can use the Accessing real-time telemetry data for extensions using the Telemetry API. The Telemetry API emits INIT_START, INIT_RUNTIME_DONE, and INIT_REPORT events with phase=invoke whenever suppressed inits occur in between invoke phases. • The fifth phase represents the SHUTDOWN phase, which runs without errors. Shutdown phase When Lambda is about to shut down the runtime, it sends a Shutdown event to each registered external extension.",
19
+ "to shut down the runtime, it sends a Shutdown event to each registered external extension. Extensions can use this time for final cleanup tasks. The Shutdown event is a response to a Next API request. Duration limit: The maximum duration of the Shutdown phase depends on the configuration of registered extensions: • 0 ms – A function with no registered extensions • 500 ms – A function with a registered internal extension • 2,000 ms – A function with one or more registered external extensions If the runtime or an extension does not respond to the Shutdown event within the limit, Lambda ends the process using a SIGKILL signal. After the function and all extensions have completed, Lambda maintains the execution environment for some time in anticipation of another function invocation. However, Lambda terminates execution environments every few hours to allow for runtime updates and maintenance —even for functions that are invoked continuously. You should not assume that the execution Running code 18 AWS Lambda Developer Guide environment will persist indefinitely. For more information, see Implement statelessness in functions. When the function is invoked again, Lambda thaws the environment for reuse. Reusing the execution environment has the following implications: • Objects declared outside of the function's handler method remain initialized, providing additional optimization when the function is invoked again. For example, if your Lambda function establishes a database connection, instead of reestablishing the connection, the original connection is used in subsequent invocations. We recommend adding logic in your code to check if a connection exists before creating a new one. • Each execution environment provides between 512 MB and 10,240 MB, in 1-MB increments, of disk space in the /tmp directory. The directory content remains when the execution environment is frozen, providing a transient cache that can be used for",
20
+ "when the execution environment is frozen, providing a transient cache that can be used for multiple invocations. You can add extra code to check if the cache has the data that you stored. For more information on deployment size limits, see Lambda quotas. • Background processes or callbacks that were initiated by your Lambda function and did not complete when the function ended resume if Lambda reuses the execution environment. Make sure that any background processes or callbacks in your code are complete before the code exits. Cold starts and latency When Lambda receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this initialization phase, the service downloads your code, starts the environment, and runs any initialization code outside of the main handler. Finally, Lambda runs the handler code. In this diagram, the first two steps of downloading the code and setting up the environment are frequently referred to as a “cold start”. You are not charged for this time, but it does add latency to your overall invocation duration. Running code 19 AWS Lambda Developer Guide After the invocation completes, the execution environment is frozen. To improve resource management and performance, Lambda retains the execution environment for a period of time. During this time, if another request arrives for the same function, Lambda can reuse the environment. This second request typically finishes more quickly, since the execution environment is already fully set up. This is called a “warm start”. Cold starts typically occur in under 1% of invocations. The duration of a cold start varies from under 100 ms to over 1 second. In general, cold starts are typically more common in development and test functions than production workloads. This is because development and test functions are usually invoked",
21
+ "test functions than production workloads. This is because development and test functions are usually invoked less frequently. Reducing cold starts with Provisioned Concurrency If you need predictable function start times for your workload, provisioned concurrency is the recommended solution to ensure the lowest possible latency. This feature pre-initializes execution environments, reducing cold starts. For example, a function with a provisioned concurrency of 6 has 6 execution environments prewarmed. Optimizing static initialization Static initialization happens before the handler code starts running in a function. This is the initialization code that you provide, that is outside of the main handler. This code is often used to import libraries and dependencies, set up configurations, and initialize connections to other services. Running code 20 AWS Lambda Developer Guide The following Python example shows importing, and configuring modules, and creating the Amazon S3 client during the initialization phase, before the lambda_handler function runs during invoke. import os import json import cv2 import logging import boto3 s3 = boto3.client('s3') logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): # Handler logic... The largest contributor of latency before function execution comes from initialization code. This code runs when a new execution environment is created for the first time. The initialization code is not run again if an invocation uses a warm execution environment. Factors that affect initialization code latency include: • The size of the function package, in terms of imported libraries and dependencies, and Lambda layers. • The amount of code and initialization work. • The performance of libraries and other services in setting up connections and other resources. There are a number of steps that developers can take to optimize static initialization latency. If a function has many objects and connections, you may be able to rearchitect a single function into multiple, specialized functions. These are individually",
22
+ "may be able to rearchitect a single function into multiple, specialized functions. These are individually smaller and each have less initialization code. It’s important that functions only import the libraries and dependencies that they need. For example, if you only use Amazon DynamoDB in the AWS SDK, you can require an individual service instead of the entire SDK. Compare the following three examples: // Instead of const AWS = require('aws-sdk'), use: const DynamoDB = require('aws-sdk/clients/dynamodb') Running code 21"
23
+ ]
dataset/chunks/wavelength_chunks.json ADDED
@@ -0,0 +1,19 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ [
2
+ "AWS Wavelength Developer Guide What is AWS Wavelength? AWS Wavelength enables developers to build applications that require edge computing infrastructure to deliver low latency to mobile devices and end users or increase the resiliency of their existing edge applications. Wavelength deploys standard AWS compute and storage services to the edge of communications service providers' (CSP) networks. You can extend a virtual private cloud (VPC) to one or more Wavelength Zones. You can then use AWS resources such as Amazon Elastic Compute Cloud (Amazon EC2) instances to run the applications that require low latency or edge resiliency within the Wavelength Zone, while seamlessly communicating back to your existing AWS services deployed in the parent AWS Region. For more information, see AWS Wavelength. Wavelength concepts The following are the key concepts: • Wavelength — A new type of AWS infrastructure designed to run workloads that require low latency or edge resiliency. • Wavelength Zone — A zone in the carrier location where the Wavelength infrastructure is deployed. Wavelength Zones are associated with an AWS Region. A Wavelength Zone is a logical extension of the Region, and is managed by the control plane in the Region. • VPC — A customer virtual private cloud (VPC) that spans Availability Zones, Local Zones, and Wavelength Zones, and has deployed resources such as Amazon EC2 instances in the subnets that are associated with the zones. • Wavelength subnet — A subnet that you create in a Wavelength Zone. You can create one or more subnets, and then run and manage AWS services, such as Amazon EC2 instances, in the subnet. • Carrier gateway — A carrier gateway serves two purposes. It allows inbound traffic from a carrier network in a specific location, and allows outbound traffic to the carrier network and internet. • Network Border Group",
3
+ "location, and allows outbound traffic to the carrier network and internet. • Network Border Group — A unique set of Availability Zones, Local Zones, or Wavelength Zones from which AWS advertises IP addresses. • Wavelength application — An application that you run on an AWS resource in a Wavelength Zone. Wavelength concepts 1 AWS Wavelength Developer Guide AWS resources on Wavelength You can create Amazon EC2 instances, Amazon EBS volumes, and Amazon VPC subnets and carrier gateways in Wavelength Zones. You can also use the following: • Amazon EC2 Auto Scaling • Amazon EKS clusters • Amazon ECS clusters • Amazon EC2 Systems Manager • Amazon CloudWatch • AWS CloudTrail • AWS CloudFormation • Application Load Balancer in select Wavelength Zones. For a list of these Zones, see Load balancing. The services in Wavelength are part of a VPC that is connected over a reliable connection to an AWS Region for easy access to services running in Regional subnets. Working with Wavelength You can create, access, and manage your EC2 resources, Wavelength Zones, and carrier gateways using any of the following interfaces: • AWS Management Console— Provides a web interface that you can use to access your Wavelength resources. • AWS Command Line Interface (AWS CLI) — Provides commands for a broad set of AWS services, including Amazon VPC, and is supported on Windows, macOS, and Linux. The services you use in Wavelength continue to use their own namespace, for example Amazon EC2 uses the \"ec2\" namespace, and Amazon EBS uses the \"ebs\" namespace. For more information, see AWS Command Line Interface. • AWS SDKs — Provides language-specific APIs and takes care of many of the connection details, such as calculating signatures, handling request retries, and handling errors. For more information, see AWS SDKs. When you use any of the",
4
+ "and handling errors. For more information, see AWS SDKs. When you use any of the interfaces for your Wavelength Zones, use the parent Region. AWS resources on Wavelength 2 AWS Wavelength Developer Guide Pricing For more information, see AWS Wavelength Pricing. Use cases for AWS Wavelength Using AWS Wavelength Zones can help you accomplish a variety of goals. This section lists a few to give you an idea of the possibilities. Contents • Online betting and regulated industries • Media and entertainment • Healthcare • Augmented reality (AR) and virtual reality (VR) • Connected vehicles • Smart factories • Real-time gaming Online betting and regulated industries AWS Wavelength provides edge resiliency to help address data residency requirements for regulated industries, such as online sports betting. Using a combination of AWS Wavelength alongside existing AWS hybrid and edge services such as AWS Outposts or AWS Local Zones, you can create highly-available architectures within state or country borders. Media and entertainment Wavelength provides the low latency needed to live stream high-resolution video and high-fidelity audio, and to embed interactive experiences into live video streams. Real-time video analytics provide the ability to generate real-time statistics that enhance the live event experience. Healthcare Using AWS Wavelength, medical training providers can offer mobile games, medical simulations for rare disease diagnosis, advanced endoscopic maneuvers, ultrasound equipment and much more. Pricing 3 AWS Wavelength Developer Guide Using AWS Wavelength to host the remote rendering engine, doctors can experience an immersive training experience without procuring the often-required expensive equipment to do so. Augmented reality (AR) and virtual reality (VR) By accessing compute resources on AWS Wavelength, AR/VR applications can reduce the Motion to Photon (MTP) latencies to the benchmark that is needed to offer a realistic customer experience. When you use AWS Wavelength, you can offer AR/VR in",
5
+ "offer a realistic customer experience. When you use AWS Wavelength, you can offer AR/VR in locations where it is not possible to run local system servers. Connected vehicles Cellular Vehicle-to-Everything (C-V2X) is an increasingly important platform for enabling functionality such as intelligent driving, real-time HD maps, and increased road safety. Low latency access to the compute infrastructure that's needed to run data processing and analytics on AWS Wavelength enables real-time monitoring of data from sensors on the vehicle. This allows for secure connectivity, in-car telematics, and autonomous driving. Smart factories Industrial automation applications use ML inference at the edge to analyze images and videos to detect quality issues on fast moving assembly lines and to trigger actions that address the issues. With AWS Wavelength, these applications can be deployed without having to use expensive, GPUbased servers on the factory floor. Real-time gaming Real-time game streaming depends on low latency to preserve the user experience. With AWS Wavelength, you can stream the most demanding games from Wavelength Zones so that they are available on end devices that have limited processing power. Augmented reality (AR) and virtual reality (VR) 4 AWS Wavelength Developer Guide How AWS Wavelength works The following diagram demonstrates how you can create a subnet that uses resources in a communications service provider (CSP) network at a specific location. For resources that must be deployed to the Wavelength Zone, first opt in to the Wavelength Zone, and then create resources in the Wavelength Zone. Contents • VPCs • Subnets • Carrier gateways • Carrier IP address • Routing • DNS • Maximum transmission unit VPCs After you create a VPC in a Region, create a subnet in a Wavelength Zone that is associated with the VPC. In addition to the Wavelength Zone, you can create resources in all of",
6
+ "the VPC. In addition to the Wavelength Zone, you can create resources in all of the Availability Zones and Local Zones that are associated with the VPC. VPCs 5 AWS Wavelength Developer Guide You have control over the VPC networking components, such as IP address assignment, subnets, and route table creation. VPCs that contain a subnet in a Wavelength Zone can connect to a carrier gateway. A carrier gateway allows you to connect to the following resources: • 4G/LTE and 5G devices on the telecommunication carrier network • Internet access including fixed wireless access for select Wavelength Zone partners. For more information, see Multi-access AWS Wavelength. • Outbound traffic to public internet resources Subnets Any subnet that you create in a Wavelength Zone inherits the main VPC route table, which includes the local route. The local route enables connectivity between the subnets in the VPC, including the subnets that are in the Wavelength Zone. AWS recommends that you configure custom route tables for your subnets in Wavelength Zones. The destinations are the same destinations as a subnet in an Availability Zone or Local Zone, with the addition of a carrier gateway. For more information, see the section called “Routing”. Carrier gateways A carrier gateway serves two purposes. It allows inbound traffic from a carrier network in a specific location, and it allows outbound traffic to the carrier network and internet. There is no inbound connection configuration from the internet to a Wavelength Zone through the carrier gateway. A carrier gateway supports IPv4 traffic. Carrier gateways are only available for VPCs that contain subnets in a Wavelength Zone. The carrier gateway provides connectivity between your Wavelength Zone and the telecommunication carrier, and devices on the telecommunication carrier network. The carrier gateway performs NAT of the Wavelength instances' IP addresses to the",
7
+ "carrier network. The carrier gateway performs NAT of the Wavelength instances' IP addresses to the Carrier IP addresses from a pool that is assigned to the network border group. The carrier gateway NAT function is similar to how an internet gateway functions in a Region. Subnets 6 AWS Wavelength Developer Guide Carrier IP address A Carrier IP address is the address that you assign to a network interface, which resides in a subnet in a Wavelength Zone (for example an EC2 instance). The carrier gateway uses the address for traffic from the interface to the internet or to mobile devices. The carrier gateway uses NAT to translate the address, and then sends the traffic to the destination. Traffic from the telecommunication carrier network routes through the carrier gateway. You allocate a Carrier IP address from a network border group, which is a unique set of Availability Zones, Local Zones, or Wavelength Zones from which AWS advertises IP addresses, for example, us-east-1-wl1-bos-wlz-1. Routing You can set the carrier gateway as a destination in a route table for the following resources: • VPCs that contain subnets in a Wavelength Zone • Subnets in Wavelength Zones Create a custom route table for the subnets in the Wavelength Zones so that the default route goes to the carrier gateway, which then sends traffic to the internet and telecommunication carrier network. Example: Carrier gateway routing to the public internet Consider a scenario with the following configuration: • A VPC with Availability Zones and a Wavelength Zone • A subnet in the Wavelength Zone • An EC2 instance in the subnet in the Wavelength Zone • A Carrier IP address for the network interface associated with the EC2 instance • An IP address association that maps the private IP address of the EC2 instance to the",
8
+ "IP address association that maps the private IP address of the EC2 instance to the Carrier IP address Carrier IP address 7 AWS Wavelength Developer Guide You need the following entries in the Wavelength subnet route table. Destination Target Notes VPC CIDR Local This route allows for intraVPC connectivity, including subnets in the Availability Zones. 0.0.0.0/0 carrier-gateway-id The Carrier IP address provides internet connectivity through the carrier gateway. Carrier gateway access to the public internet The carrier gateway provides access to the internet from your Wavelength subnets. For information about protocol considerations, see the section called “Networking considerations”. Traffic initiated from the EC2 instance for the internet uses the 0.0.0.0/0 route to route traffic to the carrier gateway. The carrier gateway maps the EC2 instance IP address to the Carrier IP address, and then sends the traffic to the telecommunication carrier. Example: Carrier gateway routing to the public internet 8 AWS Wavelength Developer Guide DNS EC2 instances use EC2 DNS to resolve domain names to IP addresses. Route 53 supports DNS features, such as domain registration, and DNS routing. Both public and private hosted Wavelength Zones are supported for routing traffic to specific domains. Route 53 resolvers are hosted in the Region. You can also use your own DNS services to resolve domain names. Maximum transmission unit Generally, the maximum transmission unit (MTU) is as follows: • 9001 bytes between EC2 instances in the same Wavelength Zone. • 1500 bytes between carrier gateway and a Wavelength Zone. • 1500 bytes between an EC2 instance in a Wavelength Zone and an EC2 instance in the Region when the traffic uses a public IP address. • 1300 bytes between an EC2 instance in a Wavelength Zone and an EC2 instance in the Region when the traffic uses a private IP address. DNS",
9
+ "an EC2 instance in the Region when the traffic uses a private IP address. DNS 9 AWS Wavelength Developer Guide Get started with AWS Wavelength The following diagram shows the resources that you need to configure to get started using AWS Wavelength. • A VPC in your Region • A carrier gateway • A public subnet in an Availability Zone in your Region • An instance in the public subnet • An instance in the Wavelength Zone subnet with a Carrier IP address Tasks • Step 1: Opt in to Wavelength Zones • Step 2: Configure your network • Step 3: Launch an instance in your Availability Zone public subnet 10 AWS Wavelength Developer Guide • Step 4: Launch an instance in the Wavelength zone • Step 5: Test the connectivity Step 1: Opt in to Wavelength Zones Before you specify a Wavelength Zone for a resource or service, you must opt in to the zone. Prerequisites • Some AWS resources are not available in all Regions. Make sure that you can create the resources that you need in the desired Region or Wavelength Zone before launching an instance in a specific Wavelength Zone. • Before you begin, review Quotas and considerations, which includes information about available Wavelength Zones, service differences, and Service Quotas. You should also speak with your mobile operator about mobile service plans and any additional requirements. To opt in to Wavelength Zone using the console 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. From the Region selector in the navigation bar, select the Region for the Wavelength Zone. 3. On the navigation pane, choose EC2 Dashboard. 4. In the upper-right corner of the page, choose Account attributes, Zones. 5. Under Wavelength Zones, choose Manage. 6. Choose Enabled. 7. Choose Update zone group. To enable Wavelength",
10
+ "Wavelength Zones, choose Manage. 6. Choose Enabled. 7. Choose Update zone group. To enable Wavelength Zones using the AWS CLI Alternatively, use the AWS CLI to enable Wavelength Zones. To do so, use the modify-availabilityzone-group command. Step 2: Configure your network After you opt in to the Wavelength Zone, create a VPC, a carrier gateway, and a public subnet in the Availability Zone. Step 1: Opt in to Wavelength Zones 11 AWS Wavelength Developer Guide Tasks • Create a VPC • Create a carrier gateway and a subnet associated with the Wavelength Zone • Create a public subnet in an Availability Zone Create a VPC Create a VPC to extend to your Wavelength Zone. To create a VPC using the console 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. Choose Create VPC. 3. For Resources to create, choose VPC only. 4. For Name tag, optionally provide a name for your VPC. Doing so creates the tag Name=value. 5. For IPv4 CIDR block, specify an IPv4 CIDR block for the VPC. We recommend that you specify a CIDR block from the private (non-publicly routable) IP address ranges as specified in RFC 1918; for example, 10.0.0.0/16, or 192.168.0.0/16. Note You can specify a range of publicly routable IPv4 addresses. However, we currently do not support direct access to the internet from publicly routable CIDR blocks in a VPC. Windows instances cannot boot correctly if launched into a VPC with ranges from 224.0.0.0 to 255.255.255.255 (Class D and Class E IP address ranges). 6. Choose Create VPC. Create a carrier gateway and a subnet associated with the Wavelength Zone After you create a VPC, create a carrier gateway, and then select the subnets that route traffic to the carrier gateway. When you choose to automatically route traffic from subnets to the carrier",
11
+ "the carrier gateway. When you choose to automatically route traffic from subnets to the carrier gateway, we create the following resources: Create a VPC 12 AWS Wavelength Developer Guide • A carrier gateway • A subnet. You can optionally assign all carrier gateway tags except the Name tag to the subnet. • A network ACL with the following resources: • A subnet association with the subnet in the Wavelength Zone • Default inbound and outbound rules for your traffic. • A route table with the following resources: • A route for local traffic • A route that routes non-local traffic to the carrier gateway • An association with the subnet To create a carrier gateway 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. In the navigation pane, choose Carrier gateways, and then choose Create carrier gateway. 3. (Optional) For Name, enter a name for the carrier gateway. 4. For VPC, choose the VPC. 5. Choose Route subnet traffic to carrier gateway, and under Subnets to route do the following: a. Under Existing subnets in Wavelength Zone, select the box for each Wavelength subnet to route to the carrier gateway. b. To create a subnet in the Wavelength Zone, choose Add new subnet, enter the required information, and then choose Add new subnet. 6. (Optional) To add a tag to the carrier gateway, choose Add tag, and then enter the tag key and tag value. 7. Choose Create carrier gateway. Create a public subnet in an Availability Zone Create a subnet in an Availability Zone in the Region. To add a subnet 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. In the navigation pane, choose Subnets. Create a public subnet in an Availability Zone 13 AWS Wavelength Developer Guide 3. Choose Create subnet. 4. For VPC, choose the VPC.",
12
+ "13 AWS Wavelength Developer Guide 3. Choose Create subnet. 4. For VPC, choose the VPC. 5. For Subnet name, provide a name for the subnet. Doing so creates the tag Name=value. 6. For Availability Zone, chose an Availability Zone, or choose No Preference to have AWS choose one for you. 7. For IPv4 CIDR block, specify an IPv4 address range for your subnet, using CIDR notation. 8. Choose Create subnet. Step 3: Launch an instance in your Availability Zone public subnet Launch an EC2 instance in the subnet that you created in the Availability Zone. You will use this instance to test the connectivity from the Region to the Wavelength Zone. You can launch EC2 instances in the public subnet that you created. For information about how to launch an instance using the Amazon EC2 console, see Launch an EC2 instance using the console in the Amazon EC2 User Guide. Step 4: Launch an instance in the Wavelength zone After you complete the networking configuration, launch an instance, and then allocate a Carrier IP address for the instance. Options • Option 1: Auto assign a Carrier IP address • Option 2: Allocate and associate a Carrier IP address from the network border group Option 1: Auto assign a Carrier IP address AWS recommends that you use the AWS CLI because you can automatically allocate and associate the Carrier IP address with the network interface. Use the run-instances command as follows to launch an instance in the Wavelength Zone subnet. Step 3: Launch an instance in your Availability Zone public subnet 14 AWS Wavelength Developer Guide aws ec2 run-instances --region us-east-1 --network-interfaces \"DeviceIndex=0,AssociateCarrierIpAddress=true,SubnetId=subnet-036aa298f4EXAMPLE\" -image-id ami-04125ecea1EXAMPLE --instance-type t3.medium • DeviceIndex – Specify 0 to indicate the primary network interface (eth0). • SubnetId – Specify the ID of the subnet in the Wavelength",
13
+ "network interface (eth0). • SubnetId – Specify the ID of the subnet in the Wavelength Zone. • AssociateCarrierIpAddress – Set this value to true to assign a Carrier IP address to the network interface. Option 2: Allocate and associate a Carrier IP address from the network border group You can launch EC2 instances in the subnet that you created when you added the carrier gateway. For more information, see the section called “Create a carrier gateway and a subnet associated with the Wavelength Zone”. Security groups control inbound and outbound traffic for instances in a subnet, just as they do for instances in an Availability Zone subnet. To connect to an EC2 instance in a subnet, specify a key pair when you launch the instance, just as you do for instances in an Availability Zone subnet. For information about how to launch an instance using the Amazon EC2 console, see Launch an EC2 instance using the console in the Amazon EC2 User Guide. To allocate and associate a Carrier IP address 1. Use the allocate-address command as follows to allocate a Carrier IP address. aws ec2 allocate-address --region us-east-1 --domain vpc --network-border-group useast-1-wl1-bos-wlz-1 The following is example output. { \"AllocationId\": \"eipalloc-05807b62acEXAMPLE\", \"PublicIpv4Pool\": \"amazon\", \"NetworkBorderGroup\": \"us-east-1-wl1-bos-wlz-1\", \"Domain\": \"vpc\", \"CarrierIp\": \"155.146.10.111\" } Option 2: Allocate and associate a Carrier IP address from the network border group 15 AWS Wavelength 2. Developer Guide Use the associate-address command as follows to associate the Carrier IP address with the EC2 instance. aws ec2 associate-address --allocation-id eipalloc-05807b62acEXAMPLE --networkinterface-id eni-1a2b3c4d The following is example output. { \"AssociationId\": \"eipassoc-02463d08ceEXAMPLE\", } Step 5: Test the connectivity Before you test the connectivity, do the following: • Review the section called “Networking considerations” • Configure the instance security group to allow ICMP traffic. Test the connectivity from the instance in the",
14
+ "instance security group to allow ICMP traffic. Test the connectivity from the instance in the Region to the Wavelength Zone instance. Depending on your operating system, use SSH or RDP to connect to the Carrier IP address of your Wavelength Zone instance. You can use a secure bastion host. Run the ping command to the Wavelength Zone instance. In the following example, the IP address of the subnet in the Wavelength Zone is 10.0.3.112. ping 10.0.3.112 Pinging 10.0.3.112 Reply from 10.0.3.112: Reply from 10.0.3.112: Reply from 10.0.3.112: bytes=32 time=<1ms TTL=128 bytes=32 time=<1ms TTL=128 bytes=32 time=<1ms TTL=128 Ping statistics for 10.0.3.112 Packets: Sent = 3, Received = 3, Lost = 0 (0% lost) Approximate round trip time in milliseconds Minimum = 0ms, Maximum = 0ms, Average = 0ms Step 5: Test the connectivity 16 AWS Wavelength Developer Guide Test the connectivity from the instance in the Wavelength Zone instance to the carrier network. Depending on your operating system, use SSH or RDP to connect to the Carrier IP address of your Wavelength Zone instance. You can use a secure bastion host. You need a device on the carrier network in order to test the connectivity from the Wavelength Zone to the carrier network. Run the ping command to an address in the carrier network. In the following example, the carrier network IP address is 198.51.100.130. ping 198.51.100.130 Pinging 198.51.100.130 Reply from 198.51.100.130: Reply from 198.51.100.130: Reply from 198.51.100.130: bytes=32 time=<1ms TTL=128 bytes=32 time=<1ms TTL=128 bytes=32 time=<1ms TTL=128 Ping statistics for 198.51.100.130 Packets: Sent = 3, Received = 3, Lost = 0 (0% lost) Approximate round trip time in milliseconds Minimum = 0ms, Maximum = 0ms, Average = 0ms Step 5: Test the connectivity 17 AWS Wavelength Developer Guide Carrier gateway for AWS Wavelength A carrier gateway serves two purposes. It allows",
15
+ "Developer Guide Carrier gateway for AWS Wavelength A carrier gateway serves two purposes. It allows inbound traffic from a carrier network in a specific location, and it allows outbound traffic to the carrier network and the internet. There is generally no inbound connection configuration from the internet to a Wavelength Zone through the carrier gateway with the exception of select partners. For more information, see Multi-access AWS Wavelength. A carrier gateway supports IPv4 traffic. Carrier gateways are only available for VPCs that contain subnets in a Wavelength Zone. The carrier gateway provides connectivity between your Wavelength Zone and the carrier, and devices on the carrier network. The carrier gateway performs NAT of the Wavelength instances' IP addresses to the Carrier IP addresses from a pool that is assigned to the network border group. The carrier gateway NAT function is similar to how an internet gateway functions in a Region. Enable access to the carrier network To enable access to or from the carrier network for instances in a Wavelength subnet, you must do the following: • Create a VPC. • Create a carrier gateway and attach the carrier gateway to your VPC. When you create the carrier gateway, you can optionally choose which subnets route to the carrier gateway. When you select this option, we automatically create the resources related to carrier gateways, such as route tables and network ACLs. If you do not choose this option, then you must perform the following tasks: • Select the subnets that route traffic to the carrier gateway. • Ensure that your subnet route tables have a route that directs traffic to the carrier gateway. • Ensure that instances in your subnet have a globally unique Carrier IP address. • Ensure that your network access control lists and security group rules allow the",
16
+ "address. • Ensure that your network access control lists and security group rules allow the relevant traffic to flow to and from your instance. Enable access to the carrier network 18 AWS Wavelength Developer Guide Work with carrier gateways The following sections describe how to manually create a carrier gateway for your VPC to support inbound traffic from the carrier network (for example, mobile phones), and to support outbound traffic to the carrier network and the internet. Tasks • Create a VPC • Create a carrier gateway • Create a security group to access the carrier network • Allocate and associate a Carrier IP address with the instance in the Wavelength Zone subnet • Routing to a Wavelength Zone carrier gateway • View the carrier gateway details • Manage carrier gateway tags • Delete a carrier gateway Create a VPC You can create an empty Wavelength VPC as follows. Limitation You can specify a range of publicly routable IPv4 addresses. However, we do not support direct access to the internet from publicly routable CIDR blocks in a VPC. Windows instances cannot boot correctly if launched into a VPC with ranges from 224.0.0.0 to 255.255.255.255 (Class D and Class E IP address ranges). 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. In the navigation pane, choose Your VPCs, Create VPC. 3. Do the following and then choose Create. • Name tag: Optionally provide a name for your VPC. Doing so creates a tag with a key of Name and the value that you specify. • IPv4 CIDR block: Specify an IPv4 CIDR block for the VPC. We recommend that you specify a CIDR block from the private (non-publicly routable) IP address ranges as specified in RFC 1918; for example, 10.0.0.0/16, or 192.168.0.0/16. Work with carrier gateways 19 AWS Wavelength Developer",
17
+ "RFC 1918; for example, 10.0.0.0/16, or 192.168.0.0/16. Work with carrier gateways 19 AWS Wavelength Developer Guide To create a VPC using the AWS CLI Use the create-vpc command. Create a carrier gateway After you create a VPC, create a carrier gateway and then select the subnets that route traffic to the carrier gateway. If you have not opted in to a Wavelength Zone, the Amazon Virtual Private Cloud Console prompts you to opt in. For more information, see the section called “Manage Zones”. When you choose to automatically route traffic from subnets to the carrier gateway, we create the following resources: • A carrier gateway • A subnet. You can optionally assign all carrier gateway tags that do not have a Key value of Name to the subnet. • A network ACL with the following resources: • A subnet associated with the subnet in the Wavelength Zone • Default inbound and outbound rules for all of your traffic. • A route table with the following resources: • A route for all local traffic • A route that routes all non-local traffic to the carrier gateway • An association with the subnet To create a carrier gateway 1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. 2. In the navigation pane, choose Carrier Gateways, and then choose Create carrier gateway. 3. Optional: For Name, enter a name for the carrier gateway. 4. For VPC, choose the VPC. 5. Choose Route subnet traffic to carrier gateway, and under Subnets to route do the following. a. Under Existing subnets in Wavelength Zone, select the box for each subnet to route to the carrier gateway. Create a carrier gateway 20 AWS Wavelength b. Developer Guide To create a subnet in the Wavelength Zone, choose Add new subnet, specify the following information, and then choose Add",
18
+ "the Wavelength Zone, choose Add new subnet, specify the following information, and then choose Add new subnet: • Name tag: Optionally provide a name for your subnet. Doing so creates a tag with a key of Name and the value that you specify. • VPC: Choose the VPC. • Availability Zone: Choose the Wavelength Zone. • IPv4 CIDR block: Specify an IPv4 CIDR block for your subnet, for example, 10.0.1.0/24. • To apply the carrier gateway tags to the subnet, select Apply same tags from this carrier gateway. 6. 7. (Optional) To add a tag to the carrier gateway, choose Add tag, and then do the following: • For Key, enter the key name. • For Value, enter the key value. Choose Create carrier gateway. To create a carrier gateway using the AWS CLI 1. Use the create-carrier-gateway command. 2. Add a VPC route table with the following resources: • A route for all VPC local traffic • A route that routes all non-local traffic to the carrier gateway • An association with the subnets in the Wavelength Zone For more information, see the section called “Routing to a Wavelength Zone carrier gateway”. Create a security group to access the carrier network By default, a VPC security group allows all outbound traffic. You can create a new security group and add rules that allow inbound traffic from the carrier. Then, you associate the security group with instances in the subnet. Create a security group to access the carrier network 21"
19
+ ]
dataset/docs/batch.txt ADDED
@@ -0,0 +1,855 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ AWS Batch
2
+
3
+ User Guide
4
+
5
+ What is AWS Batch?
6
+ AWS Batch helps you to run batch computing workloads on the AWS Cloud. Batch computing
7
+ is a common way for developers, scientists, and engineers to access large amounts of compute
8
+ resources. AWS Batch removes the undifferentiated heavy lifting of configuring and managing the
9
+ required infrastructure, similar to traditional batch computing software. This service can efficiently
10
+ provision resources in response to jobs submitted in order to eliminate capacity constraints, reduce
11
+ compute costs, and deliver results quickly.
12
+ As a fully managed service, AWS Batch helps you to run batch computing workloads of any scale.
13
+ AWS Batch automatically provisions compute resources and optimizes the workload distribution
14
+ based on the quantity and scale of the workloads. With AWS Batch, there's no need to install or
15
+ manage batch computing software, so you can focus your time on analyzing results and solving
16
+ problems.
17
+
18
+ 1
19
+
20
+ AWS Batch
21
+
22
+ User Guide
23
+
24
+ AWS Batch provides all of the necessary functionality to run high-scale, compute-intensive
25
+ workloads on top of AWS managed container orchestration services, Amazon ECS and Amazon EKS.
26
+ AWS Batch is able to scale compute capacity on Amazon EC2 instances and Fargate resources.
27
+ AWS Batch provides a fully managed service for batch workloads, and delivers the operational
28
+ capabilities to optimize these types of workloads for throughput, speed, resource efficiency, and
29
+ cost.
30
+ AWS Batch also enables SageMaker Training job queuing, allowing data scientists and ML engineers
31
+ to submit Training jobs with priorities to configurable queues. This capability ensures that ML
32
+ workloads run automatically as soon as resources become available, eliminating the need for
33
+ manual coordination and improving resource utilization.
34
+ For machine learning workloads, AWS Batch provides queuing capabilities for SageMaker Training
35
+ jobs. You can configure queues with specific policies to optimize cost, performance, and resource
36
+ allocation for your ML Training workloads.
37
+
38
+ This provides a shared responsibility model where administrators set up the infrastructure and
39
+ permissions, while data scientists can focus on submitting and monitoring their ML training
40
+ workloads. Jobs are automatically queued and executed based on configured priorities and
41
+ resource availability.
42
+
43
+ 2
44
+
45
+ AWS Batch
46
+
47
+ User Guide
48
+
49
+ Are you a first-time AWS Batch user?
50
+ If you are a first-time user of AWS Batch, we recommend that you begin by reading the following
51
+ sections:
52
+ • Components of AWS Batch
53
+ • Create IAM account and administrative user
54
+ • Setting up AWS Batch
55
+ • Getting started with AWS Batch tutorials
56
+ • Getting started with AWS Batch on SageMaker AI
57
+
58
+ Related services
59
+ AWS Batch is a fully managed batch computing service that plans, schedules, and runs your
60
+ containerized batch ML, simulation, and analytics workloads across the full range of AWS compute
61
+ offerings, such as Amazon ECS, Amazon EKS, AWS Fargate, and Spot or On-Demand Instances. For
62
+ more information about each managed compute service, see:
63
+ • Amazon EC2 User Guide
64
+ • AWS Fargate Developer Guide
65
+ • Amazon EKS User Guide
66
+ • Amazon SageMaker AI Developer Guide
67
+
68
+ Accessing AWS Batch
69
+ You can access AWS Batch using the following:
70
+ AWS Batch console
71
+ The web interface where you create and manage resources.
72
+ AWS Command Line Interface
73
+ Interact with AWS services using commands in your command line shell. The AWS Command
74
+ Line Interface is supported on Windows, macOS, and Linux. For more information about the
75
+ AWS CLI, see AWS Command Line Interface User Guide. You can find the AWS Batch commands
76
+ in the AWS CLI Command Reference.
77
+ Are you a first-time AWS Batch user?
78
+
79
+ 3
80
+
81
+ AWS Batch
82
+
83
+ User Guide
84
+
85
+ AWS SDKs
86
+ If you prefer to build applications using language-specific APIs instead of submitting a request
87
+ over HTTP or HTTPS, use the libraries, sample code, tutorials, and other resources provided by
88
+ AWS. These libraries provide basic functions that automate tasks, such as cryptographically
89
+ signing your requests, retrying requests, and handling error responses. These functions make it
90
+ more efficient for you to get started. For more information, see Tools to Build on AWS.
91
+
92
+ Components of AWS Batch
93
+ AWS Batch simplifies running batch jobs across multiple Availability Zones within a Region. You
94
+ can create AWS Batch compute environments within a new or existing VPC. After a compute
95
+ environment is up and associated with a job queue, you can define job definitions that specify
96
+ which Docker container images to run your jobs. Container images are stored in and pulled from
97
+ container registries, which may exist within or outside of your AWS infrastructure.
98
+
99
+ Compute environment
100
+ A compute environment is a set of managed or unmanaged compute resources that are used to
101
+ run jobs. With managed compute environments, you can specify desired compute type (Fargate
102
+ or EC2) at several levels of detail. You can set up compute environments that use a particular type
103
+ of EC2 instance, a particular model such as c5.2xlarge or m5.10xlarge. Or, you can choose
104
+ only to specify that you want to use the newest instance types. You can also specify the minimum,
105
+ desired, and maximum number of vCPUs for the environment, along with the amount that you're
106
+ Components of AWS Batch
107
+
108
+ 4
109
+
110
+ AWS Batch
111
+
112
+ User Guide
113
+
114
+ willing to pay for a Spot Instance as a percentage of the On-Demand Instance price and a target
115
+ set of VPC subnets. AWS Batch efficiently launches, manages, and terminates compute types as
116
+ needed. You can also manage your own compute environments. As such, you're responsible for
117
+ setting up and scaling the instances in an Amazon ECS cluster that AWS Batch creates for you. For
118
+ more information, see Compute environments for AWS Batch.
119
+
120
+ Job queues
121
+ When you submit an AWS Batch job, you submit it to a particular job queue, where the
122
+ job resides until it's scheduled onto a compute environment. You associate one or more
123
+ compute environments with a job queue. You can also assign priority values for these compute
124
+ environments and even across job queues themselves. For example, you can have a high priority
125
+ queue that you submit time-sensitive jobs to, and a low priority queue for jobs that can run
126
+ anytime when compute resources are cheaper. For more information, see Job queues.
127
+
128
+ Job definitions
129
+ A job definition specifies how jobs are to be run. You can think of a job definition as a blueprint for
130
+ the resources in your job. You can supply your job with an IAM role to provide access to other AWS
131
+ resources. You also specify both memory and CPU requirements. The job definition can also control
132
+ container properties, environment variables, and mount points for persistent storage. Many of
133
+ the specifications in a job definition can be overridden by specifying new values when submitting
134
+ individual Jobs. For more information, see Job definitions
135
+
136
+ Jobs
137
+ A unit of work (such as a shell script, a Linux executable, or a Docker container image) that you
138
+ submit to AWS Batch. It has a name, and runs as a containerized application on AWS Fargate or
139
+ Amazon EC2 resources in your compute environment, using parameters that you specify in a job
140
+ definition. Jobs can reference other jobs by name or by ID, and can be dependent on the successful
141
+ completion of other jobs or the availability of resources you specify. For more information, see
142
+ Jobs.
143
+
144
+ Scheduling policy
145
+ You can use scheduling policies to configure how compute resources in a job queue are allocated
146
+ between users or workloads. Using fair-share scheduling policies, you can assign different share
147
+ identifiers to workloads or users. The AWS Batch job scheduler defaults to a first-in, first-out (FIFO)
148
+ strategy. For more information, see Fair-share scheduling policies.
149
+ Job queues
150
+
151
+ 5
152
+
153
+ AWS Batch
154
+
155
+ User Guide
156
+
157
+ Consumable resources
158
+ A consumable resource is a resource that is needed to run your jobs, such as a 3rd party license
159
+ token, database access bandwidth, the need to throttle calls to a third-party API, and so on.
160
+ You specify the consumable resources which are needed for a job to run, and Batch takes these
161
+ resource dependencies into account when it schedules a job. You can reduce the under-utilization
162
+ of compute resources by allocating only the jobs that have all the required resources available. For
163
+ more information, see Resource-aware scheduling .
164
+
165
+ Service Environment
166
+ A Service Environment define how AWS Batch integrates with SageMaker for job execution. Service
167
+ Environments enable AWS Batch to submit and manage jobs on SageMaker while providing the
168
+ queuing, scheduling, and priority management capabilities of AWS Batch. Service Environments
169
+ define capacity limits for specific service types such as SageMaker Training jobs. The capacity limits
170
+ control the maximum resources that can be used by service jobs in the environment. For more
171
+ information, see Service environments for AWS Batch.
172
+
173
+ Service job
174
+ A service job is a unit of work that you submit to AWS Batch to run on a service environment.
175
+ Service jobs leverage AWS Batch's queuing and scheduling capabilities while delegating actual
176
+ execution to the external service. For example, SageMaker Training jobs submitted as service
177
+ jobs are queued and prioritized by AWS Batch, but the SageMaker Training job execution occurs
178
+ within SageMaker AI infrastructure. This integration enables data scientists and ML engineers
179
+ to benefit from AWS Batch's automated workload management, and priority queuing, for their
180
+ SageMaker AI Training workloads. Service jobs can reference other jobs by name or ID and support
181
+ job dependencies. For more information, see Service jobs in AWS Batch.
182
+
183
+ Consumable resources
184
+
185
+ 6
186
+
187
+ AWS Batch
188
+
189
+ User Guide
190
+
191
+ Setting up AWS Batch
192
+ If you've already signed up for Amazon Web Services (AWS) and are using Amazon Elastic Compute
193
+ Cloud (Amazon EC2) or Amazon Elastic Container Service (Amazon ECS), you can soon use AWS
194
+ Batch. The setup process for these services is similar. This is because AWS Batch uses Amazon ECS
195
+ container instances in its compute environments. To use the AWS CLI with AWS Batch, you must
196
+ use a version of the AWS CLI that supports the latest AWS Batch features. If you don't see support
197
+ for an AWS Batch feature in the AWS CLI, upgrade to the latest version. For more information, see
198
+ http://aws.amazon.com/cli/.
199
+ Note
200
+ Because AWS Batch uses components of Amazon EC2, you use the Amazon EC2 console for
201
+ many of these steps.
202
+
203
+ Complete the following tasks to get set up for AWS Batch.
204
+ Topics
205
+ • Create IAM account and administrative user
206
+ • Create IAM roles for your compute environments and container instances
207
+ • Create a key pair for your instances
208
+ • Create a VPC
209
+ • Create a security group
210
+ • Install the AWS CLI
211
+
212
+ Create IAM account and administrative user
213
+ To get started, you need to create an AWS account and a single user that is typically granted
214
+ administrative rights. To accomplish this, complete the following tutorials:
215
+
216
+ Sign up for an AWS account
217
+ If you do not have an AWS account, complete the following steps to create one.
218
+ Create IAM account and administrative user
219
+
220
+ 7
221
+
222
+ AWS Batch
223
+
224
+ User Guide
225
+
226
+ To sign up for an AWS account
227
+ 1.
228
+
229
+ Open https://portal.aws.amazon.com/billing/signup.
230
+
231
+ 2.
232
+
233
+ Follow the online instructions.
234
+ Part of the sign-up procedure involves receiving a phone call or text message and entering a
235
+ verification code on the phone keypad.
236
+ When you sign up for an AWS account, an AWS account root user is created. The root user
237
+ has access to all AWS services and resources in the account. As a security best practice, assign
238
+ administrative access to a user, and use only the root user to perform tasks that require root
239
+ user access.
240
+
241
+ AWS sends you a confirmation email after the sign-up process is complete. At any time, you can
242
+ view your current account activity and manage your account by going to https://aws.amazon.com/
243
+ and choosing My Account.
244
+
245
+ Create a user with administrative access
246
+ After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity
247
+ Center, and create an administrative user so that you don't use the root user for everyday tasks.
248
+ Secure your AWS account root user
249
+ 1.
250
+
251
+ Sign in to the AWS Management Console as the account owner by choosing Root user and
252
+ entering your AWS account email address. On the next page, enter your password.
253
+ For help signing in by using root user, see Signing in as the root user in the AWS Sign-In User
254
+ Guide.
255
+
256
+ 2.
257
+
258
+ Turn on multi-factor authentication (MFA) for your root user.
259
+ For instructions, see Enable a virtual MFA device for your AWS account root user (console) in
260
+ the IAM User Guide.
261
+
262
+ Create a user with administrative access
263
+ 1.
264
+
265
+ Enable IAM Identity Center.
266
+
267
+ Create a user with administrative access
268
+
269
+ 8
270
+
271
+ AWS Batch
272
+
273
+ User Guide
274
+
275
+ For instructions, see Enabling AWS IAM Identity Center in the AWS IAM Identity Center User
276
+ Guide.
277
+ 2.
278
+
279
+ In IAM Identity Center, grant administrative access to a user.
280
+ For a tutorial about using the IAM Identity Center directory as your identity source, see
281
+ Configure user access with the default IAM Identity Center directory in the AWS IAM Identity
282
+ Center User Guide.
283
+
284
+ Sign in as the user with administrative access
285
+
286
+
287
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email
288
+ address when you created the IAM Identity Center user.
289
+ For help signing in using an IAM Identity Center user, see Signing in to the AWS access portal in
290
+ the AWS Sign-In User Guide.
291
+
292
+ Assign access to additional users
293
+ 1.
294
+
295
+ In IAM Identity Center, create a permission set that follows the best practice of applying leastprivilege permissions.
296
+ For instructions, see Create a permission set in the AWS IAM Identity Center User Guide.
297
+
298
+ 2.
299
+
300
+ Assign users to a group, and then assign single sign-on access to the group.
301
+ For instructions, see Add groups in the AWS IAM Identity Center User Guide.
302
+
303
+ Create IAM roles for your compute environments and container
304
+ instances
305
+ Your AWS Batch compute environments and container instances require AWS account credentials
306
+ to make calls to other AWS APIs on your behalf. Create an AWS Identity and Access Management
307
+ role that provides these credentials to your compute environments and container instances, then
308
+ associate that role with your compute environments.
309
+
310
+ Create IAM roles
311
+
312
+ 9
313
+
314
+ AWS Batch
315
+
316
+ User Guide
317
+
318
+ Note
319
+ To verify that your AWS account has the required permissions, see Initial IAM service set up
320
+ for your account.
321
+ The AWS Batch compute environment and container instance roles are automatically
322
+ created for you in the console first-run experience. So, if you intend to use the AWS
323
+ Batch console, you can move ahead to the next section. If you plan to use the AWS CLI
324
+ instead, complete the procedures in Using service-linked roles for AWS Batch, Amazon ECS
325
+ instance role, and Tutorial: Create the IAM execution role before creating your first compute
326
+ environment.
327
+
328
+ Create a key pair for your instances
329
+ AWS uses public-key cryptography to secure the login information for your instance. A Linux
330
+ instance, such as an AWS Batch compute environment container instance, has no password to use
331
+ for SSH access. You use a key pair to log in to your instance securely. You specify the name of the
332
+ key pair when you create your compute environment, then provide the private key when you log in
333
+ using SSH.
334
+ If you didn't create a key pair already, you can create one using the Amazon EC2 console. Note that,
335
+ if you plan to launch instances in multiple AWS Regions, create a key pair in each Region. For more
336
+ information about Regions, see Regions and Availability Zones in the Amazon EC2 User Guide.
337
+ To create a key pair
338
+ 1.
339
+
340
+ Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
341
+
342
+ 2.
343
+
344
+ From the navigation bar, select an AWS Region for the key pair. You can select any Region
345
+ that's available to you, regardless of your location: however, key pairs are specific to a Region.
346
+ For example, if you plan to launch an instance in the US West (Oregon) Region, create a key
347
+ pair for the instance in the same Region.
348
+
349
+ 3.
350
+
351
+ In the navigation pane, choose Key Pairs, Create Key Pair.
352
+
353
+ 4.
354
+
355
+ In the Create Key Pair dialog box, for Key pair name, enter a name for the new key pair , and
356
+ choose Create. Choose a name that you can remember, such as your user name, followed by key-pair, plus the Region name. For example, me-key-pair-uswest2.
357
+
358
+ Create a key pair
359
+
360
+ 10
361
+
362
+ AWS Batch
363
+
364
+ 5.
365
+
366
+ User Guide
367
+
368
+ The private key file is automatically downloaded by your browser. The base file name is the
369
+ name that you specified as the name of your key pair, and the file name extension is .pem.
370
+ Save the private key file in a safe place.
371
+ Important
372
+ This is the only chance for you to save the private key file. You need to provide the
373
+ name of your key pair when you launch an instance and the corresponding private key
374
+ each time that you connect to the instance.
375
+
376
+ 6.
377
+
378
+ If you use an SSH client on a Mac or Linux computer to connect to your Linux instance, use the
379
+ following command to set the permissions of your private key file. That way, only you can read
380
+ it.
381
+ $ chmod 400 your_user_name-key-pair-region_name.pem
382
+
383
+ For more information, see Amazon EC2 Key Pairs in the Amazon EC2 User Guide.
384
+ To connect to your instance using your key pair
385
+ To connect to your Linux instance from a computer running Mac or Linux, specify the .pem file
386
+ to your SSH client with the -i option and the path to your private key. To connect to your Linux
387
+ instance from a computer running Windows, use either MindTerm or PuTTY. If you plan to use
388
+ PuTTY, install it and use the following procedure to convert the .pem file to a .ppk file.
389
+ (Optional) To prepare to connect to a Linux instance from Windows using PuTTY
390
+ 1.
391
+
392
+ Download and install PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/. Be
393
+ sure to install the entire suite.
394
+
395
+ 2.
396
+
397
+ Start PuTTYgen (for example, from the Start menu, choose All Programs, PuTTY, and
398
+ PuTTYgen).
399
+
400
+ 3.
401
+
402
+ Under Type of key to generate, choose RSA. If you're using an earlier version of PuTTYgen,
403
+ choose SSH-2 RSA.
404
+
405
+ Create a key pair
406
+
407
+ 11
408
+
409
+ AWS Batch
410
+
411
+ 4.
412
+
413
+ User Guide
414
+
415
+ Choose Load. By default, PuTTYgen displays only files with the extension .ppk. To locate your
416
+ .pem file, choose the option to display files of all types.
417
+
418
+ 5.
419
+
420
+ Select the private key file that you created in the previous procedure and choose Open.
421
+ Choose OK to dismiss the confirmation dialog box.
422
+
423
+ 6.
424
+
425
+ Choose Save private key. PuTTYgen displays a warning about saving the key without a
426
+ passphrase. Choose Yes.
427
+
428
+ 7.
429
+
430
+ Specify the same name for the key that you used for the key pair. PuTTY automatically adds
431
+ the .ppk file extension.
432
+
433
+ Create a VPC
434
+ With Amazon Virtual Private Cloud (Amazon VPC), you can launch AWS resources into a virtual
435
+ network that you've defined. We strongly recommend that you launch your container instances in a
436
+ VPC.
437
+ If you have a default VPC, you also can skip this section and move to the next task Create a security
438
+ group. To determine whether you have a default VPC, see Supported Platforms in the Amazon EC2
439
+ Console in the Amazon EC2 User Guide
440
+ For information about how to create an Amazon VPC, see Create a VPC only in the Amazon VPC
441
+ User Guide. Refer to the following table to determine what options to select.
442
+ Option
443
+
444
+ Value
445
+
446
+ Resources to create
447
+
448
+ VPC only
449
+
450
+ Name
451
+
452
+ Optionally provide a name for
453
+ your VPC.
454
+
455
+ IPv4 CIDR block
456
+
457
+ IPv4 CIDR manual input
458
+ The CIDR block size must
459
+ have a size between /16
460
+ and /28.
461
+
462
+ Create a VPC
463
+
464
+ 12
465
+
466
+ AWS Batch
467
+
468
+ User Guide
469
+
470
+ Option
471
+
472
+ Value
473
+
474
+ IPv6 CIDR block
475
+
476
+ No IPv6 CIDR block
477
+
478
+ Tenancy
479
+
480
+ Default
481
+
482
+ For more information about Amazon VPC, see What is Amazon VPC? in the Amazon VPC User Guide.
483
+
484
+ Create a security group
485
+ Security groups act as a firewall for associated compute environment container instances,
486
+ controlling both inbound and outbound traffic at the container instance level. A security group can
487
+ be used only in the VPC for which it is created.
488
+ You can add rules to a security group that enable you to connect to your container instance from
489
+ your IP address using SSH. You can also add rules that allow inbound and outbound HTTP and
490
+ HTTPS access from anywhere. Add any rules to open ports that are required by your tasks.
491
+ Note that if you plan to launch container instances in multiple Regions, you need to create a
492
+ security group in each Region. For more information, see Regions and Availability Zones in the
493
+ Amazon EC2 User Guide.
494
+ Note
495
+ You need the public IP address of your local computer, which you can get using a service.
496
+ For example, we provide the following service: http://checkip.amazonaws.com/ or https://
497
+ checkip.amazonaws.com/. To locate another service that provides your IP address, use the
498
+ search phrase "what is my IP address." If you're connecting through an Internet service
499
+ provider (ISP) or from behind a firewall without a static IP address, find out the range of IP
500
+ addresses that are used by client computers.
501
+
502
+ To create a security group using the console
503
+ 1.
504
+
505
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
506
+
507
+ 2.
508
+
509
+ In the navigation pane, choose Security Groups.
510
+
511
+ 3.
512
+
513
+ Choose Create security group.
514
+
515
+ Create a security group
516
+
517
+ 13
518
+
519
+ AWS Batch
520
+
521
+ 4.
522
+
523
+ User Guide
524
+
525
+ Enter a name and description for the security group. You cannot change the name and
526
+ description of a security group after it is created.
527
+
528
+ 5.
529
+
530
+ From VPC, choose the VPC.
531
+
532
+ 6.
533
+
534
+ (Optional) By default, new security groups start with only an outbound rule that allows all
535
+ traffic to leave the resource. You must add rules to enable any inbound traffic or to restrict the
536
+ outbound traffic.
537
+ AWS Batch container instances don't require any inbound ports to be open. However, you
538
+ might want to add an SSH rule. That way, you can log into the container instance and examine
539
+ the containers in jobs with Docker commands. If you want your container instance to host a job
540
+ that runs a web server, you can also add rules for HTTP. Complete the following steps to add
541
+ these optional security group rules.
542
+ On the Inbound tab, create the following rules and choose Create:
543
+ • Choose Add Rule. For Type, choose HTTP. For Source, choose Anywhere (0.0.0.0/0).
544
+ • Choose Add Rule. For Type, choose SSH. For Source, choose Custom IP, and specify the
545
+ public IP address of your computer or network in Classless Inter-Domain Routing (CIDR)
546
+ notation. If your company allocates addresses from a range, specify the entire range, such as
547
+ 203.0.113.0/24. To specify an individual IP address in CIDR notation, choose My IP. This
548
+ adds the routing prefix /32 to the public IP address.
549
+
550
+ Note
551
+ For security reasons, we don't recommend that you allow SSH access from all IP
552
+ addresses (0.0.0.0/0) to your instance but only for testing purposes and only for a
553
+ short time.
554
+ 7.
555
+
556
+ You can add tags now, or you can add them later. To add a tag, choose Add new tag and enter
557
+ the tag key and value.
558
+
559
+ 8.
560
+
561
+ Choose Create security group.
562
+
563
+ To create a security group using the command line, see create-security-group (AWS CLI)
564
+ For more information about security groups, see Work with security groups.
565
+
566
+ Create a security group
567
+
568
+ 14
569
+
570
+ AWS Batch
571
+
572
+ User Guide
573
+
574
+ Install the AWS CLI
575
+ To use the AWS CLI with AWS Batch, install the latest AWS CLI version. For information about
576
+ installing the AWS CLI or upgrading it to the latest version, see Installing the AWS Command Line
577
+ Interface in the AWS Command Line Interface User Guide.
578
+
579
+ Install the AWS CLI
580
+
581
+ 15
582
+
583
+ AWS Batch
584
+
585
+ User Guide
586
+
587
+ Getting started with AWS Batch tutorials
588
+ You can use the AWS Batch first-run wizard to get started quickly with AWS Batch. After you
589
+ complete the Prerequisites, you can use the first-run wizard to create a compute environment, a job
590
+ definition, and a job queue.
591
+ You can also submit a sample "Hello World" job using the AWS Batch first-run wizard to test your
592
+ configuration. If you already have a Docker image that you want to launch in AWS Batch, you can
593
+ use that image to create a job definition.
594
+ Afterward, you can use the AWS Batch first-run wizard to create a compute environment, job
595
+ queue, and submit a sample Hello World job.
596
+
597
+ Getting started with Amazon EC2 orchestration using the
598
+ Wizard
599
+ Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS
600
+ Cloud. Using Amazon EC2 eliminates your need to invest in hardware up front, so you can develop
601
+ and deploy applications faster.
602
+ You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure
603
+ security and networking, and manage storage. Amazon EC2 enables you to scale up or down to
604
+ handle changes in requirements or spikes in popularity, reducing your need to forecast traffic.
605
+
606
+ Overview
607
+ This tutorial demonstrates how to setup AWS Batch with the Wizard to configure Amazon EC2 and
608
+ run Hello World.
609
+ Intended Audience
610
+ This tutorial is designed for system administrators and developers responsible for setting up,
611
+ testing, and deploying AWS Batch.
612
+ Features Used
613
+ This tutorial shows you how to use the AWS Batch console wizard to:
614
+ • Create and configure an Amazon EC2 compute environment
615
+ • Create a job queue.
616
+ Getting started with Amazon EC2 using the Wizard
617
+
618
+ 16
619
+
620
+ AWS Batch
621
+
622
+ User Guide
623
+
624
+ • Create a job definition
625
+ • Create and submit a job to run
626
+ • View the output of the job in CloudWatch
627
+ Time Required
628
+ It should take about 10–15 minutes to complete this tutorial.
629
+ Regional Restrictions
630
+ There are no country or regional restrictions associated with using this solution.
631
+ Resource Usage Costs
632
+ There's no charge for creating an AWS account. However, by implementing this solution, you
633
+ might incur some or all of the costs that are listed in the following table.
634
+ Description
635
+
636
+ Cost (US dollars)
637
+
638
+ Amazon EC2 instance
639
+
640
+ You pay for each Amazon EC2 instance that
641
+ is created. For more information about
642
+ pricing, see Amazon EC2 Pricing.
643
+
644
+ Prerequisites
645
+ Before you begin:
646
+ • Create an AWS account if you don't have one.
647
+ • Create the ecsInstanceRole Instance role.
648
+
649
+ Step 1: Create a compute environment
650
+ Important
651
+ To get started as simply and quickly as possible, this tutorial includes steps with default
652
+ settings. Before creating for production use, we recommend that you familiarize yourself
653
+ with all settings and deploy with the settings that meet your requirements.
654
+
655
+ To create a compute environment for an Amazon EC2 orchestration, do the following:
656
+ Prerequisites
657
+
658
+ 17
659
+
660
+ AWS Batch
661
+
662
+ User Guide
663
+
664
+ 1.
665
+
666
+ Open the AWS Batch console first-run wizard.
667
+
668
+ 2.
669
+
670
+ For Configure job and orchestration type, choose Amazon Elastic Compute Cloud(Amazon
671
+ EC2).
672
+
673
+ 3.
674
+
675
+ Choose Next.
676
+
677
+ 4.
678
+
679
+ In the Compute environment configuration section for Name, specify a unique name for
680
+ your compute environment. The name can be up to 128 characters in length. It can contain
681
+ uppercase and lowercase letters, numbers, hyphens (-), and underscores (_).
682
+
683
+ 5.
684
+
685
+ For Instance role, choose an existing instance role that has the required IAM permissions
686
+ attached. This instance role allows the Amazon ECS container instances in your compute
687
+ environment to make calls to the required AWS API operations. For more information, see
688
+ Amazon ECS instance role.
689
+ The default name of the Instance role is ecsInstanceRole.
690
+
691
+ 6.
692
+
693
+ For Instance configuration you can leave the default settings.
694
+
695
+ 7.
696
+
697
+ For Network configuration use your default VPC for the AWS Region.
698
+
699
+ 8.
700
+
701
+ Choose Next.
702
+
703
+ Step 2: Create a job queue
704
+ A job queue stores your submitted jobs until the AWS Batch Scheduler runs the job on a resource in
705
+ your compute environment. For more information, see Job queues
706
+ To create a job queue for an Amazon EC2 orchestration, do the following:
707
+ 1.
708
+
709
+ For Job queue configuration for Name, specify a unique name for your job queue. The name
710
+ can be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers,
711
+ hyphens (-), and underscores (_).
712
+
713
+ 2.
714
+
715
+ For all other configuration options you can leave the default value.
716
+
717
+ 3.
718
+
719
+ Choose Next.
720
+
721
+ Step 3: Create a job definition
722
+ AWS Batch job definitions specify how jobs are to be run. Even though each job must reference a
723
+ job definition, many of the parameters that are specified in the job definition can be overridden at
724
+ runtime.
725
+ Step 2: Create a job queue
726
+
727
+ 18
728
+
729
+ AWS Batch
730
+
731
+ User Guide
732
+
733
+ To create the job definition:
734
+ 1.
735
+
736
+ For Create a job definition
737
+ a.
738
+
739
+ for Name, specify a unique name for your job queue. The name can be up to 128
740
+ characters in length. It can contain uppercase and lowercase letters, numbers, hyphens (-),
741
+ and underscores (_).
742
+
743
+ b.
744
+
745
+ For Command - optional you can change hello world to a custom message or leave it
746
+ as is.
747
+
748
+ 2.
749
+
750
+ For all other configuration options you can leave the default value.
751
+
752
+ 3.
753
+
754
+ Choose Next.
755
+
756
+ Step 4: Create a job
757
+ To create a job, do the following:
758
+ 1.
759
+
760
+ In the Job configuration section for Name, specify a unique name for the job. The name can
761
+ be up to 128 characters in length. It can contain uppercase and lowercase letters, numbers,
762
+ hyphens (-), and underscores (_).
763
+
764
+ 2.
765
+
766
+ For all other configuration options you can leave the default value.
767
+
768
+ 3.
769
+
770
+ Choose Next.
771
+
772
+ Step 5: Review and create
773
+ On the Review and create page, review the configuration steps. If you need to make changes,
774
+ choose Edit. When you're finished, choose Create resources.
775
+ 1.
776
+
777
+ For Review and create choose Create resources.
778
+
779
+ 2.
780
+
781
+ A window opens as AWS Batch starts to allocate your resources. Once complete choose Go to
782
+ dashboard. On the dashboard you should see all of your allocated resources and that the job is
783
+ in the Runnable state. Your job is scheduled to run and should complete in 2–3 minuets.
784
+
785
+ Step 6: View the Job's output
786
+ To view the Job's output, do the following:
787
+ Step 4: Create a job
788
+
789
+ 19
790
+
791
+ AWS Batch
792
+
793
+ User Guide
794
+
795
+ 1.
796
+
797
+ In the navigation pane choose Jobs.
798
+
799
+ 2.
800
+
801
+ In the Job queue drop down choose the Job queue you created for the tutorial.
802
+
803
+ 3.
804
+
805
+ The Jobs table lists all of your Jobs and what their current status is. Once the Job's Status is
806
+ Succeeded choose the Name of the Job to view the Job's details.
807
+
808
+ 4.
809
+
810
+ In the Details pane choose Log stream name. The CloudWatch console for the Job will open
811
+ and there should be one event with the Message of hello world or your custom message.
812
+
813
+ Step 7: Clean up your tutorial resources
814
+ You are charged for the Amazon EC2 instance while it is enabled. You can delete the instance to
815
+ stop incurring charges.
816
+ To delete the resources you created, do the following:
817
+ 1.
818
+
819
+ In the navigation pane choose Job queue.
820
+
821
+ 2.
822
+
823
+ In the Job queue table choose the Job queue you created for the tutorial.
824
+
825
+ 3.
826
+
827
+ Choose Disable. Once the Job queue State is Disabled you can choose Delete.
828
+
829
+ 4.
830
+
831
+ Once the Job queue is deleted, in the navigation pane choose Compute environments.
832
+
833
+ 5.
834
+
835
+ Choose the compute environment you created for this tutorial and then choose Disable. It may
836
+ take 1–2 minuets for the compute environment to complete being disabled.
837
+
838
+ 6.
839
+
840
+ Once the compute environment’s State is Disabled, choose Delete. It may take 1–2 minuets for
841
+ the compute environment to be deleted.
842
+
843
+ Additional resources
844
+ After you complete the tutorial, you might want to explore the following topics::
845
+ • Explore the AWS Batch core components. For more information, see Components of AWS Batch.
846
+ • Learn more about the different Compute Environments available in AWS Batch.
847
+ • Learn more about Job queues and their different scheduling options.
848
+ • Learn more about Job definitions and the different configuration options.
849
+ • Learn more about the different types of Jobs.
850
+
851
+ Step 7: Clean up your tutorial resources
852
+
853
+ 20
854
+
855
+
dataset/docs/beanstalk.txt ADDED
@@ -0,0 +1,667 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ AWS Elastic Beanstalk
2
+
3
+ Developer Guide
4
+
5
+ What is AWS Elastic Beanstalk?
6
+ With Elastic Beanstalk you can deploy web applications into the AWS Cloud on a variety of
7
+ supported platforms. You build and deploy your applications. Elastic Beanstalk provisions Amazon
8
+ EC2 instances, configures load balancing, sets up health monitoring, and dynamically scales your
9
+ environment.
10
+ In addition to web server environments, Elastic Beanstalk also provides worker environments which
11
+ you can use to process messages from an Amazon SQS queue, useful for asynchronous or longrunning tasks. For more information, see Elastic Beanstalk worker environments.
12
+
13
+ 1
14
+
15
+ AWS Elastic Beanstalk
16
+
17
+ Developer Guide
18
+
19
+ Supported platforms
20
+ Elastic Beanstalk supports applications developed in Go, Java, .NET, Node.js, PHP, Python,
21
+ and Ruby. Elastic Beanstalk also supports Docker containers, where you can choose your own
22
+ programming language and application dependencies. When you deploy your application, Elastic
23
+ Supported platforms
24
+
25
+ 2
26
+
27
+ AWS Elastic Beanstalk
28
+
29
+ Developer Guide
30
+
31
+ Beanstalk builds the selected supported platform version and provisions one or more AWS
32
+ resources, such as Amazon EC2 instances, in your AWS account to run your application.
33
+ You can interact with Elastic Beanstalk through the Elastic Beanstalk console, the AWS Command
34
+ Line Interface (AWS CLI), or the EB CLI, a high-level command line tool designed specifically for
35
+ Elastic Beanstalk.
36
+ You can perform most deployment tasks, such as changing the size of your fleet of Amazon
37
+ EC2 instances or monitoring your application, directly from the Elastic Beanstalk web interface
38
+ (console).
39
+ To learn more about how to deploy a sample web application using Elastic Beanstalk, see Learn
40
+ how to get started with Elastic Beanstalk.
41
+
42
+ Application deploy workflow
43
+ To use Elastic Beanstalk, you create an application, then upload your application source bundle
44
+ to Elastic Beanstalk. Next, you provide information about the application, and Elastic Beanstalk
45
+ automatically launches an environment and creates and configures the AWS resources needed to
46
+ run your code.
47
+ After you create and deploy your application and your environment is launched, you can manage
48
+ your environment and deploy new application versions. Information about the application—
49
+ including metrics, events, and environment status—is made available through the Elastic Beanstalk
50
+ console, APIs, and Command Line Interfaces.
51
+ The following diagram illustrates Elastic Beanstalk workflow:
52
+
53
+ Pricing
54
+ There is no additional charge for Elastic Beanstalk. You pay only for the underlying AWS resources
55
+ that your application consumes. For details about pricing, see the Elastic Beanstalk service detail
56
+ page.
57
+ Application deploy workflow
58
+
59
+ 3
60
+
61
+ AWS Elastic Beanstalk
62
+
63
+ Developer Guide
64
+
65
+ Next steps
66
+ We recommend the tutorial, Getting started tutorial, to start using Elastic Beanstalk. The tutorial
67
+ steps you through creating, viewing, and updating a sample Elastic Beanstalk application.
68
+
69
+ Next steps
70
+
71
+ 4
72
+
73
+ AWS Elastic Beanstalk
74
+
75
+ Developer Guide
76
+
77
+ Learn how to get started with Elastic Beanstalk
78
+ With Elastic Beanstalk you can deploy, monitor, and scale web applications and services. Typically,
79
+ you will develop your code locally then deploy it to Amazon EC2 server instances. Theses instances,
80
+ also called environments, run on platforms that can be upgraded through the AWS console or the
81
+ command line.
82
+ To get started, we recommend deploying a pre-built sample application directly from the console.
83
+ Then, you can learn how to develop locally and deploy from the command line in the the section
84
+ called “QuickStart for PHP”.
85
+ There is no cost for using Elastic Beanstalk, but standard fees do apply to AWS resources that you
86
+ create during the course of this tutorial until you delete them at the end. The total charges are
87
+ typically less than a dollar. For information about how to minimize charges, see AWS free tier.
88
+ After completing this tutorial, you will understand the basics of creating, configuring, deploying,
89
+ updating, and monitoring an Elastic Beanstalk application with environments running on Amazon
90
+ EC2 instances.
91
+ Estimated duration: 35-45 minutes
92
+
93
+ 5
94
+
95
+ AWS Elastic Beanstalk
96
+
97
+ Developer Guide
98
+
99
+ 6
100
+
101
+ AWS Elastic Beanstalk
102
+
103
+ Developer Guide
104
+
105
+ What you will build
106
+ Your first Elastic Beanstalk application will consist of a single Amazon EC2 environment running
107
+ the PHP sample on a PHP managed platform.
108
+ Elastic Beanstalk application
109
+ An Elastic Beanstalk application is a container for Elastic Beanstalk components, including
110
+ environments where your application code runs on platforms provided and managed by Elastic
111
+ Beanstalk, or in custom containers that you provide.
112
+ Environment
113
+ An Elastic Beanstalk environment is a collection of AWS resources running together including
114
+ an Amazon EC2 instance. When you create an environment, Elastic Beanstalk provisions the
115
+ necessary resources into your AWS account.
116
+ Platform
117
+ A platform is a combination of an operating system, programming language runtime, web
118
+ server, application server, and additional Elastic Beanstalk components. Elastic Beanstalk
119
+ provides manged platforms, or you can provide your own platform in a container.
120
+ Elastic Beanstalk supports platforms for different programming languages, application servers,
121
+ and Docker containers. When you create an environment, you must choose the platform. You can
122
+ upgrade the platform, but you cannot change the platform for an environment.
123
+ Switching platforms
124
+ If you need to change programming languages, you must create and switch to a new
125
+ environment on a different platform.
126
+
127
+ Step 1 - Create an application
128
+ To create your example application, you'll use the Create application console wizard. It creates an
129
+ Elastic Beanstalk application and launches an environment within it.
130
+ Reminder: an environment is a collection of AWS resources required to run your application code.
131
+ What you will build
132
+
133
+ 7
134
+
135
+ AWS Elastic Beanstalk
136
+
137
+ Developer Guide
138
+
139
+ To create an application
140
+ 1.
141
+
142
+ Open the Elastic Beanstalk console.
143
+
144
+ 2.
145
+
146
+ Choose Create application.
147
+
148
+ 3.
149
+
150
+ For Application name enter getting-started-app.
151
+
152
+ The console provides a six step process for creating an application and configuring an environment.
153
+ For this quick start, you'll only need to focus on the first two steps, then you can skip ahead to
154
+ review and create your application and environment.
155
+ To configure an environment
156
+ 1.
157
+
158
+ In Environment information, for Environment name enter: gs-app-web-env.
159
+
160
+ 2.
161
+
162
+ For Platform, choose the PHP platform.
163
+
164
+ 3.
165
+
166
+ For Application code and Presets, accept the defaults (Sample application and Single instance),
167
+ then choose Next.
168
+
169
+ To configure service access
170
+ Next, you need two roles. A service role allows Elastic Beanstalk to monitor your EC2 instances and
171
+ upgrade you environment’s platform. An EC2 instance profile role permits tasks such as writing logs
172
+ and interacting with other services.
173
+ To create the Service role
174
+ 1.
175
+
176
+ For Service role, choose Create role.
177
+
178
+ 2.
179
+
180
+ For Trusted entity type, choose AWS service.
181
+
182
+ Step 1 - Create an application
183
+
184
+ 8
185
+
186
+ AWS Elastic Beanstalk
187
+
188
+ 3.
189
+
190
+ For Use case, choose Elastic Beanstalk – Environment.
191
+
192
+ 4.
193
+
194
+ Choose Next.
195
+
196
+ 5.
197
+
198
+ Verify that Permissions policies include the following, then choose Next:
199
+
200
+ Developer Guide
201
+
202
+ • AWSElasticBeanstalkEnhancedHealth
203
+ • AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
204
+ 6.
205
+
206
+ Choose Create role.
207
+
208
+ 7.
209
+
210
+ Return to the Configure service access tab, refresh the list, then select the newly created
211
+ service role.
212
+
213
+ To create the EC2 instance profile
214
+ 1.
215
+
216
+ Choose Create role.
217
+
218
+ 2.
219
+
220
+ For Trusted entity type, choose AWS service.
221
+
222
+ 3.
223
+
224
+ For Use case, choose Elastic Beanstalk – Compute.
225
+
226
+ 4.
227
+
228
+ Choose Next.
229
+
230
+ 5.
231
+
232
+ Verify that Permissions policies include the following, then choose Next:
233
+ • AWSElasticBeanstalkWebTier
234
+ • AWSElasticBeanstalkWorkerTier
235
+ • AWSElasticBeanstalkMulticontainerDocker
236
+
237
+ 6.
238
+
239
+ Choose Create role.
240
+
241
+ 7.
242
+
243
+ Return to the Configure service access tab, refresh the list, then select the newly created EC2
244
+ instance profile.
245
+
246
+ To finish configuring and creating your application
247
+ 1.
248
+
249
+ Skip over EC2 key pair.
250
+ We'll show you other ways to connect to your Amazon EC2 instances through the Console.
251
+
252
+ 2.
253
+
254
+ Choose Skip to Review to move over several optional steps.
255
+ Optional steps: networking, databases, scaling parameters, advanced configuration for updates,
256
+ monitoring, and logging.
257
+
258
+ 3.
259
+
260
+ On the Review page which shows a summary of your choices, choose Submit.
261
+
262
+ Step 1 - Create an application
263
+
264
+ 9
265
+
266
+ AWS Elastic Beanstalk
267
+
268
+ Developer Guide
269
+
270
+ Congratulations!
271
+ You have created an application and configured an environment! Now you need to wait for
272
+ the resources to deploy.
273
+
274
+ Step 2 - Deploy your application
275
+ When you create an application, Elastic Beanstalk sets up the environments for you. You just need
276
+ to sit back and wait.
277
+ The initial deploy can take up to five minutes to create the resources. Updates will take less time
278
+ because only changes will be deployed to your stack.
279
+
280
+ When you create the example application, Elastic Beanstalk creates the following resources:
281
+ • EC2 instance – An Amazon EC2 virtual machine configured to run web apps on the platform you
282
+ selected.
283
+ Every platform runs a different set of software, configuration files, and scripts to support a
284
+ specific language version, framework, web container, or combination thereof. Most platforms
285
+ use either Apache or nginx as a reverse proxy to forward web traffic to your web app, serve static
286
+ assets, and generate access and error logs. You can connect to your Amazon EC2 instances to
287
+ view configuration and logs.
288
+
289
+ Step 2 - Deploy your application
290
+
291
+ 10
292
+
293
+ AWS Elastic Beanstalk
294
+
295
+ Developer Guide
296
+
297
+ • Instance security group – An Amazon EC2 security group will be created to allow incoming
298
+ requests on port 80, so inbound traffic on a load balancer can reach your web app.
299
+ • Amazon S3 bucket – A storage location for your source code, logs, and other artifacts.
300
+ • Amazon CloudWatch alarms – Two CloudWatch alarms are created to monitor the load on your
301
+ instances and scale them up or down as needed.
302
+ • AWS CloudFormation stack – Elastic Beanstalk uses AWS CloudFormation to deploy the
303
+ resources in your environment and make configuration changes. You can view the resource
304
+ definition template in the AWS CloudFormation console.
305
+ • Domain name – A domain name that routes to your web app in the form :
306
+ subdomain.region.elasticbeanstalk.com.
307
+ Elastic Beanstalk creates your application, launches an environment, makes an application version,
308
+ then deploys your code into the environment. During the process, the console tracks progress and
309
+ displays event status in the Events tab.
310
+
311
+ Step 2 - Deploy your application
312
+
313
+ 11
314
+
315
+ AWS Elastic Beanstalk
316
+
317
+ Developer Guide
318
+
319
+ After all of the resources are deployed, the environment's health should change to Ok.
320
+
321
+ Step 2 - Deploy your application
322
+
323
+ 12
324
+
325
+ AWS Elastic Beanstalk
326
+
327
+ Developer Guide
328
+
329
+ Your application is ready!
330
+ After you see your application health change to Ok, you can browse to your web
331
+ application's website.
332
+
333
+ Step 3 - Explore the Elastic Beanstalk environment
334
+ You'll start exploring your deployed application environment from the Environment overview
335
+ page in the console.
336
+ To view the environment and your application
337
+ 1.
338
+
339
+ Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.
340
+
341
+ 2.
342
+
343
+ In the navigation pane, choose Environments, and then choose the name of your environment
344
+ from the list.
345
+
346
+ 3.
347
+
348
+ Choose Go to environment to browse your application!
349
+ (You can also choose the URL link listed for Domain to browse your application.)
350
+ The connection will be HTTP (not HTTPS), so you might see a warning in your browser.
351
+
352
+ Step 3 - Explore the environment
353
+
354
+ 13
355
+
356
+ AWS Elastic Beanstalk
357
+
358
+ Developer Guide
359
+
360
+ Back in the Elastic Beanstalk console, the upper portion shows the Environment overview with
361
+ top level information about your environment, including name, domain URL, current health status,
362
+ running version, and the platform that the application is running on. The running version and
363
+ platform are essential for troubleshooting your currently deployed application.
364
+ After the overview pane, you will see recent environment activity in the Events tab.
365
+
366
+ Step 3 - Explore the environment
367
+
368
+ 14
369
+
370
+ AWS Elastic Beanstalk
371
+
372
+ Developer Guide
373
+
374
+ While Elastic Beanstalk creates your AWS resources and launches your application, the environment
375
+ is in a Pending state. Status messages about launch events are continuously added to the list of
376
+ Events .
377
+ The environment's Domain is the URL for your deployed web application. In the left navigation
378
+ pane, Go to environment also takes you to your domain. Similarly, the left navigation pane has
379
+ links that correspond to the various tabs.
380
+ Take note of the Configuration link in the left navigation pane. which displays a summary of
381
+ environment configuration option values, grouped by category.
382
+
383
+ Environment configuration settings
384
+ Take note of the Configuration link in the left navigation pane. You can view and edit
385
+ detailed environment settings, such as service roles, networking, database, scaling,
386
+ managed platform updates, memory, health monitoring, rolling deployment, logging, and
387
+ more!
388
+
389
+ The various tabs contain detailed information about your environment:
390
+
391
+ Step 3 - Explore the environment
392
+
393
+ 15
394
+
395
+ AWS Elastic Beanstalk
396
+
397
+ Developer Guide
398
+
399
+ • Events – View an updating list of information and error messages from the Elastic Beanstalk
400
+ service and other services for resources in your environment.
401
+ • Health – View status and detailed health information for the Amazon EC2 instances running your
402
+ application.
403
+ • Logs – Retrieve and download logs from the Amazon EC2 in your environment. You can retrieve
404
+ full logs or recent activity. The retrieved logs are available for 15 minutes.
405
+ • Monitoring – View statistics for the environment, such as average latency and CPU utilization.
406
+ • Alarms – View and edit alarms that are configured for environment metrics.
407
+ • Managed updates – View information about upcoming and completed managed platform
408
+ updates and instance replacement.
409
+ • Tags – View and edit key-value pairs that are applied to your environment.
410
+
411
+ Note
412
+ Links in the console navigation pane will display the corresponding tab.
413
+
414
+ Troubleshooting with logs
415
+ For troubleshooting unexpected behaviors or debugging deployments, you might want to check
416
+ the logs in your environments.
417
+ You can request 100 lines of all the log files under the Logs tab in the Elastic Beanstalk console.
418
+ Alternatively, you can connect directly to the Amazon EC2 instance and tail the logs in realtime.
419
+ To request the logs (Elastic Beanstalk console)
420
+ 1.
421
+
422
+ Navigate to your environment in the Elastic Beanstalk console.
423
+
424
+ 2.
425
+
426
+ Choose the Logs tab or left-nav, then choose Request logs.
427
+
428
+ 3.
429
+
430
+ Select Last 100 lines.
431
+
432
+ 4.
433
+
434
+ After the logs are created, choose the Download link to view the logs in the browser.
435
+
436
+ In the logs, find the log and note the directory for the nginx access log.
437
+
438
+ Troubleshooting with logs
439
+
440
+ 16
441
+
442
+ AWS Elastic Beanstalk
443
+
444
+ Developer Guide
445
+
446
+ Add a policy to enable connections to Amazon EC2
447
+ Before you can connect, you must add a policy that enables connections to Amazon EC2 with
448
+ Session Manager.
449
+ 1.
450
+
451
+ Navigate to the IAM console.
452
+
453
+ 2.
454
+
455
+ Find and select the aws-elasticbeanstalk-ec2-role role.
456
+
457
+ 3.
458
+
459
+ Choose Add permission, then Attach policies.
460
+
461
+ 4.
462
+
463
+ Search for a default policy that begins with the following text:
464
+ AmazonSSMManagedEC2Instance, then add it to the role.
465
+
466
+ To connect to your Amazon EC2 with Session Manager
467
+ 1.
468
+
469
+ Navigate to the Amazon EC2 console.
470
+
471
+ 2.
472
+
473
+ Choose Instances, then select your gs-app-web-env instance.
474
+
475
+ 3.
476
+
477
+ Choose Connect, then Session Manager.
478
+
479
+ 4.
480
+
481
+ Choose Connect.
482
+
483
+ After connecting to the instance, start a bash shell and tail the logs:
484
+ 1.
485
+
486
+ Run the command bash.
487
+
488
+ 2.
489
+
490
+ Run the command cd /var/log/nginx.
491
+
492
+ 3.
493
+
494
+ Run the command tail -f access.log.
495
+
496
+ 4.
497
+
498
+ In your browser, go to the application domain URL. Refresh.
499
+
500
+ Congratulations, you're connected!
501
+ You should see log entries in your instance update every time you refresh the page.
502
+
503
+ Connect button not working?
504
+ If the connect button is not available, go back to IAM and verify that you added the
505
+ necessary policy to the role.
506
+
507
+ Troubleshooting with logs
508
+
509
+ 17
510
+
511
+ AWS Elastic Beanstalk
512
+
513
+ Developer Guide
514
+
515
+ Step 4 - Update your application
516
+ Eventually, you will want to update your application. You can deploy a new version at any time, as
517
+ long as no other update operations are in progress on your environment.
518
+ The application version that you started this tutorial with is called Sample Application.
519
+
520
+ To update your application version
521
+ 1.
522
+
523
+ Download the following PHP sample application:
524
+ PHP – php-v2.zip
525
+
526
+ 2.
527
+
528
+ Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.
529
+
530
+ 3.
531
+
532
+ In the navigation pane, choose Environments, and then choose the name of your environment
533
+ from the list.
534
+
535
+ 4.
536
+
537
+ On the environment overview page, choose Upload and deploy.
538
+
539
+ 5.
540
+
541
+ Select Choose file, and then upload the sample application source bundle that you
542
+ downloaded.
543
+ The console automatically fills in the Version label with a new unique label, automatically
544
+ incrementing a trailing integer. If you choose your own version label, ensure that it's unique.
545
+
546
+ Step 4 - Update your application
547
+
548
+ 18
549
+
550
+ AWS Elastic Beanstalk
551
+
552
+ 6.
553
+
554
+ Developer Guide
555
+
556
+ Choose Deploy.
557
+
558
+ While Elastic Beanstalk deploys your file to your Amazon EC2 instances, you can view the
559
+ deployment status on the Environment overview page. While the application version is updated,
560
+ the environment Health status is gray. When the deployment is complete, Elastic Beanstalk
561
+ performs an application health check. When the application responds to the health check, it's
562
+ considered healthy and the status returns to green. The environment overview shows the new
563
+ Running Version—the name you provided as the Version label.
564
+ Elastic Beanstalk also uploads your new application version and adds it to the table of application
565
+ versions. To view the table, choose Application versions under getting-started-app on the
566
+ navigation pane.
567
+
568
+ Update success!
569
+ You should see an updated "v2" message after refreshing your browser.
570
+ If you want to edit the source yourself, unzip, edit, then re-zip the source bundle. On
571
+ macOS, use the following command from inside your php directory with the -X to exclude
572
+ extra file attributes:
573
+ zip -X -r ../php-v2.zip .
574
+
575
+ Step 5 - Scale your application
576
+ You can configure your environment to better suit your application. For example, if you have
577
+ a compute-intensive application, you can change the type of Amazon Elastic Compute Cloud
578
+ (Amazon EC2) instance that is running your application. To apply configuration changes, Elastic
579
+ Beanstalk performs an environment update.
580
+ Some configuration changes are simple and happen quickly. Some changes require deleting
581
+ and recreating AWS resources, which can take several minutes. When you change configuration
582
+ settings, Elastic Beanstalk warns you about potential application downtime.
583
+
584
+ Step 5 - Scale your application
585
+
586
+ 19
587
+
588
+ AWS Elastic Beanstalk
589
+
590
+ Developer Guide
591
+
592
+ Increase capacity settings
593
+ In this example of a configuration change, you edit your environment's capacity settings. You
594
+ configure a load-balanced, scalable environment that has between two and four Amazon EC2
595
+ instances in its Auto Scaling group, and then you verify that the change occurred. Elastic Beanstalk
596
+ creates an additional Amazon EC2 instance, adding to the single instance that it created initially.
597
+ Then, Elastic Beanstalk associates both instances with the environment's load balancer. As a result,
598
+ your application's responsiveness is improved and its availability is increased.
599
+ To change your environment's capacity
600
+ 1.
601
+
602
+ Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.
603
+
604
+ 2.
605
+
606
+ In the navigation pane, choose Environments, and then choose the name of your environment
607
+ from the list.
608
+
609
+ 3.
610
+
611
+ In the navigation pane, choose Configuration.
612
+
613
+ 4.
614
+
615
+ In the Instance traffic and scaling configuration category, choose Edit.
616
+
617
+ 5.
618
+
619
+ Collapse the Instances section, so you can more easily see the Capacity section. Under Auto
620
+ Scaling group change Environment type to Load balanced.
621
+
622
+ 6.
623
+
624
+ In the Instances row, change Min to 2 and Max to 4.
625
+
626
+ Increase capacity settings
627
+
628
+ 20
629
+
630
+ AWS Elastic Beanstalk
631
+
632
+ 7.
633
+
634
+ Developer Guide
635
+
636
+ To save the changes choose Apply at the bottom of the page.
637
+ If you are warned that the update will replace all of your current instances. Choose Confirm.
638
+
639
+ The environment update can take a few minutes. You should see several updates in the list of
640
+ events. Watch for the event Successfully deployed new configuration to environment.
641
+
642
+ Verify increased capacity
643
+ After the environment update is complete and the environment is ready, Elastic Beanstalk
644
+ automatically launched a second instance to meet your new minimum capacity setting.
645
+ To verify the increased capacity
646
+ 1.
647
+
648
+ Choose Health from either the tab list or left navigation pane.
649
+
650
+ 2.
651
+
652
+ Review the Enhanced instance health section.
653
+
654
+ You just scaled up!
655
+ With two Amazon EC2 instances, your environment capacity has doubled, and it only took a
656
+ few minutes.
657
+
658
+ Cleaning up your Elastic Beanstalk environment
659
+ To ensure that you're not charged for any services you aren't using, delete all application versions
660
+ and terminate environments, which also deletes the AWS resources that the environment created
661
+ for you.
662
+
663
+ Verify increased capacity
664
+
665
+ 21
666
+
667
+
dataset/docs/ec2.txt ADDED
@@ -0,0 +1,778 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ Amazon Elastic Compute Cloud
2
+
3
+ User Guide
4
+
5
+ What is Amazon EC2?
6
+ Amazon Elastic Compute Cloud (Amazon EC2) provides on-demand, scalable computing capacity
7
+ in the Amazon Web Services (AWS) Cloud. Using Amazon EC2 reduces hardware costs so you can
8
+ develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few
9
+ virtual servers as you need, configure security and networking, and manage storage. You can add
10
+ capacity (scale up) to handle compute-heavy tasks, such as monthly or yearly processes, or spikes in
11
+ website traffic. When usage decreases, you can reduce capacity (scale down) again.
12
+ An EC2 instance is a virtual server in the AWS Cloud. When you launch an EC2 instance, the
13
+ instance type that you specify determines the hardware available to your instance. Each instance
14
+ type offers a different balance of compute, memory, network, and storage resources. For more
15
+ information, see the Amazon EC2 Instance Types Guide.
16
+
17
+ Features of Amazon EC2
18
+ Amazon EC2 provides the following high-level features:
19
+ Instances
20
+ Virtual servers.
21
+ Amazon Machine Images (AMIs)
22
+ Preconfigured templates for your instances that package the components you need for your
23
+ server (including the operating system and additional software).
24
+ Instance types
25
+ Various configurations of CPU, memory, storage, networking capacity, and graphics hardware
26
+ for your instances.
27
+ Features
28
+
29
+ 1
30
+
31
+ Amazon Elastic Compute Cloud
32
+
33
+ User Guide
34
+
35
+ Amazon EBS volumes
36
+ Persistent storage volumes for your data using Amazon Elastic Block Store (Amazon EBS).
37
+ Instance store volumes
38
+ Storage volumes for temporary data that is deleted when you stop, hibernate, or terminate
39
+ your instance.
40
+ Key pairs
41
+ Secure login information for your instances. AWS stores the public key and you store the private
42
+ key in a secure place.
43
+ Security groups
44
+ A virtual firewall that allows you to specify the protocols, ports, and source IP ranges that can
45
+ reach your instances, and the destination IP ranges to which your instances can connect.
46
+ Amazon EC2 supports the processing, storage, and transmission of credit card data by a merchant
47
+ or service provider, and has been validated as being compliant with Payment Card Industry (PCI)
48
+ Data Security Standard (DSS). For more information about PCI DSS, including how to request a
49
+ copy of the AWS PCI Compliance Package, see PCI DSS Level 1.
50
+
51
+ Related services
52
+ Services to use with Amazon EC2
53
+ You can use other AWS services with the instances that you deploy using Amazon EC2.
54
+ Amazon EC2 Auto Scaling
55
+ Helps ensure you have the correct number of Amazon EC2 instances available to handle the
56
+ load for your application.
57
+ AWS Backup
58
+ Automate backing up your Amazon EC2 instances and the Amazon EBS volumes attached to
59
+ them.
60
+ Amazon CloudWatch
61
+ Monitor your instances and Amazon EBS volumes.
62
+ Related services
63
+
64
+ 2
65
+
66
+ Amazon Elastic Compute Cloud
67
+
68
+ User Guide
69
+
70
+ Elastic Load Balancing
71
+ Automatically distribute incoming application traffic across multiple instances.
72
+ Amazon GuardDuty
73
+ Detect potentially unauthorized or malicious use of your EC2 instances.
74
+ EC2 Image Builder
75
+ Automate the creation, management, and deployment of customized, secure, and up-to-date
76
+ server images.
77
+ AWS Launch Wizard
78
+ Size, configure, and deploy AWS resources for third-party applications without having to
79
+ manually identify and provision individual AWS resources.
80
+ AWS Systems Manager
81
+ Perform operations at scale on EC2 instances with this secure end-to-end management
82
+ solution.
83
+ Additional compute services
84
+ You can launch instances using another AWS compute service instead of using Amazon EC2.
85
+ Amazon Lightsail
86
+ Build websites or web applications using Amazon Lightsail, a cloud platform that provides the
87
+ resources that you need to deploy your project quickly, for a low, predictable monthly price. To
88
+ compare Amazon EC2 and Lightsail, see Amazon Lightsail or Amazon EC2.
89
+ Amazon Elastic Container Service (Amazon ECS)
90
+ Deploy, manage, and scale containerized applications on a cluster of EC2 instances. For more
91
+ information, see Choosing an AWS container service.
92
+ Amazon Elastic Kubernetes Service (Amazon EKS)
93
+ Run your Kubernetes applications on AWS. For more information, see Choosing an AWS
94
+ container service.
95
+
96
+ Related services
97
+
98
+ 3
99
+
100
+ Amazon Elastic Compute Cloud
101
+
102
+ User Guide
103
+
104
+ Access Amazon EC2
105
+ You can create and manage your Amazon EC2 instances using the following interfaces:
106
+ Amazon EC2 console
107
+ A simple web interface to create and manage Amazon EC2 instances and resources. If you've
108
+ signed up for an AWS account, you can access the Amazon EC2 console by signing into the AWS
109
+ Management Console and selecting EC2 from the console home page.
110
+ AWS Command Line Interface
111
+ Enables you to interact with AWS services using commands in your command-line shell. It is
112
+ supported on Windows, Mac, and Linux. For more information about the AWS CLI , see AWS
113
+ Command Line Interface User Guide. You can find the Amazon EC2 commands in the AWS CLI
114
+ Command Reference.
115
+ AWS CloudFormation
116
+ Amazon EC2 supports creating resources using AWS CloudFormation. You create a template, in
117
+ JSON or YAML format, that describes your AWS resources, and AWS CloudFormation provisions
118
+ and configures those resources for you. You can reuse your CloudFormation templates to
119
+ provision the same resources multiple times, whether in the same Region and account or in
120
+ multiple Regions and accounts. For more information about supported resource types and
121
+ properties for Amazon EC2, see EC2 resource type reference in the AWS CloudFormation User
122
+ Guide.
123
+ AWS SDKs
124
+ If you prefer to build applications using language-specific APIs instead of submitting a request
125
+ over HTTP or HTTPS, AWS provides libraries, sample code, tutorials, and other resources
126
+ for software developers. These libraries provide basic functions that automate tasks such
127
+ as cryptographically signing your requests, retrying requests, and handling error responses,
128
+ making it easier for you to get started. For more information, see Tools to Build on AWS.
129
+ AWS Tools for PowerShell
130
+ A set of PowerShell modules that are built on the functionality exposed by the SDK for .NET.
131
+ The Tools for PowerShell enable you to script operations on your AWS resources from the
132
+ PowerShell command line. To get started, see the AWS Tools for PowerShell User Guide. You
133
+ can find the cmdlets for Amazon EC2, in the AWS Tools for PowerShell Cmdlet Reference.
134
+ Access EC2
135
+
136
+ 4
137
+
138
+ Amazon Elastic Compute Cloud
139
+
140
+ User Guide
141
+
142
+ Query API
143
+ Amazon EC2 provides a Query API. These requests are HTTP or HTTPS requests that use the
144
+ HTTP verbs GET or POST and a Query parameter named Action. For more information about
145
+ the API actions for Amazon EC2, see Actions in the Amazon EC2 API Reference.
146
+
147
+ Pricing for Amazon EC2
148
+ Amazon EC2 provides the following pricing options:
149
+ Free Tier
150
+ You can get started with Amazon EC2 for free. To explore the Free Tier options, see AWS Free
151
+ Tier.
152
+ On-Demand Instances
153
+ Pay for the instances that you use by the second, with a minimum of 60 seconds, with no longterm commitments or upfront payments.
154
+ Savings Plans
155
+ You can reduce your Amazon EC2 costs by making a commitment to a consistent amount of
156
+ usage, in USD per hour, for a term of 1 or 3 years.
157
+ Reserved Instances
158
+ You can reduce your Amazon EC2 costs by making a commitment to a specific instance
159
+ configuration, including instance type and Region, for a term of 1 or 3 years.
160
+ Spot Instances
161
+ Request unused EC2 instances, which can reduce your Amazon EC2 costs significantly.
162
+ Dedicated Hosts
163
+ Reduce costs by using a physical EC2 server that is fully dedicated for your use, either OnDemand or as part of a Savings Plan. You can use your existing server-bound software licenses
164
+ and get help meeting compliance requirements.
165
+ On-Demand Capacity Reservations
166
+ Reserve compute capacity for your EC2 instances in a specific Availability Zone for any duration
167
+ of time.
168
+ Pricing
169
+
170
+ 5
171
+
172
+ Amazon Elastic Compute Cloud
173
+
174
+ User Guide
175
+
176
+ Per-second billing
177
+ Removes the cost of unused minutes and seconds from your bill.
178
+ For a complete list of charges and prices for Amazon EC2 and more information about the purchase
179
+ models, see Amazon EC2 pricing.
180
+
181
+ Estimates, billing, and cost optimization
182
+ To create estimates for your AWS use cases, use the AWS Pricing Calculator.
183
+ To estimate the cost of transforming Microsoft workloads to a modern architecture that uses
184
+ open source and cloud-native services deployed on AWS, use the AWS Modernization Calculator for
185
+ Microsoft Workloads.
186
+ To see your bill, go to the Billing and Cost Management Dashboard in the AWS Billing and Cost
187
+ Management console. Your bill contains links to usage reports that provide details about your bill.
188
+ To learn more about AWS account billing, see AWS Billing and Cost Management User Guide.
189
+ If you have questions concerning AWS billing, accounts, and events, contact AWS Support.
190
+ To calculate the cost of a sample provisioned environment, see Cloud Economics Center. When
191
+ calculating the cost of a provisioned environment, remember to include incidental costs such as
192
+ snapshot storage for EBS volumes.
193
+ You can optimize the cost, security, and performance of your AWS environment using AWS Trusted
194
+ Advisor.
195
+ You can use AWS Cost Explorer to analyze the cost and usage of your EC2 instances. You can view
196
+ data up to the last 13 months, and forecast how much you are likely to spend for the next 12
197
+ months. For more information, see Analyzing your costs and usage with AWS Cost Explorer in the
198
+ AWS Cost Management User Guide.
199
+
200
+ Resources
201
+ • Amazon EC2 features
202
+ • AWS re:Post
203
+ • AWS Skill Builder
204
+ • AWS Support
205
+ Estimates, billing, and cost optimization
206
+
207
+ 6
208
+
209
+ Amazon Elastic Compute Cloud
210
+
211
+ User Guide
212
+
213
+ • Hands-on Tutorials
214
+ • Web Hosting
215
+ • Windows on AWS
216
+
217
+ Resources
218
+
219
+ 7
220
+
221
+ Amazon Elastic Compute Cloud
222
+
223
+ User Guide
224
+
225
+ Get started with Amazon EC2
226
+ Use this tutorial to get started with Amazon Elastic Compute Cloud (Amazon EC2). You'll learn how
227
+ to launch and connect to an EC2 instance. An instance is a virtual server in the AWS Cloud. With
228
+ Amazon EC2, you can set up and configure the operating system and applications that run on your
229
+ instance.
230
+ Overview
231
+ The following diagram shows the key components that you'll use in this tutorial:
232
+ • An image – A template that contains the software to run on your instance, such as the operating
233
+ system.
234
+ • A key pair – A set of security credentials that you use to prove your identity when connecting to
235
+ your instance. The public key is on your instance and the private key is on your computer.
236
+ • A network – A virtual private cloud (VPC) is a virtual network dedicated to your AWS account.
237
+ To help you get started quickly, your account comes with a default VPC in each AWS Region, and
238
+ each default VPC has a default subnet in each Availability Zone.
239
+ • A security group – Acts as a virtual firewall to control inbound and outbound traffic.
240
+ • An EBS volume – We require a root volume for the image. You can optionally add data volumes.
241
+
242
+ 8
243
+
244
+ Amazon Elastic Compute Cloud
245
+
246
+ User Guide
247
+
248
+ Cost for this tutorial
249
+ When you create your AWS account, you can get started with Amazon EC2 for free using the AWS
250
+ Free Tier.
251
+ If you created your AWS account before July 15, 2025, it's less than 12 months old, and you haven't
252
+ already exceeded the Free Tier benefits for Amazon EC2, it won't cost you anything to complete
253
+ this tutorial, because we help you select options that are within the Free Tier benefits. Otherwise,
254
+ you'll incur the standard Amazon EC2 usage fees from the time that you launch the instance (even
255
+ if it remains idle) until you terminate it.
256
+ If you created your AWS account on or after July 15, 2025, it's less than 6 months old, and you
257
+ haven't used up all your credits, it won't cost you anything to complete this tutorial, because we
258
+ help you select options that are within the Free Tier benefits.
259
+ For information on how to determine whether you are eligible for the Free Tier, see the section
260
+ called “Track your Free Tier usage”.
261
+ Tasks
262
+ • Step 1: Launch an instance
263
+ • Step 2: Connect to your instance
264
+ • Step 3: Clean up your instance
265
+ 9
266
+
267
+ Amazon Elastic Compute Cloud
268
+
269
+ User Guide
270
+
271
+ • Next steps
272
+
273
+ Step 1: Launch an instance
274
+ You can launch an EC2 instance using the AWS Management Console as described in the following
275
+ procedure. This tutorial is intended to help you quickly launch your first instance, so it doesn't
276
+ cover all possible options.
277
+ To launch an instance
278
+ 1.
279
+
280
+ Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
281
+
282
+ 2.
283
+
284
+ In the navigation bar at the top of the screen, we display the current AWS Region — for
285
+ example, Ohio. You can use the selected Region, or optionally select a Region that is closer to
286
+ you.
287
+
288
+ 3.
289
+
290
+ From the EC2 console dashboard, in the Launch instance pane, choose Launch instance.
291
+
292
+ 4.
293
+
294
+ Under Name and tags, for Name, enter a descriptive name for your instance.
295
+
296
+ 5.
297
+
298
+ Under Application and OS Images (Amazon Machine Image), do the following:
299
+ a.
300
+
301
+ Choose Quick Start, and then choose the operating system (OS) for your instance. For
302
+ your first Linux instance, we recommend that you choose Amazon Linux.
303
+
304
+ b.
305
+
306
+ From Amazon Machine Image (AMI), select an AMI that is marked Free Tier eligible.
307
+
308
+ 6.
309
+
310
+ Under Instance type, for Instance type, select an instance type that is marked Free Tier
311
+ eligible.
312
+
313
+ 7.
314
+
315
+ Under Key pair (login), for Key pair name, choose an existing key pair or choose Create new
316
+ key pair to create your first key pair.
317
+
318
+ Warning
319
+ If you choose Proceed without a key pair (Not recommended), you won't be able to
320
+ connect to your instance using the methods described in this tutorial.
321
+ 8.
322
+
323
+ Under Network settings, notice that we selected your default VPC, selected the option to use
324
+ the default subnet in an Availability Zone that we choose for you, and configured a security
325
+ group with a rule that allows connections to your instance from anywhere (0.0.0.0.0/0).
326
+
327
+ Step 1: Launch an instance
328
+
329
+ 10
330
+
331
+ Amazon Elastic Compute Cloud
332
+
333
+ User Guide
334
+
335
+ Warning
336
+ If you specify 0.0.0.0/0, you are enabling traffic from any IP addresses in the world.
337
+ For the SSH and RDP protocols, you might consider this acceptable for a short time
338
+ in a test environment, but it's unsafe for production environments. In production, be
339
+ sure to authorize access only from the appropriate individual IP address or range of
340
+ addresses.
341
+
342
+ For your first instance, we recommend that you use the default settings. Otherwise, you can
343
+ update your network settings as follows:
344
+
345
+ 9.
346
+
347
+
348
+
349
+ (Optional) To use a specific default subnet, choose Edit and then choose a subnet.
350
+
351
+
352
+
353
+ (Optional) To use a different VPC, choose Edit and then choose an existing VPC. If the VPC
354
+ isn't configured for public internet access, you won't be able to connect to your instance.
355
+
356
+
357
+
358
+ (Optional) To restrict inbound connection traffic to a specific network, choose Custom
359
+ instead of Anywhere, and enter the CIDR block for your network.
360
+
361
+
362
+
363
+ (Optional) To use a different security group, choose Select existing security group and
364
+ choose an existing security group. If the security group does not have a rule that allows
365
+ connection traffic from your network, you won't be able to connect to your instance. For
366
+ a Linux instance, you must allow SSH traffic. For a Windows instance, you must allow RDP
367
+ traffic.
368
+
369
+ Under Configure storage, notice that we configured a root volume but no data volumes. This
370
+ is sufficient for test purposes.
371
+
372
+ 10. Review a summary of your instance configuration in the Summary panel, and when you're
373
+ ready, choose Launch instance.
374
+ 11. If the launch is successful, choose the ID of the instance from the Success notification to open
375
+ the Instances page and monitor the status of the launch.
376
+ 12. Select the checkbox for the instance. The initial instance state is pending. After the instance
377
+ starts, its state changes to running. Choose the Status and alarms tab. After your instance
378
+ passes its status checks, it is ready to receive connection requests.
379
+
380
+ Step 1: Launch an instance
381
+
382
+ 11
383
+
384
+ Amazon Elastic Compute Cloud
385
+
386
+ User Guide
387
+
388
+ Step 2: Connect to your instance
389
+ The procedure that you use depends on the operating system of the instance. If you can't connect
390
+ to your instance, see Troubleshoot issues connecting to your Amazon EC2 Linux instance for
391
+ assistance.
392
+
393
+ Linux instances
394
+ You can connect to your Linux instance using any SSH client. If you are running Windows on
395
+ your computer, open a terminal and run the ssh command to verify that you have an SSH client
396
+ installed. If the command is not found, install OpenSSH for Windows.
397
+ To connect to your instance using SSH
398
+ 1.
399
+
400
+ Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
401
+
402
+ 2.
403
+
404
+ In the navigation pane, choose Instances.
405
+
406
+ 3.
407
+
408
+ Select the instance and then choose Connect.
409
+
410
+ 4.
411
+
412
+ On the Connect to instance page, choose the SSH client tab.
413
+
414
+ 5.
415
+
416
+ (Optional) If you created a key pair when you launched the instance and downloaded the
417
+ private key (.pem file) to a computer running Linux or macOS, run the example chmod
418
+ command to set the permissions for your private key.
419
+
420
+ 6.
421
+
422
+ Copy the example SSH command. The following is an example, where key-pair-name.pem
423
+ is the name of your private key file, ec2-user is the username associated with the image, and
424
+ the string after the @ symbol is the public DNS name of the instance.
425
+ ssh -i key-pair-name.pem ec2-user@ec2-198-51-100-1.us-east-2.compute.amazonaws.com
426
+
427
+ 7.
428
+
429
+ In a terminal window on your computer, run the ssh command that you saved in the previous
430
+ step. If the private key file is not in the current directory, you must specify the fully-qualified
431
+ path to the key file in this command.
432
+ The following is an example response:
433
+ The authenticity of host 'ec2-198-51-100-1.us-east-2.compute.amazonaws.com
434
+ (198-51-100-1)' can't be established.
435
+ ECDSA key fingerprint is l4UB/neBad9tvkgJf1QZWxheQmR59WgrgzEimCG6kZY.
436
+ Are you sure you want to continue connecting (yes/no)?
437
+
438
+ Step 2: Connect to your instance
439
+
440
+ 12
441
+
442
+ Amazon Elastic Compute Cloud
443
+
444
+ 8.
445
+
446
+ User Guide
447
+
448
+ (Optional) Verify that the fingerprint in the security alert matches the instance fingerprint
449
+ contained in the console output when you first start an instance. To get the console output,
450
+ choose Actions, Monitor and troubleshoot, Get system log. If the fingerprints don't match,
451
+ someone might be attempting a man-in-the-middle attack. If they match, continue to the next
452
+ step.
453
+
454
+ 9.
455
+
456
+ Enter yes.
457
+ The following is an example response:
458
+ Warning: Permanently added 'ec2-198-51-100-1.useast-2.compute.amazonaws.com' (ECDSA) to the list of known hosts.
459
+
460
+ Windows instances
461
+ To connect to a Windows instance using RDP, you must retrieve the initial administrator password
462
+ and then enter this password when you connect to your instance. It takes a few minutes after
463
+ instance launch before this password is available. Your account must have permission to call the
464
+ GetPasswordData action. For more information, see Example policies to control access the Amazon
465
+ EC2 API.
466
+ The default username for the Administrator account depends on the language of the operating
467
+ system (OS) contained in the AMI. To determine the correct username, identify the language
468
+ of the OS, and then choose the corresponding username. For example, for an English OS, the
469
+ username is Administrator, for a French OS it's Administrateur, and for a Portuguese OS it's
470
+ Administrador. If a language version of the OS does not have a username in the same language,
471
+ choose the username Administrator (Other). For more information, see Localized Names for
472
+ Administrator Account in Windows in the Microsoft website.
473
+ To retrieve the initial administrator password
474
+ 1.
475
+
476
+ Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
477
+
478
+ 2.
479
+
480
+ In the navigation pane, choose Instances.
481
+
482
+ 3.
483
+
484
+ Select the instance and then choose Connect.
485
+
486
+ 4.
487
+
488
+ On the Connect to instance page, choose the RDP client tab.
489
+
490
+ 5.
491
+
492
+ For Username, choose the default username for the Administrator account. The username you
493
+ choose must match the language of the operating system (OS) contained in the AMI that you
494
+
495
+ Step 2: Connect to your instance
496
+
497
+ 13
498
+
499
+ Amazon Elastic Compute Cloud
500
+
501
+ User Guide
502
+
503
+ used to launch your instance. If there is no username in the same language as your OS, choose
504
+ Administrator (Other).
505
+ 6.
506
+
507
+ Choose Get password.
508
+
509
+ 7.
510
+
511
+ On the Get Windows password page, do the following:
512
+ a.
513
+
514
+ Choose Upload private key file and navigate to the private key (.pem) file that you
515
+ specified when you launched the instance. Select the file and choose Open to copy the
516
+ entire contents of the file to this window.
517
+
518
+ b.
519
+
520
+ Choose Decrypt password. The Get Windows password page closes, and the default
521
+ administrator password for the instance appears under Password, replacing the Get
522
+ password link shown previously.
523
+
524
+ c.
525
+
526
+ Copy the password and save it in a safe place. This password is required to connect to the
527
+ instance.
528
+
529
+ The following procedure uses the Remote Desktop Connection client for Windows (MSTSC). If
530
+ you're using a different RDP client, download the RDP file and then see the documentation for the
531
+ RDP client for the steps to establish the RDP connection.
532
+ To connect to a Windows instance using an RDP client
533
+ 1.
534
+
535
+ On the Connect to instance page, choose Download remote desktop file. When the
536
+ file download is finished, choose Cancel to return to the Instances page. The RDP file is
537
+ downloaded to your Downloads folder.
538
+
539
+ 2.
540
+
541
+ Run mstsc.exe to open the RDP client.
542
+
543
+ 3.
544
+
545
+ Expand Show options, choose Open, and select the .rdp file from your Downloads folder.
546
+
547
+ 4.
548
+
549
+ By default, Computer is the public IPv4 DNS name of the instance and User name is the
550
+ administrator account. To connect to the instance using IPv6 instead, replace the public IPv4
551
+ DNS name of the instance with its IPv6 address. Review the default settings and change them
552
+ as needed.
553
+
554
+ 5.
555
+
556
+ Choose Connect. If you receive a warning that the publisher of the remote connection is
557
+ unknown, choose Connect to continue.
558
+
559
+ 6.
560
+
561
+ Enter the password that you saved previously, and then choose OK.
562
+
563
+ 7.
564
+
565
+ Due to the nature of self-signed certificates, you might get a warning that the security
566
+ certificate could not be authenticated. Do one of the following:
567
+
568
+
569
+ If you trust the certificate, choose Yes to connect to your instance.
570
+
571
+ Step 2: Connect to your instance
572
+
573
+ 14
574
+
575
+ Amazon Elastic Compute Cloud
576
+
577
+
578
+
579
+ User Guide
580
+
581
+ [Windows] Before you proceed, compare the thumbprint of the certificate with the value
582
+ in the system log to confirm the identity of the remote computer. Choose View certificate
583
+ and then choose Thumbprint from the Details tab. Compare this value to the value of
584
+ RDPCERTIFICATE-THUMBPRINT in Actions, Monitor and troubleshoot, Get system log.
585
+
586
+
587
+
588
+ [Mac OS X] Before you proceed, compare the fingerprint of the certificate with the
589
+ value in the system log to confirm the identity of the remote computer. Choose Show
590
+ Certificate, expand Details, and choose SHA1 Fingerprints. Compare this value to the
591
+ value of RDPCERTIFICATE-THUMBPRINT in Actions, Monitor and troubleshoot, Get
592
+ system log.
593
+
594
+ 8.
595
+
596
+ If the RDP connection is successful, the RDP client displays the Windows login screen and
597
+ then the Windows desktop. If you receive an error message instead, see the section called
598
+ “Remote Desktop can't connect to the remote computer”. When you are finished with the RDP
599
+ connection, you can close the RDP client.
600
+
601
+ Step 3: Clean up your instance
602
+ After you've finished with the instance that you created for this tutorial, you should clean up by
603
+ terminating the instance. If you want to do more with this instance before you clean up, see Next
604
+ steps.
605
+
606
+ Important
607
+ Terminating an instance effectively deletes it; you can't reconnect to an instance after
608
+ you've terminated it.
609
+
610
+ You'll stop incurring charges for that instance or usage that counts against your Free Tier limits as
611
+ soon as the instance status changes to shutting down or terminated. To keep your instance
612
+ for later, but not incur charges or usage that counts against your Free Tier limits, you can stop the
613
+ instance now and then start it again later. For more information, see Stop and start Amazon EC2
614
+ instances.
615
+ To terminate your instance
616
+ 1.
617
+
618
+ In the navigation pane, choose Instances. In the list of instances, select the instance.
619
+
620
+ 2.
621
+
622
+ Choose Instance state, Terminate (delete) instance.
623
+
624
+ Step 3: Clean up your instance
625
+
626
+ 15
627
+
628
+ Amazon Elastic Compute Cloud
629
+
630
+ 3.
631
+
632
+ User Guide
633
+
634
+ Choose Terminate (delete) when prompted for confirmation.
635
+ Amazon EC2 shuts down and terminates your instance. After your instance is terminated, it
636
+ remains visible on the console for a short while, and then the entry is automatically deleted.
637
+ You cannot remove the terminated instance from the console display yourself.
638
+
639
+ Next steps
640
+ After you start your instance, you might want to explore the following next steps:
641
+ • Explore the Amazon EC2 core concepts with the introductory tutorials. For more information, see
642
+ Tutorials for launching EC2 instances.
643
+ • Learn how to track your Amazon EC2 Free Tier usage using the console. For more information,
644
+ see the section called “Track your Free Tier usage”.
645
+ • Configure a CloudWatch alarm to notify you if your usage exceeds the Free Tier (for accounts
646
+ created before July 15, 2025). For more information, see Tracking your AWS Free Tier usage in
647
+ the AWS Billing User Guide.
648
+ • Add an EBS volume. For more information, see Create an Amazon EBS volume in the Amazon EBS
649
+ User Guide.
650
+ • Learn how to remotely manage your EC2 instance using the Run command. For more
651
+ information, see AWS Systems Manager Run Command in the AWS Systems Manager User Guide.
652
+ • Learn about instance purchasing options. For more information, see Amazon EC2 billing and
653
+ purchasing options.
654
+ • Get advice about instance types. For more information, see Get recommendations from EC2
655
+ instance type finder.
656
+
657
+ Next steps
658
+
659
+ 16
660
+
661
+ Amazon Elastic Compute Cloud
662
+
663
+ User Guide
664
+
665
+ Best practices for Amazon EC2
666
+ To ensure the maximum benefit from Amazon EC2, we recommend that you perform the following
667
+ best practices.
668
+ Security
669
+ • Manage access to AWS resources and APIs using identity federation with an identity provider and
670
+ IAM roles whenever possible. For more information, see Creating IAM policies in the IAM User
671
+ Guide.
672
+ • Implement the least permissive rules for your security group.
673
+ • Regularly patch, update, and secure the operating system and applications on your instance.
674
+ For more information, see Update management. For guidelines specific to Windows operating
675
+ systems, see Security best practices for Windows instances.
676
+ • Use Amazon Inspector to automatically discover and scan Amazon EC2 instances for software
677
+ vulnerabilities and unintended network exposure. For more information, see the Amazon
678
+ Inspector User Guide.
679
+ • Use AWS Security Hub controls to monitor your Amazon EC2 resources against security best
680
+ practices and security standards. For more information about using Security Hub, see Amazon
681
+ Elastic Compute Cloud controls in the AWS Security Hub User Guide.
682
+ Storage
683
+ • Understand the implications of the root device type for data persistence, backup, and recovery.
684
+ For more information, see Root device type.
685
+ • Use separate Amazon EBS volumes for the operating system versus your data. Ensure that the
686
+ volume with your data persists after instance termination. For more information, see Preserve
687
+ data when an instance is terminated.
688
+ • Use the instance store available for your instance to store temporary data. Remember that the
689
+ data stored in instance store is deleted when you stop, hibernate, or terminate your instance.
690
+ If you use instance store for database storage, ensure that you have a cluster with a replication
691
+ factor that ensures fault tolerance.
692
+ • Encrypt EBS volumes and snapshots. For more information, see Amazon EBS encryption in the
693
+ Amazon EBS User Guide.
694
+ 17
695
+
696
+ Amazon Elastic Compute Cloud
697
+
698
+ User Guide
699
+
700
+ Resource management
701
+ • Use instance metadata and custom resource tags to track and identify your AWS resources.
702
+ For more information, see Use instance metadata to manage your EC2 instance and Tag your
703
+ Amazon EC2 resources.
704
+ • View your current limits for Amazon EC2. Plan to request any limit increases in advance of the
705
+ time that you'll need them. For more information, see Amazon EC2 service quotas.
706
+ • Use AWS Trusted Advisor to inspect your AWS environment, and then make recommendations
707
+ when opportunities exist to save money, improve system availability and performance, or help
708
+ close security gaps. For more information, see AWS Trusted Advisor in the AWS Support User
709
+ Guide.
710
+ Backup and recovery
711
+ • Regularly back up your EBS volumes using Amazon EBS snapshots, and create an Amazon
712
+ Machine Image (AMI) from your instance to save the configuration as a template for launching
713
+ future instances. For more information about AWS services that help achieve this use case, see
714
+ AWS Backup and Amazon Data Lifecycle Manager.
715
+ • Deploy critical components of your application across multiple Availability Zones, and replicate
716
+ your data appropriately.
717
+ • Design your applications to handle dynamic IP addressing when your instance restarts. For more
718
+ information, see Amazon EC2 instance IP addressing.
719
+ • Monitor and respond to events. For more information, see Monitor Amazon EC2 resources.
720
+ • Ensure that you are prepared to handle failover. For a basic solution, you can manually attach
721
+ a network interface or Elastic IP address to a replacement instance. For more information, see
722
+ Elastic network interfaces. For an automated solution, you can use Amazon EC2 Auto Scaling. For
723
+ more information, see the Amazon EC2 Auto Scaling User Guide.
724
+ • Regularly test the process of recovering your instances and Amazon EBS volumes to ensure data
725
+ and services are restored successfully.
726
+ Networking
727
+ • Set the time-to-live (TTL) value for your applications to 255, for IPv4 and IPv6. If you use a
728
+ smaller value, there is a risk that the TTL will expire while application traffic is in transit, causing
729
+ reachability issues for your instances.
730
+
731
+ 18
732
+
733
+ Amazon Elastic Compute Cloud
734
+
735
+ User Guide
736
+
737
+ Amazon Machine Images in Amazon EC2
738
+ An Amazon Machine Image (AMI) is an image that provides the software that is required to set up
739
+ and boot an Amazon EC2 instance. Each AMI also contains a block device mapping that specifies
740
+ the block devices to attach to the instances that you launch. You must specify an AMI when you
741
+ launch an instance. The AMI must be compatible with the instance type that you chose for your
742
+ instance. You can use an AMI provided by AWS, a public AMI, an AMI that someone else shared with
743
+ you, or an AMI that you purchased from the AWS Marketplace.
744
+ An AMI is specific to the following:
745
+ • Region
746
+ • Operating system
747
+ • Processor architecture
748
+ • Root device type
749
+ • Virtualization type
750
+ You can launch multiple instances from a single AMI when you require multiple instances with the
751
+ same configuration. You can use different AMIs to launch instances when you require instances
752
+ with different configurations, as shown in the following diagram.
753
+
754
+ 19
755
+
756
+ Amazon Elastic Compute Cloud
757
+
758
+ User Guide
759
+
760
+ You can create an AMI from your Amazon EC2 instances and then use it to launch instances with
761
+ the same configuration. You can copy an AMI to another AWS Region, and then use it to launch
762
+ instances in that Region. You can also share an AMI that you created with other accounts so that
763
+ they can launch instances with the same configuration. You can sell your AMI using the AWS
764
+ Marketplace.
765
+ Contents
766
+ • AMI types and characteristics in Amazon EC2
767
+ • Find an AMI that meets the requirements for your EC2 instance
768
+ • Paid AMIs in the AWS Marketplace for Amazon EC2 instances
769
+ • Amazon EC2 AMI lifecycle
770
+ • Instance launch behavior with Amazon EC2 boot modes
771
+ • Use encryption with EBS-backed AMIs
772
+ • Understand shared AMI usage in Amazon EC2
773
+ • Monitor AMI events using Amazon EventBridge
774
+ • Understand AMI billing information
775
+ • AMI quotas in Amazon EC2
776
+ 20
777
+
778
+
dataset/docs/ecs-dg.txt ADDED
@@ -0,0 +1,851 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ Amazon Elastic Container Service
2
+
3
+ Developer Guide
4
+
5
+ What is Amazon Elastic Container Service?
6
+ Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service
7
+ that helps you easily deploy, manage, and scale containerized applications. As a fully managed
8
+ service, Amazon ECS comes with AWS configuration and operational best practices built-in. It's
9
+ integrated with both AWS tools, such as Amazon Elastic Container Registry, and third-party tools,
10
+ such as Docker. This integration makes it easier for teams to focus on building the applications, not
11
+ the environment. You can run and scale your container workloads across AWS Regions in the cloud,
12
+ and on-premises, without the complexity of managing a control plane.
13
+
14
+ Terminology and components
15
+ There are three layers in Amazon ECS:
16
+ • Capacity - The infrastructure where your containers run
17
+ • Controller - Deploy and manage your applications that run on the containers
18
+ • Provisioning - The tools that you can use to interface with the scheduler to deploy and manage
19
+ your applications and containers
20
+ The following diagram shows the Amazon ECS layers.
21
+
22
+ Terminology and components
23
+
24
+ 1
25
+
26
+ Amazon Elastic Container Service
27
+
28
+ Developer Guide
29
+
30
+ The capacity is the infrastructure where your containers run. The following is an overview of the
31
+ capacity options:
32
+ • Amazon EC2 instances in the AWS cloud
33
+ You choose the instance type, the number of instances, and manage the capacity.
34
+ • Serverless (AWS Fargate) in the AWS cloud
35
+ Fargate is a serverless, pay-as-you-go compute engine. With Fargate you don't need to manage
36
+ servers, handle capacity planning, or isolate container workloads for security.
37
+ • On-premises virtual machines (VM) or servers
38
+ Amazon ECS Anywhere provides support for registering an external instance such as an onpremises server or virtual machine (VM), to your Amazon ECS cluster.
39
+ The Amazon ECS scheduler is the software that manages your applications.
40
+ Terminology and components
41
+
42
+ 2
43
+
44
+ Amazon Elastic Container Service
45
+
46
+ Developer Guide
47
+
48
+ Features
49
+ Amazon ECS provides the following high-level features:
50
+ Task definition
51
+ The blueprint for the application.
52
+ Cluster
53
+ The infrastructure your application runs on.
54
+ Task
55
+ An application such as a batch job that performs work, and then stops.
56
+ Service
57
+ A long running stateless application.
58
+ Account Setting
59
+ Allows access to features.
60
+ Cluster Auto Scaling
61
+ Amazon ECS manages the scaling of Amazon EC2 instances that are registered to your cluster.
62
+ Service Auto Scaling
63
+ Amazon ECS increases or decreases the desired number of tasks in your service automatically.
64
+
65
+ Provisioning
66
+ There are multiple options for provisioning Amazon ECS:
67
+ • AWS Management Console — Provides a web interface that you can use to access your Amazon
68
+ ECS resources.
69
+ • AWS Command Line Interface (AWS CLI) — Provides commands for a broad set of AWS services,
70
+ including Amazon ECS. It's supported on Windows, Mac, and Linux. For more information, see
71
+ AWS Command Line Interface.
72
+ • AWS SDKs — Provides language-specific APIs and takes care of many of the connection details.
73
+ These include calculating signatures, handling request retries, and error handling. For more
74
+ information, see AWS SDKs.
75
+ Features
76
+
77
+ 3
78
+
79
+ Amazon Elastic Container Service
80
+
81
+ Developer Guide
82
+
83
+ • AWS CDK — Provides an open-source software development framework that you can
84
+ use to model and provision your cloud application resources using familiar programming
85
+ languages. The AWS CDK provisions your resources in a safe, repeatable manner through AWS
86
+ CloudFormation.
87
+
88
+ Pricing
89
+ Amazon ECS pricing depends on the capacity option you choose for your containers.
90
+ • Amazon ECS pricing – Pricing information for Amazon ECS.
91
+ • AWS Fargate pricing – Pricing information for Fargate.
92
+
93
+ Related services
94
+ Services to use with Amazon ECS
95
+ You can use other AWS services to help you deploy yours tasks and services on Amazon ECS.
96
+ Amazon EC2 Auto Scaling
97
+ Helps ensure you have the correct number of Amazon EC2 instances available to handle the
98
+ load for your application.
99
+ Amazon CloudWatch
100
+ Monitor your services and tasks.
101
+ Amazon Elastic Container Registry
102
+ Store and manage container images.
103
+ Elastic Load Balancing
104
+ Automatically distribute incoming service traffic.
105
+ Amazon GuardDuty
106
+ Detect potentially unauthorized or malicious use of your container instances and workloads.
107
+
108
+ Pricing
109
+
110
+ 4
111
+
112
+ Amazon Elastic Container Service
113
+
114
+ Developer Guide
115
+
116
+ Learn how to create and use Amazon ECS resources
117
+ The following guides provide an introduction to the tools available to access Amazon ECS and
118
+ introductory procedures to run containers. Docker basics takes you through the basic steps to
119
+ create a Docker container image and upload it to an Amazon ECR private repository. The getting
120
+ started guides walk you through using the AWS Copilot command line interface and the AWS
121
+ Management Console to complete the common tasks to run your containers on Amazon ECS and
122
+ AWS Fargate.
123
+ Contents
124
+ • Set up to use Amazon ECS
125
+ • Creating a container image for use on Amazon ECS
126
+ • Learn how to create an Amazon ECS Linux task for the Fargate launch type
127
+ • Learn how to create an Amazon ECS Windows task for the Fargate launch type
128
+ • Learn how to create an Amazon ECS Windows task for the EC2 launch type
129
+ • Creating Amazon ECS resources using the AWS CDK
130
+ • Creating Amazon ECS resources using the AWS Copilot command line interface
131
+
132
+ Set up to use Amazon ECS
133
+ If you've already signed up for Amazon Web Services (AWS) and have been using Amazon Elastic
134
+ Compute Cloud (Amazon EC2), you are close to being able to use Amazon ECS. The set-up process
135
+ for the two services is similar. The following guide prepares you for launching your first Amazon
136
+ ECS cluster.
137
+ Complete the following tasks to get set up for Amazon ECS.
138
+
139
+ AWS Management Console
140
+ The AWS Management Console is a browser-based interface for managing Amazon ECS resources.
141
+ The console provides a visual overview of the service, making it easy to explore Amazon ECS
142
+ features and functions without needing to use additional tools. Many related tutorials and
143
+ walkthroughs are available that can guide you through use of the console.
144
+ For a tutorial that guides you through the console, see Learn how to create and use Amazon ECS
145
+ resources.
146
+ Set up
147
+
148
+ 5
149
+
150
+ Amazon Elastic Container Service
151
+
152
+ Developer Guide
153
+
154
+ When starting out, many customers prefer using the console because it provides instant visual
155
+ feedback on whether the actions they take succeed. AWS customers that are familiar with the AWS
156
+ Management Console, can easily manage related resources such as load balancers and Amazon EC2
157
+ instances.
158
+ Start with the AWS Management Console.
159
+
160
+ Sign up for an AWS account
161
+ If you do not have an AWS account, complete the following steps to create one.
162
+ To sign up for an AWS account
163
+ 1.
164
+
165
+ Open https://portal.aws.amazon.com/billing/signup.
166
+
167
+ 2.
168
+
169
+ Follow the online instructions.
170
+ Part of the sign-up procedure involves receiving a phone call or text message and entering a
171
+ verification code on the phone keypad.
172
+ When you sign up for an AWS account, an AWS account root user is created. The root user
173
+ has access to all AWS services and resources in the account. As a security best practice, assign
174
+ administrative access to a user, and use only the root user to perform tasks that require root
175
+ user access.
176
+
177
+ AWS sends you a confirmation email after the sign-up process is complete. At any time, you can
178
+ view your current account activity and manage your account by going to https://aws.amazon.com/
179
+ and choosing My Account.
180
+
181
+ Create a user with administrative access
182
+ After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity
183
+ Center, and create an administrative user so that you don't use the root user for everyday tasks.
184
+ Secure your AWS account root user
185
+ 1.
186
+
187
+ Sign in to the AWS Management Console as the account owner by choosing Root user and
188
+ entering your AWS account email address. On the next page, enter your password.
189
+ For help signing in by using root user, see Signing in as the root user in the AWS Sign-In User
190
+ Guide.
191
+
192
+ Sign up for an AWS account
193
+
194
+ 6
195
+
196
+ Amazon Elastic Container Service
197
+
198
+ 2.
199
+
200
+ Developer Guide
201
+
202
+ Turn on multi-factor authentication (MFA) for your root user.
203
+ For instructions, see Enable a virtual MFA device for your AWS account root user (console) in
204
+ the IAM User Guide.
205
+
206
+ Create a user with administrative access
207
+ 1.
208
+
209
+ Enable IAM Identity Center.
210
+ For instructions, see Enabling AWS IAM Identity Center in the AWS IAM Identity Center User
211
+ Guide.
212
+
213
+ 2.
214
+
215
+ In IAM Identity Center, grant administrative access to a user.
216
+ For a tutorial about using the IAM Identity Center directory as your identity source, see
217
+ Configure user access with the default IAM Identity Center directory in the AWS IAM Identity
218
+ Center User Guide.
219
+
220
+ Sign in as the user with administrative access
221
+
222
+
223
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email
224
+ address when you created the IAM Identity Center user.
225
+ For help signing in using an IAM Identity Center user, see Signing in to the AWS access portal in
226
+ the AWS Sign-In User Guide.
227
+
228
+ Assign access to additional users
229
+ 1.
230
+
231
+ In IAM Identity Center, create a permission set that follows the best practice of applying leastprivilege permissions.
232
+ For instructions, see Create a permission set in the AWS IAM Identity Center User Guide.
233
+
234
+ 2.
235
+
236
+ Assign users to a group, and then assign single sign-on access to the group.
237
+ For instructions, see Add groups in the AWS IAM Identity Center User Guide.
238
+
239
+ Create a user with administrative access
240
+
241
+ 7
242
+
243
+ Amazon Elastic Container Service
244
+
245
+ Developer Guide
246
+
247
+ Create a virtual private cloud
248
+ You can use Amazon Virtual Private Cloud (Amazon VPC) to launch AWS resources into a virtual
249
+ network that you've defined. We strongly suggest that you launch your container instances in a
250
+ VPC.
251
+ If you have a default VPC, you can skip this section and move to the next task, Create a security
252
+ group. To determine whether you have a default VPC, see Work with your default VPC and default
253
+ subnets in the Amazon VPC User Guide. Otherwise, you can create a nondefault VPC in your account
254
+ using the steps below.
255
+ For information about how to create a VPC, see Create a VPC in the Amazon VPC User Guide, and
256
+ use the following table to determine what options to select.
257
+
258
+ Option
259
+
260
+ Value
261
+
262
+ Resources to create
263
+
264
+ VPC only
265
+
266
+ Name
267
+
268
+ Optionally provide a name for
269
+ your VPC.
270
+
271
+ IPv4 CIDR block
272
+
273
+ IPv4 CIDR manual input
274
+ The CIDR block size must
275
+ have a size between /16
276
+ and /28.
277
+
278
+ IPv6 CIDR block
279
+
280
+ No IPv6 CIDR block
281
+
282
+ Tenancy
283
+
284
+ Default
285
+
286
+ For more information about Amazon VPC, see What is Amazon VPC? in the Amazon VPC User Guide.
287
+
288
+ Create a security group
289
+ Security groups act as a firewall for associated container instances, controlling both inbound
290
+ and outbound traffic at the container instance level. You can add rules to a security group that
291
+ enable you to connect to your container instance from your IP address using SSH. You can also add
292
+ Create a virtual private cloud
293
+
294
+ 8
295
+
296
+ Amazon Elastic Container Service
297
+
298
+ Developer Guide
299
+
300
+ rules that allow inbound and outbound HTTP and HTTPS access from anywhere. Add any rules to
301
+ open ports that are required by your tasks. Container instances require external network access to
302
+ communicate with the Amazon ECS service endpoint.
303
+ If you plan to launch container instances in multiple Regions, you need to create a security group
304
+ in each Region. For more information, see Regions and Availability Zones in the Amazon EC2 User
305
+ Guide.
306
+ Tip
307
+ You need the public IP address of your local computer, which you can get using a service.
308
+ For example, we provide the following service: http://checkip.amazonaws.com/ or https://
309
+ checkip.amazonaws.com/. To locate another service that provides your IP address, use the
310
+ search phrase "what is my IP address." If you are connecting through an internet service
311
+ provider (ISP) or from behind a firewall without a static IP address, you must find out the
312
+ range of IP addresses used by client computers.
313
+
314
+ For information about how to create a security group, see Create a security group for your Amazon
315
+ EC2 instance in the Amazon EC2 User Guide and use the following table to determine what options
316
+ to select.
317
+ Option
318
+
319
+ Value
320
+
321
+ Region
322
+
323
+ The same Region in which you
324
+ created your key pair.
325
+
326
+ Name
327
+
328
+ A name that is easy for you to
329
+ remember, such as ecs-insta
330
+ nces-default-cluster.
331
+
332
+ VPC
333
+
334
+ The default VPC (marked with
335
+ "(default)").
336
+ Note
337
+ If your account
338
+ supports Amazon EC2
339
+ Classic, select the VPC
340
+
341
+ Create a security group
342
+
343
+ 9
344
+
345
+ Amazon Elastic Container Service
346
+
347
+ Option
348
+
349
+ Developer Guide
350
+
351
+ Value
352
+ that you created in
353
+ the previous task.
354
+
355
+ For information about the outbound rules to add for your use cases, see Security group rules for
356
+ different use cases in the Amazon EC2 User Guide.
357
+ Amazon ECS container instances do not require any inbound ports to be open. However, you might
358
+ want to add an SSH rule so you can log into the container instance and examine the tasks with
359
+ Docker commands. You can also add rules for HTTP and HTTPS if you want your container instance
360
+ to host a task that runs a web server. Container instances do require external network access to
361
+ communicate with the Amazon ECS service endpoint. Complete the following steps to add these
362
+ optional security group rules.
363
+ Add the following three inbound rules to your security group.For information about how to create
364
+ a security group, see Configure security group rules in the Amazon EC2 User Guide.
365
+
366
+ Option
367
+
368
+ Value
369
+
370
+ HTTP rule
371
+
372
+ Type: HTTP
373
+ Source: Anywhere
374
+ (0.0.0.0/0 )
375
+ This option automatically
376
+ adds the 0.0.0.0/0 IPv4 CIDR
377
+ block as the source. This is
378
+ acceptable for a short time
379
+ in a test environment, but
380
+ it's unsafe in production
381
+ environments. In production,
382
+ authorize only a specific IP
383
+ address or range of addresses
384
+ to access your instance.
385
+
386
+ HTTPS rule
387
+ Create a security group
388
+
389
+ Type: HTTPS
390
+ 10
391
+
392
+ Amazon Elastic Container Service
393
+
394
+ Option
395
+
396
+ Developer Guide
397
+
398
+ Value
399
+ Source: Anywhere
400
+ (0.0.0.0/0 )
401
+ This is acceptable for a short
402
+ time in a test environment,
403
+ but it's unsafe in productio
404
+ n environments. In productio
405
+ n, authorize only a specific IP
406
+ address or range of addresses
407
+ to access your instance.
408
+
409
+ Create a security group
410
+
411
+ 11
412
+
413
+ Amazon Elastic Container Service
414
+
415
+ Developer Guide
416
+
417
+ Option
418
+
419
+ Value
420
+
421
+ SSH rule
422
+
423
+ Type: SSH
424
+ Source: Custom, specify the
425
+ public IP address of your
426
+ computer or network in
427
+ CIDR notation. To specify an
428
+ individual IP address in CIDR
429
+ notation, add the routing
430
+ prefix /32. For example, if
431
+ your IP address is 203.0.113
432
+ .25 , specify 203.0.113
433
+ .25/32 . If your company
434
+ allocates addresses from
435
+ a range, specify the entire
436
+ range, such as 203.0.113
437
+ .0/24 .
438
+ Important
439
+ For security reasons,
440
+ we don't recommend
441
+ that you allow
442
+ SSH access from
443
+ all IP addresses
444
+ (0.0.0.0/0 ) to
445
+ your instance, except
446
+ for testing purposes
447
+ and only for a short
448
+ time.
449
+
450
+ Create the credentials to connect to your EC2 instance
451
+ For Amazon ECS, a key pair is only needed if you intend on using the EC2 launch type.
452
+
453
+ Create the credentials to connect to your EC2 instance
454
+
455
+ 12
456
+
457
+ Amazon Elastic Container Service
458
+
459
+ Developer Guide
460
+
461
+ AWS uses public-key cryptography to secure the login information for your instance. A Linux
462
+ instance, such as an Amazon ECS container instance, has no password to use for SSH access. You
463
+ use a key pair to log in to your instance securely. You specify the name of the key pair when you
464
+ launch your container instance, then provide the private key when you log in using SSH.
465
+ If you haven't created a key pair already, you can create one using the Amazon EC2 console. If you
466
+ plan to launch instances in multiple regions, you'll need to create a key pair in each region. For
467
+ more information about regions, see Regions and Availability Zones in the Amazon EC2 User Guide.
468
+ To create a key pair
469
+
470
+
471
+ Use the Amazon EC2 console to create a key pair. For more information about creating a key
472
+ pair, see Create a key pair in the Amazon EC2 User Guide.
473
+
474
+ For information about how to connect to your instance, see Connect to your Linux instance in the
475
+ Amazon EC2 User Guide.
476
+
477
+ Install the AWS CLI
478
+ The AWS Management Console can be used to manage all operations manually with Amazon ECS.
479
+ However, you can install the AWS CLI on your local desktop or a developer box so that you can
480
+ build scripts that can automate common management tasks in Amazon ECS.
481
+ To use the AWS CLI with Amazon ECS, install the latest AWS CLI version. For information about
482
+ installing the AWS CLI or upgrading it to the latest version, see Installing or updating to the latest
483
+ version of the AWS CLI in the AWS Command Line Interface User Guide.
484
+ The AWS Command Line Interface (AWS CLI) is a unified tool that you can use to manage your AWS
485
+ services. With this one tool alone, you can both control multiple AWS services and automate these
486
+ services through scripts. The Amazon ECS commands in the AWS CLI are a reflection of the Amazon
487
+ ECS API.
488
+ The AWS CLI is suitable for customers who prefer and are used to scripting and interfacing with
489
+ a command line tool and know exactly which actions they want to perform on their Amazon ECS
490
+ resources. The AWS CLI is also helpful to customers who want to familiarize themselves with the
491
+ Amazon ECS APIs. Customers can use the AWS CLI to perform a number of operations on Amazon
492
+ ECS resources, including Create, Read, Update, and Delete operations, directly from the command
493
+ line interface.
494
+ Install the AWS CLI
495
+
496
+ 13
497
+
498
+ Amazon Elastic Container Service
499
+
500
+ Developer Guide
501
+
502
+ Use the AWS CLI if you are or want to become familiar with the Amazon ECS APIs and
503
+ corresponding CLI commands and want to write automated scripts and perform specific actions on
504
+ Amazon ECS resources.
505
+ AWS also provides the command line tools AWS Tools for Windows PowerShell. For more
506
+ information, see the AWS Tools for Windows PowerShell User Guide.
507
+
508
+ Next steps for using Amazon ECS
509
+ After installing the AWS CLI, there are many different tools you can utilize as you continue to use
510
+ Amazon ECS. The following links explain what some of those tools are and give examples of how to
511
+ use them with Amazon ECS.
512
+ • Create your first container image with Docker and push it to Amazon ECR for use in your Amazon
513
+ ECS task definitions.
514
+ • Learn how to create an Amazon ECS Linux task for the Fargate launch type.
515
+ • Learn how to create an Amazon ECS Windows task for the Fargate launch type.
516
+ • Learn how to create an Amazon ECS Windows task for the EC2 launch type.
517
+ • Using your preferred programming language, define infrastructure or architecture as code with
518
+ the Creating Amazon ECS resources using the AWS CDK.
519
+ • Define and manage all AWS resources in your environment with automated deployment using
520
+ Using Amazon ECS with AWS CloudFormation.
521
+ • Use the complete Creating Amazon ECS resources using the AWS Copilot command line interface
522
+ end-to-end developer workflow to create, release, and operate container applications that
523
+ comply with AWS best practices for infrastructure.
524
+
525
+ Creating a container image for use on Amazon ECS
526
+ Amazon ECS uses Docker images in task definitions to launch containers. Docker is a technology
527
+ that provides the tools for you to build, run, test, and deploy distributed applications in containers.
528
+ Amazon ECS schedules containerized applications on to container instances or on to AWS Fargate.
529
+ Containerized applications are packaged as container images. This example creates a container
530
+ image for a web server.
531
+ You can create your first Docker image, and then push that image to Amazon ECR, which is a
532
+ container registry, for use in your Amazon ECS task definitions. This walkthrough assumes that you
533
+ Next steps for using Amazon ECS
534
+
535
+ 14
536
+
537
+ Amazon Elastic Container Service
538
+
539
+ Developer Guide
540
+
541
+ possess a basic understanding of what Docker is and how it works. For more information about
542
+ Docker, see What is Docker? and the Docker documentation.
543
+
544
+ Prerequisites
545
+ Before you begin, ensure the following prerequisites are met.
546
+ • Ensure you have completed the Amazon ECR setup steps. For more information, see Moving an
547
+ image through its lifecycle in Amazon ECR in the Amazon Elastic Container Registry User Guide.
548
+ • Your user has the required IAM permissions to access and use the Amazon ECR service. For more
549
+ information, see Amazon ECR managed policies.
550
+ • You have Docker installed. For Docker installation steps for Amazon Linux 2023, see Installing
551
+ Docker on AL2023. For all other operating systems, see the Docker documentation at Docker
552
+ Desktop overview.
553
+ • You have the AWS CLI installed and configured. For more information, see Installing or updating
554
+ to the latest version of the AWS CLI in the AWS Command Line Interface User Guide.
555
+ If you don't have or need a local development environment and you prefer to use an Amazon EC2
556
+ instance to use Docker, we provide the following steps to launch an Amazon EC2 instance using
557
+ Amazon Linux 2023 and install Docker Engine and the Docker CLI.
558
+ Installing Docker on AL2023
559
+ Docker is available on many different operating systems, including most modern Linux
560
+ distributions, like Ubuntu, and even macOS and Windows. For more information about how to
561
+ install Docker on your particular operating system, go to the Docker installation guide.
562
+ You do not need a local development system to use Docker. If you are using Amazon EC2 already,
563
+ you can launch an Amazon Linux 2023 instance and install Docker to get started.
564
+ If you already have Docker installed, skip to Create a Docker image.
565
+ To install Docker on an Amazon EC2 instance using an Amazon Linux 2023 AMI
566
+ 1.
567
+
568
+ Launch an instance with the latest Amazon Linux 2023 AMI. For more information, see Launch
569
+ an EC2 instance using the launch instance wizard in the console in the Amazon EC2 User Guide.
570
+
571
+ 2.
572
+
573
+ Connect to your instance. For more information, see Connect to your EC2 instance in the
574
+ Amazon EC2 User Guide.
575
+
576
+ 3.
577
+
578
+ Update the installed packages and package cache on your instance.
579
+
580
+ Prerequisites
581
+
582
+ 15
583
+
584
+ Amazon Elastic Container Service
585
+
586
+ Developer Guide
587
+
588
+ sudo yum update -y
589
+
590
+ 4.
591
+
592
+ Install the most recent Docker Community Edition package.
593
+ sudo yum install docker
594
+
595
+ 5.
596
+
597
+ Start the Docker service.
598
+ sudo service docker start
599
+
600
+ 6.
601
+
602
+ Add the ec2-user to the docker group so you can execute Docker commands without using
603
+ sudo.
604
+ sudo usermod -a -G docker ec2-user
605
+
606
+ 7.
607
+
608
+ Log out and log back in again to pick up the new docker group permissions. You can
609
+ accomplish this by closing your current SSH terminal window and reconnecting to your
610
+ instance in a new one. Your new SSH session will have the appropriate docker group
611
+ permissions.
612
+
613
+ 8.
614
+
615
+ Verify that the ec2-user can run Docker commands without sudo.
616
+ docker info
617
+
618
+ Note
619
+ In some cases, you may need to reboot your instance to provide permissions for the
620
+ ec2-user to access the Docker daemon. Try rebooting your instance if you see the
621
+ following error:
622
+ Cannot connect to the Docker daemon. Is the docker daemon running on this
623
+ host?
624
+
625
+ Create a Docker image
626
+ Amazon ECS task definitions use container images to launch containers on the container instances
627
+ in your clusters. In this section, you create a Docker image of a simple web application, and test
628
+ Create a Docker image
629
+
630
+ 16
631
+
632
+ Amazon Elastic Container Service
633
+
634
+ Developer Guide
635
+
636
+ it on your local system or Amazon EC2 instance, and then push the image to the Amazon ECR
637
+ container registry so you can use it in an Amazon ECS task definition.
638
+ To create a Docker image of a simple web application
639
+ 1.
640
+
641
+ Create a file called Dockerfile. A Dockerfile is a manifest that describes the base image
642
+ to use for your Docker image and what you want installed and running on it. For more
643
+ information about Dockerfiles, go to the Dockerfile Reference.
644
+ touch Dockerfile
645
+
646
+ 2.
647
+
648
+ Edit the Dockerfile you just created and add the following content.
649
+ FROM public.ecr.aws/amazonlinux/amazonlinux:latest
650
+ # Update installed packages and install Apache
651
+ RUN yum update -y && \
652
+ yum install -y httpd
653
+ # Write hello world message
654
+ RUN echo 'Hello World!' > /var/www/html/index.html
655
+ # Configure Apache
656
+ RUN echo 'mkdir -p /var/run/httpd' >> /root/run_apache.sh && \
657
+ echo 'mkdir -p /var/lock/httpd' >> /root/run_apache.sh && \
658
+ echo '/usr/sbin/httpd -D FOREGROUND' >> /root/run_apache.sh && \
659
+ chmod 755 /root/run_apache.sh
660
+ EXPOSE 80
661
+ CMD /root/run_apache.sh
662
+
663
+ This Dockerfile uses the public Amazon Linux 2023 image hosted on Amazon ECR Public.
664
+ The RUN instructions update the package caches, installs some software packages for the
665
+ web server, and then write the "Hello World!" content to the web servers document root. The
666
+ EXPOSE instruction means that port 80 on the container is the one that is listening, and the
667
+ CMD instruction starts the web server.
668
+ 3.
669
+
670
+ Build the Docker image from your Dockerfile.
671
+
672
+ Create a Docker image
673
+
674
+ 17
675
+
676
+ Amazon Elastic Container Service
677
+
678
+ Developer Guide
679
+
680
+ Note
681
+ Some versions of Docker may require the full path to your Dockerfile in the following
682
+ command, instead of the relative path shown below.
683
+ If you run the command an ARM based system, such as Apple Silicon, use the -platform option "--platform linux/amd64".
684
+
685
+ docker build -t hello-world .
686
+
687
+ 4.
688
+
689
+ List your container image.
690
+ docker images --filter reference=hello-world
691
+
692
+ Output:
693
+ REPOSITORY
694
+ SIZE
695
+ hello-world
696
+ 194MB
697
+
698
+ 5.
699
+
700
+ TAG
701
+
702
+ IMAGE ID
703
+
704
+ CREATED
705
+
706
+ latest
707
+
708
+ e9ffedc8c286
709
+
710
+ 4 minutes ago
711
+
712
+ Run the newly built image. The -p 80:80 option maps the exposed port 80 on the container
713
+ to port 80 on the host system.
714
+ docker run -t -i -p 80:80 hello-world
715
+
716
+ Note
717
+ Output from the Apache web server is displayed in the terminal window. You can
718
+ ignore the "Could not reliably determine the fully qualified domain
719
+ name" message.
720
+ 6.
721
+
722
+ Open a browser and point to the server that is running Docker and hosting your container.
723
+ • If you are using an EC2 instance, this is the Public DNS value for the server, which is the
724
+ same address you use to connect to the instance with SSH. Make sure that the security group
725
+ for your instance allows inbound traffic on port 80.
726
+
727
+ Create a Docker image
728
+
729
+ 18
730
+
731
+ Amazon Elastic Container Service
732
+
733
+ Developer Guide
734
+
735
+ • If you are running Docker locally, point your browser to http://localhost/.
736
+ You should see a web page with your "Hello World!" statement.
737
+ 7.
738
+
739
+ Stop the Docker container by typing Ctrl + c.
740
+
741
+ Push your image to Amazon Elastic Container Registry
742
+ Amazon ECR is a managed AWS managed image registry service. You can use the Docker CLI to
743
+ push, pull, and manage images in your Amazon ECR repositories. For Amazon ECR product details,
744
+ featured customer case studies, and FAQs, see the Amazon Elastic Container Registry product detail
745
+ pages.
746
+ To tag your image and push it to Amazon ECR
747
+ 1.
748
+
749
+ Create an Amazon ECR repository to store your hello-world image. Note the
750
+ repositoryUri in the output.
751
+ Substitute region, with your AWS Region, for example, us-east-1.
752
+ aws ecr create-repository --repository-name hello-repository --region region
753
+
754
+ Output:
755
+ {
756
+ "repository": {
757
+ "registryId": "aws_account_id",
758
+ "repositoryName": "hello-repository",
759
+ "repositoryArn": "arn:aws:ecr:region:aws_account_id:repository/hellorepository",
760
+ "createdAt": 1505337806.0,
761
+ "repositoryUri": "aws_account_id.dkr.ecr.region.amazonaws.com/hellorepository"
762
+ }
763
+ }
764
+
765
+ 2.
766
+
767
+ Tag the hello-world image with the repositoryUri value from the previous step.
768
+ docker tag hello-world aws_account_id.dkr.ecr.region.amazonaws.com/hello-repository
769
+
770
+ Push your image to Amazon Elastic Container Registry
771
+
772
+ 19
773
+
774
+ Amazon Elastic Container Service
775
+
776
+ 3.
777
+
778
+ Developer Guide
779
+
780
+ Run the aws ecr get-login-password command. Specify the registry URI you want to
781
+ authenticate to. For more information, see Registry Authentication in the Amazon Elastic
782
+ Container Registry User Guide.
783
+ aws ecr get-login-password --region region | docker login --username AWS -password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
784
+
785
+ Output:
786
+ Login Succeeded
787
+
788
+ Important
789
+ If you receive an error, install or upgrade to the latest version of the AWS CLI. For more
790
+ information, see Installing or updating to the latest version of the AWS CLI in the AWS
791
+ Command Line Interface User Guide.
792
+ 4.
793
+
794
+ Push the image to Amazon ECR with the repositoryUri value from the earlier step.
795
+ docker push aws_account_id.dkr.ecr.region.amazonaws.com/hello-repository
796
+
797
+ Clean up
798
+ To continue on with creating an Amazon ECS task definition and launching a task with your
799
+ container image, skip to the Next steps. When you are done experimenting with your Amazon ECR
800
+ image, you can delete the repository so you are not charged for image storage.
801
+ aws ecr delete-repository --repository-name hello-repository --region region --force
802
+
803
+ Next steps
804
+ Your task definitions require a task execution role. For more information, see Amazon ECS task
805
+ execution IAM role.
806
+ After you have created and pushed your container image to Amazon ECR, you can use that image in
807
+ a task definition. For more information, see one of the following:
808
+ • the section called “Learn how to create a Linux task for the Fargate launch type”
809
+
810
+ Clean up
811
+
812
+ 20
813
+
814
+ Amazon Elastic Container Service
815
+
816
+ Developer Guide
817
+
818
+ • the section called “Learn how to create a Windows task for the Fargate launch type”
819
+ • Creating an Amazon ECS Linux task for the Fargate launch type with the AWS CLI
820
+
821
+ Learn how to create an Amazon ECS Linux task for the Fargate
822
+ launch type
823
+ Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management
824
+ service that makes it easy to run, stop, and manage your containers. You can host your containers
825
+ on a serverless infrastructure that is managed by Amazon ECS by launching your services or tasks
826
+ on AWS Fargate. For more information on Fargate, see AWS Fargate for Amazon ECS.
827
+ Get started with Amazon ECS on AWS Fargate by using the Fargate launch type for your tasks in
828
+ the Regions where Amazon ECS supports AWS Fargate.
829
+ Complete the following steps to get started with Amazon ECS on AWS Fargate.
830
+
831
+ Prerequisites
832
+ Before you begin, complete the steps in Set up to use Amazon ECS and that your IAM user has the
833
+ permissions specified in the AdministratorAccess IAM policy example.
834
+ The console attempts to automatically create the task execution IAM role, which is required for
835
+ Fargate tasks. To ensure that the console is able to create this IAM role, one of the following must
836
+ be true:
837
+ • Your user has administrator access. For more information, see Set up to use Amazon ECS.
838
+ • Your user has the IAM permissions to create a service role. For more information, see Creating a
839
+ Role to Delegate Permissions to an AWS Service.
840
+ • A user with administrator access has manually created the task execution role so that it is
841
+ available on the account to be used. For more information, see Amazon ECS task execution IAM
842
+ role.
843
+
844
+ Important
845
+ The security group you select when creating a service with your task definition must have
846
+ port 80 open for inbound traffic. Add the following inbound rule to your security group.
847
+ Learn how to create a Linux task for the Fargate launch type
848
+
849
+ 21
850
+
851
+
dataset/docs/eks-ug.txt ADDED
@@ -0,0 +1,1221 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ Amazon EKS
2
+
3
+ User Guide
4
+
5
+ What is Amazon EKS?
6
+ Amazon EKS: Simplified Kubernetes Management
7
+ Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that
8
+ eliminates the complexity of operating Kubernetes clusters. With EKS, you can:
9
+ • Deploy applications faster with less operational overhead
10
+ • Scale seamlessly to meet changing workload demands
11
+ • Improve security through AWS integration and automated updates
12
+ • Choose between standard EKS or fully automated EKS Auto Mode
13
+ Amazon Elastic Kubernetes Service (Amazon EKS) is the premiere platform for running Kubernetes
14
+ clusters, both in the Amazon Web Services (AWS) cloud and in your own data centers (EKS
15
+ Anywhere and Amazon EKS Hybrid Nodes).
16
+ Amazon EKS simplifies building, securing, and maintaining Kubernetes clusters. It can be more cost
17
+ effective at providing enough resources to meet peak demand than maintaining your own data
18
+ centers. Two of the main approaches to using Amazon EKS are as follows:
19
+ • EKS standard: AWS manages the Kubernetes control plane when you create a cluster with EKS.
20
+ Components that manage nodes, schedule workloads, integrate with the AWS cloud, and store
21
+ and scale control plane information to keep your clusters up and running, are handled for you
22
+ automatically.
23
+ • EKS Auto Mode: Using the EKS Auto Mode feature, EKS extends its control to manage Nodes
24
+ (Kubernetes data plane) as well. It simplifies Kubernetes management by automatically
25
+ provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources,
26
+ continuously optimizing costs, patching operating systems, and integrating with AWS security
27
+ services.
28
+ The following diagram illustrates how Amazon EKS integrates your Kubernetes clusters with the
29
+ AWS cloud, depending on which method of cluster creation you choose:
30
+
31
+ Amazon EKS: Simplified Kubernetes Management
32
+
33
+ 1
34
+
35
+ Amazon EKS
36
+
37
+ User Guide
38
+
39
+ Amazon EKS helps you accelerate time to production, improve performance, availability and
40
+ resiliency, and enhance system security. For more information, see Amazon Elastic Kubernetes
41
+ Service.
42
+
43
+ Features of Amazon EKS
44
+ Amazon EKS provides the following high-level features:
45
+ Management interfaces
46
+ EKS offers multiple interfaces to provision, manage, and maintain clusters, including AWS
47
+ Management Console, Amazon EKS API/SDKs, CDK, AWS CLI, eksctl CLI, AWS CloudFormation,
48
+ and Terraform. For more information, see Get started and Configure clusters.
49
+
50
+ Features of Amazon EKS
51
+
52
+ 2
53
+
54
+ Amazon EKS
55
+
56
+ User Guide
57
+
58
+ Access control tools
59
+ EKS relies on both Kubernetes and AWS Identity and Access Management (AWS IAM) features
60
+ to manage access from users and workloads. For more information, see the section called
61
+ “Kubernetes API access” and the section called “Workload access to AWS ”.
62
+ Compute resources
63
+ For compute resources, EKS allows the full range of Amazon EC2 instance types and AWS
64
+ innovations such as Nitro and Graviton with Amazon EKS for you to optimize the compute for
65
+ your workloads. For more information, see Manage compute.
66
+ Storage
67
+ EKS Auto Mode automatically creates storage classes using EBS volumes. Using Container
68
+ Storage Interface (CSI) drivers, you can also use Amazon S3, Amazon EFS, Amazon FSX, and
69
+ Amazon File Cache for your application storage needs. For more information, see App data
70
+ storage.
71
+ Security
72
+ The shared responsibility model is employed as it relates to Security in Amazon EKS. For more
73
+ information, see Security best practices, Infrastructure security, and Kubernetes security.
74
+ Monitoring tools
75
+ Use the observability dashboard to monitor Amazon EKS clusters. Monitoring tools include
76
+ Prometheus, CloudWatch, Cloudtrail, and ADOT Operator. For more information on dashboards,
77
+ metrics servers, and other tools, see EKS cluster costs and Kubernetes Metrics Server.
78
+ Kubernetes compatibility and support
79
+ Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible
80
+ applications without refactoring and use Kubernetes community tooling and plugins. EKS offers
81
+ both standard support and eks/latest/userguide/kubernetes-versions-extended.html[extended
82
+ support,type="documentation"] for Kubernetes. For more information, see eks/latest/
83
+ userguide/kubernetes-versions.html[Understand the Kubernetes version lifecycle on
84
+ EKS,type="documentation"].
85
+
86
+ Related services
87
+ Services to use with Amazon EKS
88
+ Related services
89
+
90
+ 3
91
+
92
+ Amazon EKS
93
+
94
+ User Guide
95
+
96
+ You can use other AWS services with the clusters that you deploy using Amazon EKS:
97
+ Amazon EC2
98
+ Obtain on-demand, scalable compute capacity with Amazon EC2.
99
+ Amazon EBS
100
+ Attach scalable, high-performance block storage resources with Amazon EBS.
101
+ Amazon ECR
102
+ Store container images securely with Amazon ECR.
103
+ Amazon CloudWatch
104
+ Monitor AWS resources and applications in real time with Amazon CloudWatch.
105
+ Amazon Prometheus
106
+ Track metrics for containerized applications with Amazon Managed Service for Prometheus.
107
+ Elastic Load Balancing
108
+ Distribute incoming traffic across multiple targets with Elastic Load Balancing.
109
+ Amazon GuardDuty
110
+ Detect threats to EKS clusters with Amazon GuardDuty.
111
+ AWS Resilience Hub
112
+ Assess EKS cluster resiliency with AWS Resilience Hub.
113
+
114
+ Amazon EKS Pricing
115
+ Amazon EKS has per cluster pricing based on Kubernetes cluster version support, pricing for
116
+ Amazon EKS Auto Mode, and per vCPU pricing for Amazon EKS Hybrid Nodes.
117
+ When using Amazon EKS, you pay separately for the AWS resources you use to run your
118
+ applications on Kubernetes worker nodes. For example, if you are running Kubernetes worker
119
+ nodes as Amazon EC2 instances with Amazon EBS volumes and public IPv4 addresses, you are
120
+ charged for the instance capacity through Amazon EC2, the volume capacity through Amazon EBS,
121
+ and the IPv4 address through Amazon VPC.
122
+ Amazon EKS Pricing
123
+
124
+ 4
125
+
126
+ Amazon EKS
127
+
128
+ User Guide
129
+
130
+ Visit the respective pricing pages of the AWS services you are using with your Kubernetes
131
+ applications for detailed pricing information.
132
+ • For Amazon EKS cluster, Amazon EKS Auto Mode, and Amazon EKS Hybrid Nodes pricing, see
133
+ Amazon EKS Pricing.
134
+ • For Amazon EC2 pricing, see Amazon EC2 On-Demand Pricing and Amazon EC2 Spot Pricing.
135
+ • For AWS Fargate pricing, see AWS Fargate Pricing.
136
+ • You can use your savings plans for compute used in Amazon EKS clusters. For more information,
137
+ see Pricing with Savings Plans.
138
+
139
+ Common use cases in Amazon EKS
140
+ Amazon EKS offers robust managed Kubernetes services on AWS, designed to optimize
141
+ containerized applications. The following are a few of the most common use cases of Amazon EKS,
142
+ helping you leverage its strengths for your specific needs.
143
+ Deploying high-availability applications
144
+ Using Elastic Load Balancing, you can make sure that your applications are highly available
145
+ across multiple Availability Zones.
146
+ Building microservices architectures
147
+ Use Kubernetes service discovery features with AWS Cloud Map or Amazon VPC Lattice to build
148
+ resilient systems.
149
+ Automating software release process
150
+ Manage continuous integration and continuous deployment (CICD) pipelines that simplify the
151
+ process of automated building, testing, and deployment of applications.
152
+ Running serverless applications
153
+ Use AWS Fargate with Amazon EKS to run serverless applications. This means you can focus
154
+ solely on application development, while Amazon EKS and Fargate handle the underlying
155
+ infrastructure.
156
+ Executing machine learning workloads
157
+ Amazon EKS is compatible with popular machine learning frameworks such as TensorFlow,
158
+ MXNet, and PyTorch. With GPU support, you can handle even complex machine learning tasks
159
+ effectively.
160
+ Common use cases
161
+
162
+ 5
163
+
164
+ Amazon EKS
165
+
166
+ User Guide
167
+
168
+ Deploying consistently on premises and in the cloud
169
+ To simplify running Kubernetes in on-premises environments, you can use the same Amazon
170
+ EKS clusters, features, and tools to run self-managed nodes on AWS Outposts or can use
171
+ Amazon EKS Hybrid Nodes with your own infrastructure. For self-contained, air-gapped
172
+ environments, you can use Amazon EKS Anywhere to automate Kubernetes cluster lifecycle
173
+ management on your own infrastructure.
174
+ Running cost-effective batch processing and big data workloads
175
+ Utilize Spot Instances to run your batch processing and big data workloads such as Apache
176
+ Hadoop and Spark, at a fraction of the cost. This lets you take advantage of unused Amazon
177
+ EC2 capacity at discounted prices.
178
+ Securing application and ensuring compliance
179
+ Implement strong security practices and maintain compliance with Amazon EKS, which
180
+ integrates with AWS security services such as AWS Identity and Access Management (IAM),
181
+ Amazon Virtual Private Cloud (Amazon VPC), and AWS Key Management Service (AWS KMS).
182
+ This ensures data privacy and protection as per industry standards.
183
+
184
+ Amazon EKS architecture
185
+ Amazon EKS aligns with the general cluster architecture of Kubernetes. For more information, see
186
+ Kubernetes Components in the Kubernetes documentation. The following sections summarize
187
+ some extra architecture details for Amazon EKS.
188
+
189
+ Control plane
190
+ Amazon EKS ensures every cluster has its own unique Kubernetes control plane. This design keeps
191
+ each cluster’s infrastructure separate, with no overlaps between clusters or AWS accounts. The
192
+ setup includes:
193
+ Distributed components
194
+ The control plane positions at least two API server instances and three etcd instances across
195
+ three AWS Availability Zones within an AWS Region.
196
+ Optimal performance
197
+ Amazon EKS actively monitors and adjusts control plane instances to maintain peak
198
+ performance.
199
+ Architecture
200
+
201
+ 6
202
+
203
+ Amazon EKS
204
+
205
+ User Guide
206
+
207
+ Resilience
208
+ If a control plane instance falters, Amazon EKS quickly replaces it, using different Availability
209
+ Zone if needed.
210
+ Consistent uptime
211
+ By running clusters across multiple Availability Zones, a reliable API server endpoint availability
212
+ Service Level Agreement (SLA) is achieved.
213
+ Amazon EKS uses Amazon Virtual Private Cloud (Amazon VPC) to limit traffic between control
214
+ plane components within a single cluster. Cluster components can’t view or receive communication
215
+ from other clusters or AWS accounts, except when authorized by Kubernetes role-based access
216
+ control (RBAC) policies.
217
+
218
+ Compute
219
+ In addition to the control plane, an Amazon EKS cluster has a set of worker machines called
220
+ nodes. Selecting the appropriate Amazon EKS cluster node type is crucial for meeting your specific
221
+ requirements and optimizing resource utilization. Amazon EKS offers the following primary node
222
+ types:
223
+ EKS Auto Mode
224
+ EKS Auto Mode extends AWS management beyond the control plane to include the data plane,
225
+ automating cluster infrastructure management. It integrates core Kubernetes capabilities as
226
+ built-in components, including compute autoscaling, networking, load balancing, DNS, storage,
227
+ and GPU support. EKS Auto Mode dynamically manages nodes based on workload demands,
228
+ using immutable AMIs with enhanced security features. It automates updates and upgrades
229
+ while respecting Pod Disruption Budgets, and includes managed components that would
230
+ otherwise require add-on management. This option is ideal for users who want to leverage AWS
231
+ expertise for day-to-day operations, minimize operational overhead, and focus on application
232
+ development rather than infrastructure management.
233
+ AWS Fargate
234
+ Fargate is a serverless compute engine for containers that eliminates the need to manage
235
+ the underlying instances. With Fargate, you specify your application’s resource needs, and
236
+ AWS automatically provisions, scales, and maintains the infrastructure. This option is ideal for
237
+ users who prioritize ease-of-use and want to concentrate on application development and
238
+ deployment rather than managing infrastructure.
239
+ Compute
240
+
241
+ 7
242
+
243
+ Amazon EKS
244
+
245
+ User Guide
246
+
247
+ Karpenter
248
+ Karpenter is a flexible, high-performance Kubernetes cluster autoscaler that helps improve
249
+ application availability and cluster efficiency. Karpenter launches right-sized compute resources
250
+ in response to changing application load. This option can provision just-in-time compute
251
+ resources that meet the requirements of your workload.
252
+ Managed node groups
253
+ Managed node groups are a blend of automation and customization for managing a collection
254
+ of Amazon EC2 instances within an Amazon EKS cluster. AWS takes care of tasks like patching,
255
+ updating, and scaling nodes, easing operational aspects. In parallel, custom kubelet
256
+ arguments are supported, opening up possibilities for advanced CPU and memory management
257
+ policies. Moreover, they enhance security via AWS Identity and Access Management (IAM) roles
258
+ for service accounts, while curbing the need for separate permissions per cluster.
259
+ Self-managed nodes
260
+ Self-managed nodes offer full control over your Amazon EC2 instances within an Amazon
261
+ EKS cluster. You are in charge of managing, scaling, and maintaining the nodes, giving you
262
+ total control over the underlying infrastructure. This option is suitable for users who need
263
+ granular control and customization of their nodes and are ready to invest time in managing and
264
+ maintaining their infrastructure.
265
+ Amazon EKS Hybrid Nodes
266
+ With Amazon EKS Hybrid Nodes, you can use your on-premises and edge infrastructure as
267
+ nodes in Amazon EKS clusters. Amazon EKS Hybrid Nodes unifies Kubernetes management
268
+ across environments and offloads Kubernetes control plane management to AWS for your onpremises and edge applications.
269
+
270
+ Kubernetes concepts
271
+ Amazon Elastic Kubernetes Service (Amazon EKS) is an AWS managed service based on the open
272
+ source Kubernetes project. While there are things you need to know about how the Amazon EKS
273
+ service integrates with AWS Cloud (particularly when you first create an Amazon EKS cluster), once
274
+ it’s up and running, you use your Amazon EKS cluster in much that same way as you would any
275
+ other Kubernetes cluster. So to begin managing Kubernetes clusters and deploying workloads, you
276
+ need at least a basic understanding of Kubernetes concepts.
277
+ Kubernetes concepts
278
+
279
+ 8
280
+
281
+ Amazon EKS
282
+
283
+ User Guide
284
+
285
+ This page divides Kubernetes concepts into three sections: the section called “Why Kubernetes?”,
286
+ the section called “Clusters”, and the section called “Workloads”. The first section describes the
287
+ value of running a Kubernetes service, in particular as a managed service like Amazon EKS. The
288
+ Workloads section covers how Kubernetes applications are built, stored, run, and managed. The
289
+ Clusters section lays out the different components that make up Kubernetes clusters and what your
290
+ responsibilities are for creating and maintaining Kubernetes clusters.
291
+ Topics
292
+ • Why Kubernetes?
293
+ • Clusters
294
+ • Workloads
295
+ • Next steps
296
+ As you go through this content, links will lead you to further descriptions of Kubernetes concepts
297
+ in both Amazon EKS and Kubernetes documentation, in case you want to take deep dives into any
298
+ of the topics we cover here. For details about how Amazon EKS implements Kubernetes control
299
+ plane and compute features, see the section called “Architecture”.
300
+
301
+ Why Kubernetes?
302
+ Kubernetes was designed to improve availability and scalability when running mission-critical,
303
+ production-quality containerized applications. Rather than just running Kubernetes on a single
304
+ machine (although that is possible), Kubernetes achieves those goals by allowing you to run
305
+ applications across sets of computers that can expand or contract to meet demand. Kubernetes
306
+ includes features that make it easier for you to:
307
+ • Deploy applications on multiple machines (using containers deployed in Pods)
308
+ • Monitor container health and restart failed containers
309
+ • Scale containers up and down based on load
310
+ • Update containers with new versions
311
+ • Allocate resources between containers
312
+ • Balance traffic across machines
313
+ Having Kubernetes automate these types of complex tasks allows an application developer
314
+ to focus on building and improving their application workloads, rather than worrying about
315
+ Why Kubernetes?
316
+
317
+ 9
318
+
319
+ Amazon EKS
320
+
321
+ User Guide
322
+
323
+ infrastructure. The developer typically creates configuration files, formatted as YAML files, that
324
+ describe the desired state of the application. This could include which containers to run, resource
325
+ limits, number of Pod replicas, CPU/memory allocation, affinity rules, and more.
326
+
327
+ Attributes of Kubernetes
328
+ To achieve its goals, Kubernetes has the following attributes:
329
+ • Containerized — Kubernetes is a container orchestration tool. To use Kubernetes, you must first
330
+ have your applications containerized. Depending on the type of application, this could be as a
331
+ set of microservices, as batch jobs or in other forms. Then, your applications can take advantage
332
+ of a Kubernetes workflow that encompasses a huge ecosystem of tools, where containers can
333
+ be stored as images in a container registry, deployed to a Kubernetes cluster, and run on an
334
+ available node. You can build and test individual containers on your local computer with Docker
335
+ or another container runtime, before deploying them to your Kubernetes cluster.
336
+ • Scalable — If the demand for your applications exceeds the capacity of the running instances of
337
+ those applications, Kubernetes is able to scale up. As needed, Kubernetes can tell if applications
338
+ require more CPU or memory and respond by either automatically expanding available capacity
339
+ or using more of existing capacity. Scaling can be done at the Pod level, if there is enough
340
+ compute available to just run more instances of the application (horizontal Pod autoscaling), or
341
+ at the node level, if more nodes need to be brought up to handle the increased capacity (Cluster
342
+ Autoscaler or Karpenter). As capacity is no longer needed, these services can delete unnecessary
343
+ Pods and shut down unneeded nodes.
344
+ • Available — If an application or node becomes unhealthy or unavailable, Kubernetes can move
345
+ running workloads to another available node. You can force the issue by simply deleting a
346
+ running instance of a workload or node that’s running your workloads. The bottom line here is
347
+ that workloads can be brought up in other locations if they can no longer run where they are.
348
+ • Declarative — Kubernetes uses active reconciliation to constantly check that the state that you
349
+ declare for your cluster matches the actual state. By applying Kubernetes objects to a cluster,
350
+ typically through YAML-formatted configuration files, you can, for example, ask to start up
351
+ the workloads you want to run on your cluster. You can later change the configurations to do
352
+ something like use a later version of a container or allocate more memory. Kubernetes will do
353
+ what it needs to do to establish the desired state. This can include bringing nodes up or down,
354
+ stopping and restarting workloads, or pulling updated containers.
355
+ • Composable — Because an application typically consists of multiple components, you want
356
+ to be able to manage a set of these components (often represented by multiple containers)
357
+ together. While Docker Compose offers a way to do this directly with Docker, the Kubernetes
358
+ Why Kubernetes?
359
+
360
+ 10
361
+
362
+ Amazon EKS
363
+
364
+ User Guide
365
+
366
+ Kompose command can help you do that with Kubernetes. See Translate a Docker Compose File
367
+ to Kubernetes Resources for an example of how to do this.
368
+ • Extensible — Unlike proprietary software, the open source Kubernetes project is designed
369
+ to be open to you extending Kubernetes any way that you like to meet your needs. APIs and
370
+ configuration files are open to direct modifications. Third-parties are encouraged to write their
371
+ own Controllers, to extend both infrastructure and end-user Kubernetes features. Webhooks let
372
+ you set up cluster rules to enforce policies and adapt to changing conditions. For more ideas on
373
+ how to extend Kubernetes clusters, see Extending Kubernetes.
374
+ • Portable — Many organizations have standardized their operations on Kubernetes because it
375
+ allows them to manage all of their application needs in the same way. Developers can use the
376
+ same pipelines to build and store containerized applications. Those applications can then be
377
+ deployed to Kubernetes clusters running on-premises, in clouds, on point-of-sales terminals in
378
+ restaurants, or on IOT devices dispersed across company’s remote sites. Its open source nature
379
+ makes it possible for people to develop these special Kubernetes distributions, along will tools
380
+ needed to manage them.
381
+
382
+ Managing Kubernetes
383
+ Kubernetes source code is freely available, so with your own equipment you could install and
384
+ manage Kubernetes yourself. However, self-managing Kubernetes requires deep operational
385
+ expertise and takes time and effort to maintain. For those reasons, most people deploying
386
+ production workloads choose a cloud provider (such as Amazon EKS) or on-premises provider (such
387
+ as Amazon EKS Anywhere) with its own tested Kubernetes distribution and support of Kubernetes
388
+ experts. This allows you to offload much of the undifferentiated heavy lifting needed to maintain
389
+ your clusters, including:
390
+ • Hardware — If you don’t have hardware available to run Kubernetes per your requirements,
391
+ a cloud provider such as AWS Amazon EKS can save you on upfront costs. With Amazon EKS,
392
+ this means that you can consume the best cloud resources offered by AWS, including computer
393
+ instances (Amazon Elastic Compute Cloud), your own private environment (Amazon VPC),
394
+ central identity and permissions management (IAM), and storage (Amazon EBS). AWS manages
395
+ the computers, networks, data centers, and all the other physical components needed to
396
+ run Kubernetes. Likewise, you don’t have to plan your datacenter to handle the maximum
397
+ capacity on your highest-demand days. For Amazon EKS Anywhere, or other on premises
398
+ Kubernetes clusters, you are responsible for managing the infrastructure used in your Kubernetes
399
+ deployments, but you can still rely on AWS to help you keep Kubernetes up to date.
400
+ Why Kubernetes?
401
+
402
+ 11
403
+
404
+ Amazon EKS
405
+
406
+ User Guide
407
+
408
+ • Control plane management — Amazon EKS manages the security and availability of the AWShosted Kubernetes control plane, which is responsible for scheduling containers, managing the
409
+ availability of applications, and other key tasks, so you can focus on your application workloads.
410
+ If your cluster breaks, AWS should have the means to restore your cluster to a running state. For
411
+ Amazon EKS Anywhere, you would manage the control plane yourself.
412
+ • Tested upgrades — When you upgrade your clusters, you can rely on Amazon EKS or Amazon
413
+ EKS Anywhere to provide tested versions of their Kubernetes distributions.
414
+ • Add-ons — There are hundreds of projects built to extend and work with Kubernetes that you
415
+ can add to your cluster’s infrastructure or use to aid the running of your workloads. Instead
416
+ of building and managing those add-ons yourself, AWS provides the section called “Amazon
417
+ EKS add-ons” that you can use with your clusters. Amazon EKS Anywhere provides Curated
418
+ Packages that include builds of many popular open source projects. So you don’t have to build
419
+ the software yourself or manage critical security patches, bug fixes, or upgrades. Likewise, if the
420
+ defaults meet your needs, it’s typical for very little configuration of those add-ons to be needed.
421
+ See the section called “Extend Clusters” for details on extending your cluster with add-ons.
422
+
423
+ Kubernetes in action
424
+ The following diagram shows key activities you would do as a Kubernetes Admin or Application
425
+ Developer to create and use a Kubernetes cluster. In the process, it illustrates how Kubernetes
426
+ components interact with each other, using the AWS cloud as the example of the underlying cloud
427
+ provider.
428
+
429
+ Why Kubernetes?
430
+
431
+ 12
432
+
433
+ Amazon EKS
434
+
435
+ User Guide
436
+
437
+ A Kubernetes Admin creates the Kubernetes cluster using a tool specific to the type of provider on
438
+ which the cluster will be built. This example uses the AWS cloud as the provider, which offers the
439
+ managed Kubernetes service called Amazon EKS. The managed service automatically allocates the
440
+ resources needed to create the cluster, including creating two new Virtual Private Clouds (Amazon
441
+ VPCs) for the cluster, setting up networking, and mapping Kubernetes permissions directly into
442
+ the new VPCs for cloud asset management. The managed service also sees that the control plane
443
+ services have places to run and allocates zero or more Amazon EC2 instances as Kubernetes nodes
444
+ for running workloads. AWS manages one Amazon VPC itself for the control plane, while the other
445
+ Amazon VPC contains the customer nodes that run workloads.
446
+ Many of the Kubernetes Admin’s tasks going forward are done using Kubernetes tools such as
447
+ kubectl. That tool makes requests for services directly to the cluster’s control plane. The ways
448
+ that queries and changes are made to the cluster are then very similar to the ways you would do
449
+ them on any Kubernetes cluster.
450
+ An application developer wanting to deploy workloads to this cluster can perform several tasks.
451
+ The developer needs to build the application into one or more container images, then push those
452
+ images to a container registry that is accessible to the Kubernetes cluster. AWS offers the Amazon
453
+ Elastic Container Registry (Amazon ECR) for that purpose.
454
+ Why Kubernetes?
455
+
456
+ 13
457
+
458
+ Amazon EKS
459
+
460
+ User Guide
461
+
462
+ To run the application, the developer can create YAML-formatted configuration files that tell the
463
+ cluster how to run the application, including which containers to pull from the registry and how
464
+ to wrap those containers in Pods. The control plane (scheduler) schedules the containers to one or
465
+ more nodes and the container runtime on each node actually pulls and runs the needed containers.
466
+ The developer can also set up an application load balancer to balance traffic to available containers
467
+ running on each node and expose the application so it is available on a public network to the
468
+ outside world. With that all done, someone wanting to use the application can connect to the
469
+ application endpoint to access it.
470
+ The following sections go through details of each of these features, from the perspective of
471
+ Kubernetes Clusters and Workloads.
472
+
473
+ Clusters
474
+ If your job is to start and manage Kubernetes clusters, you should know how Kubernetes clusters
475
+ are created, enhanced, managed, and deleted. You should also know what the components are that
476
+ make up a cluster and what you need to do to maintain those components.
477
+ Tools for managing clusters handle the overlap between the Kubernetes services and the
478
+ underlying hardware provider. For that reason, automation of these tasks tend to be done by
479
+ the Kubernetes provider (such as Amazon EKS or Amazon EKS Anywhere) using tools that are
480
+ specific to the provider. For example, to start an Amazon EKS cluster you can use eksctl create
481
+ cluster, while for Amazon EKS Anywhere you can use eksctl anywhere create cluster.
482
+ Note that while these commands create a Kubernetes cluster, they are specific to the provider and
483
+ are not part of the Kubernetes project itself.
484
+
485
+ Cluster creation and management tools
486
+ The Kubernetes project offers tools for creating a Kubernetes cluster manually. So if you want
487
+ to install Kubernetes on a single machine, or run the control plane on a machine and add nodes
488
+ manually, you can use CLI tools like kind, minikube, or kubeadm that are listed under Kubernetes
489
+ Install Tools. To simplify and automate the full lifecycle of cluster creation and management, it is
490
+ much easier to use tools supported by an established Kubernetes provider, such as Amazon EKS or
491
+ Amazon EKS Anywhere.
492
+ In AWS Cloud, you can create Amazon EKS clusters using CLI tools, such as eksctl, or more
493
+ declarative tools, such as Terraform (see Amazon EKS Blueprints for Terraform). You can also create
494
+ a cluster from the AWS Management Console. See Amazon EKS features for a list what you get
495
+ with Amazon EKS. Kubernetes responsibilities that Amazon EKS takes on for you include:
496
+ Clusters
497
+
498
+ 14
499
+
500
+ Amazon EKS
501
+
502
+ User Guide
503
+
504
+ • Managed control plane — AWS makes sure that the Amazon EKS cluster is available and scalable
505
+ because it manages the control plane for you and makes it available across AWS Availability
506
+ Zones.
507
+ • Node management — Instead of manually adding nodes, you can have Amazon EKS create
508
+ nodes automatically as needed, using Managed Node Groups (see the section called “Managed
509
+ node groups”) or Karpenter. Managed Node Groups have integrations with Kubernetes Cluster
510
+ Autoscaling. Using node management tools, you can take advantage of cost savings, with things
511
+ like Spot Instances and node consolidation, and availability, using Scheduling features to set how
512
+ workloads are deployed and nodes are selected.
513
+ • Cluster networking — Using CloudFormation templates, eksctl sets up networking between
514
+ control plane and data plane (node) components in the Kubernetes cluster. It also sets up
515
+ endpoints through which internal and external communications can take place. See Demystifying cluster networking for Amazon EKS worker nodes for details. Communications
516
+ between Pods in Amazon EKS is done using Amazon EKS Pod Identities (see the section
517
+ called “Pod Identity”), which provides a means of letting Pods tap into AWS cloud methods of
518
+ managing credentials and permissions.
519
+ • Add-Ons — Amazon EKS saves you from having to build and add software components that are
520
+ commonly used to support Kubernetes clusters. For example, when you create an Amazon EKS
521
+ cluster from the AWS Management Console, it automatically adds the Amazon EKS kube-proxy
522
+ (the section called “kube-proxy”), Amazon VPC CNI plugin for Kubernetes (the section called
523
+ “Amazon VPC CNI”), and CoreDNS (the section called “CoreDNS”) add-ons. See the section called
524
+ “Amazon EKS add-ons” for more on these add-ons, including a list of which are available.
525
+ To run your clusters on your own on-premises computers and networks, Amazon offers Amazon
526
+ EKS Anywhere. Instead of the AWS Cloud being the provider, you have the choice of running
527
+ Amazon EKS Anywhere on VMWare vSphere, bare metal (Tinkerbell provider), Snow, CloudStack, or
528
+ Nutanix platforms using your own equipment.
529
+ Amazon EKS Anywhere is based on the same Amazon EKS Distro software that is used by Amazon
530
+ EKS. However, Amazon EKS Anywhere relies on different implementations of the Kubernetes
531
+ Cluster API (CAPI) interface to manage the full lifecycle of the machines in an Amazon EKS
532
+ Anywhere cluster (such as CAPV for vSphere and CAPC for CloudStack). Because the entire cluster
533
+ is running on your equipment, you take on the added responsibility of managing the control plane
534
+ and backing up its data (see etcd later in this document).
535
+
536
+ Clusters
537
+
538
+ 15
539
+
540
+ Amazon EKS
541
+
542
+ User Guide
543
+
544
+ Cluster components
545
+ Kubernetes cluster components are divided into two major areas: control plane and worker nodes.
546
+ Control Plane Components manage the cluster and provide access to its APIs. Worker nodes
547
+ (sometimes just referred to as Nodes) provide the places where the actual workloads are run. Node
548
+ Components consist of services that run on each node to communicate with the control plane and
549
+ run containers. The set of worker nodes for your cluster is referred to as the Data Plane.
550
+ Control plane
551
+ The control plane consists of a set of services that manage the cluster. These services may all be
552
+ running on a single computer or may be spread across multiple computers. Internally, these are
553
+ referred to as Control Plane Instances (CPIs). How CPIs are run depends on the size of the cluster
554
+ and requirements for high availability. As demand increase in the cluster, a control plane service
555
+ can scale to provide more instances of that service, with requests being load balanced between the
556
+ instances.
557
+ Tasks that components of the Kubernetes control plane performs include:
558
+ • Communicating with cluster components (API server) — The API server (kube-apiserver)
559
+ exposes the Kubernetes API so requests to the cluster can be made from both inside and outside
560
+ of the cluster. In other words, requests to add or change a cluster’s objects (Pods, Services,
561
+ Nodes, and so on) can come from outside commands, such as requests from kubectl to run a
562
+ Pod. Likewise, requests can be made from the API server to components within the cluster, such
563
+ as a query to the kubelet service for the status of a Pod.
564
+ • Store data about the cluster (etcd key value store) — The etcd service provides the critical
565
+ role of keeping track of the current state of the cluster. If the etcd service became inaccessible,
566
+ you would be unable to update or query the status of the cluster, though workloads would
567
+ continue to run for a while. For that reason, critical clusters typically have multiple, loadbalanced instances of the etcd service running at a time and do periodic backups of the etcd
568
+ key value store in case of data loss or corruption. Keep in mind that, in Amazon EKS, this is all
569
+ handled for you automatically by default. Amazon EKS Anywhere provides instruction for etcd
570
+ backup and restore. See the etcd Data Model to learn how etcd manages data.
571
+ • Schedule Pods to nodes (Scheduler) — Requests to start or stop a Pod in Kubernetes are
572
+ directed to the Kubernetes Scheduler (kube-scheduler). Because a cluster could have multiple
573
+ nodes that are capable of running the Pod, it is up to the Scheduler to choose which node (or
574
+ nodes, in the case of replicas) the Pod should run on. If there is not enough available capacity
575
+ to run the requested Pod on an existing node, the request will fail, unless you have made other
576
+ Clusters
577
+
578
+ 16
579
+
580
+ Amazon EKS
581
+
582
+ User Guide
583
+
584
+ provisions. Those provisions could include enabling services such as Managed Node Groups (the
585
+ section called “Managed node groups”) or Karpenter that can automatically start up new nodes
586
+ to handle the workloads.
587
+ • Keep components in desired state (Controller Manager) — The Kubernetes Controller Manager
588
+ runs as a daemon process (kube-controller-manager) to watch the state of the cluster and
589
+ make changes to the cluster to reestablish the expected states. In particular, there are several
590
+ controllers that watch over different Kubernetes objects, which includes a statefulsetcontroller, endpoint-controller, cronjob-controller, node-controller, and
591
+ others.
592
+ • Manage cloud resources (Cloud Controller Manager) — Interactions between Kubernetes and
593
+ the cloud provider that carries out requests for the underlying data center resources are handled
594
+ by the Cloud Controller Manager (cloud-controller-manager). Controllers managed by the Cloud
595
+ Controller Manager can include a route controller (for setting up cloud network routes), service
596
+ controller (for using cloud load balancing services), and node lifecycle controller (to keep nodes
597
+ in sync with Kubernetes throughout their lifecycles).
598
+ Worker Nodes (data plane)
599
+ For a single-node Kubernetes cluster, workloads run on the same machine as the control plane.
600
+ However, a more standard configuration is to have one or more separate computer systems (Nodes)
601
+ that are dedicated to running Kubernetes workloads.
602
+ When you first create a Kubernetes cluster, some cluster creation tools allow you to configure a
603
+ certain number nodes to be added to the cluster (either by identifying existing computer systems
604
+ or by having the provider create new ones). Before any workloads are added to those systems,
605
+ services are added to each node to implement these features:
606
+ • Manage each node (kubelet) — The API server communicates with the kubelet service running
607
+ on each node to make sure that the node is properly registered and Pods requested by the
608
+ Scheduler are running. The kubelet can read the Pod manifests and set up storage volumes or
609
+ other features needed by the Pods on the local system. It can also check on the health of the
610
+ locally running containers.
611
+ • Run containers on a node (container runtime) — The Container Runtime on each node
612
+ manages the containers requested for each Pod assigned to the node. That means that it can
613
+ pull container images from the appropriate registry, run the container, stop it, and responds to
614
+ queries about the container. The default container runtime is containerd. As of Kubernetes 1.24,
615
+ the special integration of Docker (dockershim) that could be used as the container runtime was
616
+ Clusters
617
+
618
+ 17
619
+
620
+ Amazon EKS
621
+
622
+ User Guide
623
+
624
+ dropped from Kubernetes. While you can still use Docker to test and run containers on your local
625
+ system, to use Docker with Kubernetes you would now have to Install Docker Engine on each
626
+ node to use it with Kubernetes.
627
+ • Manage networking between containers (kube-proxy) — To be able to support
628
+ communication between Pods, Kubernetes uses a feature referred to as a Service to set up Pod
629
+ networks that track IP addresses and ports associated with those Pods. The kube-proxy service
630
+ runs on every node to allow that communication between Pods to take place.
631
+
632
+ Extend Clusters
633
+ There are some services you can add to Kubernetes to support the cluster, but are not run in the
634
+ control plane. These services often run directly on nodes in the kube-system namespace or in its
635
+ own namespace (as is often done with third-party service providers). A common example is the
636
+ CoreDNS service, which provides DNS services to the cluster. Refer to Discovering builtin services
637
+ for information on how to see which cluster services are running in kube-system on your cluster.
638
+ There are different types of add-ons you can consider adding to your clusters. To keep your clusters
639
+ healthy, you can add observability features (see Monitor clusters) that allow you to do things like
640
+ logging, auditing, and metrics. With this information, you can troubleshoot problems that occur,
641
+ often through the same observability interfaces. Examples of these types of services include
642
+ Amazon GuardDuty, CloudWatch (see the section called “Amazon CloudWatch”), AWS Distro for
643
+ OpenTelemetry, Amazon VPC CNI plugin for Kubernetes (see the section called “Amazon VPC
644
+ CNI”), and Grafana Kubernetes Monitoring. For storage (see App data storage), add-ons to Amazon
645
+ EKS include Amazon Elastic Block Store CSI Driver (see the section called “Amazon EBS”), Amazon
646
+ Elastic File System CSI Driver (see the section called “Amazon EFS”), and several third-party storage
647
+ add-ons such as Amazon FSx for NetApp ONTAP CSI driver the section called “Amazon FSx for
648
+ NetApp ONTAP”).
649
+ For a more complete list of available Amazon EKS add-ons, see the section called “Amazon EKS
650
+ add-ons”.
651
+
652
+ Workloads
653
+ Kubernetes defines a Workload as "an application running on Kubernetes." That application can
654
+ consist of a set of microservices run as Containers in Pods, or could be run as a batch job or other
655
+ type of applications. The job of Kubernetes is to make sure that the requests that you make for
656
+ those objects to be set up or deployed are carried out. As someone deploying applications, you
657
+ Workloads
658
+
659
+ 18
660
+
661
+ Amazon EKS
662
+
663
+ User Guide
664
+
665
+ should learn about how containers are built, how Pods are defined, and what methods you can use
666
+ for deploying them.
667
+
668
+ Containers
669
+ The most basic element of an application workload that you deploy and manage in Kubernetes is
670
+ a Pod . A Pod represents a way of holding the components of an application as well as defining
671
+ specifications that describe the Pod’s attributes. Contrast this to something like an RPM or Deb
672
+ package, which packages together software for a Linux system, but does not itself run as an entity.
673
+ Because the Pod is the smallest deployable unit, it typically holds a single container. However,
674
+ multiple containers can be in a Pod in cases where the containers are tightly coupled. For example,
675
+ a web server container might be packaged in a Pod with a sidecar type of container that may
676
+ provide logging, monitoring, or other service that is closely tied to the web server container. In this
677
+ case, being in the same Pod ensures that for each running instance of the Pod, both containers
678
+ always run on the same node. Likewise, all containers in a Pod share the same environment, with
679
+ the containers in a Pod running as though they are in the same isolated host. The effect of this is
680
+ that the containers share a single IP address that provides access to the Pod and the containers can
681
+ communicate with each other as though they were running on their own localhost.
682
+ Pod specifications (PodSpec) define the desired state of the Pod. You can deploy an individual
683
+ Pod or multiple Pods by using workload resources to manage Pod Templates. Workload resources
684
+ include Deployments (to manage multiple Pod Replicas), StatefulSets (to deploy Pods that need
685
+ to be unique, such as database Pods), and DaemonSets (where a Pod needs to run continuously on
686
+ every node). More on those later.
687
+ While a Pod is the smallest unit you deploy, a container is the smallest unit that you build and
688
+ manage.
689
+ Building Containers
690
+ The Pod is really just a structure around one or more containers, with each container itself holding
691
+ the file system, executables, configuration files, libraries, and other components to actually run
692
+ the application. Because a company called Docker Inc. first popularized containers, some people
693
+ refer to containers as Docker Containers. However, the Open Container Initiative has since defined
694
+ container runtimes, images, and distribution methods for the industry. Add to that the fact that
695
+ containers were created from many existing Linux features, others often refer to containers as OCI
696
+ Containers, Linux Containers, or just Containers.
697
+ Workloads
698
+
699
+ 19
700
+
701
+ Amazon EKS
702
+
703
+ User Guide
704
+
705
+ When you build a container, you typically start with a Dockerfile (literally named that). Inside that
706
+ Dockerfile, you identify:
707
+ • A base image — A base container image is a container that is typically built from either a
708
+ minimal version of an operating system’s file system (such as Red Hat Enterprise Linux or
709
+ Ubuntu) or a minimal system that is enhanced to provide software to run specific types of
710
+ applications (such as a nodejs or python apps).
711
+ • Application software — You can add your application software to your container in much the
712
+ same way you would add it to a Linux system. For example, in your Dockerfile you can run npm
713
+ and yarn to install a Java application or yum and dnf to install RPM packages. In other words,
714
+ using a RUN command in a Dockerfile, you can run any command that is available in the file
715
+ system of your base image to install software or configure software inside of the resulting
716
+ container image.
717
+ • Instructions — The Dockerfile reference describes the instructions you can add to a Dockerfile
718
+ when you configure it. These include instructions used to build what is in the container itself
719
+ (ADD or COPY files from the local system), identify commands to execute when the container is
720
+ run (CMD or ENTRYPOINT), and connect the container to the system it runs on (by identifying the
721
+ USER to run as, a local VOLUME to mount, or the ports to EXPOSE).
722
+ While the docker command and service have traditionally been used to build containers (docker
723
+ build), other tools that are available to build container images include podman and nerdctl. See
724
+ Building Better Container Images or Overview of Docker Build to learn about building containers.
725
+ Storing Containers
726
+ Once you’ve built your container image, you can store it in a container distribution registry on
727
+ your workstation or on a public container registry. Running a private container registry on your
728
+ workstation allows you to store container images locally, making them readily available to you.
729
+ To store container images in a more public manner, you can push them to a public container
730
+ registry. Public container registries provide a central location for storing and distributing container
731
+ images. Examples of public container registries include the Amazon Elastic Container Registry, Red
732
+ Hat Quay registry, and Docker Hub registry.
733
+ When running containerized workloads on Amazon Elastic Kubernetes Service (Amazon EKS) we
734
+ recommend pulling copies of Docker Official Images that are stored in Amazon Elastic Container
735
+ Registry. Amazon ECR has been storing these images since 2021. You can search for popular
736
+ Workloads
737
+
738
+ 20
739
+
740
+ Amazon EKS
741
+
742
+ User Guide
743
+
744
+ container images in the Amazon ECR Public Gallery, and specifically for the Docker Hub images,
745
+ you can search the Amazon ECR Docker Gallery.
746
+ Running containers
747
+ Because containers are built in a standard format, a container can run on any machine that can run
748
+ a container runtime (such as Docker) and whose contents match the local machine’s architecture
749
+ (such as x86_64 or arm). To test a container or just run it on your local desktop, you can use
750
+ docker run or podman run commands to start up a container on the localhost. For Kubernetes,
751
+ however, each worker node has a container runtime deployed and it is up to Kubernetes to request
752
+ that a node run a container.
753
+ Once a container has been assigned to run on a node, the node looks to see if the requested
754
+ version of the container image already exists on the node. If it doesn’t, Kubernetes tells the
755
+ container runtime to pull that container from the appropriate container registry, then run that
756
+ container locally. Keep in mind that a container image refers to the software package that is moved
757
+ around between your laptop, the container registry, and Kubernetes nodes. A container refers to a
758
+ running instance of that image.
759
+
760
+ Pods
761
+ Once your containers are ready, working with Pods includes configuring, deploying, and making the
762
+ Pods accessible.
763
+ Configuring Pods
764
+ When you define a Pod, you assign a set of attributes to it. Those attributes must include at least
765
+ the Pod name and the container image to run. However, there are many other things you want to
766
+ configure with your Pod definitions as well (see the PodSpec page for details on what can go into a
767
+ Pod). These include:
768
+ • Storage — When a running container is stopped and deleted, data storage in that container
769
+ will disappear, unless you set up more permanent storage. Kubernetes supports many different
770
+ storage types and abstracts them under the umbrella of Volumes. Storage types include CephFS,
771
+ NFS, iSCSI, and others. You can even use a local block device from the local computer. With
772
+ one of those storage types available from your cluster, you can mount the storage volume to a
773
+ selected mount point in your container’s file system. A Persistent Volume is one that continues to
774
+ exist after the Pod is deleted, while an Ephemeral Volume is deleted when the Pod is deleted. If
775
+ your cluster administrator created different storage classes for your cluster, you might have the
776
+ Workloads
777
+
778
+ 21
779
+
780
+ Amazon EKS
781
+
782
+ User Guide
783
+
784
+ option for choosing the attributes of the storage you use, such as whether the volume is deleted
785
+ or reclaimed after use, whether it will expand if more space is needed, and even whether it meets
786
+ certain performance requirements.
787
+ • Secrets — By making Secrets available to containers in Pod specs, you can provide the
788
+ permissions those containers need to access file systems, data bases, or other protected assets.
789
+ Keys, passwords, and tokens are among the items that can be stored as secrets. Using secrets
790
+ makes it so you don’t have to store this information in container images, but need only make the
791
+ secrets available to running containers. Similar to Secrets are ConfigMaps. A ConfigMap tends to
792
+ hold less critical information, such as key-value pairs for configuring a service.
793
+ • Container resources — Objects for further configuring containers can take the form of resource
794
+ configuration. For each container, you can request the amount of memory and CPU that it can
795
+ use, as well as place limits of the total amount of those resources that the container can use. See
796
+ Resource Management for Pods and Containers for examples.
797
+ • Disruptions — Pods can be disrupted involuntarily (a node goes down) or voluntarily (an upgrade
798
+ is desired). By configuring a Pod disruption budget, you can exert some control over how
799
+ available your application remains when disruptions occur. See Specifying a Disruption Budget
800
+ for your application for examples.
801
+ • Namespaces — Kubernetes provides different ways to isolate Kubernetes components and
802
+ workloads from each other. Running all the Pods for a particular application in the same
803
+ Namespace is a common way to secure and manage those Pods together. You can create your
804
+ own namespaces to use or choose to not indicate a namespace (which causes Kubernetes to
805
+ use the default namespace). Kubernetes control plane components typically run in the kubesystem namespace.
806
+ The configuration just described is typically gathered together in a YAML file to be applied to the
807
+ Kubernetes cluster. For personal Kubernetes clusters, you might just store these YAML files on
808
+ your local system. However, with more critical clusters and workloads, GitOps is a popular way to
809
+ automate storage and updates to both workload and Kubernetes infrastructure resources.
810
+ The objects used to gather together and deploy Pod information is defined by one of the following
811
+ deployment methods.
812
+ Deploying Pods
813
+ The method you would choose for deploying Pods depends on the type of application you plan to
814
+ run with those Pods. Here are some of your choices:
815
+ Workloads
816
+
817
+ 22
818
+
819
+ Amazon EKS
820
+
821
+ User Guide
822
+
823
+ • Stateless applications — A stateless application doesn’t save a client’s session data, so another
824
+ session doesn’t need to refer back to what happened to a previous session. This makes it easier
825
+ to just replace Pods with new ones if they become unhealthy or move them around without
826
+ saving state. If you are running a stateless application (such as a web server), you can use a
827
+ Deployment to deploy Podsand ReplicaSets. A ReplicaSet defines how many instances of a Pod
828
+ that you want running concurrently. Although you can run a ReplicaSet directly, it is common
829
+ to run replicas directly within a Deployment, to define how many replicas of a Pod should be
830
+ running at a time.
831
+ • Stateful applications — A stateful application is one where the identity of the Pod and the
832
+ order in which Pods are launched are important. These applications need persistent storage
833
+ that is stable and need to be deployed and scaled in a consistent manner. To deploy a stateful
834
+ application in Kubernetes, you can use StatefulSets. An example of an application that is
835
+ typically run as a StatefulSet is a database. Within a StatefulSet, you could define replicas, the
836
+ Pod and its containers, storage volumes to mount, and locations in the container where data are
837
+ stored. See Run a Replicated Stateful Application for an example of a database being deployed
838
+ as a ReplicaSet.
839
+ • Per-node applications — There are times when you want to run an application on every node in
840
+ your Kubernetes cluster. For example, your data center might require that every computer run
841
+ a monitoring application or a particular remote access service. For Kubernetes, you can use a
842
+ DaemonSet to ensure that the selected application runs on every node in your cluster.
843
+ • Applications run to completion — There are some applications you want to run to complete a
844
+ particular task. This could include one that runs monthly status reports or cleans out old data.
845
+ A Job object can be used to set up an application to start up and run, then exit when the task is
846
+ done. A CronJob object lets you set up an application to run at a specific hour, minute, day of the
847
+ month, month, or day of the week, using a structure defined by the Linux crontab format.
848
+ Making applications accessible from the network
849
+ With applications often deployed as a set of microservices that moved around to different places,
850
+ Kubernetes needed a way for those microservices to be able to find each other. Also, for others
851
+ to access an application outside of the Kubernetes cluster, Kubernetes needed a way to expose
852
+ that application on outside addresses and ports. These networking-related features are done with
853
+ Service and Ingress objects, respectively:
854
+ • Services — Because a Pod can move around to different nodes and addresses, another Pod that
855
+ needs to communicate with the first Pod could find it difficult to locate where it is. To solve
856
+ Workloads
857
+
858
+ 23
859
+
860
+ Amazon EKS
861
+
862
+ User Guide
863
+
864
+ this problem, Kubernetes lets you represent an application as a Service. With a Service, you
865
+ can identify a Pod or set of Pods with a particular name, then indicate what port exposes that
866
+ application’s service from the Pod and what ports another application could use to contact that
867
+ service. Another Pod within a cluster can simply request a Service by name and Kubernetes will
868
+ direct that request to the proper port for an instance of the Pod running that service.
869
+ • Ingress — Ingress is what can make applications represented by Kubernetes Services available to
870
+ clients that are outside of the cluster. Basic features of Ingress include a load balancer (managed
871
+ by Ingress), the Ingress controller, and rules for routing requests from the controller to the
872
+ Service. There are several Ingress Controllers that you can choose from with Kubernetes.
873
+
874
+ Next steps
875
+ Understanding basic Kubernetes concepts and how they relate to Amazon EKS will help you
876
+ navigate both the Amazon EKS documentation and Kubernetes documentation to find the
877
+ information you need to manage Amazon EKS clusters and deploy workloads to those clusters. To
878
+ begin using Amazon EKS, choose from the following:
879
+ • the section called “Create cluster (eksctl)”
880
+ • the section called “Create a cluster”
881
+ • the section called “Sample deployment (Linux)”
882
+ • Cluster management
883
+
884
+ Deploy Amazon EKS clusters across cloud and on-premises
885
+ environments
886
+ Understand Amazon EKS deployment options
887
+ Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service that
888
+ enables you to run Kubernetes seamlessly in the cloud and in your on-premises environments.
889
+ In the cloud, Amazon EKS automates Kubernetes cluster infrastructure management for the
890
+ Kubernetes control plane and nodes. This is essential for scheduling containers, managing
891
+ application availability, dynamically scaling resources, optimizing compute, storing cluster data,
892
+ and performing other critical functions. With Amazon EKS, you get the robust performance,
893
+ scalability, reliability, and availability of AWS infrastructure, along with native integrations with
894
+ AWS networking, security, storage, and observability services.
895
+ Next steps
896
+
897
+ 24
898
+
899
+ Amazon EKS
900
+
901
+ User Guide
902
+
903
+ To simplify running Kubernetes in your on-premises environments, you can use the same Amazon
904
+ EKS clusters, features, and tools to the section called “Nodes” or Amazon EKS Hybrid Nodes on
905
+ your own infrastructure, or you can use Amazon EKS Anywhere for self-contained air-gapped
906
+ environments.
907
+
908
+ Amazon EKS in the cloud
909
+ You can use Amazon EKS with compute in AWS Regions, AWS Local Zones, and AWS Wavelength
910
+ Zones. With Amazon EKS in the cloud, the security, scalability, and availability of the Kubernetes
911
+ control plane is fully managed by AWS in the AWS Region. When running applications with
912
+ compute in AWS Regions, you get the full breadth of AWS and Amazon EKS features, including
913
+ Amazon EKS Auto Mode, which fully automates Kubernetes cluster infrastructure management
914
+ for compute, storage, and networking on AWS with a single click. When running applications with
915
+ compute in AWS Local Zones and AWS Wavelength Zones, you can use Amazon EKS self-managed
916
+ nodes to connect Amazon EC2 instances for your cluster compute and can use the other available
917
+ AWS services in AWS Local Zones and AWS Wavelength Zones. For more information see AWS Local
918
+ Zones features and AWS Wavelength Zones features.
919
+
920
+ Amazon EKS in AWS Regions
921
+
922
+ Amazon EKS in Local/Wav
923
+ elength Zones
924
+
925
+ Kuberenetes control plane
926
+ management
927
+
928
+ AWS-managed
929
+
930
+ AWS-managed
931
+
932
+ Kubernetes control plane
933
+ location
934
+
935
+ AWS Regions
936
+
937
+ AWS Regions
938
+
939
+ Kubernetes data plane
940
+
941
+ • Amazon EKS Auto Mode
942
+ • Amazon EKS Managed
943
+ Node Groups
944
+
945
+ • Amazon EKS Managed
946
+ Node Groups (Local Zones
947
+ only)
948
+
949
+ • Amazon EC2 self-managed
950
+ nodes
951
+
952
+ • Amazon EC2 self-managed
953
+ nodes
954
+
955
+ • AWS Fargate
956
+ Kubernetes data plane
957
+ location
958
+
959
+ Amazon EKS in the cloud
960
+
961
+ AWS Regions
962
+
963
+ AWS Local or Wavelength
964
+ Zones
965
+
966
+ 25
967
+
968
+ Amazon EKS
969
+
970
+ User Guide
971
+
972
+ Amazon EKS in your data center or edge environments
973
+ If you need to run applications in your own data centers or edge environments, you can use
974
+ Amazon EKS on AWS Outposts or Amazon EKS Hybrid Nodes. You can use self-managed nodes with
975
+ Amazon EC2 instances on AWS Outposts for your cluster compute, or you can use Amazon EKS
976
+ Hybrid Nodes with your own on-premises or edge infrastructure for your cluster compute. AWS
977
+ Outposts is AWS-managed infrastructure that you run in your data centers or co-location facilities,
978
+ whereas Amazon EKS Hybrid Nodes runs on your physical or virtual machines that you manage in
979
+ your on-premises or edge environments. Amazon EKS on AWS Outposts and Amazon EKS Hybrid
980
+ Nodes require a reliable connection from your on-premises environments to an AWS Region, and
981
+ you can use the same Amazon EKS clusters, features, and tools you use to run applications in the
982
+ cloud. When running on AWS Outposts, you can alternatively deploy the entire Kubernetes cluster
983
+ on AWS Outposts with Amazon EKS local clusters on AWS Outposts.
984
+ Amazon EKS Hybrid Nodes
985
+
986
+ Amazon EKS on AWS
987
+ Outposts
988
+
989
+ Kuberenetes control plane
990
+ management
991
+
992
+ AWS-managed
993
+
994
+ AWS-managed
995
+
996
+ Kubernetes control plane
997
+ location
998
+
999
+ AWS Regions
1000
+
1001
+ AWS Regions or AWS
1002
+ Outposts
1003
+
1004
+ Kubernetes data plane
1005
+
1006
+ Customer-managed physical
1007
+ or virtual machines
1008
+
1009
+ Amazon EC2 self-managed
1010
+ nodes
1011
+
1012
+ Kubernetes data plane
1013
+ location
1014
+
1015
+ Customer data center or edge
1016
+ environment
1017
+
1018
+ Customer data center or edge
1019
+ environment
1020
+
1021
+ Amazon EKS Anywhere for air-gapped environments
1022
+ Amazon EKS Anywhere simplifies Kubernetes cluster management through the automation
1023
+ of undifferentiated heavy lifting such as infrastructure setup and Kubernetes cluster lifecycle
1024
+ operations in on-premises and edge environments. Unlike Amazon EKS, Amazon EKS Anywhere is
1025
+ a customer-managed product and customers are responsible for cluster lifecycle operations and
1026
+ maintenance of Amazon EKS Anywhere clusters. Amazon EKS Anywhere is built on the Kubernetes
1027
+ sub-project Cluster API (CAPI) and supports a range of infrastructure including VMware vSphere,
1028
+ Amazon EKS in your data center or edge environments
1029
+
1030
+ 26
1031
+
1032
+ Amazon EKS
1033
+
1034
+ User Guide
1035
+
1036
+ bare metal, Nutanix, Apache CloudStack, and AWS Snow. Amazon EKS Anywhere can be run in airgapped environments and offers optional integrations with regional AWS services for observability
1037
+ and identity management. To receive support for Amazon EKS Anywhere and access to AWSvended Kubernetes add-ons, you can purchase Amazon EKS Anywhere Enterprise Subscriptions.
1038
+ Amazon EKS Anywhere
1039
+ Kuberenetes control plane management
1040
+
1041
+ Customer-managed
1042
+
1043
+ Kubernetes control plane location
1044
+
1045
+ Customer data center or edge environment
1046
+
1047
+ Kubernetes data plane
1048
+
1049
+ Customer-managed physical or virtual
1050
+ machines
1051
+
1052
+ Kubernetes data plane location
1053
+
1054
+ Customer data center or edge environment
1055
+
1056
+ Amazon EKS tooling
1057
+ You can use the Amazon EKS Connector to register and connect any conformant Kubernetes cluster
1058
+ to AWS and view it in the Amazon EKS console. After a cluster is connected, you can see the status,
1059
+ configuration, and workloads for that cluster in the Amazon EKS console. You can use this feature
1060
+ to view connected clusters in Amazon EKS console, but the Amazon EKS Connector does not
1061
+ enable management or mutating operations for your connected clusters through the Amazon EKS
1062
+ console.
1063
+ Amazon EKS Distro is the AWS distribution of the underlying Kubernetes components that power
1064
+ all Amazon EKS offerings. It includes the core components required for a functioning Kubernetes
1065
+ cluster such as Kubernetes control plane components (etcd, kube-apiserver, kube-scheduler, kubecontroller-manager) and networking components (CoreDNS, kube-proxy, CNI plugins). Amazon EKS
1066
+ Distro can be used to self-manage Kubernetes clusters with your choice of tooling. Amazon EKS
1067
+ Distro deployments are not covered by AWS Support Plans.
1068
+
1069
+ Amazon EKS tooling
1070
+
1071
+ 27
1072
+
1073
+ Amazon EKS
1074
+
1075
+ User Guide
1076
+
1077
+ Set up to use Amazon EKS
1078
+ To prepare for the command-line management of your Amazon EKS clusters, you need to install
1079
+ several tools. Use the following to set up credentials, create and modify clusters, and work with
1080
+ clusters once they are running:
1081
+ • Set up AWS CLI – Get the AWS CLI to set up and manage the services you need to work with
1082
+ Amazon EKS clusters. In particular, you need AWS CLI to configure credentials, but you also need
1083
+ it with other AWS services.
1084
+ • Set up kubectl and eksctl – The eksctl CLI interacts with AWS to create, modify, and delete
1085
+ Amazon EKS clusters. Once a cluster is up, use the open source kubectl command to manage
1086
+ Kubernetes objects within your Amazon EKS clusters.
1087
+ • Set up a development environment (optional)– Consider adding the following tools:
1088
+ • Local deployment tool – If you’re new to Kubernetes, consider installing a local deployment
1089
+ tool like minikube or kind. These tools allow you to have an Amazon EKS cluster on your local
1090
+ machine for testing applications.
1091
+ • Package manager – helm is a popular package manager for Kubernetes that simplifies the
1092
+ installation and management of complex packages. With Helm, it’s easier to install and
1093
+ manage packages like the AWS Load Balancer Controller on your Amazon EKS cluster.
1094
+
1095
+ Next steps
1096
+ • Set up AWS CLI
1097
+ • Set up kubectl and eksctl
1098
+ • Quickstart: Deploy a web app and store data
1099
+
1100
+ Set up AWS CLI
1101
+ The AWS CLI is a command line tool for working with AWS services, including Amazon EKS. It is
1102
+ also used to authenticate IAM users or roles for access to the Amazon EKS cluster and other AWS
1103
+ resources from your local machine. To provision resources in AWS from the command line, you
1104
+ need to obtain an AWS access key ID and secret key to use in the command line. Then you need to
1105
+ configure these credentials in the AWS CLI. If you haven’t already installed the AWS CLI, see Install
1106
+ or update the latest version of the AWS CLI in the AWS Command Line Interface User Guide.
1107
+ Next steps
1108
+
1109
+ 28
1110
+
1111
+ Amazon EKS
1112
+
1113
+ User Guide
1114
+
1115
+ To create an access key
1116
+ 1. Sign into the AWS Management Console.
1117
+ 2. For single-user or multiple-user accounts:
1118
+ • Single-user account –:: In the top right, choose your AWS user name to open the navigation
1119
+ menu. For example, choose webadmin .
1120
+ • Multiple-user account –:: Choose IAM from the list of services. From the IAM Dashboard,
1121
+ select Users, and choose the name of the user.
1122
+ 3. Choose Security credentials.
1123
+ 4. Under Access keys, choose Create access key.
1124
+ 5. Choose Command Line Interface (CLI), then choose Next.
1125
+ 6. Choose Create access key.
1126
+ 7. Choose Download .csv file.
1127
+
1128
+ To configure the AWS CLI
1129
+ After installing the AWS CLI, do the following steps to configure it. For more information, see
1130
+ Configure the AWS CLI in the AWS Command Line Interface User Guide.
1131
+ 1. In a terminal window, enter the following command:
1132
+ aws configure
1133
+
1134
+ Optionally, you can configure a named profile, such as --profile cluster-admin. If
1135
+ you configure a named profile in the AWS CLI, you must always pass this flag in subsequent
1136
+ commands.
1137
+ 2. Enter your AWS credentials. For example:
1138
+ Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
1139
+ Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
1140
+ Default region name [None]: region-code
1141
+ Default output format [None]: json
1142
+
1143
+ To create an access key
1144
+
1145
+ 29
1146
+
1147
+ Amazon EKS
1148
+
1149
+ User Guide
1150
+
1151
+ To get a security token
1152
+ If needed, run the following command to get a new security token for the AWS CLI. For more
1153
+ information, see get-session-token in the AWS CLI Command Reference.
1154
+ By default, the token is valid for 15 minutes. To change the default session timeout, pass the -duration-seconds flag. For example:
1155
+ aws sts get-session-token --duration-seconds 3600
1156
+
1157
+ This command returns the temporary security credentials for an AWS CLI session. You should see
1158
+ the following response output:
1159
+ {
1160
+ "Credentials": {
1161
+ "AccessKeyId": "ASIA5FTRU3LOEXAMPLE",
1162
+ "SecretAccessKey": "JnKgvwfqUD9mNsPoi9IbxAYEXAMPLE",
1163
+ "SessionToken": "VERYLONGSESSIONTOKENSTRING",
1164
+ "Expiration": "2023-02-17T03:14:24+00:00"
1165
+ }
1166
+ }
1167
+
1168
+ To verify the user identity
1169
+ If needed, run the following command to verify the AWS credentials for your IAM user identity
1170
+ (such as ClusterAdmin) for the terminal session.
1171
+ aws sts get-caller-identity
1172
+
1173
+ This command returns the Amazon Resource Name (ARN) of the IAM entity that’s configured for
1174
+ the AWS CLI. You should see the following example response output:
1175
+ {
1176
+ "UserId": "AKIAIOSFODNN7EXAMPLE",
1177
+ "Account": "01234567890",
1178
+ "Arn": "arn:aws:iam::01234567890:user/ClusterAdmin"
1179
+ }
1180
+
1181
+ To get a security token
1182
+
1183
+ 30
1184
+
1185
+ Amazon EKS
1186
+
1187
+ User Guide
1188
+
1189
+ Next steps
1190
+ • Set up kubectl and eksctl
1191
+ • Quickstart: Deploy a web app and store data
1192
+
1193
+ Set up kubectl and eksctl
1194
+ Once the AWS CLI is installed, there are two other tools you should install to create and manage
1195
+ your Kubernetes clusters:
1196
+ • kubectl: The kubectl command line tool is the main tool you will use to manage resources
1197
+ within your Kubernetes cluster. This page describes how to download and set up the kubectl
1198
+ binary that matches the version of your Kubernetes cluster. See Install or update kubectl.
1199
+ • eksctl: The eksctl command line tool is made for creating EKS clusters in the AWS cloud or
1200
+ on-premises (with EKS Anywhere), as well as modifying and deleting those clusters. See Install
1201
+ eksctl.
1202
+
1203
+ Install or update kubectl
1204
+ This topic helps you to download and install, or update, the kubectl binary on your device. The
1205
+ binary is identical to the upstream community versions. The binary is not unique to Amazon EKS
1206
+ or AWS. Use the steps below to get the specific version of kubectl that you need, although many
1207
+ builders simply run brew install kubectl to install it.
1208
+ Note
1209
+ You must use a kubectl version that is within one minor version difference of your
1210
+ Amazon EKS cluster control plane. For example, a 1.32 kubectl client works with
1211
+ Kubernetes 1.31, 1.32, and 1.33 clusters.
1212
+
1213
+ Step 1: Check if kubectl is installed
1214
+ Determine whether you already have kubectl installed on your device.
1215
+ kubectl version --client
1216
+
1217
+ Next steps
1218
+
1219
+ 31
1220
+
1221
+
dataset/docs/fargate.txt ADDED
@@ -0,0 +1,432 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ Amazon Elastic Container Service
2
+
3
+ Developer Guide
4
+
5
+ AWS Fargate for Amazon ECS
6
+ AWS Fargate is a technology that you can use with Amazon ECS to run containers without having
7
+ to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to
8
+ provision, configure, or scale clusters of virtual machines to run containers. This removes the need
9
+ to choose server types, decide when to scale your clusters, or optimize cluster packing.
10
+ When you run your tasks and services with the Fargate launch type, you package your application
11
+ in containers, specify the CPU and memory requirements, define networking and IAM policies, and
12
+ launch the application. Each Fargate task has its own isolation boundary and does not share the
13
+ underlying kernel, CPU resources, memory resources, or elastic network interface with another
14
+ task. You configure your task definitions for Fargate by setting the requiresCompatibilities
15
+ task definition parameter to FARGATE. For more information, see Launch types.
16
+ Fargate offers platform versions for Amazon Linux 2 (platform version 1.3.0), Bottlerocket
17
+ operating system (platform version 1.4.0), and Microsoft Windows 2019 Server Full and Core
18
+ editions.Unless otherwise specified, the information on this page applies to all Fargate platforms.
19
+ This topic describes the different components of Fargate tasks and services, and calls out special
20
+ considerations for using Fargate with Amazon ECS.
21
+ For information about the Regions that support Linux containers on Fargate, see the section called
22
+ “Linux containers on AWS Fargate”.
23
+ For information about the Regions that support Windows containers on Fargate, see the section
24
+ called “Windows containers on AWS Fargate”.
25
+
26
+ Walkthroughs
27
+ For information about how to get started using the console, see:
28
+ • Learn how to create an Amazon ECS Linux task for the Fargate launch type
29
+ • Learn how to create an Amazon ECS Windows task for the Fargate launch type
30
+ For information about how to get started using the AWS CLI, see:
31
+ • Creating an Amazon ECS Linux task for the Fargate launch type with the AWS CLI
32
+ Walkthroughs
33
+
34
+ 167
35
+
36
+ Amazon Elastic Container Service
37
+
38
+ Developer Guide
39
+
40
+ • Creating an Amazon ECS Windows task for the Fargate launch type with the AWS CLI
41
+
42
+ Capacity providers
43
+ The following capacity providers are available:
44
+ • Fargate
45
+ • Fargate Spot - Run interruption tolerant Amazon ECS tasks at a discounted rate compared to
46
+ the AWS Fargate price. Fargate Spot runs tasks on spare compute capacity. When AWS needs the
47
+ capacity back, your tasks will be interrupted with a two-minute warning. For more information,
48
+ see Amazon ECS clusters for Fargate.
49
+
50
+ Task definitions
51
+ Tasks that use the Fargate launch type don't support all of the Amazon ECS task definition
52
+ parameters that are available. Some parameters aren't supported at all, and others behave
53
+ differently for Fargate tasks. For more information, see Task CPU and memory.
54
+
55
+ Platform versions
56
+ AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate
57
+ task infrastructure. It is a combination of the kernel and container runtime versions. You select
58
+ a platform version when you run a task or when you create a service to maintain a number of
59
+ identical tasks.
60
+ New revisions of platform versions are released as the runtime environment evolves, for example,
61
+ if there are kernel or operating system updates, new features, bug fixes, or security updates. A
62
+ Fargate platform version is updated by making a new platform version revision. Each task runs on
63
+ one platform version revision during its lifecycle. If you want to use the latest platform version
64
+ revision, then you must start a new task. A new task that runs on Fargate always runs on the
65
+ latest revision of a platform version, ensuring that tasks are always started on secure and patched
66
+ infrastructure.
67
+ If a security issue is found that affects an existing platform version, AWS creates a new patched
68
+ revision of the platform version and retires tasks running on the vulnerable revision. In some cases,
69
+ you may be notified that your tasks on Fargate have been scheduled for retirement. For more
70
+ information, see Task retirement and maintenance for AWS Fargate on Amazon ECS .
71
+ Capacity providers
72
+
73
+ 168
74
+
75
+ Amazon Elastic Container Service
76
+
77
+ Developer Guide
78
+
79
+ For more information see Fargate platform versions for Amazon ECS.
80
+
81
+ Service load balancing
82
+ Your Amazon ECS service on AWS Fargate can optionally be configured to use Elastic Load
83
+ Balancing to distribute traffic evenly across the tasks in your service.
84
+ Amazon ECS services on AWS Fargate support the Application Load Balancer, Network Load
85
+ Balancer, and load balancer types. Application Load Balancers are used to route HTTP/HTTPS (or
86
+ layer 7) traffic. Network Load Balancers are used to route TCP or UDP (or layer 4) traffic. For more
87
+ information, see Use load balancing to distribute Amazon ECS service traffic.
88
+ When you create a target group for these services, you must choose ip as the target type, not
89
+ instance. This is because tasks that use the awsvpc network mode are associated with an elastic
90
+ network interface, not an Amazon EC2 instance. For more information, see Use load balancing to
91
+ distribute Amazon ECS service traffic.
92
+ Using a Network Load Balancer to route UDP traffic to your Amazon ECS on AWS Fargate tasks is
93
+ only supported when using platform version 1.4 or later.
94
+
95
+ Usage metrics
96
+ You can use CloudWatch usage metrics to provide visibility into your accounts usage of resources.
97
+ Use these metrics to visualize your current service usage on CloudWatch graphs and dashboards.
98
+ AWS Fargate usage metrics correspond to AWS service quotas. You can configure alarms that alert
99
+ you when your usage approaches a service quota. For more information about AWS Fargate service
100
+ quotas, Amazon ECS endpoints and quotas in the Amazon Web Services General Reference..
101
+ For more information about AWS Fargate usage metrics, see AWS Fargate usage metrics.
102
+
103
+ Amazon ECS security considerations for when to use the
104
+ Fargate launch type
105
+ We recommend that customers looking for strong isolation for their tasks use Fargate. Fargate
106
+ runs each task in a hardware virtualization environment. This ensures that these containerized
107
+ workloads do not share network interfaces, Fargate ephemeral storage, CPU, or memory with other
108
+ tasks. For more information, see Security Overview of AWS Fargate.
109
+ Service load balancing
110
+
111
+ 169
112
+
113
+ Amazon Elastic Container Service
114
+
115
+ Developer Guide
116
+
117
+ Fargate security best practices in Amazon ECS
118
+ We recommend that you take into account the following best practices when you use AWS Fargate.
119
+ For additional guidance, see Security overview of AWS Fargate.
120
+
121
+ Use AWS KMS to encrypt ephemeral storage for Fargate
122
+ You should have your ephemeral storage encrypted by either AWS KMS or your own customer
123
+ managed keys. For tasks that are hosted on Fargate using platform version 1.4.0 or later, each
124
+ task receives 20 GiB of ephemeral storage. For more information, see customer managed key
125
+ (CMK). You can increase the total amount of ephemeral storage, up to a maximum of 200 GiB,
126
+ by specifying the ephemeralStorage parameter in your task definition. For such tasks that
127
+ were launched on May 28, 2020 or later, the ephemeral storage is encrypted with an AES-256
128
+ encryption algorithm using an encryption key managed by Fargate.
129
+ For more information, see Storage options for Amazon ECS tasks.
130
+ Example: Launching an task on Fargate platform version 1.4.0 with ephemeral storage
131
+ encryption
132
+ The following command will launch a task on Fargate platform version 1.4. Because this task
133
+ is launched as part of the cluster, it uses the 20 GiB of ephemeral storage that's automatically
134
+ encrypted.
135
+ aws ecs run-task --cluster clustername \
136
+ --task-definition taskdefinition:version \
137
+ --count 1
138
+ --launch-type "FARGATE" \
139
+ --platform-version 1.4.0 \
140
+ --network-configuration
141
+ "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
142
+ --region region
143
+
144
+ SYS_PTRACE capability for kernel syscall tracing with Fargate
145
+ The default configuration of Linux capabilities that are added or removed from your container are
146
+ provided by Docker.
147
+ Tasks that are launched on Fargate only support adding the SYS_PTRACE kernel capability.
148
+ The following video shows how to use this feature through the Sysdig Falco project.
149
+ Fargate security best practices
150
+
151
+ 170
152
+
153
+ Amazon Elastic Container Service
154
+
155
+ Developer Guide
156
+
157
+ #ContainersFromTheCouch - Troubleshooting your Fargate Task using SYS_PTRACE capability
158
+ The code discussed in the previous video can be found on GitHub here.
159
+
160
+ Use Amazon GuardDuty with Fargate Runtime Monitoring
161
+ Amazon GuardDuty is a threat detection service that helps protect your accounts, containers,
162
+ workloads, and the data within your AWS environment. Using machine learning (ML) models, and
163
+ anomaly and threat detection capabilities, GuardDuty continuously monitors different log sources
164
+ and runtime activity to identify and prioritize potential security risks and malicious activities in
165
+ your environment.
166
+ Runtime Monitoring in GuardDuty protects workloads running on Fargate by continuously
167
+ monitoring AWS log and networking activity to identify malicious or unauthorized behavior.
168
+ Runtime Monitoring uses a lightweight, fully managed GuardDuty security agent that analyzes onhost behavior, such as file access, process execution, and network connections. This covers issues
169
+ including escalation of privileges, use of exposed credentials, or communication with malicious IP
170
+ addresses, domains, and the presence of malware on your Amazon EC2 instances and container
171
+ workloads. For more information, see GuardDuty Runtime Monitoring in the GuardDuty User Guide.
172
+
173
+ Fargate security considerations for Amazon ECS
174
+ Each task has a dedicated infrastructure capacity because Fargate runs each workload on an
175
+ isolated virtual environment. Workloads that run on Fargate do not share network interfaces,
176
+ ephemeral storage, CPU, or memory with other tasks. You can run multiple containers within a task
177
+ including application containers and sidecar containers, or simply sidecars. A sidecar is a container
178
+ that runs alongside an application container in an Amazon ECS task. While the application
179
+ container runs core application code, processes running in sidecars can augment the application.
180
+ Sidecars help you segregate application functions into dedicated containers, making it easier for
181
+ you to update parts of your application.
182
+ Containers that are part of the same task share resources for the Fargate launch type because
183
+ these containers will always run on the same host and share compute resources. These containers
184
+ also share the ephemeral storage provided by Fargate. Linux containers in a task share network
185
+ namespaces, including the IP address and network ports. Inside a task, containers that belong to
186
+ the task can inter-communicate over localhost.
187
+ The runtime environment in Fargate prevents you from using certain controller features that are
188
+ supported on EC2 instances. Consider the following when you architect workloads that run on
189
+ Fargate:
190
+ Use Amazon GuardDuty with Fargate Runtime Monitoring
191
+
192
+ 171
193
+
194
+ Amazon Elastic Container Service
195
+
196
+ Developer Guide
197
+
198
+ • No privileged containers or access - Features such as privileged containers or access are currently
199
+ unavailable on Fargate. This will affect uses cases such as running Docker in Docker.
200
+ • Limited access to Linux capabilities - The environment in which containers run on Fargate is
201
+ locked down. Additional Linux capabilities, such as CAP_SYS_ADMIN and CAP_NET_ADMIN, are
202
+ restricted to prevent a privilege escalation. Fargate supports adding the CAP_SYS_PTRACE Linux
203
+ capability to tasks to allow observability and security tools deployed within the task to monitor
204
+ the containerized application.
205
+ • No access to the underlying host - Neither customers nor AWS operators can connect to a host
206
+ running customer workloads. You can use ECS exec to run commands in or get a shell to a
207
+ container running on Fargate. You can use ECS exec to help collect diagnostic information for
208
+ debugging. Fargate also prevents containers from accessing the underlying host’s resources, such
209
+ as the file system, devices, networking, and container runtime.
210
+ • Networking - You can use security groups and network ACLs to control inbound and outbound
211
+ traffic. Fargate tasks receive an IP address from the configured subnet in your VPC.
212
+
213
+ Fargate platform versions for Amazon ECS
214
+ AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate
215
+ task infrastructure. It is a combination of the kernel and container runtime versions. You select
216
+ a platform version when you run a task or when you create a service to maintain a number of
217
+ identical tasks.
218
+ New revisions of platform versions are released as the runtime environment evolves, for example,
219
+ if there are kernel or operating system updates, new features, bug fixes, or security updates. A
220
+ Fargate platform version is updated by making a new platform version revision. Each task runs on
221
+ one platform version revision during its lifecycle. If you want to use the latest platform version
222
+ revision, then you must start a new task. A new task that runs on Fargate always runs on the
223
+ latest revision of a platform version, ensuring that tasks are always started on secure and patched
224
+ infrastructure.
225
+ If a security issue is found that affects an existing platform version, AWS creates a new patched
226
+ revision of the platform version and retires tasks running on the vulnerable revision. In some cases,
227
+ you may be notified that your tasks on Fargate have been scheduled for retirement. For more
228
+ information, see Task retirement and maintenance for AWS Fargate on Amazon ECS .
229
+ You specify the platform version when you run a task, or deploy a service.
230
+ Fargate platform versions
231
+
232
+ 172
233
+
234
+ Amazon Elastic Container Service
235
+
236
+ Developer Guide
237
+
238
+ Consider the following when specifying a platform version:
239
+ • You can specify a a specific version number, for example 1.4.0, or LATEST.
240
+ The LATEST Linux platform version is 1.4.0.
241
+ The LATEST Windows platform version is 1.0.0.
242
+ • If you want to update the platform version for a service, create a deployment. For example,
243
+ assume that you have a service that runs tasks on the Linux platform version 1.3.0. To change
244
+ the service to run tasks on the Linux platform version 1.4.0, you update your service and
245
+ specify a new platform version. Your tasks are redeployed with the latest platform version and
246
+ the latest platform version revision. For more information about deployments, see Amazon ECS
247
+ services.
248
+ • If your service is scaled up without updating the platform version, those tasks receive the
249
+ platform version that was specified on the service's current deployment. For example, assume
250
+ that you have a service that runs tasks on the Linux platform version 1.3.0. If you increase the
251
+ desired count of the service, the service scheduler starts the new tasks using the latest platform
252
+ version revision of platform version 1.3.0.
253
+ • New tasks always run on the latest revision of a platform version. This ensures tasks are always
254
+ on secured and patched infrastructure.
255
+ • The platform version numbers for Linux containers and Windows containers on Fargate are
256
+ independent. For example, the behavior, features, and software used in platform version 1.0.0
257
+ for Windows containers on Fargate aren't comparable to those of platform version 1.0.0 for
258
+ Linux containers on Fargate.
259
+ • The following applies to Fargate Windows platform versions.
260
+ Microsoft Windows Server container images must be created from a specific version of Windows
261
+ Server. You must select the same version of Windows Server in the platformFamily when you
262
+ run a task or create a service that matches the Windows Server container image. Additionally,
263
+ you can provide a matching operatingSystemFamily in the task definition to prevent tasks
264
+ from being run on the wrong Windows version. For more information, see Matching container
265
+ host version with container image versions on the Microsoft Learn website.
266
+
267
+ Fargate platform versions
268
+
269
+ 173
270
+
271
+ Amazon Elastic Container Service
272
+
273
+ Developer Guide
274
+
275
+ Migrating to Linux platform version 1.4.0 on Amazon ECS
276
+ Consider the following when migrating your Amazon ECS on Fargate tasks from platform version
277
+ 1.0.0, 1.1.0, 1.2.0, or 1.3.0 to platform version 1.4.0. It is best practice to confirm your task
278
+ works properly on platform version 1.4.0 before you migrate the tasks.
279
+ • The network traffic behavior to and from tasks has been updated. Starting with platform version
280
+ 1.4.0, all Amazon ECS on Fargate tasks receive a single elastic network interface (referred to as
281
+ the task ENI) and all network traffic flows through that ENI within your VPC. The traffic is visible
282
+ to you through your VPC flow logs. For more information see Amazon ECS task networking
283
+ options for the Fargate launch type.
284
+ • If you use interface VPC endpoints, consider the following.
285
+ • For container images hosted with Amazon ECR, you need the following endpoints. For more
286
+ information, see Amazon ECR interface VPC endpoints (AWS PrivateLink) in the Amazon Elastic
287
+ Container Registry User Guide.
288
+ • com.amazonaws.region.ecr.dkr Amazon ECR VPC endpoint
289
+ • com.amazonaws.region.ecr.api Amazon ECR VPC endpoint
290
+ • Amazon S3 gateway endpoint
291
+ • When your task definition references Secrets Manager secrets to retrieve sensitive data for
292
+ your containers, you must create the interface VPC endpoints for Secrets Manager. For more
293
+ information, see Using Secrets Manager with VPC Endpoints in the AWS Secrets Manager User
294
+ Guide.
295
+ • When your task definition references Systems Manager Parameter Store parameters to retrieve
296
+ sensitive data for your containers, you must create the interface VPC endpoints for Systems
297
+ Manager. For more information, see Improve the security of EC2 instances by using VPC
298
+ endpoints for Systems Manager in the AWS Systems Manager User Guide.
299
+ • The security group for the Elastic Network Interface (ENI) associated with your task needs the
300
+ security group rules to allow traffic between the task and the VPC endpoints.
301
+
302
+ Fargate Linux platform version change log
303
+ The following are the available Linux platform versions. For information about platform version
304
+ deprecation, see AWS Fargate Linux platform version deprecation.
305
+
306
+ Migrating to Linux platform version 1.4.0
307
+
308
+ 174
309
+
310
+ Amazon Elastic Container Service
311
+
312
+ Developer Guide
313
+
314
+ 1.4.0
315
+ The following is the changelog for platform version 1.4.0.
316
+ • Beginning on November 5, 2020, any new Amazon ECS task launched on Fargate using platform
317
+ version 1.4.0 will be able to use the following features:
318
+ • When using Secrets Manager to store sensitive data, you can inject a specific JSON key or
319
+ a specific version of a secret as an environment variable or in a log configuration. For more
320
+ information, see Pass sensitive data to an Amazon ECS container.
321
+ • Specify environment variables in bulk using the environmentFiles container definition
322
+ parameter. For more information, see Pass an individual environment variable to an Amazon
323
+ ECS container.
324
+ • Tasks run in a VPC and subnet enabled for IPv6 will be assigned both a private IPv4 address
325
+ and an IPv6 address. For more information, see Amazon ECS task networking options for the
326
+ Fargate launch type.
327
+ • The task metadata endpoint version 4 provides additional metadata about your task and
328
+ container including the task launch type, the Amazon Resource Name (ARN) of the container,
329
+ and the log driver and log driver options used. When querying the /stats endpoint you
330
+ also receive network rate stats for your containers. For more information, see Task metadata
331
+ endpoint version 4.
332
+ • Beginning on July 30, 2020, any new Amazon ECS task launched on Fargate using platform
333
+ version 1.4.0 will be able to route UDP traffic using a Network Load Balancer to their Amazon
334
+ ECS on Fargate tasks. For more information, see Use load balancing to distribute Amazon ECS
335
+ service traffic.
336
+ • Beginning on May 28, 2020, any new Amazon ECS task launched on Fargate using platform
337
+ version 1.4.0 will have its ephemeral storage encrypted with an AES-256 encryption algorithm
338
+ using an AWS owned encryption key. For more information, see Fargate task ephemeral storage
339
+ for Amazon ECS and Storage options for Amazon ECS tasks.
340
+ • Added support for using Amazon EFS file system volumes for persistent task storage. For more
341
+ information, see Use Amazon EFS volumes with Amazon ECS.
342
+ • The ephemeral task storage has been increased to a minimum of 20 GB for each task. For more
343
+ information, see Fargate task ephemeral storage for Amazon ECS.
344
+ • The network traffic behavior to and from tasks has been updated. Starting with platform version
345
+ 1.4.0, all Fargate tasks receive a single elastic network interface (referred to as the task ENI) and
346
+ all network traffic flows through that ENI within your VPC and will be visible to you through
347
+ Linux Platform version change log
348
+
349
+ 175
350
+
351
+ Amazon Elastic Container Service
352
+
353
+ Developer Guide
354
+
355
+ your VPC flow logs. For more information about networking for the Amazon EC2 launch type,
356
+ see Amazon ECS task networking options for the EC2 launch type. For more information about
357
+ networking for the Fargate launch type, see Amazon ECS task networking options for the Fargate
358
+ launch type.
359
+ • Task ENIs add support for jumbo frames. Network interfaces are configured with a maximum
360
+ transmission unit (MTU), which is the size of the largest payload that fits within a single frame.
361
+ The larger the MTU, the more application payload can fit within a single frame, which reduces
362
+ per-frame overhead and increases efficiency. Supporting jumbo frames will reduce overhead
363
+ when the network path between your task and the destination supports jumbo frames, such as
364
+ all traffic that remains within your VPC.
365
+ • CloudWatch Container Insights will include network performance metrics for Fargate tasks. For
366
+ more information, see Monitor Amazon ECS containers using Container Insights with enhanced
367
+ observability.
368
+ • Added support for the task metadata endpoint version 4 which provides additional information
369
+ for your Fargate tasks, including network stats for the task and which Availability Zone the task
370
+ is running in. For more information, see Amazon ECS task metadata endpoint version 4 and
371
+ Amazon ECS task metadata endpoint version 4 for tasks on Fargate.
372
+ • Added support for the SYS_PTRACE Linux parameter in container definitions. For more
373
+ information, see Linux parameters.
374
+ • The Fargate container agent replaces the use of the Amazon ECS container agent for all Fargate
375
+ tasks. Usually, this change does not have an effect on how your tasks run.
376
+ • The container runtime is now using Containerd instead of Docker. Most likely, this change does
377
+ not have an effect on how your tasks run. You will notice that some error messages that originate
378
+ with the container runtime changes from mentioning Docker to more general errors. For more
379
+ information, see Amazon ECS stopped task error messages.
380
+ • Based on Amazon Linux 2.
381
+ 1.3.0
382
+ The following is the changelog for platform version 1.3.0.
383
+ • Beginning on Sept 30, 2019, any new Fargate task that is launched supports the awsfirelens
384
+ log driver. Configure the FireLens for Amazon ECS to use task definition parameters to route logs
385
+ to an AWS service or AWS Partner Network (APN) destination for log storage and analytics. For
386
+ more information, see Send Amazon ECS logs to an AWS service or AWS Partner.
387
+ Linux Platform version change log
388
+
389
+ 176
390
+
391
+ Amazon Elastic Container Service
392
+
393
+ Developer Guide
394
+
395
+ • Added task recycling for Fargate tasks, which is the process of refreshing tasks that are a part of
396
+ an Amazon ECS service. For more information, Task retirement and maintenance for AWS Fargate
397
+ on Amazon ECS.
398
+ • Beginning on March 27, 2019, any new Fargate task that is launched can use additional task
399
+ definition parameters that you use to define a proxy configuration, dependencies for container
400
+ startup and shutdown as well as a per-container start and stop timeout value. For more
401
+ information, see Proxy configuration, Container dependency, and Container timeouts.
402
+ • Beginning on April 2, 2019, any new Fargate task that is launched supports injecting sensitive
403
+ data into your containers by storing your sensitive data in either AWS Secrets Manager secrets or
404
+ AWS Systems Manager Parameter Store parameters and then referencing them in your container
405
+ definition. For more information, see Pass sensitive data to an Amazon ECS container.
406
+ • Beginning on May 1, 2019, any new Fargate task that is launched supports referencing sensitive
407
+ data in the log configuration of a container using the secretOptions container definition
408
+ parameter. For more information, see Pass sensitive data to an Amazon ECS container.
409
+ • Beginning on May 1, 2019, any new Fargate task that is launched supports the splunk log driver
410
+ in addition to the awslogs log driver. For more information, see Storage and logging.
411
+ • Beginning on July 9, 2019, any new Fargate tasks that is launched supports CloudWatch
412
+ Container Insights. For more information, see Monitor Amazon ECS containers using Container
413
+ Insights with enhanced observability.
414
+ • Beginning on December 3, 2019, the Fargate Spot capacity provider is supported. For more
415
+ information, see Amazon ECS clusters for Fargate.
416
+ • Based on Amazon Linux 2.
417
+
418
+ AWS Fargate Linux platform version deprecation
419
+ This page lists Linux platform versions that AWS Fargate has deprecated or have been scheduled
420
+ for deprecation. These platform versions remain available until the published deprecation date.
421
+ A force update date is provided for each platform version scheduled for deprecation. On the force
422
+ update date, any service using the LATEST platform version that is pointed to a platform version
423
+ that is scheduled for deprecation will be updated using the force new deployment option. When
424
+ the service is updated using the force new deployment option, all tasks running on a platform
425
+ version scheduled for deprecation are stopped and new tasks are launched using the platform
426
+ version that the LATEST tag points to at that time. Standalone tasks or services with an explicit
427
+ platform version set are not affected by the force update date.
428
+ Linux platform version deprecation
429
+
430
+ 177
431
+
432
+
dataset/docs/lambda-dg.txt ADDED
@@ -0,0 +1,755 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ AWS Lambda
2
+
3
+ Developer Guide
4
+
5
+ What is AWS Lambda?
6
+ You can use AWS Lambda to run code without provisioning or managing servers. Lambda runs
7
+ your code on a high-availability compute infrastructure and manages all the computing resources,
8
+ including server and operating system maintenance, capacity provisioning, automatic scaling, and
9
+ logging. You organize your code into Lambda functions. The Lambda service runs your function
10
+ only when needed and scales automatically. For pricing information, see AWS Lambda Pricing for
11
+ details.
12
+ When using Lambda, you are responsible only for your code. Lambda manages the compute fleet
13
+ that offers a balance of memory, CPU, network, and other resources to run your code. Because
14
+ Lambda manages these resources, you cannot log in to compute instances or customize the
15
+ operating system on provided runtimes.
16
+
17
+ When to use Lambda
18
+ Lambda is an ideal compute service for application scenarios that need to scale up rapidly, and
19
+ scale down to zero when not in demand. For example, you can use Lambda for:
20
+ • Stream processing: Use Lambda and Amazon Kinesis to process real-time streaming data for
21
+ application activity tracking, transaction order processing, clickstream analysis, data cleansing,
22
+ log filtering, indexing, social media analysis, Internet of Things (IoT) device data telemetry, and
23
+ metering.
24
+ • Web applications: Combine Lambda with other AWS services to build powerful web applications
25
+ that automatically scale up and down and run in a highly available configuration across multiple
26
+ data centers. To build web applications with AWS services, developers can use infrastructure as
27
+ code (IaC) and orchestration tools such as AWS CloudFormation, AWS Cloud Development Kit
28
+ (AWS CDK), AWS Serverless Application Model, or coordinate complex workflows using AWS Step
29
+ Functions.
30
+ • Mobile backends: Build backends using Lambda and Amazon API Gateway to authenticate and
31
+ process API requests. Use AWS Amplify to easily integrate with your iOS, Android, Web, and
32
+ React Native frontends.
33
+ • IoT backends: Build serverless backends using Lambda to handle web, mobile, IoT, and thirdparty API requests.
34
+ • File processing: Use Amazon Simple Storage Service (Amazon S3) to trigger Lambda data
35
+ processing in real time after an upload.
36
+ When to use Lambda
37
+
38
+ 1
39
+
40
+ AWS Lambda
41
+
42
+ Developer Guide
43
+
44
+ • Database Operations and Integration: Use Lambda to process database interactions both
45
+ reactively and proactively, from handling queue messages for Amazon RDS operations like user
46
+ registrations and order submissions, to responding to DynamoDB changes for audit logging, data
47
+ replication, and automated workflows.
48
+ • Scheduled and Periodic Tasks: Use Lambda with EventBridge rules to execute time-based
49
+ operations such as database maintenance, data archiving, report generation, and other
50
+ scheduled business processes using cron-like expressions.
51
+
52
+ How Lambda works
53
+ Because Lambda is a serverless, event-driven compute service, it uses a different programming
54
+ paradigm than traditional web applications. The following model illustrates how Lambda
55
+ fundamentally works:
56
+ 1. You write and organize your code in Lambda functions, which are the basic building blocks you
57
+ use to create a Lambda application.
58
+ 2. You control security and access through Lambda permissions, using execution roles to manage
59
+ what AWS services your functions can interact with and what resource policies can interact with
60
+ your code.
61
+ 3. Event sources and AWS services trigger your Lambda functions, passing event data in JSON
62
+ format, which your functions process (this includes event source mappings).
63
+ 4. Lambda runs your code with language-specific runtimes (like Node.js and Python) in execution
64
+ environments that package your runtime, layers, and extensions.
65
+
66
+ Tip
67
+ To learn how to build serverless solutions, check out the Serverless Developer Guide.
68
+
69
+ Key features
70
+ Configure, control, and deploy secure applications:
71
+ • Environment variables modify application behavior without new code deployments.
72
+ • Versions safely test new features while maintaining stable production environments.
73
+ How Lambda works
74
+
75
+ 2
76
+
77
+ AWS Lambda
78
+
79
+ Developer Guide
80
+
81
+ • Lambda layers optimize code reuse and maintenance by sharing common components across
82
+ multiple functions.
83
+ • Code signing enforce security compliance by ensuring only approved code reaches production
84
+ systems.
85
+
86
+ Scale and perform reliably:
87
+ • Concurrency and scaling controls precisely manage application responsiveness and resource
88
+ utilization during traffic spikes.
89
+ • Lambda SnapStart significantly reduce cold start times. Lambda SnapStart can provide as low as
90
+ sub-second startup performance, typically with no changes to your function code.
91
+ • Response streaming optimize function performance by delivering large payloads incrementally
92
+ for real-time processing.
93
+ • Container images package functions with complex dependencies using container workflows.
94
+
95
+ Connect and integrate seamlessly:
96
+ • VPC networks secure sensitive resources and internal services.
97
+ • File system integration that shares persistent data and manage stateful operations across
98
+ function invocations.
99
+ • Function URLs create public-facing APIs and endpoints without additional services.
100
+ • Lambda extensions augment functions with monitoring, security, and operational tools.
101
+
102
+ Related information
103
+ • For information on how Lambda works, see How Lambda works.
104
+ • To start using Lambda, see Create your first Lambda function.
105
+ • For a list of example applications, see Getting started with example applications and patterns.
106
+
107
+ How Lambda works
108
+ Lambda functions are the basic building blocks you use to build Lambda applications. To write
109
+ functions, it's essential to understand the core concepts and components that make up the Lambda
110
+ Related information
111
+
112
+ 3
113
+
114
+ AWS Lambda
115
+
116
+ Developer Guide
117
+
118
+ programming model. This section will guide you through the fundamental elements you need to
119
+ know to start building serverless applications with Lambda.
120
+ • Lambda functions and function handlers - A Lambda function is a small block of code that
121
+ runs in response to events. functions are the basic building blocks you use to build applications.
122
+ Function handlers are the entry point for event objects that your Lambda function code
123
+ processes.
124
+ • Lambda execution environment and runtimes - Lambda execution environments manage the
125
+ resources required to run your function. Run times are the language-specific environments your
126
+ functions run in.
127
+ • Events and triggers - how other AWS services invoke your functions in response to specific
128
+ events.
129
+ • Lambda permissions and roles - how you control who can access your functions and what other
130
+ AWS services your functions can interact with.
131
+
132
+ Tip
133
+ If you want to start by understanding serverless development more generally, see
134
+ Understanding the difference between traditional and serverless development in the AWS
135
+ Serverless Developer Guide.
136
+
137
+ Lambda functions and function handlers
138
+ In Lambda, functions are the fundamental building blocks you use to create applications. A
139
+ Lambda function is a piece of code that runs in response to events, such as a user clicking a button
140
+ on a website or a file being uploaded to an Amazon Simple Storage Service (Amazon S3) bucket.
141
+ You can think of a function as a kind of self-contained program with the following properties.
142
+ A Lambda function handler is the method in your function code that processes events. When a
143
+ function runs in response to an event, Lambda runs the function handler. Data about the event
144
+ that caused the function to run is passed directly to the handler. While the code in a Lambda
145
+ function can contain more than one method or function, Lambda functions can only have one
146
+ handler.
147
+ To create a Lambda function, you bundle your function code and its dependencies in a deployment
148
+ package. Lambda supports two types of deployment package, .zip file archives and container
149
+ images.
150
+ Lambda functions and function handlers
151
+
152
+ 4
153
+
154
+ AWS Lambda
155
+
156
+ Developer Guide
157
+
158
+ • A function has one specific job or purpose
159
+ • They run only when needed in response to specific events
160
+ • They automatically stop running when finished
161
+
162
+ Lambda execution environment and runtimes
163
+ Lambda functions run inside a secure, isolated execution environment which Lambda manages for
164
+ you. This execution environment manages the processes and resources that are needed to run your
165
+ function. When a function is first invoked, Lambda creates a new execution environment for the
166
+ function to run in. After the function has finished running, Lambda doesn't stop the execution
167
+ environment right away; if the function is invoked again, Lambda can re-use the existing execution
168
+ environment.
169
+ The Lambda execution environment also contains a runtime, a language-specific environment that
170
+ relays event information and responses between Lambda and your function. Lambda provides a
171
+ number of managed runtimes for the most popular programming languages, or you can create
172
+ your own.
173
+ For managed runtimes, Lambda automatically applies security updates and patches to functions
174
+ using the runtime.
175
+
176
+ Events and triggers
177
+ You can also invoke a Lambda function directly by using the Lambda console, AWS CLI, or one of
178
+ the AWS Software Development Kits (SDKs). It's more usual in a production application for your
179
+ function to be invoked by another AWS service in response to a particular event. For example, you
180
+ might want a function to run whenever an item is added to an Amazon DynamoDB table.
181
+ To make your function respond to events, you set up a trigger. A trigger connects your function
182
+ to an event source, and your function can have multiple triggers. When an event occurs, Lambda
183
+ receives event data as a JSON document and converts it into an object that your code can process.
184
+ You might define the following JSON format for your event and the Lambda runtime converts this
185
+ JSON to an object before passing it to your function's handler.
186
+ Example custom Lambda event
187
+ {
188
+ "Location": "SEA",
189
+ "WeatherData":{
190
+ Lambda execution environment and runtimes
191
+
192
+ 5
193
+
194
+ AWS Lambda
195
+
196
+ Developer Guide
197
+
198
+ "TemperaturesF":{
199
+ "MinTempF": 22,
200
+ "MaxTempF": 78
201
+ },
202
+ "PressuresHPa":{
203
+ "MinPressureHPa": 1015,
204
+ "MaxPressureHPa": 1027
205
+ }
206
+ }
207
+ }
208
+
209
+ Stream and queue services like Amazon Kinesis or Amazon SQS, Lambda use an event source
210
+ mapping instead of a standard trigger. Event source mappings poll the source for new data, batch
211
+ records together, and then invoke your function with the batched events. For more information,
212
+ see How event source mappings differ from direct triggers.
213
+ To understand how a trigger works, start by completing the Use an Amazon S3 trigger tutorial, or
214
+ for a general overview of using triggers and instructions on creating a trigger using the Lambda
215
+ console, see Integrating other services.
216
+
217
+ Lambda permissions and roles
218
+ For Lambda, there are two main types of permissions that you need to configure:
219
+ • Permissions that your function needs to access other AWS services
220
+ • Permissions that other users and AWS services need to access your function
221
+ The following sections describe both of these permission types and discuss best practices for
222
+ applying least-privilege permissions.
223
+
224
+ Permissions for functions to access other AWS resources
225
+ Lambda functions often need to access other AWS resources and perform actions on them. For
226
+ example, a function might read items from a DynamoDB table, store an object in an S3 bucket,
227
+ or write to an Amazon SQS queue. To give functions the permissions they need to perform these
228
+ actions, you use an execution role.
229
+ A Lambda execution role is a special kind of AWS Identity and Access Management (IAM) role, an
230
+ identity you create in your account that has specific permissions associated with it defined in a
231
+ policy.
232
+ Lambda permissions and roles
233
+
234
+ 6
235
+
236
+ AWS Lambda
237
+
238
+ Developer Guide
239
+
240
+ Every Lambda function must have an execution role, and a single role can be used by more than
241
+ one function. When a function is invoked, Lambda assumes the function's execution role and is
242
+ granted permission to take the actions defined in the role's policy.
243
+ When you create a function in the Lambda console, Lambda automatically creates an execution
244
+ role for your function. The role's policy gives your function basic permissions to write log outputs
245
+ to Amazon CloudWatch Logs. To give your function permission to perform actions on other
246
+ AWS resources, you need to edit the role to add the extra permissions. The easiest way to add
247
+ permissions is to use an AWS managed policy. Managed policies are created and administered by
248
+ AWS and provide permissions for many common use cases. For example, if your function performs
249
+ CRUD operations on a DynamoDB table, you can add the AmazonDynamoDBFullAccess policy to
250
+ your role.
251
+
252
+ Permissions for other users and resources to access your function
253
+ To grant other AWS service permission to access your Lambda function, you use a resourcebased policy. In IAM, resource-based policies are attached to a resource (in this case, your Lambda
254
+ function) and define who can access the resource and what actions they are allowed to take.
255
+ For another AWS service to invoke your function through a trigger, your function's resource-based
256
+ policy must grant that service permission to use the lambda:InvokeFunction action. If you
257
+ create the trigger using the console, Lambda automatically adds this permission for you.
258
+ To grant permission to other AWS users to access your function, you can define this in your
259
+ function's resource-based policy in exactly the same way as for another AWS service or resource.
260
+ You can also use an identity-based policy that's associated with the user.
261
+
262
+ Best practices for Lambda permissions
263
+ When you set permissions using IAM policies, security best practice is to grant only the permissions
264
+ required to perform a task. This is known as the principle of least privilege. To get started granting
265
+ permissions for your function, you might choose to use an AWS managed policy. Managed policies
266
+ can be the quickest and easiest way to grant permissions to perform a task, but they might also
267
+ include other permissions you don't need. As you move from early development through test and
268
+ production, we recommend you reduce permissions to only those needed by defining your own
269
+ customer-managed policies.
270
+ The same principle applies when granting permissions to access your function using a resourcebased policy. For example, if you want to give permission to Amazon S3 to invoke your function,
271
+ Lambda permissions and roles
272
+
273
+ 7
274
+
275
+ AWS Lambda
276
+
277
+ Developer Guide
278
+
279
+ best practice is to limit access to individual buckets, or buckets in particular AWS accounts, rather
280
+ than giving blanket permissions to the S3 service.
281
+
282
+ Lambda permissions and roles
283
+
284
+ 8
285
+
286
+ AWS Lambda
287
+
288
+ Developer Guide
289
+
290
+ Running code with Lambda
291
+ When you write a Lambda function, you are creating code that will run in a unique serverless
292
+ environment. Understanding how Lambda actually runs your code involves two key aspects:
293
+ the programming model that defines how your code interacts with Lambda, and the execution
294
+ environment lifecycle that determines how Lambda manages your code's runtime environment.
295
+
296
+ The Lambda programming model
297
+ Programming model functions as a common set of rules for how Lambda works with your code,
298
+ regardless of whether you're writing in Python, Java, or any other supported language. The
299
+ programming model includes your runtime and handler.
300
+ 1. Lambda receives an event.
301
+ 2. Lambda uses the runtime (like Python or Java) to prepare the event in a format your code can
302
+ use.
303
+ 3. The runtime sends the formatted event to your handler.
304
+ 4. Your handler processes the event using the code you've written in your Lambda function.
305
+ Essential to this model is the handler, where Lambda sends events to be processed by your code.
306
+ Think of it as the entry point to your code. When Lambda receives an event, it passes this event and
307
+ some context information to your handler. The handler then runs your code to process these events
308
+ - for example, it might read a file when it's uploaded to Amazon S3, analyze an image, or update
309
+ a database. Once your code finishes processing an event, the handler is ready to process the next
310
+ one.
311
+
312
+ The Lambda execution model
313
+ While the programming model defines how Lambda interacts with your code, Execution
314
+ environment is where Lambda actually runs your function — it's a secure, isolated compute space
315
+ created specifically for your function. Each environment follows a lifecycle of three phases.
316
+ 1. Initialization: Lambda creates the environment and gets everything ready to run your function.
317
+ This includes setting up your chosen runtime, loading your code, and running any startup code
318
+ you've written.
319
+ 2. Invocation: When events arrive, Lambda uses this environment to run your function. The
320
+ environment can process many events over time, one after another. As more events come in,
321
+ Running code
322
+
323
+ 9
324
+
325
+ AWS Lambda
326
+
327
+ Developer Guide
328
+
329
+ Lambda creates additional environments to handle the increased demand. When demand drops,
330
+ Lambda stops environments that are no longer needed.
331
+ 3. Shutdown: Eventually, Lambda will shut down environments. Before doing this, it gives your
332
+ function a chance to clean up any remaining tasks.
333
+ This environment handles important aspects of running your function. It provides your
334
+ function with memory and a /tmp directory for temporary storage. It maintains resources like
335
+ database connections between invocations, so your function can reuse them. It offers features
336
+ like provisioned concurrency, where Lambda prepares environments in advance to improve
337
+ performance.
338
+
339
+ Understanding the Lambda programming model
340
+ Lambda provides a programming model that is common to all of the runtimes. The programming
341
+ model defines the interface between your code and the Lambda system. You tell Lambda the entry
342
+ point to your function by defining a handler in the function configuration. The runtime passes in
343
+ objects to the handler that contain the invocation event and the context, such as the function name
344
+ and request ID.
345
+ When the handler finishes processing the first event, the runtime sends it another. The function's
346
+ class stays in memory, so clients and variables that are declared outside of the handler method in
347
+ initialization code can be reused. To save processing time on subsequent events, create reusable
348
+ resources like AWS SDK clients during initialization. Once initialized, each instance of your function
349
+ can process thousands of requests.
350
+ Your function also has access to local storage in the /tmp directory, a transient cache that can be
351
+ used for multiple invocations. For more information, see Execution environment.
352
+ When AWS X-Ray tracing is enabled, the runtime records separate subsegments for initialization
353
+ and execution.
354
+ The runtime captures logging output from your function and sends it to Amazon CloudWatch
355
+ Logs. In addition to logging your function's output, the runtime also logs entries when function
356
+ invocation starts and ends. This includes a report log with the request ID, billed duration,
357
+ initialization duration, and other details. If your function throws an error, the runtime returns that
358
+ error to the invoker.
359
+
360
+ Running code
361
+
362
+ 10
363
+
364
+ AWS Lambda
365
+
366
+ Developer Guide
367
+
368
+ Note
369
+ Logging is subject to CloudWatch Logs quotas. Log data can be lost due to throttling or, in
370
+ some cases, when an instance of your function is stopped.
371
+
372
+ Lambda scales your function by running additional instances of it as demand increases, and by
373
+ stopping instances as demand decreases. This model leads to variations in application architecture,
374
+ such as:
375
+ • Unless noted otherwise, incoming requests might be processed out of order or concurrently.
376
+ • Do not rely on instances of your function being long lived, instead store your application's state
377
+ elsewhere.
378
+ • Use local storage and class-level objects to increase performance, but keep to a minimum the
379
+ size of your deployment package and the amount of data that you transfer onto the execution
380
+ environment.
381
+ For a hands-on introduction to the programming model in your preferred programming language,
382
+ see the following chapters.
383
+ • Building Lambda functions with Node.js
384
+ • Building Lambda functions with Python
385
+ • Building Lambda functions with Ruby
386
+ • Building Lambda functions with Java
387
+ • Building Lambda functions with Go
388
+ • Building Lambda functions with C#
389
+ • Building Lambda functions with PowerShell
390
+
391
+ Understanding the Lambda execution environment lifecycle
392
+ Lambda invokes your function in an execution environment, which provides a secure and isolated
393
+ runtime environment. The execution environment manages the resources required to run your
394
+ function. The execution environment also provides lifecycle support for the function's runtime and
395
+ any external extensions associated with your function.
396
+ Running code
397
+
398
+ 11
399
+
400
+ AWS Lambda
401
+
402
+ Developer Guide
403
+
404
+ The function's runtime communicates with Lambda using the Runtime API. Extensions
405
+ communicate with Lambda using the Extensions API. Extensions can also receive log messages and
406
+ other telemetry from the function by using the Telemetry API.
407
+
408
+ When you create your Lambda function, you specify configuration information, such as the amount
409
+ of memory available and the maximum execution time allowed for your function. Lambda uses this
410
+ information to set up the execution environment.
411
+ The function's runtime and each external extension are processes that run within the execution
412
+ environment. Permissions, resources, credentials, and environment variables are shared between
413
+ the function and the extensions.
414
+ Topics
415
+ • Lambda execution environment lifecycle
416
+ • Cold starts and latency
417
+ • Reducing cold starts with Provisioned Concurrency
418
+ • Optimizing static initialization
419
+ Lambda execution environment lifecycle
420
+
421
+ Running code
422
+
423
+ 12
424
+
425
+ AWS Lambda
426
+
427
+ Developer Guide
428
+
429
+ Each phase starts with an event that Lambda sends to the runtime and to all registered extensions.
430
+ The runtime and each extension indicate completion by sending a Next API request. Lambda
431
+ freezes the execution environment when the runtime and each extension have completed and
432
+ there are no pending events.
433
+ Topics
434
+ • Init phase
435
+ • Failures during the Init phase
436
+ • Restore phase (Lambda SnapStart only)
437
+ • Invoke phase
438
+ • Failures during the invoke phase
439
+ • Shutdown phase
440
+ Init phase
441
+ In the Init phase, Lambda performs three tasks:
442
+ • Start all extensions (Extension init)
443
+ • Bootstrap the runtime (Runtime init)
444
+ • Run the function's static code (Function init)
445
+ • Run any before-checkpoint runtime hooks (Lambda SnapStart only)
446
+ The Init phase ends when the runtime and all extensions signal that they are ready by sending
447
+ a Next API request. The Init phase is limited to 10 seconds. If all three tasks do not complete
448
+ within 10 seconds, Lambda retries the Init phase at the time of the first function invocation with
449
+ the configured function timeout.
450
+ When Lambda SnapStart is activated, the Init phase happens when you publish a function
451
+ version. Lambda saves a snapshot of the memory and disk state of the initialized execution
452
+ environment, persists the encrypted snapshot, and caches it for low-latency access. If you have a
453
+ before-checkpoint runtime hook, then the code runs at the end of Init phase.
454
+ Note
455
+ The 10-second timeout doesn't apply to functions that are using provisioned concurrency
456
+ or SnapStart. For provisioned concurrency and SnapStart functions, your initialization code
457
+ Running code
458
+
459
+ 13
460
+
461
+ AWS Lambda
462
+
463
+ Developer Guide
464
+
465
+ can run for up to 15 minutes. The time limit is 130 seconds or the configured function
466
+ timeout (maximum 900 seconds), whichever is higher.
467
+
468
+ When you use provisioned concurrency, Lambda initializes the execution environment when
469
+ you configure the PC settings for a function. Lambda also ensures that initialized execution
470
+ environments are always available in advance of invocations. You may see gaps between your
471
+ function's invocation and initialization phases. Depending on your function's runtime and memory
472
+ configuration, you may also see variable latency on the first invocation on an initialized execution
473
+ environment.
474
+ For functions using on-demand concurrency, Lambda may occasionally initialize execution
475
+ environments ahead of invocation requests. When this happens, you may also observe a time gap
476
+ between your function's initialization and invocation phases. We recommend you to not take a
477
+ dependency on this behavior.
478
+ Failures during the Init phase
479
+ If a function crashes or times out during the Init phase, Lambda emits error information in the
480
+ INIT_REPORT log.
481
+ Example — INIT_REPORT log for timeout
482
+ INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
483
+
484
+ Example — INIT_REPORT log for extension failure
485
+ INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type:
486
+ Extension.Crash
487
+
488
+ If the Init phase is successful, Lambda doesn't emit the INIT_REPORT log unless SnapStart or
489
+ provisioned concurrency is enabled. SnapStart and provisioned concurrency functions always emit
490
+ INIT_REPORT. For more information, see Monitoring for Lambda SnapStart.
491
+ Restore phase (Lambda SnapStart only)
492
+ When you first invoke a SnapStart function and as the function scales up, Lambda resumes new
493
+ execution environments from the persisted snapshot instead of initializing the function from
494
+ scratch. If you have an after-restore runtime hook, the code runs at the end of the Restore phase.
495
+ You are charged for the duration of after-restore runtime hooks. The runtime must load and afterRunning code
496
+
497
+ 14
498
+
499
+ AWS Lambda
500
+
501
+ Developer Guide
502
+
503
+ restore runtime hooks must complete within the timeout limit (10 seconds). Otherwise, you'll get
504
+ a SnapStartTimeoutException. When the Restore phase completes, Lambda invokes the function
505
+ handler (the Invoke phase).
506
+ Failures during the Restore phase
507
+ If the Restore phase fails, Lambda emits error information in the RESTORE_REPORT log.
508
+ Example — RESTORE_REPORT log for timeout
509
+ RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
510
+
511
+ Example — RESTORE_REPORT log for runtime hook failure
512
+ RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
513
+
514
+ For more information about the RESTORE_REPORT log, see Monitoring for Lambda SnapStart.
515
+ Invoke phase
516
+ When a Lambda function is invoked in response to a Next API request, Lambda sends an Invoke
517
+ event to the runtime and to each extension.
518
+ The function's timeout setting limits the duration of the entire Invoke phase. For example, if you
519
+ set the function timeout as 360 seconds, the function and all extensions need to complete within
520
+ 360 seconds. Note that there is no independent post-invoke phase. The duration is the sum of all
521
+ invocation time (runtime + extensions) and is not calculated until the function and all extensions
522
+ have finished executing.
523
+ The invoke phase ends after the runtime and all extensions signal that they are done by sending a
524
+ Next API request.
525
+ Failures during the invoke phase
526
+ If the Lambda function crashes or times out during the Invoke phase, Lambda resets the
527
+ execution environment. The following diagram illustrates Lambda execution environment behavior
528
+ when there's an invoke failure:
529
+
530
+ Running code
531
+
532
+ 15
533
+
534
+ AWS Lambda
535
+
536
+ Developer Guide
537
+
538
+ In the previous diagram:
539
+ • The first phase is the INIT phase, which runs without errors.
540
+ • The second phase is the INVOKE phase, which runs without errors.
541
+ • At some point, suppose your function runs into an invoke failure (common causes include
542
+ function timeouts, runtime errors, memory exhaustion, VPC connectivity issues, permission
543
+ errors, concurrency limits, and various configuration problems). For a complete list of possible
544
+ invocation failures, see the section called “Invocation”. The third phase, labeled INVOKE WITH
545
+ ERROR , illustrates this scenario. When this happens, the Lambda service performs a reset.
546
+ The reset behaves like a Shutdown event. First, Lambda shuts down the runtime, then sends a
547
+ Shutdown event to each registered external extension. The event includes the reason for the
548
+ shutdown. If this environment is used for a new invocation, Lambda re-initializes the extension
549
+ and runtime together with the next invocation.
550
+ Note that the Lambda reset does not clear the /tmp directory content prior to the next init
551
+ phase. This behavior is consistent with the regular shutdown phase.
552
+
553
+ Note
554
+ AWS is currently implementing changes to the Lambda service. Due to these changes,
555
+ you may see minor differences between the structure and content of system log
556
+ messages and trace segments emitted by different Lambda functions in your AWS
557
+ account.
558
+ If your function's system log configuration is set to plain text, this change affects the
559
+ log messages captured in CloudWatch Logs when your function experiences an invoke
560
+ failure. The following examples show log outputs in both old and new formats.
561
+ These changes will be implemented during the coming weeks, and all functions in all
562
+ AWS Regions except the China and GovCloud regions will transition to use the newformat log messages and trace segments.
563
+
564
+ Example CloudWatch Logs log output (runtime or extension crash) - old style
565
+ START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
566
+ RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without
567
+ providing a reason
568
+ Runtime.ExitError
569
+ Running code
570
+
571
+ 16
572
+
573
+ AWS Lambda
574
+
575
+ Developer Guide
576
+
577
+ END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
578
+ REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed
579
+ Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
580
+
581
+ Example CloudWatch Logs log output (function timeout) - old style
582
+ START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
583
+ 2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after
584
+ 3.00 seconds
585
+ END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
586
+ REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed
587
+ Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23
588
+ ms
589
+
590
+ The new format for CloudWatch logs includes an additional statusfield in the REPORT line. In
591
+ the case of a runtime or extension crash, the REPORT line also includes a field ErrorType.
592
+
593
+ Example CloudWatch Logs log output (runtime or extension crash) - new style
594
+ START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
595
+ END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
596
+ REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed
597
+ Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00
598
+ ms Status: error Error Type: Runtime.ExitError
599
+
600
+ Example CloudWatch Logs log output (function timeout) - new style
601
+ START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
602
+ END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
603
+ REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed
604
+ Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00
605
+ ms Status: timeout
606
+
607
+ • The fourth phase represents the INVOKE phase immediately following an invoke failure.
608
+ Here, Lambda initializes the environment again by re-running the INIT phase. This is called a
609
+ suppressed init. When suppressed inits occur, Lambda doesn't explicitly report an additional INIT
610
+ phase in CloudWatch Logs. Instead, you may notice that the duration in the REPORT line includes
611
+ an additional INIT duration + the INVOKE duration. For example, suppose you see the following
612
+ logs in CloudWatch:
613
+ Running code
614
+
615
+ 17
616
+
617
+ AWS Lambda
618
+
619
+ Developer Guide
620
+
621
+ 2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
622
+ 2022-12-20T01:00:02.500-08:00 END RequestId: XXX
623
+ 2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
624
+ Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
625
+
626
+ In this example, the difference between the REPORT and START timestamps is 2.5 seconds.
627
+ This doesn't match the reported duration of 3022.91 millseconds, because it doesn't take into
628
+ account the extra INIT (suppressed init) that Lambda performed. In this example, you can infer
629
+ that the actual INVOKE phase took 2.5 seconds.
630
+ For more insight into this behavior, you can use the Accessing real-time telemetry
631
+ data for extensions using the Telemetry API. The Telemetry API emits INIT_START,
632
+ INIT_RUNTIME_DONE, and INIT_REPORT events with phase=invoke whenever suppressed
633
+ inits occur in between invoke phases.
634
+ • The fifth phase represents the SHUTDOWN phase, which runs without errors.
635
+ Shutdown phase
636
+ When Lambda is about to shut down the runtime, it sends a Shutdown event to each registered
637
+ external extension. Extensions can use this time for final cleanup tasks. The Shutdown event is a
638
+ response to a Next API request.
639
+ Duration limit: The maximum duration of the Shutdown phase depends on the configuration of
640
+ registered extensions:
641
+ • 0 ms – A function with no registered extensions
642
+ • 500 ms – A function with a registered internal extension
643
+ • 2,000 ms – A function with one or more registered external extensions
644
+ If the runtime or an extension does not respond to the Shutdown event within the limit, Lambda
645
+ ends the process using a SIGKILL signal.
646
+ After the function and all extensions have completed, Lambda maintains the execution
647
+ environment for some time in anticipation of another function invocation. However, Lambda
648
+ terminates execution environments every few hours to allow for runtime updates and maintenance
649
+ —even for functions that are invoked continuously. You should not assume that the execution
650
+ Running code
651
+
652
+ 18
653
+
654
+ AWS Lambda
655
+
656
+ Developer Guide
657
+
658
+ environment will persist indefinitely. For more information, see Implement statelessness in
659
+ functions.
660
+ When the function is invoked again, Lambda thaws the environment for reuse. Reusing the
661
+ execution environment has the following implications:
662
+ • Objects declared outside of the function's handler method remain initialized, providing
663
+ additional optimization when the function is invoked again. For example, if your Lambda
664
+ function establishes a database connection, instead of reestablishing the connection, the original
665
+ connection is used in subsequent invocations. We recommend adding logic in your code to check
666
+ if a connection exists before creating a new one.
667
+ • Each execution environment provides between 512 MB and 10,240 MB, in 1-MB increments, of
668
+ disk space in the /tmp directory. The directory content remains when the execution environment
669
+ is frozen, providing a transient cache that can be used for multiple invocations. You can add extra
670
+ code to check if the cache has the data that you stored. For more information on deployment
671
+ size limits, see Lambda quotas.
672
+ • Background processes or callbacks that were initiated by your Lambda function and did not
673
+ complete when the function ended resume if Lambda reuses the execution environment. Make
674
+ sure that any background processes or callbacks in your code are complete before the code exits.
675
+ Cold starts and latency
676
+ When Lambda receives a request to run a function via the Lambda API, the service first prepares an
677
+ execution environment. During this initialization phase, the service downloads your code, starts the
678
+ environment, and runs any initialization code outside of the main handler. Finally, Lambda runs the
679
+ handler code.
680
+
681
+ In this diagram, the first two steps of downloading the code and setting up the environment are
682
+ frequently referred to as a “cold start”. You are not charged for this time, but it does add latency to
683
+ your overall invocation duration.
684
+ Running code
685
+
686
+ 19
687
+
688
+ AWS Lambda
689
+
690
+ Developer Guide
691
+
692
+ After the invocation completes, the execution environment is frozen. To improve resource
693
+ management and performance, Lambda retains the execution environment for a period of
694
+ time. During this time, if another request arrives for the same function, Lambda can reuse the
695
+ environment. This second request typically finishes more quickly, since the execution environment
696
+ is already fully set up. This is called a “warm start”.
697
+ Cold starts typically occur in under 1% of invocations. The duration of a cold start varies from
698
+ under 100 ms to over 1 second. In general, cold starts are typically more common in development
699
+ and test functions than production workloads. This is because development and test functions are
700
+ usually invoked less frequently.
701
+ Reducing cold starts with Provisioned Concurrency
702
+ If you need predictable function start times for your workload, provisioned concurrency is the
703
+ recommended solution to ensure the lowest possible latency. This feature pre-initializes execution
704
+ environments, reducing cold starts.
705
+ For example, a function with a provisioned concurrency of 6 has 6 execution environments prewarmed.
706
+
707
+ Optimizing static initialization
708
+ Static initialization happens before the handler code starts running in a function. This is the
709
+ initialization code that you provide, that is outside of the main handler. This code is often used
710
+ to import libraries and dependencies, set up configurations, and initialize connections to other
711
+ services.
712
+ Running code
713
+
714
+ 20
715
+
716
+ AWS Lambda
717
+
718
+ Developer Guide
719
+
720
+ The following Python example shows importing, and configuring modules, and creating the
721
+ Amazon S3 client during the initialization phase, before the lambda_handler function runs
722
+ during invoke.
723
+ import os
724
+ import json
725
+ import cv2
726
+ import logging
727
+ import boto3
728
+ s3 = boto3.client('s3')
729
+ logger = logging.getLogger()
730
+ logger.setLevel(logging.INFO)
731
+ def lambda_handler(event, context):
732
+ # Handler logic...
733
+
734
+ The largest contributor of latency before function execution comes from initialization code. This
735
+ code runs when a new execution environment is created for the first time. The initialization code is
736
+ not run again if an invocation uses a warm execution environment. Factors that affect initialization
737
+ code latency include:
738
+ • The size of the function package, in terms of imported libraries and dependencies, and Lambda
739
+ layers.
740
+ • The amount of code and initialization work.
741
+ • The performance of libraries and other services in setting up connections and other resources.
742
+ There are a number of steps that developers can take to optimize static initialization latency. If a
743
+ function has many objects and connections, you may be able to rearchitect a single function into
744
+ multiple, specialized functions. These are individually smaller and each have less initialization code.
745
+ It’s important that functions only import the libraries and dependencies that they need. For
746
+ example, if you only use Amazon DynamoDB in the AWS SDK, you can require an individual service
747
+ instead of the entire SDK. Compare the following three examples:
748
+ // Instead of const AWS = require('aws-sdk'), use:
749
+ const DynamoDB = require('aws-sdk/clients/dynamodb')
750
+
751
+ Running code
752
+
753
+ 21
754
+
755
+
dataset/docs/wavelength.txt ADDED
@@ -0,0 +1,862 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ AWS Wavelength
2
+
3
+ Developer Guide
4
+
5
+ What is AWS Wavelength?
6
+ AWS Wavelength enables developers to build applications that require edge computing
7
+ infrastructure to deliver low latency to mobile devices and end users or increase the resiliency of
8
+ their existing edge applications. Wavelength deploys standard AWS compute and storage services
9
+ to the edge of communications service providers' (CSP) networks. You can extend a virtual private
10
+ cloud (VPC) to one or more Wavelength Zones. You can then use AWS resources such as Amazon
11
+ Elastic Compute Cloud (Amazon EC2) instances to run the applications that require low latency or
12
+ edge resiliency within the Wavelength Zone, while seamlessly communicating back to your existing
13
+ AWS services deployed in the parent AWS Region.
14
+ For more information, see AWS Wavelength.
15
+
16
+ Wavelength concepts
17
+ The following are the key concepts:
18
+ • Wavelength — A new type of AWS infrastructure designed to run workloads that require low
19
+ latency or edge resiliency.
20
+ • Wavelength Zone — A zone in the carrier location where the Wavelength infrastructure is
21
+ deployed. Wavelength Zones are associated with an AWS Region. A Wavelength Zone is a logical
22
+ extension of the Region, and is managed by the control plane in the Region.
23
+ • VPC — A customer virtual private cloud (VPC) that spans Availability Zones, Local Zones, and
24
+ Wavelength Zones, and has deployed resources such as Amazon EC2 instances in the subnets
25
+ that are associated with the zones.
26
+ • Wavelength subnet — A subnet that you create in a Wavelength Zone. You can create one or
27
+ more subnets, and then run and manage AWS services, such as Amazon EC2 instances, in the
28
+ subnet.
29
+ • Carrier gateway — A carrier gateway serves two purposes. It allows inbound traffic from a carrier
30
+ network in a specific location, and allows outbound traffic to the carrier network and internet.
31
+ • Network Border Group — A unique set of Availability Zones, Local Zones, or Wavelength Zones
32
+ from which AWS advertises IP addresses.
33
+ • Wavelength application — An application that you run on an AWS resource in a Wavelength
34
+ Zone.
35
+ Wavelength concepts
36
+
37
+ 1
38
+
39
+ AWS Wavelength
40
+
41
+ Developer Guide
42
+
43
+ AWS resources on Wavelength
44
+ You can create Amazon EC2 instances, Amazon EBS volumes, and Amazon VPC subnets and carrier
45
+ gateways in Wavelength Zones. You can also use the following:
46
+ • Amazon EC2 Auto Scaling
47
+ • Amazon EKS clusters
48
+ • Amazon ECS clusters
49
+ • Amazon EC2 Systems Manager
50
+ • Amazon CloudWatch
51
+ • AWS CloudTrail
52
+ • AWS CloudFormation
53
+ • Application Load Balancer in select Wavelength Zones. For a list of these Zones, see Load
54
+ balancing.
55
+ The services in Wavelength are part of a VPC that is connected over a reliable connection to an
56
+ AWS Region for easy access to services running in Regional subnets.
57
+
58
+ Working with Wavelength
59
+ You can create, access, and manage your EC2 resources, Wavelength Zones, and carrier gateways
60
+ using any of the following interfaces:
61
+ • AWS Management Console— Provides a web interface that you can use to access your
62
+ Wavelength resources.
63
+ • AWS Command Line Interface (AWS CLI) — Provides commands for a broad set of AWS services,
64
+ including Amazon VPC, and is supported on Windows, macOS, and Linux. The services you
65
+ use in Wavelength continue to use their own namespace, for example Amazon EC2 uses the
66
+ "ec2" namespace, and Amazon EBS uses the "ebs" namespace. For more information, see AWS
67
+ Command Line Interface.
68
+ • AWS SDKs — Provides language-specific APIs and takes care of many of the connection
69
+ details, such as calculating signatures, handling request retries, and handling errors. For more
70
+ information, see AWS SDKs.
71
+ When you use any of the interfaces for your Wavelength Zones, use the parent Region.
72
+ AWS resources on Wavelength
73
+
74
+ 2
75
+
76
+ AWS Wavelength
77
+
78
+ Developer Guide
79
+
80
+ Pricing
81
+ For more information, see AWS Wavelength Pricing.
82
+
83
+ Use cases for AWS Wavelength
84
+ Using AWS Wavelength Zones can help you accomplish a variety of goals. This section lists a few to
85
+ give you an idea of the possibilities.
86
+ Contents
87
+ • Online betting and regulated industries
88
+ • Media and entertainment
89
+ • Healthcare
90
+ • Augmented reality (AR) and virtual reality (VR)
91
+ • Connected vehicles
92
+ • Smart factories
93
+ • Real-time gaming
94
+
95
+ Online betting and regulated industries
96
+ AWS Wavelength provides edge resiliency to help address data residency requirements for
97
+ regulated industries, such as online sports betting. Using a combination of AWS Wavelength
98
+ alongside existing AWS hybrid and edge services such as AWS Outposts or AWS Local Zones, you
99
+ can create highly-available architectures within state or country borders.
100
+
101
+ Media and entertainment
102
+ Wavelength provides the low latency needed to live stream high-resolution video and high-fidelity
103
+ audio, and to embed interactive experiences into live video streams. Real-time video analytics
104
+ provide the ability to generate real-time statistics that enhance the live event experience.
105
+
106
+ Healthcare
107
+ Using AWS Wavelength, medical training providers can offer mobile games, medical simulations for
108
+ rare disease diagnosis, advanced endoscopic maneuvers, ultrasound equipment and much more.
109
+ Pricing
110
+
111
+ 3
112
+
113
+ AWS Wavelength
114
+
115
+ Developer Guide
116
+
117
+ Using AWS Wavelength to host the remote rendering engine, doctors can experience an immersive
118
+ training experience without procuring the often-required expensive equipment to do so.
119
+
120
+ Augmented reality (AR) and virtual reality (VR)
121
+ By accessing compute resources on AWS Wavelength, AR/VR applications can reduce the Motion to
122
+ Photon (MTP) latencies to the benchmark that is needed to offer a realistic customer experience.
123
+ When you use AWS Wavelength, you can offer AR/VR in locations where it is not possible to run
124
+ local system servers.
125
+
126
+ Connected vehicles
127
+ Cellular Vehicle-to-Everything (C-V2X) is an increasingly important platform for enabling
128
+ functionality such as intelligent driving, real-time HD maps, and increased road safety. Low latency
129
+ access to the compute infrastructure that's needed to run data processing and analytics on AWS
130
+ Wavelength enables real-time monitoring of data from sensors on the vehicle. This allows for
131
+ secure connectivity, in-car telematics, and autonomous driving.
132
+
133
+ Smart factories
134
+ Industrial automation applications use ML inference at the edge to analyze images and videos to
135
+ detect quality issues on fast moving assembly lines and to trigger actions that address the issues.
136
+ With AWS Wavelength, these applications can be deployed without having to use expensive, GPUbased servers on the factory floor.
137
+
138
+ Real-time gaming
139
+ Real-time game streaming depends on low latency to preserve the user experience. With AWS
140
+ Wavelength, you can stream the most demanding games from Wavelength Zones so that they are
141
+ available on end devices that have limited processing power.
142
+
143
+ Augmented reality (AR) and virtual reality (VR)
144
+
145
+ 4
146
+
147
+ AWS Wavelength
148
+
149
+ Developer Guide
150
+
151
+ How AWS Wavelength works
152
+ The following diagram demonstrates how you can create a subnet that uses resources in a
153
+ communications service provider (CSP) network at a specific location. For resources that must be
154
+ deployed to the Wavelength Zone, first opt in to the Wavelength Zone, and then create resources
155
+ in the Wavelength Zone.
156
+
157
+ Contents
158
+ • VPCs
159
+ • Subnets
160
+ • Carrier gateways
161
+ • Carrier IP address
162
+ • Routing
163
+ • DNS
164
+ • Maximum transmission unit
165
+
166
+ VPCs
167
+ After you create a VPC in a Region, create a subnet in a Wavelength Zone that is associated with
168
+ the VPC. In addition to the Wavelength Zone, you can create resources in all of the Availability
169
+ Zones and Local Zones that are associated with the VPC.
170
+ VPCs
171
+
172
+ 5
173
+
174
+ AWS Wavelength
175
+
176
+ Developer Guide
177
+
178
+ You have control over the VPC networking components, such as IP address assignment, subnets,
179
+ and route table creation.
180
+ VPCs that contain a subnet in a Wavelength Zone can connect to a carrier gateway. A carrier
181
+ gateway allows you to connect to the following resources:
182
+ • 4G/LTE and 5G devices on the telecommunication carrier network
183
+ • Internet access including fixed wireless access for select Wavelength Zone partners. For more
184
+ information, see Multi-access AWS Wavelength.
185
+ • Outbound traffic to public internet resources
186
+
187
+ Subnets
188
+ Any subnet that you create in a Wavelength Zone inherits the main VPC route table, which includes
189
+ the local route. The local route enables connectivity between the subnets in the VPC, including the
190
+ subnets that are in the Wavelength Zone.
191
+ AWS recommends that you configure custom route tables for your subnets in Wavelength Zones.
192
+ The destinations are the same destinations as a subnet in an Availability Zone or Local Zone, with
193
+ the addition of a carrier gateway. For more information, see the section called “Routing”.
194
+
195
+ Carrier gateways
196
+ A carrier gateway serves two purposes. It allows inbound traffic from a carrier network in a specific
197
+ location, and it allows outbound traffic to the carrier network and internet. There is no inbound
198
+ connection configuration from the internet to a Wavelength Zone through the carrier gateway.
199
+ A carrier gateway supports IPv4 traffic.
200
+ Carrier gateways are only available for VPCs that contain subnets in a Wavelength Zone. The carrier
201
+ gateway provides connectivity between your Wavelength Zone and the telecommunication carrier,
202
+ and devices on the telecommunication carrier network. The carrier gateway performs NAT of the
203
+ Wavelength instances' IP addresses to the Carrier IP addresses from a pool that is assigned to the
204
+ network border group. The carrier gateway NAT function is similar to how an internet gateway
205
+ functions in a Region.
206
+
207
+ Subnets
208
+
209
+ 6
210
+
211
+ AWS Wavelength
212
+
213
+ Developer Guide
214
+
215
+ Carrier IP address
216
+ A Carrier IP address is the address that you assign to a network interface, which resides in a
217
+ subnet in a Wavelength Zone (for example an EC2 instance). The carrier gateway uses the address
218
+ for traffic from the interface to the internet or to mobile devices. The carrier gateway uses
219
+ NAT to translate the address, and then sends the traffic to the destination. Traffic from the
220
+ telecommunication carrier network routes through the carrier gateway.
221
+ You allocate a Carrier IP address from a network border group, which is a unique set of Availability
222
+ Zones, Local Zones, or Wavelength Zones from which AWS advertises IP addresses, for example,
223
+ us-east-1-wl1-bos-wlz-1.
224
+
225
+ Routing
226
+ You can set the carrier gateway as a destination in a route table for the following resources:
227
+ • VPCs that contain subnets in a Wavelength Zone
228
+ • Subnets in Wavelength Zones
229
+ Create a custom route table for the subnets in the Wavelength Zones so that the default route
230
+ goes to the carrier gateway, which then sends traffic to the internet and telecommunication carrier
231
+ network.
232
+
233
+ Example: Carrier gateway routing to the public internet
234
+ Consider a scenario with the following configuration:
235
+ • A VPC with Availability Zones and a Wavelength Zone
236
+ • A subnet in the Wavelength Zone
237
+ • An EC2 instance in the subnet in the Wavelength Zone
238
+ • A Carrier IP address for the network interface associated with the EC2 instance
239
+ • An IP address association that maps the private IP address of the EC2 instance to the Carrier IP
240
+ address
241
+
242
+ Carrier IP address
243
+
244
+ 7
245
+
246
+ AWS Wavelength
247
+
248
+ Developer Guide
249
+
250
+ You need the following entries in the Wavelength subnet route table.
251
+
252
+ Destination
253
+
254
+ Target
255
+
256
+ Notes
257
+
258
+ VPC CIDR
259
+
260
+ Local
261
+
262
+ This route allows for intraVPC connectivity, including
263
+ subnets in the Availability
264
+ Zones.
265
+
266
+ 0.0.0.0/0
267
+
268
+ carrier-gateway-id
269
+
270
+ The Carrier IP address
271
+ provides internet connectivity
272
+ through the carrier gateway.
273
+
274
+ Carrier gateway access to the public internet
275
+ The carrier gateway provides access to the internet from your Wavelength subnets. For information
276
+ about protocol considerations, see the section called “Networking considerations”.
277
+ Traffic initiated from the EC2 instance for the internet uses the 0.0.0.0/0 route to route traffic to
278
+ the carrier gateway. The carrier gateway maps the EC2 instance IP address to the Carrier IP address,
279
+ and then sends the traffic to the telecommunication carrier.
280
+
281
+ Example: Carrier gateway routing to the public internet
282
+
283
+ 8
284
+
285
+ AWS Wavelength
286
+
287
+ Developer Guide
288
+
289
+ DNS
290
+ EC2 instances use EC2 DNS to resolve domain names to IP addresses. Route 53 supports DNS
291
+ features, such as domain registration, and DNS routing. Both public and private hosted Wavelength
292
+ Zones are supported for routing traffic to specific domains. Route 53 resolvers are hosted in the
293
+ Region.
294
+ You can also use your own DNS services to resolve domain names.
295
+
296
+ Maximum transmission unit
297
+ Generally, the maximum transmission unit (MTU) is as follows:
298
+ • 9001 bytes between EC2 instances in the same Wavelength Zone.
299
+ • 1500 bytes between carrier gateway and a Wavelength Zone.
300
+ • 1500 bytes between an EC2 instance in a Wavelength Zone and an EC2 instance in the Region
301
+ when the traffic uses a public IP address.
302
+ • 1300 bytes between an EC2 instance in a Wavelength Zone and an EC2 instance in the Region
303
+ when the traffic uses a private IP address.
304
+
305
+ DNS
306
+
307
+ 9
308
+
309
+ AWS Wavelength
310
+
311
+ Developer Guide
312
+
313
+ Get started with AWS Wavelength
314
+ The following diagram shows the resources that you need to configure to get started using AWS
315
+ Wavelength.
316
+ • A VPC in your Region
317
+ • A carrier gateway
318
+ • A public subnet in an Availability Zone in your Region
319
+ • An instance in the public subnet
320
+ • An instance in the Wavelength Zone subnet with a Carrier IP address
321
+
322
+ Tasks
323
+ • Step 1: Opt in to Wavelength Zones
324
+ • Step 2: Configure your network
325
+ • Step 3: Launch an instance in your Availability Zone public subnet
326
+ 10
327
+
328
+ AWS Wavelength
329
+
330
+ Developer Guide
331
+
332
+ • Step 4: Launch an instance in the Wavelength zone
333
+ • Step 5: Test the connectivity
334
+
335
+ Step 1: Opt in to Wavelength Zones
336
+ Before you specify a Wavelength Zone for a resource or service, you must opt in to the zone.
337
+ Prerequisites
338
+ • Some AWS resources are not available in all Regions. Make sure that you can create the resources
339
+ that you need in the desired Region or Wavelength Zone before launching an instance in a
340
+ specific Wavelength Zone.
341
+ • Before you begin, review Quotas and considerations, which includes information about available
342
+ Wavelength Zones, service differences, and Service Quotas. You should also speak with your
343
+ mobile operator about mobile service plans and any additional requirements.
344
+ To opt in to Wavelength Zone using the console
345
+ 1.
346
+
347
+ Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
348
+
349
+ 2.
350
+
351
+ From the Region selector in the navigation bar, select the Region for the Wavelength Zone.
352
+
353
+ 3.
354
+
355
+ On the navigation pane, choose EC2 Dashboard.
356
+
357
+ 4.
358
+
359
+ In the upper-right corner of the page, choose Account attributes, Zones.
360
+
361
+ 5.
362
+
363
+ Under Wavelength Zones, choose Manage.
364
+
365
+ 6.
366
+
367
+ Choose Enabled.
368
+
369
+ 7.
370
+
371
+ Choose Update zone group.
372
+
373
+ To enable Wavelength Zones using the AWS CLI
374
+ Alternatively, use the AWS CLI to enable Wavelength Zones. To do so, use the modify-availabilityzone-group command.
375
+
376
+ Step 2: Configure your network
377
+ After you opt in to the Wavelength Zone, create a VPC, a carrier gateway, and a public subnet in the
378
+ Availability Zone.
379
+ Step 1: Opt in to Wavelength Zones
380
+
381
+ 11
382
+
383
+ AWS Wavelength
384
+
385
+ Developer Guide
386
+
387
+ Tasks
388
+ • Create a VPC
389
+ • Create a carrier gateway and a subnet associated with the Wavelength Zone
390
+ • Create a public subnet in an Availability Zone
391
+
392
+ Create a VPC
393
+ Create a VPC to extend to your Wavelength Zone.
394
+ To create a VPC using the console
395
+ 1.
396
+
397
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
398
+
399
+ 2.
400
+
401
+ Choose Create VPC.
402
+
403
+ 3.
404
+
405
+ For Resources to create, choose VPC only.
406
+
407
+ 4.
408
+
409
+ For Name tag, optionally provide a name for your VPC. Doing so creates the tag Name=value.
410
+
411
+ 5.
412
+
413
+ For IPv4 CIDR block, specify an IPv4 CIDR block for the VPC. We recommend that you specify a
414
+ CIDR block from the private (non-publicly routable) IP address ranges as specified in RFC 1918;
415
+ for example, 10.0.0.0/16, or 192.168.0.0/16.
416
+ Note
417
+ You can specify a range of publicly routable IPv4 addresses. However, we currently
418
+ do not support direct access to the internet from publicly routable CIDR blocks in a
419
+ VPC. Windows instances cannot boot correctly if launched into a VPC with ranges from
420
+ 224.0.0.0 to 255.255.255.255 (Class D and Class E IP address ranges).
421
+
422
+ 6.
423
+
424
+ Choose Create VPC.
425
+
426
+ Create a carrier gateway and a subnet associated with the Wavelength
427
+ Zone
428
+ After you create a VPC, create a carrier gateway, and then select the subnets that route traffic to
429
+ the carrier gateway.
430
+ When you choose to automatically route traffic from subnets to the carrier gateway, we create the
431
+ following resources:
432
+ Create a VPC
433
+
434
+ 12
435
+
436
+ AWS Wavelength
437
+
438
+ Developer Guide
439
+
440
+ • A carrier gateway
441
+ • A subnet. You can optionally assign all carrier gateway tags except the Name tag to the subnet.
442
+ • A network ACL with the following resources:
443
+ • A subnet association with the subnet in the Wavelength Zone
444
+ • Default inbound and outbound rules for your traffic.
445
+ • A route table with the following resources:
446
+ • A route for local traffic
447
+ • A route that routes non-local traffic to the carrier gateway
448
+ • An association with the subnet
449
+ To create a carrier gateway
450
+ 1.
451
+
452
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
453
+
454
+ 2.
455
+
456
+ In the navigation pane, choose Carrier gateways, and then choose Create carrier gateway.
457
+
458
+ 3.
459
+
460
+ (Optional) For Name, enter a name for the carrier gateway.
461
+
462
+ 4.
463
+
464
+ For VPC, choose the VPC.
465
+
466
+ 5.
467
+
468
+ Choose Route subnet traffic to carrier gateway, and under Subnets to route do the following:
469
+ a.
470
+
471
+ Under Existing subnets in Wavelength Zone, select the box for each Wavelength subnet
472
+ to route to the carrier gateway.
473
+
474
+ b.
475
+
476
+ To create a subnet in the Wavelength Zone, choose Add new subnet, enter the required
477
+ information, and then choose Add new subnet.
478
+
479
+ 6.
480
+
481
+ (Optional) To add a tag to the carrier gateway, choose Add tag, and then enter the tag key and
482
+ tag value.
483
+
484
+ 7.
485
+
486
+ Choose Create carrier gateway.
487
+
488
+ Create a public subnet in an Availability Zone
489
+ Create a subnet in an Availability Zone in the Region.
490
+ To add a subnet
491
+ 1.
492
+
493
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
494
+
495
+ 2.
496
+
497
+ In the navigation pane, choose Subnets.
498
+
499
+ Create a public subnet in an Availability Zone
500
+
501
+ 13
502
+
503
+ AWS Wavelength
504
+
505
+ Developer Guide
506
+
507
+ 3.
508
+
509
+ Choose Create subnet.
510
+
511
+ 4.
512
+
513
+ For VPC, choose the VPC.
514
+
515
+ 5.
516
+
517
+ For Subnet name, provide a name for the subnet. Doing so creates the tag Name=value.
518
+
519
+ 6.
520
+
521
+ For Availability Zone, chose an Availability Zone, or choose No Preference to have AWS
522
+ choose one for you.
523
+
524
+ 7.
525
+
526
+ For IPv4 CIDR block, specify an IPv4 address range for your subnet, using CIDR notation.
527
+
528
+ 8.
529
+
530
+ Choose Create subnet.
531
+
532
+ Step 3: Launch an instance in your Availability Zone public
533
+ subnet
534
+ Launch an EC2 instance in the subnet that you created in the Availability Zone. You will use this
535
+ instance to test the connectivity from the Region to the Wavelength Zone.
536
+ You can launch EC2 instances in the public subnet that you created. For information about how to
537
+ launch an instance using the Amazon EC2 console, see Launch an EC2 instance using the console in
538
+ the Amazon EC2 User Guide.
539
+
540
+ Step 4: Launch an instance in the Wavelength zone
541
+ After you complete the networking configuration, launch an instance, and then allocate a Carrier IP
542
+ address for the instance.
543
+ Options
544
+ • Option 1: Auto assign a Carrier IP address
545
+ • Option 2: Allocate and associate a Carrier IP address from the network border group
546
+
547
+ Option 1: Auto assign a Carrier IP address
548
+ AWS recommends that you use the AWS CLI because you can automatically allocate and associate
549
+ the Carrier IP address with the network interface.
550
+ Use the run-instances command as follows to launch an instance in the Wavelength Zone subnet.
551
+ Step 3: Launch an instance in your Availability Zone public subnet
552
+
553
+ 14
554
+
555
+ AWS Wavelength
556
+
557
+ Developer Guide
558
+
559
+ aws ec2 run-instances --region us-east-1 --network-interfaces
560
+ "DeviceIndex=0,AssociateCarrierIpAddress=true,SubnetId=subnet-036aa298f4EXAMPLE" -image-id ami-04125ecea1EXAMPLE --instance-type t3.medium
561
+
562
+ • DeviceIndex – Specify 0 to indicate the primary network interface (eth0).
563
+ • SubnetId – Specify the ID of the subnet in the Wavelength Zone.
564
+ • AssociateCarrierIpAddress – Set this value to true to assign a Carrier IP address to the
565
+ network interface.
566
+
567
+ Option 2: Allocate and associate a Carrier IP address from the network
568
+ border group
569
+ You can launch EC2 instances in the subnet that you created when you added the carrier gateway.
570
+ For more information, see the section called “Create a carrier gateway and a subnet associated with
571
+ the Wavelength Zone”. Security groups control inbound and outbound traffic for instances in a
572
+ subnet, just as they do for instances in an Availability Zone subnet. To connect to an EC2 instance
573
+ in a subnet, specify a key pair when you launch the instance, just as you do for instances in an
574
+ Availability Zone subnet. For information about how to launch an instance using the Amazon EC2
575
+ console, see Launch an EC2 instance using the console in the Amazon EC2 User Guide.
576
+ To allocate and associate a Carrier IP address
577
+ 1.
578
+
579
+ Use the allocate-address command as follows to allocate a Carrier IP address.
580
+ aws ec2 allocate-address --region us-east-1 --domain vpc --network-border-group useast-1-wl1-bos-wlz-1
581
+
582
+ The following is example output.
583
+ {
584
+ "AllocationId": "eipalloc-05807b62acEXAMPLE",
585
+ "PublicIpv4Pool": "amazon",
586
+ "NetworkBorderGroup": "us-east-1-wl1-bos-wlz-1",
587
+ "Domain": "vpc",
588
+ "CarrierIp": "155.146.10.111"
589
+ }
590
+ Option 2: Allocate and associate a Carrier IP address from the network border group
591
+
592
+ 15
593
+
594
+ AWS Wavelength
595
+
596
+ 2.
597
+
598
+ Developer Guide
599
+
600
+ Use the associate-address command as follows to associate the Carrier IP address with the EC2
601
+ instance.
602
+ aws ec2 associate-address --allocation-id eipalloc-05807b62acEXAMPLE --networkinterface-id eni-1a2b3c4d
603
+
604
+ The following is example output.
605
+ {
606
+ "AssociationId": "eipassoc-02463d08ceEXAMPLE",
607
+ }
608
+
609
+ Step 5: Test the connectivity
610
+ Before you test the connectivity, do the following:
611
+ • Review the section called “Networking considerations”
612
+ • Configure the instance security group to allow ICMP traffic.
613
+ Test the connectivity from the instance in the Region to the Wavelength Zone instance. Depending
614
+ on your operating system, use SSH or RDP to connect to the Carrier IP address of your Wavelength
615
+ Zone instance. You can use a secure bastion host.
616
+ Run the ping command to the Wavelength Zone instance. In the following example, the IP address
617
+ of the subnet in the Wavelength Zone is 10.0.3.112.
618
+ ping 10.0.3.112
619
+ Pinging 10.0.3.112
620
+ Reply from 10.0.3.112:
621
+ Reply from 10.0.3.112:
622
+ Reply from 10.0.3.112:
623
+
624
+ bytes=32 time=<1ms TTL=128
625
+ bytes=32 time=<1ms TTL=128
626
+ bytes=32 time=<1ms TTL=128
627
+
628
+ Ping statistics for 10.0.3.112
629
+ Packets: Sent = 3, Received = 3,
630
+
631
+ Lost = 0 (0% lost)
632
+
633
+ Approximate round trip time in milliseconds
634
+ Minimum = 0ms, Maximum = 0ms, Average = 0ms
635
+
636
+ Step 5: Test the connectivity
637
+
638
+ 16
639
+
640
+ AWS Wavelength
641
+
642
+ Developer Guide
643
+
644
+ Test the connectivity from the instance in the Wavelength Zone instance to the carrier network.
645
+ Depending on your operating system, use SSH or RDP to connect to the Carrier IP address of your
646
+ Wavelength Zone instance. You can use a secure bastion host.
647
+ You need a device on the carrier network in order to test the connectivity from the Wavelength
648
+ Zone to the carrier network.
649
+ Run the ping command to an address in the carrier network. In the following example, the carrier
650
+ network IP address is 198.51.100.130.
651
+ ping 198.51.100.130
652
+ Pinging 198.51.100.130
653
+ Reply from 198.51.100.130:
654
+ Reply from 198.51.100.130:
655
+ Reply from 198.51.100.130:
656
+
657
+ bytes=32 time=<1ms TTL=128
658
+ bytes=32 time=<1ms TTL=128
659
+ bytes=32 time=<1ms TTL=128
660
+
661
+ Ping statistics for 198.51.100.130
662
+ Packets: Sent = 3, Received = 3,
663
+
664
+ Lost = 0 (0% lost)
665
+
666
+ Approximate round trip time in milliseconds
667
+ Minimum = 0ms, Maximum = 0ms, Average = 0ms
668
+
669
+ Step 5: Test the connectivity
670
+
671
+ 17
672
+
673
+ AWS Wavelength
674
+
675
+ Developer Guide
676
+
677
+ Carrier gateway for AWS Wavelength
678
+ A carrier gateway serves two purposes. It allows inbound traffic from a carrier network in a specific
679
+ location, and it allows outbound traffic to the carrier network and the internet. There is generally
680
+ no inbound connection configuration from the internet to a Wavelength Zone through the carrier
681
+ gateway with the exception of select partners. For more information, see Multi-access AWS
682
+ Wavelength.
683
+ A carrier gateway supports IPv4 traffic.
684
+ Carrier gateways are only available for VPCs that contain subnets in a Wavelength Zone. The carrier
685
+ gateway provides connectivity between your Wavelength Zone and the carrier, and devices on
686
+ the carrier network. The carrier gateway performs NAT of the Wavelength instances' IP addresses
687
+ to the Carrier IP addresses from a pool that is assigned to the network border group. The carrier
688
+ gateway NAT function is similar to how an internet gateway functions in a Region.
689
+
690
+ Enable access to the carrier network
691
+ To enable access to or from the carrier network for instances in a Wavelength subnet, you must do
692
+ the following:
693
+ • Create a VPC.
694
+ • Create a carrier gateway and attach the carrier gateway to your VPC. When you create the carrier
695
+ gateway, you can optionally choose which subnets route to the carrier gateway. When you select
696
+ this option, we automatically create the resources related to carrier gateways, such as route
697
+ tables and network ACLs. If you do not choose this option, then you must perform the following
698
+ tasks:
699
+ • Select the subnets that route traffic to the carrier gateway.
700
+ • Ensure that your subnet route tables have a route that directs traffic to the carrier gateway.
701
+ • Ensure that instances in your subnet have a globally unique Carrier IP address.
702
+ • Ensure that your network access control lists and security group rules allow the relevant traffic
703
+ to flow to and from your instance.
704
+
705
+ Enable access to the carrier network
706
+
707
+ 18
708
+
709
+ AWS Wavelength
710
+
711
+ Developer Guide
712
+
713
+ Work with carrier gateways
714
+ The following sections describe how to manually create a carrier gateway for your VPC to support
715
+ inbound traffic from the carrier network (for example, mobile phones), and to support outbound
716
+ traffic to the carrier network and the internet.
717
+ Tasks
718
+ • Create a VPC
719
+ • Create a carrier gateway
720
+ • Create a security group to access the carrier network
721
+ • Allocate and associate a Carrier IP address with the instance in the Wavelength Zone subnet
722
+ • Routing to a Wavelength Zone carrier gateway
723
+ • View the carrier gateway details
724
+ • Manage carrier gateway tags
725
+ • Delete a carrier gateway
726
+
727
+ Create a VPC
728
+ You can create an empty Wavelength VPC as follows.
729
+ Limitation
730
+ You can specify a range of publicly routable IPv4 addresses. However, we do not support direct
731
+ access to the internet from publicly routable CIDR blocks in a VPC. Windows instances cannot boot
732
+ correctly if launched into a VPC with ranges from 224.0.0.0 to 255.255.255.255 (Class D and
733
+ Class E IP address ranges).
734
+ 1.
735
+
736
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
737
+
738
+ 2.
739
+
740
+ In the navigation pane, choose Your VPCs, Create VPC.
741
+
742
+ 3.
743
+
744
+ Do the following and then choose Create.
745
+ • Name tag: Optionally provide a name for your VPC. Doing so creates a tag with a key of
746
+ Name and the value that you specify.
747
+ • IPv4 CIDR block: Specify an IPv4 CIDR block for the VPC. We recommend that you specify
748
+ a CIDR block from the private (non-publicly routable) IP address ranges as specified in RFC
749
+ 1918; for example, 10.0.0.0/16, or 192.168.0.0/16.
750
+
751
+ Work with carrier gateways
752
+
753
+ 19
754
+
755
+ AWS Wavelength
756
+
757
+ Developer Guide
758
+
759
+ To create a VPC using the AWS CLI
760
+ Use the create-vpc command.
761
+
762
+ Create a carrier gateway
763
+ After you create a VPC, create a carrier gateway and then select the subnets that route traffic to
764
+ the carrier gateway.
765
+ If you have not opted in to a Wavelength Zone, the Amazon Virtual Private Cloud Console prompts
766
+ you to opt in. For more information, see the section called “Manage Zones”.
767
+ When you choose to automatically route traffic from subnets to the carrier gateway, we create the
768
+ following resources:
769
+ • A carrier gateway
770
+ • A subnet. You can optionally assign all carrier gateway tags that do not have a Key value of Name
771
+ to the subnet.
772
+ • A network ACL with the following resources:
773
+ • A subnet associated with the subnet in the Wavelength Zone
774
+ • Default inbound and outbound rules for all of your traffic.
775
+ • A route table with the following resources:
776
+ • A route for all local traffic
777
+ • A route that routes all non-local traffic to the carrier gateway
778
+ • An association with the subnet
779
+ To create a carrier gateway
780
+ 1.
781
+
782
+ Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
783
+
784
+ 2.
785
+
786
+ In the navigation pane, choose Carrier Gateways, and then choose Create carrier gateway.
787
+
788
+ 3.
789
+
790
+ Optional: For Name, enter a name for the carrier gateway.
791
+
792
+ 4.
793
+
794
+ For VPC, choose the VPC.
795
+
796
+ 5.
797
+
798
+ Choose Route subnet traffic to carrier gateway, and under Subnets to route do the following.
799
+ a.
800
+
801
+ Under Existing subnets in Wavelength Zone, select the box for each subnet to route to
802
+ the carrier gateway.
803
+
804
+ Create a carrier gateway
805
+
806
+ 20
807
+
808
+ AWS Wavelength
809
+
810
+ b.
811
+
812
+ Developer Guide
813
+
814
+ To create a subnet in the Wavelength Zone, choose Add new subnet, specify the following
815
+ information, and then choose Add new subnet:
816
+ • Name tag: Optionally provide a name for your subnet. Doing so creates a tag with a key
817
+ of Name and the value that you specify.
818
+ • VPC: Choose the VPC.
819
+ • Availability Zone: Choose the Wavelength Zone.
820
+ • IPv4 CIDR block: Specify an IPv4 CIDR block for your subnet, for example,
821
+ 10.0.1.0/24.
822
+ • To apply the carrier gateway tags to the subnet, select Apply same tags from this
823
+ carrier gateway.
824
+
825
+ 6.
826
+
827
+ 7.
828
+
829
+ (Optional) To add a tag to the carrier gateway, choose Add tag, and then do the following:
830
+
831
+
832
+ For Key, enter the key name.
833
+
834
+
835
+
836
+ For Value, enter the key value.
837
+
838
+ Choose Create carrier gateway.
839
+
840
+ To create a carrier gateway using the AWS CLI
841
+ 1.
842
+
843
+ Use the create-carrier-gateway command.
844
+
845
+ 2.
846
+
847
+ Add a VPC route table with the following resources:
848
+ • A route for all VPC local traffic
849
+ • A route that routes all non-local traffic to the carrier gateway
850
+ • An association with the subnets in the Wavelength Zone
851
+ For more information, see the section called “Routing to a Wavelength Zone carrier gateway”.
852
+
853
+ Create a security group to access the carrier network
854
+ By default, a VPC security group allows all outbound traffic. You can create a new security group
855
+ and add rules that allow inbound traffic from the carrier. Then, you associate the security group
856
+ with instances in the subnet.
857
+
858
+ Create a security group to access the carrier network
859
+
860
+ 21
861
+
862
+
src/__init__.py ADDED
File without changes
src/chunking/base_chunker.py ADDED
@@ -0,0 +1,7 @@
 
 
 
 
 
 
 
 
1
+ from abc import ABC, abstractmethod
2
+ from typing import List
3
+
4
+ class BaseChunker(ABC):
5
+ @abstractmethod
6
+ def split_text(self, text: str) -> List[str]:
7
+ pass
src/chunking/chunk.py ADDED
@@ -0,0 +1,63 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ import argparse
2
+ import os
3
+ import json
4
+ from typing import List
5
+ from chunker import Chunker
6
+
7
+ def chunk_file(file_path: str, chunker: Chunker) -> List[str]:
8
+ with open(file_path, 'r', encoding='utf-8') as f:
9
+ text = f.read()
10
+ return chunker.split_text(text)
11
+
12
+ def save_chunks(original_file: str, chunks: List[str], input_root: str, output_dir: str):
13
+ rel_path = os.path.relpath(original_file, input_root)
14
+ base_name = os.path.splitext(rel_path)[0] + "_chunks.json"
15
+ out_path = os.path.join(output_dir, base_name)
16
+
17
+ os.makedirs(os.path.dirname(out_path), exist_ok=True)
18
+ with open(out_path, 'w', encoding='utf-8') as out_f:
19
+ json.dump(chunks, out_f, ensure_ascii=False, indent=2)
20
+
21
+ print(f"Saved {len(chunks)} chunks to {out_path}")
22
+
23
+ def process_input(input_path: str, output_dir: str, chunker: Chunker):
24
+ if os.path.isdir(input_path):
25
+ for root, _, files in os.walk(input_path):
26
+ for fname in files:
27
+ if fname.lower().endswith('.txt'):
28
+ full_path = os.path.join(root, fname)
29
+ chunks = chunk_file(full_path, chunker)
30
+ save_chunks(full_path, chunks, input_path, output_dir)
31
+ elif os.path.isfile(input_path):
32
+ if input_path.lower().endswith('.txt'):
33
+ chunks = chunk_file(input_path, chunker)
34
+ save_chunks(input_path, chunks, os.path.dirname(input_path), output_dir)
35
+ else:
36
+ print(f"Skipping non-.txt file: {input_path}")
37
+ else:
38
+ raise FileNotFoundError(f"Input path not found: {input_path}")
39
+
40
+ def main():
41
+ parser = argparse.ArgumentParser(
42
+ description="Chunk plain-text documents using your BaseChunker implementation."
43
+ )
44
+ parser.add_argument(
45
+ "input", help="Path to a .txt file or a directory of .txt files to chunk"
46
+ )
47
+ parser.add_argument(
48
+ "output", help="Directory where chunked JSON files will be written"
49
+ )
50
+ parser.add_argument(
51
+ "--chunk-size", type=int, default=200,
52
+ help="Number of tokens per chunk (default: 200)"
53
+ )
54
+ parser.add_argument(
55
+ "--overlap", type=int, default=50,
56
+ )
57
+
58
+ args = parser.parse_args()
59
+ chunker = Chunker(chunk_size=args.chunk_size, overlap=args.overlap)
60
+ process_input(args.input, args.output, chunker)
61
+
62
+ if __name__ == "__main__":
63
+ main()
src/chunking/chunker.py ADDED
@@ -0,0 +1,28 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ import re
2
+ from typing import List
3
+ from base_chunker import BaseChunker
4
+
5
+ class Chunker(BaseChunker):
6
+ def __init__(self, chunk_size: int = 200, overlap: int = 500):
7
+ if overlap >= chunk_size:
8
+ raise ValueError("overlap must be smaller than chunk size")
9
+
10
+ self.chunk_size = chunk_size
11
+ self.overlap = overlap
12
+
13
+ def split_text(self, text: str) -> List[str]:
14
+ tokens = text.strip().split()
15
+ if not tokens:
16
+ return []
17
+
18
+ chunks: List[str] = []
19
+ start = 0
20
+ while start < len(tokens):
21
+ end = min(start + self.chunk_size, len(tokens))
22
+ chunk = " ".join(tokens[start:end])
23
+ chunks.append(chunk)
24
+
25
+ start += self.chunk_size - self.overlap
26
+
27
+ return chunks
28
+
src/eval/model_baseline.py CHANGED
@@ -0,0 +1,10 @@
 
 
 
 
 
 
 
 
 
 
 
1
+ import torch
2
+
3
+ from sentence_transformers import SentenceTransformer, SentenceTransformerModelCardData, SentenceTransformerTrainingArguments, SentenceTransformerTrainer
4
+ from sentence_transformers.evaluation import InformationRetrievalEvaluator, SequentialEvaluator
5
+ from sentence_transformers.util import cos_sim
6
+ from sentence_transformers.losses import MatryoshkaLoss, MultipleNegativesRankingLoss
7
+ from sentence_transformers.training_args import BatchSamplers
8
+
9
+ from datasets import load_dataset, concatenate_datasets
10
+
src/processing/generate_qas.py ADDED
@@ -0,0 +1,70 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ import os, json, glob, time
2
+ from typing import List, Dict
3
+ from dotenv import load_dotenv
4
+ from load_chunks import load_all_chunks
5
+ from openai import OpenAI
6
+
7
+ openai = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
8
+ NUM_QUESTIONS = 4
9
+ SLEEP = 5
10
+ MODEL = "gpt-4o-mini"
11
+
12
+ def make_prompt(chunk_text: str) -> str:
13
+ return f"""
14
+ You are creating reading-comprehension questions.
15
+ Given only the text below, generate exactly {NUM_QUESTIONS} short, factual questions
16
+ that can be answered *only* from that text.
17
+ Return your output as a JSON array of objects with fields:
18
+ - id: integer question number (1..{NUM_QUESTIONS})
19
+ - question: the question text
20
+
21
+ Text:
22
+ \"\"\"
23
+ {chunk_text}
24
+ \"\"\"
25
+ """
26
+
27
+ def generate(prompt: str) -> List[Dict]:
28
+ while True:
29
+ try:
30
+ resp = openai.chat.completions.create(
31
+ model=MODEL,
32
+ messages=[
33
+ { "role": "system", "content": "You output JSON only, no extra text." },
34
+ { "role": "user", "content": prompt }
35
+ ],
36
+ temperature=0.7,
37
+ max_tokens=NUM_QUESTIONS * 50
38
+ )
39
+ text = resp.choices[0].message.content.strip()
40
+ return json.loads(text)
41
+ except json.JSONDecodeError as e:
42
+ print("Failted to parse JSON, retrying...", e)
43
+ time.sleep(1)
44
+
45
+ def main():
46
+ chunks = load_all_chunks("../../../dataset/chunks/*.json")
47
+
48
+ output_records = []
49
+ for chunk in chunks:
50
+ qas = generate(make_prompt(chunk["chunk"]))
51
+
52
+ for qa in qas:
53
+ output_records.append({
54
+ "doc_id": chunk.get("doc_id"),
55
+ "section": chunk.get("section"),
56
+ "chunk_id": chunk["chunk_id"],
57
+ "question_id": qa["id"],
58
+ "question": qa["question"]
59
+ })
60
+
61
+ time.sleep(0.5)
62
+
63
+ with open("synthetic_qa_pairs.jsonl", "w", encoding="utf-8") as out:
64
+ for rec in output_records:
65
+ out.write(json.dumps(rec, ensure_ascii=False) + "\n")
66
+
67
+ print(f"Done — generated {len(output_records)} questions across {len(chunks)} chunks.")
68
+
69
+ if __name__ == "__main__":
70
+ main()
src/processing/load_chunks.py ADDED
@@ -0,0 +1,9 @@
 
 
 
 
 
 
 
 
 
 
1
+ from typing import List, Dict
2
+ import json, glob
3
+
4
+ def load_all_chunks(glob_pattern: str) -> List[Dict]:
5
+ all_chunks = []
6
+ for path in glob.glob(glob_pattern, recursive=True):
7
+ data = json.load(open(path, encoding="utf-8"))
8
+ all_chunks.extend(data)
9
+ return all_chunks