init commit

.gitignore

@@ -206,4 +206,8 @@ marimo/_static/
 marimo/_lsp/
 __marimo__/
 
-data/
+dataset
+data/
+*.jsonl
+*.txt
+*.json

Makefile

@@ -0,0 +1,16 @@
+PY=python
+
+prepare:
+	$(PY) -m src.processing.prepare
+
+base-eval:
+	$(PY) -m src.eval.run_base_eval
+
+train:
+	$(PY) -m src.training.train
+
+ft-eval:
+	$(PY) -m src.eval.run_ft_eval
+
+demo:
+	$(PY) -m src.inference.demo_encode

README.md

@@ -1 +1,25 @@
-# Embedding-Model
+# Embedding-Model
+
+
+
+Base Model Evaluation Results
+-------------------------------------------------------------------------------------
+Metric                   768d          512d          256d          128d           64d
+-------------------------------------------------------------------------------------
+==ndcg@10==           0.2504       0.2700       0.2462       0.2189       0.1649
+mrr@10                0.1733       0.1944       0.1783       0.1592       0.1170
+map@100               0.1896       0.2096       0.1954       0.1773       0.1330
+accuracy@1            0.0543       0.0788       0.0734       0.0734       0.0462
+accuracy@3            0.2174       0.2364       0.2283       0.1902       0.1549
+accuracy@5            0.3451       0.3560       0.3152       0.2935       0.2174
+accuracy@10           0.5000       0.5163       0.4674       0.4130       0.3207
+precision@1           0.0543       0.0788       0.0734       0.0734       0.0462
+precision@3           0.0725       0.0788       0.0761       0.0634       0.0516
+precision@5           0.0690       0.0712       0.0630       0.0587       0.0435
+precision@10          0.0500       0.0516       0.0467       0.0413       0.0321
+recall@1              0.0543       0.0788       0.0734       0.0734       0.0462
+recall@3              0.2174       0.2364       0.2283       0.1902       0.1549
+recall@5              0.3451       0.3560       0.3152       0.2935       0.2174
+recall@10             0.5000       0.5163       0.4674       0.4130       0.3207
+-------------------------------------------------------------------------------------
+seq_score: 0.164851

app.py

@@ -0,0 +1,22 @@
+import src.processing.prepare as prepare
+import src.eval.run_base_eval as base_eval
+import src.training.train as train
+import src.eval.run_ft_eval as ft_eval
+
+def main():
+    print("=== Step 1: Preparing dataset ===")
+    prepare.main()
+
+    print("\n=== Step 2: Base model evaluation ===")
+    base_eval.main()
+
+    print("\n=== Step 3: Training model ===")
+    train.main()
+
+    print("\n=== Step 4: Fine-tuned model evaluation ===")
+    ft_eval.main()
+
+    print("\n✅ All steps completed.")
+
+if __name__ == "__main__":
+    main()

dataset/chunks/batch_chunks.json

@@ -1,21 +0,0 @@
-[
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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.",
-  "(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",
-  "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",
-  "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",
-  "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:",
-  "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",
-  "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"
-]

dataset/chunks/beanstalk_chunks.json

@@ -1,14 +0,0 @@
-[
-  "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",
-  "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,",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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.",
-  "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",
-  "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",
-  "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"
-]

dataset/chunks/ec2_chunks.json

@@ -1,20 +0,0 @@
-[
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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 [email protected] 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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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"
-]

dataset/chunks/ecs-dg_chunks.json

@@ -1,20 +0,0 @@
-[
-  "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",
-  "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",
-  "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",
-  "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.",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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,",
-  "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.",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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"
-]

dataset/chunks/eks-ug_chunks.json

@@ -1,38 +0,0 @@
-[
-  "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",
-  "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.",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "— 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)",
-  "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",
-  "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,",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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:",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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"
-]

dataset/chunks/fargate_chunks.json

@@ -1,17 +0,0 @@
-[
-  "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",
-  "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",
-  "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.",
-  "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",
-  "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",
-  "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 -",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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.",
-  "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",
-  "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"
-]

dataset/chunks/lambda-dg_chunks.json

@@ -1,23 +0,0 @@
-[
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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:",
-  "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.",
-  "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",
-  "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",
-  "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",
-  "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"
-]

dataset/chunks/wavelength_chunks.json

@@ -1,19 +0,0 @@
-[
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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.",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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",
-  "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"
-]

dataset/docs/batch.txt

@@ -223,367 +223,6 @@ Create IAM account and administrative user
 
 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 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 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 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 .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
-
-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 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.
-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
@@ -661,195 +300,259 @@ Prerequisites
 
 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 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
+Best practices for AWS Batch
+You can use AWS Batch to run a variety of demanding computational workloads at scale without
+managing a complex architecture. AWS Batch jobs can be used in a wide range of use cases in areas
+such as epidemiology, gaming, and machine learning.
+This topic covers the best practices to consider while using AWS Batch and guidance on how to run
+and optimize your workloads when using AWS Batch.
+Topics
+• When to use AWS Batch
+• Checklist to run at scale
+• Optimize containers and AMIs
+• Choose the right compute environment resource
+• Amazon EC2 On-Demand or Amazon EC2 Spot
+• Use Amazon EC2 Spot best practices for AWS Batch
+• Common errors and troubleshooting
+
+When to use AWS Batch
+AWS Batch runs jobs at scale and at low cost, and provides queuing services and cost-optimized
+scaling. However, not every workload is suitable to be run using AWS Batch.
+• Short jobs – If a job runs for only a few seconds, the overhead to schedule the batch job might
+take longer than the runtime of the job itself. As a workaround, binpack your tasks together
+before you submit them in AWS Batch. Then, configure your AWS Batch jobs to iterate over the
+tasks. For example, stage the individual task arguments into an Amazon DynamoDB table or as a
+file in an Amazon S3 bucket. Consider grouping tasks so the jobs run 3-5 minutes each. After you
+binpack the jobs, loop through your task groups within your AWS Batch job.
+• Jobs that must be run immediately – AWS Batch can process jobs quickly. However, AWS Batch
+is a scheduler and optimizes for cost performance, job priority, and throughput. AWS Batch
+might require time to process your requests. If you need a response in under a few seconds, then
+a service-based approach using Amazon ECS or Amazon EKS is more suitable.
+When to use AWS Batch
+
+487
 
 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.
+Checklist to run at scale
+Before you run a large workload on 50 thousand or more vCPUs, consider the following checklist.
 
-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: Create a job
-
-19
+Note
+If you plan to run a large workload on a million or more vCPUs or need guidance running at
+large scale, contact your AWS team.
+
+• Check your Amazon EC2 quotas – Check your Amazon EC2 quotas (also known as limits) in the
+Service Quotas panel of the AWS Management Console. If necessary, request a quota increase for
+your peak number of Amazon EC2 instances. Remember that Amazon EC2 Spot and Amazon OnDemand instances have separate quotas. For more information, see Getting started with Service
+Quotas.
+• Verify your Amazon Elastic Block Store quota for each Region – Each instance uses a GP2 or
+GP3 volume for the operating system. By default, the quota for each AWS Region is 300 TiB.
+However, each instance uses counts as part of this quota. So, make sure to factor this in when
+you verify your Amazon Elastic Block Store quota for each Region. If your quota is reached, you
+can’t create more instances. For more information, see Amazon Elastic Block Store endpoints and
+quotas
+• Use Amazon S3 for storage – Amazon S3 provides high throughput and helps to eliminate the
+guesswork on how much storage to provision based on the number of jobs and instances in each
+Availability Zone. For more information, see Best practices design patterns: optimizing Amazon
+S3 performance.
+• Scale gradually to identify bottlenecks early – For a job that runs on a million or more vCPUs,
+start lower and gradually increase so that you can identify bottlenecks early. For example, start
+by running on 50 thousand vCPUs. Then, increase the count to 200 thousand vCPUs, and then
+500 thousand vCPUs, and so on. In other words, continue to gradually increase the vCPU count
+until you reach the desired number of vCPUs.
+• Monitor to identify potential issues early – To avoid potential breaks and issues when running
+at scale, make sure to monitor both your application and architecture. Breaks might occur
+even when scaling from 1 thousand to 5 thousand vCPUs. You can use Amazon CloudWatch
+Logs to review log data or use CloudWatch Embedded Metrics using a client library. For more
+information, see CloudWatch Logs agent reference and aws-embedded-metrics
+Checklist to run at scale
+
+488
 
 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.
+Optimize containers and AMIs
+Container size and structure are important for the first set of jobs that you run. This is especially
+true if the container is larger than 4 GB. Container images are built in layers. The layers are
+retrieved in parallel by Docker using three concurrent threads. You can increase the number of
+concurrent threads using the max-concurrent-downloads parameter. For more information, see
+the Dockerd documentation.
+Although you can use larger containers, we recommend that you optimize container structure and
+size for faster startup times.
+• Smaller containers are fetched faster – Smaller containers can lead to faster application start
+times. To decrease container size, offload libraries or files that are updated infrequently to the
+Amazon Machine Image (AMI). You can also use bind mounts to give access to your containers.
+For more information, see Bind mounts.
+• Create layers that are even in size and break up large layers – Each layer is retrieved by one
+thread. So, a large layer might significantly impact your job startup time. We recommend a
+maximum layer size of 2 GB as a good tradeoff between larger container size and faster startup
+times. You can run the docker history your_image_id command to check your container
+image structure and layer size. For more information, see the Docker documentation.
+• Use Amazon Elastic Container Registry as your container repository – When you run thousands
+of jobs in parallel, a self-managed repository can fail or throttle throughput. Amazon ECR works
+at scale and can handle workloads with up to over a million vCPUs.
+
+Optimize containers and AMIs
+
+489
 
-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.
+AWS Batch
 
-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.
+User Guide
 
-In the navigation pane choose Job queue.
+Choose the right compute environment resource
+AWS Fargate requires less initial setup and configuration than Amazon EC2 and is likely easier
+to use, particularly if it's your first time. With Fargate, you don't need to manage servers, handle
+capacity planning, or isolate container workloads for security.
+If you have the following requirements, we recommend you use Fargate instances:
+• Your jobs must start quickly, specifically less than 30 seconds.
+• The requirements of your jobs are 16 vCPUs or less, no GPUs, and 120 GiB of memory or less.
+For more information, see When to use Fargate.
+If you have the following requirements, we recommend that you use Amazon EC2 instances:
+• You require increased control over the instance selection or require using specific instance types.
+• Your jobs require resources that AWS Fargate can’t provide, such as GPUs, more memory, a
+custom AMI, or the Amazon Elastic Fabric Adapter.
+• You require a high level of throughput or concurrency.
+• You need to customize your AMI, Amazon EC2 Launch Template, or access to special Linux
+parameters.
+With Amazon EC2, you can more finely tune your workload to your specific requirements and run at
+scale if needed.
+
+Amazon EC2 On-Demand or Amazon EC2 Spot
+Most AWS Batch customers use Amazon EC2 Spot instances because of the savings over OnDemand instances. However, if your workload runs for multiple hours and can't be interrupted,
+On-Demand instances might be more suitable for you. You can always try Spot instances first and
+switch to On-Demand if necessary.
+If you have the following requirements and expectations, use Amazon EC2 On-Demand instances:
+• The runtime of your jobs is more than an hour, and you can't tolerate interruptions to your
+workload.
+Choose the right compute environment resource
+
+490
 
-2.
+AWS Batch
 
-In the Job queue table choose the Job queue you created for the tutorial.
+User Guide
 
-3.
+• You have a strict SLO (service-level objective) for your overall workload and can’t increase
+computational time.
+• The instances that you require are more likely to see interruptions.
+If you have the following requirements and expectations, use Amazon EC2 Spot instances:
+• The runtime for your jobs is typically 30 minutes or less.
+• You can tolerate potential interruptions and job rescheduling as a part of your workload. For
+more information, see Spot Instance advisor.
+• Long running jobs can be restarted from a checkpoint if interrupted.
+You can mix both purchasing models by submitting on Spot instance first and then use
+On-Demand instance as a fallback option. For example, submit your jobs on a queue that's
+connected to compute environments that are running on Amazon EC2 Spot instances. If a job
+gets interrupted, catch the event from Amazon EventBridge and correlate it to a Spot instance
+reclamation. Then, resubmit the job to an On-Demand queue using an AWS Lambda function or
+AWS Step Functions. For more information, see Tutorial: Sending Amazon Simple Notification
+Service alerts for failed job events, Best practices for handling Amazon EC2 Spot Instance
+interruptions and Manage AWS Batch with Step Functions.
 
-Choose Disable. Once the Job queue State is Disabled you can choose Delete.
+Important
+Use different instance types, sizes, and Availability Zones for your On-Demand compute
+environment to maintain Amazon EC2 Spot instance pool availability and decrease the
+interruption rate.
 
-4.
+Use Amazon EC2 Spot best practices for AWS Batch
+When you choose Amazon Elastic Compute Cloud (EC2) Spot instances, you likely can optimize
+your workflow to save costs, sometimes significantly. For more information, see Best practices for
+Amazon EC2 Spot.
+To optimize your workflow to save costs, consider the following Amazon EC2 Spot best practices
+for AWS Batch:
 
-Once the Job queue is deleted, in the navigation pane choose Compute environments.
+Use Amazon EC2 Spot best practices for AWS Batch
 
-5.
+491
 
-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.
+AWS Batch
 
-6.
+User Guide
 
-Once the compute environment’s State is Disabled, choose Delete. It may take 1–2 minuets for
-the compute environment to be deleted.
+• Choose the SPOT_CAPACITY_OPTIMIZED allocation strategy – AWS Batch chooses Amazon
+EC2 instances from the deepest Amazon EC2 Spot capacity pools. If you’re concerned about
+interruptions, this is a suitable choice. For more information, see Instance type allocation
+strategies for AWS Batch.
+• Diversify instance types – To diversify your instance types, consider compatible sizes and
+families, then let AWS Batch choose based on price or availability. For example, consider
+c5.24xlarge as an alternative to c5.12xlarge or c5a, c5n, c5d, m5, and m5d families. For
+more information, see Be flexible about instance types and Availability Zones.
+• Reduce job runtime or checkpoint – We advise against running jobs that take an hour or more
+when using Amazon EC2 Spot instances to avoid interruptions. If you divide or checkpoint
+your jobs into smaller parts that consist of 30 minutes or less, you can significantly reduce the
+possibility of interruptions.
+• Use automated retries – To avoid disruptions to AWS Batch jobs, set automated retries for jobs.
+Batch jobs can be disrupted for any of the following reasons: a non-zero exit code is returned, a
+service error occurs, or an instance reclamation occurs. You can set up to 10 automated retries.
+For a start, we recommend that you set at least 1-3 automated retries. For information about
+tracking Amazon EC2 Spot interruptions, see Spot Interruption Dashboard.
+For AWS Batch, if you set the retry parameter, the job is placed at the front of the job queue.
+That is, the job is given priority. When you create the job definition or you submit the job in the
+AWS CLI, you can configure a retry strategy. For more information, see submit-job.
+$ aws batch submit-job --job-name MyJob \
+--job-queue MyJQ \
+--job-definition MyJD \
+--retry-strategy attempts=2
+
+• Use custom retries – You can configure a job retry strategy to a specific application exit code
+or instance reclamation. In the following example, if the host causes the failure, the job can
+be retried up to five times. However, if the job fails for a different reason, the job exits and the
+status is set to FAILED.
+"retryStrategy": {
+"attempts": 5,
+"evaluateOnExit":
+[{
+"onStatusReason" :"Host EC2*",
+"action": "RETRY"
+Use Amazon EC2 Spot best practices for AWS Batch
+
+492
 
-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 options.
-• Learn more about Job definitions and the different configuration options.
-• Learn more about the different types of Jobs.
+AWS Batch
 
-Step 7: Clean up your tutorial resources
+User Guide
 
-20
+},{
+"onReason" : "*",
+"action": "EXIT"
+}]
+}
+
+• Use the Spot Interruption Dashboard – You can use the Spot Interruption Dashboard to track
+Spot interruptions. The application provides metrics on Amazon EC2 Spot instances that are
+reclaimed and which Availability Zones that Spot instances are in. For more information, see Spot
+Interruption Dashboard
+
+Common errors and troubleshooting
+Errors in AWS Batch often occur at the application level or are caused by instance configurations
+that don’t meet your specific job requirements. Other issues include jobs getting stuck in
+the RUNNABLE status or compute environments getting stuck in an INVALID state. For more
+information about troubleshooting jobs getting stuck in RUNNABLE status, see Jobs stuck in a
+RUNNABLE status. For information about troubleshooting compute environments in an INVALID
+state, see INVALID compute environment.
+• Check Amazon EC2 Spot vCPU quotas – Verify that your current service quotas meet the job
+requirements. For example, suppose that your current service quota is 256 vCPUs and the job
+requires 10,000 vCPUs. Then, the service quota doesn't meet the job requirement. For more
+information and troubleshooting instructions, see Amazon EC2 service quotas and How do I
+increase the service quota of my Amazon EC2resources?.
+• Jobs fail before the application runs – Some jobs might fail because of a
+DockerTimeoutError error or a CannotPullContainerError error. For troubleshooting
+information, see How do I resolve the "DockerTimeoutError" error in AWS Batch?.
+• Insufficient IP addresses – The number of IP addresses in your VPC and subnets can limit the
+number of instances that you can create. Use Classless Inter-Domain Routings (CIDRs) to provide
+more IP addresses than are required to run your workloads. If necessary, you can also build a
+dedicated VPC with a large address space. For example, you can create a VPC with multiple
+CIDRs in 10.x.0.0/16 and a subnet in every Availability Zone with a CIDR of 10.x.y.0/17.
+In this example, x is between 1-4 and y is either 0 or 128. This configuration provides 36,000 IP
+addresses in every subnet.
+
+Common errors and troubleshooting
+
+493
 
 

dataset/docs/beanstalk.txt

@@ -96,12 +96,6 @@ Estimated duration: 35-45 minutes
 
 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.
@@ -316,16 +310,6 @@ Step 2 - Deploy your application
 
 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.
@@ -396,272 +380,603 @@ Step 3 - Explore the environment
 
 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 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.
+Understanding concepts in Elastic Beanstalk
+Becoming familiar with the concepts and terms will help you gain an understanding needed for
+deploying your applications with Elastic Beanstalk.
 
-Navigate to your environment in the Elastic Beanstalk console.
+142
 
-2.
+AWS Elastic Beanstalk
 
-Choose the Logs tab or left-nav, then choose Request logs.
+Developer Guide
 
-3.
+Application
+An Elastic Beanstalk application is a container for Elastic Beanstalk components, including
+environments, versions, and environment configurations. Within an Elastic Beanstalk application,
+you manage all the resources relevant to running your code.
+
+Application version
+In Elastic Beanstalk, an application version refers to a specific, labeled iteration of deployable code
+for a web application. An application version points to an Amazon Simple Storage Service (Amazon
+S3) object that contains the deployable code, such as a Java WAR file.
+An application version is part of an application. Applications can have many versions and each
+application version is unique. In a running environment, you can deploy any application version you
+already uploaded to the application, or you can upload and immediately deploy a new application
+version. For example, you could upload multiple application versions to test differences between
+them.
 
-Select Last 100 lines.
+Environment
+An environment is a collection of AWS resources running an application version. Each environment
+runs only one application version at a time, however, you can run the same application version
+or different application versions in many environments simultaneously. When you create an
+environment, Elastic Beanstalk provisions the resources needed in your AWS account to run the
+application version you specified.
+
+Environment tier
+When you launch an Elastic Beanstalk environment, you first choose an environment tier. The
+environment tier designates the type of application that the environment runs and determines
+what resources Elastic Beanstalk provisions to support it. An application that serves HTTP requests
+runs in a web server environment tier. A backend environment that pulls tasks from an Amazon
+Simple Queue Service (Amazon SQS) queue runs in a worker environment tier.
+
+Environment configuration
+An environment configuration identifies a collection of parameters and settings that define
+how an environment and its associated resources behave. When you update an environment’s
+Application
+
+143
 
-4.
+AWS Elastic Beanstalk
 
-After the logs are created, choose the Download link to view the logs in the browser.
+Developer Guide
 
-In the logs, find the log and note the directory for the nginx access log.
+configuration settings, Elastic Beanstalk automatically applies the changes to existing resources or
+deletes and deploys new resources (depending on the type of change).
 
-Troubleshooting with logs
+Saved configuration
+A saved configuration is a template that you can use as a starting point for creating unique
+environment configurations. You can create and modify saved configurations, and apply them to
+environments, using the Elastic Beanstalk console, EB CLI, AWS CLI, or API. The API and the AWS
+CLI refer to saved configurations as configuration templates.
 
-16
+Platform
+A platform is a combination of an operating system, programming language runtime, web server,
+application server, and Elastic Beanstalk components. You design and target your web application
+to a platform. Elastic Beanstalk provides a variety of platforms on which you can build your
+applications.
+For details, see Elastic Beanstalk platforms.
 
-AWS Elastic Beanstalk
+Elastic Beanstalk web server environments
+The following diagram shows an example Elastic Beanstalk architecture for a web server
+environment tier, and shows how the components in that type of environment tier work together.
 
-Developer Guide
+Saved configuration
 
-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.
+144
 
-Navigate to the IAM console.
+AWS Elastic Beanstalk
 
-2.
+Developer Guide
 
-Find and select the aws-elasticbeanstalk-ec2-role role.
+The environment is the heart of the application. In the diagram, the environment is shown within
+the top-level solid line. When you create an environment, Elastic Beanstalk provisions the resources
+required to run your application. AWS resources created for an environment include one elastic
+load balancer (ELB in the diagram), an Auto Scaling group, and one or more Amazon Elastic
+Compute Cloud (Amazon EC2) instances.
+Every environment has a CNAME (URL) that points to a load balancer. The environment
+has a URL, such as myapp.us-west-2.elasticbeanstalk.com. This URL is aliased in
+Amazon Route 53 to an Elastic Load Balancing URL—something like abcdef-123456.uswest-2.elb.amazonaws.com—by using a CNAME record. Amazon Route 53 is a highly available
+and scalable Domain Name System (DNS) web service. It provides secure and reliable routing to
+your infrastructure. Your domain name that you registered with your DNS provider will forward
+requests to the CNAME.
+The load balancer sits in front of the Amazon EC2 instances, which are part of an Auto Scaling
+group. Amazon EC2 Auto Scaling automatically starts additional Amazon EC2 instances to
+accommodate increasing load on your application. If the load on your application decreases,
+Amazon EC2 Auto Scaling stops instances, but always leaves at least one instance running.
+The software stack running on the Amazon EC2 instances is dependent on the container type.
+A container type defines the infrastructure topology and software stack to be used for that
+environment. For example, an Elastic Beanstalk environment with an Apache Tomcat container uses
+the Amazon Linux operating system, Apache web server, and Apache Tomcat software. For a list of
+supported container types, see Elastic Beanstalk supported platforms. Each Amazon EC2 instance
+that runs your application uses one of these container types. In addition, a software component
+called the host manager (HM) runs on each Amazon EC2 instance. The host manager is responsible
+for the following:
+• Deploying the application
+• Aggregating events and metrics for retrieval via the console, the API, or the command line
+• Generating instance-level events
+• Monitoring the application log files for critical errors
+• Monitoring the application server
+• Patching instance components
+• Rotating your application's log files and publishing them to Amazon S3
+
+Web server environments
+
+145
 
-3.
+AWS Elastic Beanstalk
 
-Choose Add permission, then Attach policies.
+Developer Guide
 
-4.
+The host manager reports metrics, errors and events, and server instance status, which are
+available via the Elastic Beanstalk console, APIs, and CLIs.
+The Amazon EC2 instances shown in the diagram are part of one security group. A security group
+defines the firewall rules for your instances. By default, Elastic Beanstalk defines a security
+group, which allows everyone to connect using port 80 (HTTP). You can define more than one
+security group. For example, you can define a security group for your database server. For more
+information about Amazon EC2 security groups and how to configure them for your Elastic
+Beanstalk application, see EC2 security groups.
+
+Elastic Beanstalk worker environments
+AWS resources created for a worker environment tier include an Auto Scaling group, one or more
+Amazon EC2 instances, and an IAM role. For the worker environment tier, Elastic Beanstalk also
+creates and provisions an Amazon SQS queue if you don’t already have one. When you launch a
+worker environment, Elastic Beanstalk installs the necessary support files for your programming
+language of choice and a daemon on each EC2 instance in the Auto Scaling group. The daemon
+reads messages from an Amazon SQS queue. The daemon sends data from each message that
+it reads to the web application running in the worker environment for processing. If you have
+multiple instances in your worker environment, each instance has its own daemon, but they all read
+from the same Amazon SQS queue.
+The following diagram shows the different components and their interactions across environments
+and AWS services.
+
+Worker environments
+
+146
 
-Search for a default policy that begins with the following text:
-AmazonSSMManagedEC2Instance, then add it to the role.
+AWS Elastic Beanstalk
 
-To connect to your Amazon EC2 with Session Manager
-1.
+Developer Guide
 
-Navigate to the Amazon EC2 console.
+Amazon CloudWatch is used for alarms and health monitoring. For more information, go to Basic
+health reporting.
+For details about how the worker environment tier works, see Elastic Beanstalk worker
+environments.
 
-2.
+Design considerations for your Elastic Beanstalk applications
+Because applications deployed using AWS Elastic Beanstalk run on AWS Cloud resources, you
+should keep several configuration factors in mind to optimize your applications: scalability, security,
+persistent storage, fault tolerance, content delivery, software updates and patching, and connectivity.
+Each of these are covered separately in this topic. For a comprehensive list of technical AWS
+whitepapers, covering topics such as architecture, as well as security and economics, see AWS Cloud
+Computing Whitepapers.
 
-Choose Instances, then select your gs-app-web-env instance.
+Design considerations
 
-3.
+147
 
-Choose Connect, then Session Manager.
+AWS Elastic Beanstalk
 
-4.
+Developer Guide
 
-Choose Connect.
+Scalability
+When operating in a physical hardware environment, in contrast to a cloud environment, you can
+approach scalability in one of either two ways. Either you can scale up through vertical scaling
+or you can scale out through horizontal scaling. The scale-up approach requires that you invest
+in powerful hardware, which can support the increasing demands of your business. The scaleout approach requires that you follow a distributed model of investment. As such, your hardware
+and application acquisitions can be more targeted, your data sets are federated, and your design
+is service oriented. The scale-up approach can be expensive, and there's also the risk that your
+demand could outgrow your capacity. In this regard, the scale-out approach is usually more
+effective. However, when using it, you must be able to predict demand at regular intervals and
+deploy infrastructure in chunks to meet that demand. As a result, this approach can often lead to
+unused capacity and might require some careful monitoring.
+By migrating to the cloud, you can make your infrastructure align well with demand by leveraging
+the elasticity of cloud. Elasticity helps to streamline resource acquisition and release. With it,
+your infrastructure can rapidly scale in and scale out as demand fluctuates. To use it, configure
+your Auto Scaling settings to scale up or down based on the metrics for the resources in your
+environment. For example, you can set metrics such as server utilization or network I/O. You can
+use Auto Scaling for compute capacity to be added automatically whenever usage rises and for it
+to be removed whenever usage drops. You can publish system metrics (for example, CPU, memory,
+disk I/O, and network I/O) to Amazon CloudWatch. Then, you can use CloudWatch to configure
+alarms to trigger Auto Scaling actions or send notifications based on these metrics. For instructions
+on how to configure Auto Scaling, see Auto Scaling your Elastic Beanstalk environment instances.
+We also recommend that you design all your Elastic Beanstalk applications as stateless as possible,
+using loosely coupled, fault-tolerant components that can be scaled out as needed. For more
+information about designing scalable application architectures for AWS, see AWS Well-Architected
+Framework.
+
+Security
+Security on AWS is a shared responsibility. Amazon Web Services protects the physical resources
+in your environment and ensures that the Cloud is a safe place for you to run applications. You're
+responsible for the security of data coming in and out of your Elastic Beanstalk environment and
+the security of your application.
+Configure SSL to protect information that flows between your application and clients. To configure
+SSL, you need a free certificate from AWS Certificate Manager (ACM). If you already have a
+Scalability
+
+148
 
-After connecting to the instance, start a bash shell and tail the logs:
-1.
+AWS Elastic Beanstalk
 
-Run the command bash.
+Developer Guide
 
-2.
+certificate from an external certificate authority (CA), you can use ACM to import that your
+certificate. Otherwise, you can import it using the AWS CLI.
+If ACM isn't available in your AWS Region, you can purchase a certificate from an external CA, such
+as VeriSign or Entrust. Then, use the AWS Command Line Interface (AWS CLI) to upload a thirdparty or self-signed certificate and private key to AWS Identity and Access Management (IAM). The
+public key of the certificate authenticates your server to the browser. It also serves as the basis for
+creating the shared session key that encrypts the data in both directions. For instructions on how
+to create, upload, and assign an SSL certificate to your environment, see Configuring HTTPS for
+your Elastic Beanstalk environment.
+When you configure an SSL certificate for your environment, data is encrypted between the client
+and the Elastic Load Balancing load balancer for your environment. By default, encryption is
+terminated at the load balancer, and traffic between the load balancer and Amazon EC2 instances
+is unencrypted.
 
-Run the command cd /var/log/nginx.
+Persistent storage
+Elastic Beanstalk applications run on Amazon EC2 instances that have no persistent local storage.
+When the Amazon EC2 instances terminate, the local file system isn't saved. New Amazon EC2
+instances start with a default file system. We recommend that you configure your application to
+store data in a persistent data source. AWS offers a number of persistent storage services that you
+can use for your application. The following table lists them.
+Storage service
 
-3.
+Service documentation
 
-Run the command tail -f access.log.
+Elastic Beanstalk integration
 
-4.
+Amazon S3
 
-In your browser, go to the application domain URL. Refresh.
+Amazon Simple Storage
+Service Documentation
 
-Congratulations, you're connected!
-You should see log entries in your instance update every time you refresh the page.
+Using Elastic Beanstalk with
+Amazon S3
 
-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.
+Amazon Elastic File
+System
 
-Troubleshooting with logs
+Amazon Elastic File System
+Documentation
 
-17
+Using Elastic Beanstalk with
+Amazon Elastic File System
 
-AWS Elastic Beanstalk
+Amazon Elastic Block
+Store
 
-Developer Guide
+Amazon Elastic Block Store
 
-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.
+Amazon DynamoDB
 
-To update your application version
-1.
+Amazon DynamoDB
+Documentation
 
-Download the following PHP sample application:
-PHP – php-v2.zip
+Persistent storage
 
-2.
+Feature Guide: Elastic Block
+Store
+Using Elastic Beanstalk with
+Amazon DynamoDB
+149
 
-Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.
+AWS Elastic Beanstalk
 
-3.
+Developer Guide
 
-In the navigation pane, choose Environments, and then choose the name of your environment
-from the list.
+Storage service
 
-4.
+Service documentation
 
-On the environment overview page, choose Upload and deploy.
+Elastic Beanstalk integration
 
-5.
+Amazon Relational
+Database Service (RDS)
 
-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. If you choose your own version label, ensure that it's unique.
+Amazon Relational Database
+Service Documentation
 
-Step 4 - Update your application
+Using Elastic Beanstalk with
+Amazon RDS
 
-18
+Note
+Elastic Beanstalk creates a webapp user for you to set up as the owner of application
+directories on EC2 instances. For Amazon Linux 2 platform versions that are released on
+or after Feburary 3, 2022, Elastic Beanstalk assigns the webapp user a uid (user id) and gid
+(group id) value of 900 for new environments. It does the same for existing environments
+following a platform version update. This approach keeps consistent access permission for
+the webapp user to permanent file system storage.
+In the unlikely situation that another user or process is already using 900, the operating
+system defaults the webapp user uid and gid to another value. Run the Linux command
+id webapp on your EC2 instances to verify the uid and gid values that are assigned to the
+webapp user.
+
+Fault tolerance
+As a rule of thumb, you should be a pessimist when designing architecture for the cloud. Leverage
+the elasticity that it offers. Always design, implement, and deploy for automated recovery from
+failure. Use multiple Availability Zones for your Amazon EC2 instances and for Amazon RDS.
+Availability Zones are conceptually like logical data centers. Use Amazon CloudWatch to get more
+visibility into the health of your Elastic Beanstalk application and take appropriate actions in case
+of hardware failure or performance degradation. Configure your Auto Scaling settings to maintain
+your fleet of Amazon EC2 instances at a fixed size so that unhealthy Amazon EC2 instances are
+replaced by new ones. If you're using Amazon RDS, then set the retention period for backups, so
+that Amazon RDS can perform automated backups.
+
+Content delivery
+When users connect to your website, their requests may be routed through a number of individual
+networks. As a result, users might experience poor performance due to high latency. Amazon
+CloudFront can help ameliorate latency issues by distributing your web content, such as images
+and video, across a network of edge locations around the world. Users' requests are routed to the
+Fault tolerance
+
+150
 
 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
+nearest edge location, so content is delivered with the best possible performance. CloudFront
+works seamlessly with Amazon S3, which durably stores the original, definitive versions of your
+files. For more information about Amazon CloudFront, see the Amazon CloudFront Developer
+Guide.
+
+Software updates and patching
+AWS Elastic Beanstalk regularly releases platform updates to provide fixes, software updates,
+and new features. Elastic Beanstalk offers several options to handle platform updates. With
+managed platform updates your environment automatically upgrades to the latest version of a
+platform during a scheduled maintenance window while your application remains in service. For
+environments created on November 25, 2019 or later using the Elastic Beanstalk console, managed
+updates are enabled by default whenever possible. You can also manually initiate updates using
+the Elastic Beanstalk console or EB CLI.
+
+Connectivity
+Elastic Beanstalk needs to be able to connect to the instances in your environment to complete
+deployments. When you deploy an Elastic Beanstalk application inside an Amazon VPC, the
+configuration required to enable connectivity depends on the type of Amazon VPC environment
+you create:
+• For single-instance environments, no additional configuration is required. This is because, with
+these environments, Elastic Beanstalk assigns each Amazon EC2 instance a public Elastic IP
+address that enables the instance to communicate directly with the internet.
+• For load-balanced, scalable environments in an Amazon VPC with both public and private
+subnets, you must do the following:
+• Create a load balancer in the public subnet to route inbound traffic from the internet to the
+Amazon EC2 instances.
+• Create a network address translation (NAT) device to route outbound traffic from the Amazon
+EC2 instances in private subnets to the internet.
+• Create inbound and outbound routing rules for the Amazon EC2 instances inside the private
+subnet.
+• If you're using a NAT instance, configure the security groups for the NAT instance and Amazon
+EC2 instances to enable internet communication.
+• For a load-balanced, scalable environment in an Amazon VPC that has one public subnet, no
+additional configuration is required. This is because, with this environment, your Amazon EC2
+Software updates and patching
+
+151
 
 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.
+instances are configured with a public IP address that enables the instances to communicate with
+the internet.
+For more information about using Elastic Beanstalk with Amazon VPC, see Using Elastic Beanstalk
+with Amazon VPC.
 
-Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.
+Connectivity
 
-2.
+152
 
-In the navigation pane, choose Environments, and then choose the name of your environment
-from the list.
-
-3.
+AWS Elastic Beanstalk
 
-In the navigation pane, choose Configuration.
+Developer Guide
 
-4.
+Elastic Beanstalk platforms
+AWS Elastic Beanstalk provides a variety of platforms on which you can build your applications.
+You design your web application to one of these platforms, and Elastic Beanstalk deploys your
+code to the platform version you selected to create an active application environment.
+Elastic Beanstalk provides platforms for different programming languages, application servers, and
+Docker containers. Some platforms have multiple concurrently-supported versions.
+Topics
+• Elastic Beanstalk platforms glossary
+• Shared responsibility model for Elastic Beanstalk platform maintenance
+• Elastic Beanstalk platform support policy
+• Elastic Beanstalk platform release schedule
+• Elastic Beanstalk supported platforms
+• Elastic Beanstalk Linux platforms
+• Extending Elastic Beanstalk Linux platforms
+
+Elastic Beanstalk platforms glossary
+Following are key terms related to AWS Elastic Beanstalk platforms and their lifecycle.
+Runtime
+The programming language-specific runtime software (framework, libraries, interpreter, vm,
+etc.) required to run your application code.
+Elastic Beanstalk Components
+Software components that Elastic Beanstalk adds to a platform to enable Elastic Beanstalk
+functionality. For example, the enhanced health agent is necessary for gathering and reporting
+health information.
+Platform
+A combination of an operating system (OS), runtime, web server, application server, and
+Elastic Beanstalk components. Platforms provide components that are available to run your
+application.
+Platforms glossary
 
-In the Instance traffic and scaling configuration category, choose Edit.
+742
 
-5.
+AWS Elastic Beanstalk
 
-Collapse the Instances section, so you can more easily see the Capacity section. Under Auto
-Scaling group change Environment type to Load balanced.
+Developer Guide
 
-6.
+Platform Version
+A combination of specific versions of an operating system (OS), runtime, web server, application
+server, and Elastic Beanstalk components. You create an Elastic Beanstalk environment based
+on a platform version and deploy your application to it.
+A platform version has a semantic version number of the form X.Y.Z, where X is the major
+version, Y is the minor version, and Z is the patch version.
+A platform version can be in one of the following states:
+• Recommended – The latest platform version in a supported platform branch. This version
+contains the most up-to-date components and is recommended for use in production
+environments.
+• Not Recommended – Any platform version that is not the latest version in its platform
+branch. While these versions may remain functional, we strongly recommend updating to
+the latest platform version. You can use managed platform updates to help stay up-to-date
+automatically.
+You can verify if a platform version is recommended using the AWS CLI command describeplatform-version and checking the PlatformLifecycleState field.
+Platform Branch
+A line of platform versions sharing specific (typically major) versions of some of their
+components, such as the operating system (OS), runtime, or Elastic Beanstalk components. For
+example: Python 3.13 running on 64bit Amazon Linux 2023; IIS 10.0 running on 64bit Windows
+Server 2025. Platform branches receive updates in the form of new platform versions. Each
+successive platform version in a branch is an update to the previous one.
+The recommended version in each supported platform branch is available to you
+unconditionally for environment creation. A previous platform version is available to you if you
+were using an environment with it at the time the platform version was superceded by a new
+platform version. Previous platform versions lack the most up-to-date components and aren't
+recommended for use.
+A platform branch can be in one of the following states:
+• Supported – A current platform branch. It consists entirely of supported components.
+Supported components have not reached End of Life (EOL), as designated by their
+suppliers. It receives ongoing platform updates, and is recommended for use in production
+Platforms glossary
+
+743
 
-In the Instances row, change Min to 2 and Max to 4.
+AWS Elastic Beanstalk
 
-Increase capacity settings
+Developer Guide
 
-20
+environments. For a list of supported platform branches, see Elastic Beanstalk supported
+platforms in the AWS Elastic Beanstalk Platforms guide.
+• Beta – A preview, pre-release platform branch. It's experimental in nature. It may receive
+ongoing platform updates for a while, but has no long-term support. A beta platform branch
+isn't recommended for use in production environments. Use it only for evaluation. For a list
+of beta platform branches, see Elastic Beanstalk Platform Versions in Public Beta in the AWS
+Elastic Beanstalk Platforms guide.
+• Deprecated – A platform branch where one or more components (such as the runtime or
+operating system) are approaching End of Life (EOL) or have reached EOL, as designated
+by their suppliers. While a deprecated platform branch continues to receive new platform
+versions until its retirement date, components that have reached EOL don't receive updates.
+For example, if a runtime version reaches EOL, the platform branch will be marked as
+deprecated but will continue to receive operating system updates until the platform branch
+retirement date. The platform branch will not continue to receive updates to the EOL runtime
+version. A deprecated platform branch isn't recommended for use.
+• Retired – A platform branch that no longer receives any updates. Retired platform branches
+aren't available to create new Elastic Beanstalk environments using the Elastic Beanstalk
+console. If your environment uses a retired platform branch, you must update to a supported
+platform branch to continue receiving updates. A retired platform branch isn't recommended
+for use. For more details about retired platform branches, see the section called “Platform
+support policy”. For a list of platform branches scheduled for retirement, see Retiring
+platform branch schedule. To see past retired platform branches, see Retired platform branch
+history.
+If your environment uses a deprecated or retired platform branch, we recommend that you
+update it to a platform version in a supported platform branch. For details, see the section
+called “Platform updates”.
+You can verify the state of a platform branch using the AWS CLI command describe-platformversion and checking the PlatformBranchLifecycleState field.
+Platform Update
+A release of new platform versions that contain updates to some components of the platform
+—OS, runtime, web server, application server, and Elastic Beanstalk components. Platform
+updates follow semantic version taxonomy, and can have three levels:
+
+Platforms glossary
+
+744
 
 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.
+• Major update – An update that has changes that are incompatible with existing platform
+versions. You may need to modify your application to run correctly on a new major version. A
+major update has a new major platform version number.
+• Minor update – An update that has changes that are backward compatible with existing
+platform versions in most cases. Depending on your application, you may need to modify
+your application to run correctly on a new minor version. A minor update has a new minor
+platform version number.
+• Patch update – An update that consists of maintenance releases (bug fixes, security updates,
+and performance improvements) that are backward compatible with an existing platform
+version. A patch update has a new patch platform version number.
+Managed Updates
+An Elastic Beanstalk feature that automatically applies patch and minor updates to the
+operating system (OS), runtime, web server, application server, and Elastic Beanstalk
+components for an Elastic Beanstalk supported platform version. A managed update applies a
+newer platform version in the same platform branch to your environment. You can configure
+managed updates to apply only patch updates, or minor and patch updates. You can also
+disable managed updates completely.
+For more information, see Managed platform updates.
+
+Shared responsibility model for Elastic Beanstalk platform
+maintenance
+AWS and our customers share responsibility for achieving a high level of software component
+security and compliance. This shared model reduces your operational burden.
+For details, see the AWS Shared Responsibility Model.
+AWS Elastic Beanstalk helps you perform your side of the shared responsibility model by providing
+a managed updates feature. This feature automatically applies patch and minor updates for an
+Elastic Beanstalk supported platform version. If a managed update fails, Elastic Beanstalk notifies
+you of the failure to ensure that you are aware of it and can take immediate action.
+For more information, see Managed platform updates.
+In addition, Elastic Beanstalk does the following:
+Shared responsibility model
+
+745
 
-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.
+AWS Elastic Beanstalk
 
-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.
+Developer Guide
 
-Choose Health from either the tab list or left navigation pane.
+• Publishes its platform support policy and retirement schedule for the coming 12 months.
+• Releases patch, minor, and major updates of operating system (OS), runtime, application server,
+and web server components typically within 30 days of their availability. Elastic Beanstalk
+is responsible for creating updates to Elastic Beanstalk components that are present on its
+supported platform versions. All other updates come directly from their suppliers (owners or
+community).
+We announce all updates to our supported platforms in our release notes in the AWS Elastic
+Beanstalk Release Notes guide. We also provide a list of all supported platforms and their
+components, along with a platform history, in the AWS Elastic Beanstalk Platforms guide. For more
+information see Supported platforms and component history.
+You are responsible to do the following:
+• Update all the components that you control (identified as Customer in the AWS Shared
+Responsibility Model). This includes ensuring the security of your application, your data, and any
+components that your application requires and that you downloaded.
+• Ensure that your Elastic Beanstalk environments are running on a supported platform version,
+and migrate any environment running on a retired platform version to a supported version.
+• If you’re using a custom Amazon machine image (AMI) for your Elastic Beanstalk environment,
+patch, maintain, and test your custom AMI so that it remains current and compatible with
+a supported Elastic Beanstalk platform version. For more information about managing
+environments with a custom AMI, see Using a custom Amazon machine image (AMI) in your
+Elastic Beanstalk environment.
+• Resolve all issues that come up in failed managed update attempts and retry the update.
+• Patch the OS, runtime, application server, and web server yourself if you opted out of Elastic
+Beanstalk managed updates. You can do this by applying platform updates manually or directly
+patching the components on all relevant environment resources.
+• Manage the security and compliance of any AWS services that you use outside of Elastic
+Beanstalk according to the AWS Shared Responsibility Model.
+
+Shared responsibility model
+
+746
 
-2.
+AWS Elastic Beanstalk
 
-Review the Enhanced instance health section.
+Developer Guide
 
-You just scaled up!
-With two Amazon EC2 instances, your environment capacity has doubled, and it only took a
-few minutes.
+Elastic Beanstalk platform support policy
+Elastic Beanstalk supports platform branches that still receive ongoing minor and patch updates
+from their suppliers (owners or community). For a complete definition of related terms, see Elastic
+Beanstalk platforms glossary.
+
+Retired platform branches
+When a component of a supported platform branch is marked End of Life (EOL) by its supplier,
+Elastic Beanstalk marks the platform branch as retired. Components of a platform branch include
+the following: operating system (OS), runtime language version, application server, or web server.
+Once a platform branch is marked as retired the following policies apply:
+• Elastic Beanstalk stops providing maintenance updates, including security updates.
+• Elastic Beanstalk no longer provides technical support for retired platform branches.
+• Elastic Beanstalk no longer makes the platform branch available to new Elastic Beanstalk
+customers for deployments to new environments. There is a 90 day grace period from the
+published retirement date for existing customers with active environments that are running on
+retired platform branches.
+
+Note
+A retired platform branch will not be available in the Elastic Beanstalk console. However, it
+will be available through the AWS CLI, EB CLI and EB API for customers that have existing
+environments based on the retired platform branch. Existing customers can also use the
+Clone environment and Rebuild environment consoles.
 
-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.
+For a list of platform branches that are scheduled for retirement see the Retiring platform branch
+schedule in the Elastic Beanstalk platform schedule topic that follows.
+For more information about what to expect when your environment’s platform branch retires, see
+Platform retirement FAQ.
 
-Verify increased capacity
+Platform support policy
 
-21
+747
 
 

dataset/docs/ec2.txt

@@ -67,40 +67,6 @@ Related services
 
 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 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
@@ -139,89 +105,6 @@ Access EC2
 
 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 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 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
@@ -775,4 +658,930 @@ Contents
 • AMI quotas in Amazon EC2
 20
 
+Amazon Elastic Compute Cloud
+
+User Guide
+
+AMI types and characteristics in Amazon EC2
+When you launch an instance, the AMI that you choose must be compatible with the instance type
+that you choose. You can select an AMI to use based on the following characteristics:
+• Region
+• Operating system
+• Processor architecture
+• Launch permissions
+• Root device type
+• Virtualization types
+
+Launch permissions
+Launch permissions determine who can use an AMI to launch instances. You can think of launch
+permissions as sharing an AMI—when you grant launch permissions, you're sharing the AMI
+with other users. Only the owner of an AMI can determine its availability by specifying launch
+permissions. Launch permissions fall into the following categories.
+Launch
+permission
+
+Description
+
+public
+
+The owner grants launch permissions to all AWS accounts.
+
+explicit
+
+The owner grants launch permissions to specific AWS accounts, organizat
+ions, or organizational units (OUs).
+
+implicit
+
+The owner has implicit launch permissions for an AMI.
+
+Amazon and the Amazon EC2 community provide a large selection of public AMIs. For more
+information, see Understand shared AMI usage in Amazon EC2. Developers can charge for their
+AMIs. For more information, see Paid AMIs in the AWS Marketplace for Amazon EC2 instances.
+
+Root device type
+All AMIs are categorized as either backed by Amazon EBS or backed by instance store.
+AMI characteristics
+
+21
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+• Amazon EBS-backed AMI – The root device for an instance launched from the AMI is an Amazon
+Elastic Block Store (Amazon EBS) volume created from an Amazon EBS snapshot. Supported for
+both Linux and Windows AMIs.
+• Amazon instance store-backed AMI – The root device for an instance launched from the AMI is an
+instance store volume created from a template stored in Amazon S3. Supported for Linux AMIs
+only. Windows AMIs do not support instance store for the root device.
+For more information, see Root volumes for your Amazon EC2 instances.
+Note
+Instance store-backed AMIs are considered end of life and are not recommended for new
+usage. They are only supported on the following older instance types: C1, C3, D2, I2, M1,
+M2, M3, R3, and X1.
+
+The following table summarizes the important differences when using the two types of AMIs.
+Characteristic
+
+Amazon EBS-backed AMI
+
+Amazon instance store-backed
+AMI
+
+Root device volume
+
+EBS volume
+
+Instance store volume
+
+Boot time for an
+instance
+
+Usually less than 1 minute
+
+Usually less than 5 minutes
+
+By default, the root volume
+is deleted when the instance
+terminates.* Data on any other
+EBS volumes persists after
+instance termination by default.
+
+Data on any instance store
+volumes persists only during the
+life of the instance.
+
+Can be in a stopped state. Even
+when the instance is stopped and
+not running, the root volume is
+persisted in Amazon EBS.
+
+Cannot be in a stopped state;
+instances are running or
+terminated.
+
+Data persistence
+
+Stopped state
+
+Root device type
+
+22
+
+Amazon Elastic Compute Cloud
+
+Characteristic
+
+Modifications
+
+Charges
+
+AMI creation/bundling
+
+User Guide
+
+Amazon EBS-backed AMI
+
+Amazon instance store-backed
+AMI
+
+The instance type, kernel, RAM
+disk, and user data can be
+changed while the instance is
+stopped.
+
+Instance attributes are fixed for
+the life of an instance.
+
+You're charged for instance
+usage, EBS volume usage, and
+storing your AMI as an EBS snaps
+hot.
+
+You're charged for instance usage
+and storing your AMI in Amazon
+S3.
+
+Uses a single command/call
+
+Requires installation and use of
+AMI tools
+
+* By default, EBS root volumes have the DeleteOnTermination flag set to true. For information
+about how to change this flag so that the volume persists after termination, see Keep an Amazon
+EBS root volume after an Amazon EC2 instance terminates.
+** Supported with io2 EBS Block Express only. For more information, see Provisioned IOPS SSD
+Block Express volumes in the Amazon EBS User Guide.
+
+Determine the root device type of your AMI
+The AMI that you use to launch an EC2 instance determines the type of the root volume. The root
+volume of an EC2 instance is either an EBS volume or an instance store volume.
+Nitro-based instances support only EBS root volumes. The following previous generation instance
+types are the only instance types that support instance store root volumes: C1, C3, D2, I2, M1, M2,
+M3, R3, and X1.
+Console
+To determine the root device type of an AMI
+1.
+
+Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
+
+Determine the AMI root device type
+
+23
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Amazon EC2 instances
+An Amazon EC2 instance is a virtual server in the AWS cloud environment. You have full control
+over your instance, from the time that you first start it (referred to as launching an instance) until
+you delete it (referred to as terminating an instance). You can choose from a variety of operating
+systems when you launch your instance. You can connect to your instance and customize it to meet
+your needs. For example, you can configure the operating system, install operating system updates,
+and install applications on your instance.
+Amazon EC2 provides a wide range of instance types. You can choose an instance type that
+provides the compute resources, memory, storage, and network performance that you need to run
+your applications.
+With Amazon EC2, you pay only for what you use. Billing for your instance starts when you launch
+your instance and it transitions to the running state. Billing stops when you stop your instance and
+resumes when you start your instance. When you terminate your instance, billing stops when it
+transitions to the shutting down state.
+Amazon EC2 provides features that you can use to optimize the performance and the cost of
+your instances. For example, you can use Amazon EC2 Fleet or Amazon EC2 Auto Scaling to scale
+your capacity up or down as your instance utilization changes. You can reduce the costs for your
+instances using Spot Instances or Savings Plans.
+A managed instance is managed by a service provider, such as Amazon EKS Auto Mode. You can’t
+directly modify the settings of a managed instance. Managed instances are identified by a true
+value in the Managed field. For more information, see Amazon EC2 managed instances.
+Features and tasks
+• Amazon EC2 instance types
+• Amazon EC2 managed instances
+• Amazon EC2 billing and purchasing options
+• Store instance launch parameters in Amazon EC2 launch templates
+• Launch an Amazon EC2 instance
+• Connect to your EC2 instance
+• Amazon EC2 instance state changes
+267
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+• Automatic instance recovery
+• Use instance metadata to manage your EC2 instance
+• Detect whether a host is an EC2 instance
+• Instance identity documents for Amazon EC2 instances
+• Precision clock and time synchronization on your EC2 instance
+• Manage device drivers for your EC2 instance
+• Configure your Amazon EC2 Windows instance
+• Upgrade an EC2 Windows instance to a newer version of Windows Server
+• Tutorial: Connect an Amazon EC2 instance to an Amazon RDS database
+
+Amazon EC2 instance types
+When you launch an instance, the instance type that you specify determines the hardware of the
+host computer used for your instance. Each instance type offers different compute, memory, and
+storage capabilities, and is grouped in an instance family based on these capabilities. Select an
+instance type based on the requirements of the application or software that you plan to run on
+your instance. For more information about features and use cases, see Amazon EC2 Instance Types.
+Amazon EC2 dedicates some resources of the host computer, such as CPU, memory, and instance
+storage, to a particular instance. Amazon EC2 shares other resources of the host computer, such as
+the network and the disk subsystem, among instances. If each instance on a host computer tries
+to use as much of one of these shared resources as possible, each receives an equal share of that
+resource. However, when a resource is underused, an instance can consume a higher share of that
+resource while it's available.
+Each instance type provides higher or lower minimum performance from a shared resource. For
+example, instance types with high I/O performance have a larger allocation of shared resources.
+Allocating a larger share of shared resources also reduces the variance of I/O performance. For
+most applications, moderate I/O performance is more than enough. However, for applications that
+require greater or more consistent I/O performance, consider an instance type with higher I/O
+performance.
+Contents
+• Available instance types
+• Hardware specifications
+Instance types
+
+268
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+• Hypervisor type
+• AMI virtualization types
+• Processors
+• Find an Amazon EC2 instance type
+• Get recommendations from EC2 instance type finder
+• Get EC2 instance recommendations from Compute Optimizer
+• Amazon EC2 instance type changes
+• Burstable performance instances
+• Performance acceleration with GPU instances
+• Amazon EC2 Mac instances
+• Amazon EBS-optimized instance types
+• CPU options for Amazon EC2 instances
+• AMD SEV-SNP for Amazon EC2 instances
+• Processor state control for Amazon EC2 Linux instances
+
+Available instance types
+Amazon EC2 provides a wide selection of instance types optimized to fit different use cases.
+Instance types comprise varying combinations of CPU, memory, storage, and networking capacity
+and give you the flexibility to choose the appropriate mix of resources for your applications. Each
+instance type includes one or more instance sizes, allowing you to scale your resources to the
+requirements of your target workload.
+Instance type naming conventions
+Names are based on instance family, generation, processor family, capabilities, and size. For more
+information, see Naming conventions in the Amazon EC2 Instance Types Guide.
+Find an instance type
+To determine which instance types meet your requirements, such as supported Regions, compute
+resources, or storage resources, see Find an Amazon EC2 instance type and Amazon EC2 instance
+type specifications in the Amazon EC2 Instance Types Guide.
+Available instance types
+
+269
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+• Launch a container instance using an Inf1 or Inf2 instance and an Amazon ECS-optimized AMI.
+For more information, see Amazon Linux 2 (Inferentia) AMIs in the Amazon Elastic Container
+Service Developer Guide.
+• Create an Amazon EKS cluster with nodes running Inf1 instances. For more information, see
+Inferentia support in the Amazon EKS User Guide.
+
+Find an Amazon EC2 instance type
+Before you can launch an instance, you must select an instance type to use. The instance type
+that you choose might depend on the resources that your workload requires, such as compute,
+memory, or storage resources. It can be beneficial to identify several instance types that might suit
+your workload and evaluate their performance in a test environment. There is no substitute for
+measuring the performance of your application under load.
+You can get suggestions and guidance for EC2 instance types using the EC2 instance type finder.
+For more information, see the section called “EC2 instance type finder”.
+If you already have running EC2 instances, you can use AWS Compute Optimizer to get
+recommendations about the instance types that you should use to improve performance,
+save money, or both. For more information, see the section called “Compute Optimizer
+recommendations”.
+Tasks
+• Find an instance type using the console
+• Describe an instance type using the AWS CLI
+• Find an instance type using the AWS CLI
+• Find an instance type using the Tools for PowerShell
+
+Find an instance type using the console
+You can find an instance type that meets your needs using the Amazon EC2 console.
+To find an instance type using the console
+1.
+
+Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
+
+2.
+
+From the navigation bar, select the Region in which to launch your instances. You can select
+any Region that's available to you, regardless of your location.
+
+Find an instance type
+
+274
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+3.
+
+In the navigation pane, choose Instance Types.
+
+4.
+
+(Optional) Choose the preferences (gear) icon to select which instance type attributes to
+display, such as On-Demand Linux pricing, and then choose Confirm. Alternatively, select the
+name of an instance type to open its details page and view all attributes available through
+the console. The console does not display all the attributes available through the API or the
+command line.
+
+5.
+
+Use the instance type attributes to filter the list of displayed instance types to only the
+instance types that meet your needs. For example, you can filter on the following attributes:
+• Availability zones – The name of the Availability Zone, Local Zone, or Wavelength Zone. For
+more information, see the section called “Regions and Zones”.
+• vCPUs or Cores – The number of vCPUs or cores.
+• Memory (GiB) – The memory size, in GiB.
+• Network performance – The network performance, in Gigabits.
+• Local instance storage – Indicates whether the instance type has local instance storage
+(true | false).
+
+6.
+
+(Optional) To see a side-by-side comparison, select the checkbox for multiple instance types.
+The comparison is displayed at the bottom of the screen.
+
+7.
+
+(Optional) To save the list of instance types to a comma-separated values (.csv) file for further
+review, choose Actions, Download list CSV. The file includes all instance types that match the
+filters you set.
+
+8.
+
+(Optional) To launch instances using an instance type that meet your needs, select the
+checkbox for the instance type and choose Actions, Launch instance. For more information,
+see Launch an EC2 instance using the launch instance wizard in the console.
+
+Describe an instance type using the AWS CLI
+You can use the describe-instance-types command to describe a specific instance type.
+To fully describe an instance type
+The following command displays all available details for the specified instance type. The output is
+lengthy, so it is omitted here.
+aws ec2 describe-instance-types \
+--instance-types t2.micro \
+Find an instance type
+
+275
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+EC2 Fleet and Spot Fleet
+EC2 Fleet and Spot Fleet are designed to be a useful way to launch a fleet of tens, hundreds,
+or thousands of Amazon EC2 instances in a single operation. Each instance in a fleet is either
+configured by a launch template or a set of launch parameters that you configure manually at
+launch.
+Topics
+• Features and benefits
+• Which is the best fleet method to use?
+• Configuration options for your EC2 Fleet or Spot Fleet
+• Work with EC2 Fleet
+• Work with Spot Fleet
+• Monitor your EC2 Fleet or Spot Fleet
+• Tutorials for EC2 Fleet
+• Example CLI configurations for EC2 Fleet
+• Example CLI configurations Spot Fleet
+• Quotas for EC2 Fleet and Spot Fleet
+
+Features and benefits
+Fleets provide the following features and benefits, enabling you to maximize cost savings and
+optimize availability and performance when running applications on multiple EC2 instances.
+Multiple instance types
+A fleet can launch multiple instance types, ensuring it isn't dependent on the availability of any
+single instance type. This increases the overall availability of instances in your fleet.
+Distributing instances across Availability Zones
+A fleet automatically attempts to distribute instances evenly across multiple Availability Zones
+for high availability. This provides resiliency in case an Availability Zone becomes unavailable.
+
+Features and benefits
+
+1933
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Multiple purchasing options
+A fleet can launch multiple purchase options (Spot and On-Demand Instances), allowing you to
+optimize costs through Spot Instance usage. You can also take advantage of Reserved Instance
+and Savings Plans discounts by using them in conjunction with On-Demand Instances in the
+fleet.
+Automated replacement of Spot Instances
+If your fleet includes Spot Instances, it can automatically request replacement Spot capacity if
+your Spot Instances are interrupted. Through Capacity Rebalancing, a fleet can also monitor and
+proactively replace your Spot Instances that are at an elevated risk of interruption.
+Reserve On-Demand capacity
+A fleet can use an On-Demand Capacity Reservation to reserve On-Demand capacity. A fleet can
+also include Capacity Blocks for ML, allowing you to reserve GPU instances on a future date to
+support short duration machine learning (ML) workloads.
+
+Which is the best fleet method to use?
+As a general best practice, we recommend launching fleets of Spot and On-Demand Instances with
+Amazon EC2 Auto Scaling because it provides additional features you can use to manage your fleet.
+The list of additional features includes automatic health check replacements for both Spot and OnDemand Instances, application-based health checks, and an integration with Elastic Load Balancing
+to ensure an even distribution of application traffic to your healthy instances. You can also use
+Auto Scaling groups when you use AWS services such as Amazon ECS, Amazon EKS (self-managed
+node groups), and Amazon VPC Lattice. For more information, see the Amazon EC2 Auto Scaling
+User Guide.
+If you can't use Amazon EC2 Auto Scaling, then you might consider using EC2 Fleet or Spot Fleet.
+EC2 Fleet and Spot Fleet offer the same core functionality. However, EC2 Fleet is only available
+using a command line and does not provide console support. Spot Fleet provides console support,
+but is based on a legacy API with no planned investment.
+Use the following table to determine which fleet method to use.
+
+Which fleet method to use?
+
+1934
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Fleet method
+
+When to use?
+
+Use case
+
+Amazon EC2 Auto Scaling
+
+• You need multiple
+instances with either a
+single configuration or a
+mixed configuration.
+
+Create an Auto Scaling group
+that manages the lifecycle of
+your instances while maintaini
+ng the desired number of
+instances. Supports horizontal
+scaling (adding more instances
+) between specified minimum
+
+• You want to automate the
+lifecycle management of
+your instances.
+EC2 Fleet
+
+• You need multiple
+instances with either a
+single configuration or a
+mixed configuration.
+• You want to self-manage
+your instance lifecycle.
+• If you don’t need auto
+scaling, we recommend
+that you use an instant
+type EC2 Fleet.
+
+and maximum limits.
+Create an instant fleet of
+both On-Demand Instances
+and Spot Instances in a single
+operation, with multiple
+launch specifications that
+vary by instance type, AMI,
+Availability Zone, or subnet.
+The Spot Instance allocation
+strategy defaults to lowestprice per unit, but we
+recommend changing it to
+price-capacity-opt
+imized .
+
+Spot Fleet
+
+• We strongly discourage
+using Spot Fleet because
+it is based on a legacy API
+with no planned investmen
+t.
+
+Use Spot Fleet only if you
+need console support for a
+use case for when you would
+use EC2 Fleet.
+
+• If you want to manage
+your instance lifecycle,
+rather use EC2 Fleet.
+• If you don't want to
+manage your instance
+
+Which fleet method to use?
+
+1935
+
+Amazon Elastic Compute Cloud
+
+Fleet method
+
+User Guide
+
+When to use?
+
+Use case
+
+lifecycle, rather use an
+Auto Scaling group.
+
+Configuration options for your EC2 Fleet or Spot Fleet
+When planning your EC2 Fleet or Spot Fleet, we recommend that you consider the following
+options when deciding how to configure your fleet.
+
+Configura
+tion
+option
+
+Question
+
+Documentation
+
+Fleet
+request
+type
+
+Do you want a fleet that submits a one-time
+request for the desired target capacity, or a fleet
+that maintains target capacity over time?
+
+EC2 Fleet and Spot Fleet
+request types
+
+Spot
+Instances
+
+Do you plan to include Spot Instances in your
+fleet? Review the Spot best practices and use
+them when you plan your fleet so that you can
+provision the instances at the lowest possible
+price.
+
+Best practices for Amazon
+EC2 Spot
+
+Spending
+limit for
+your fleet
+
+Do you want to limit how much you'll pay for
+your fleet per hour?
+
+Set a spending limit for your
+EC2 Fleet or Spot Fleet
+
+Instance
+types and
+attribute
+-based
+instance
+type
+selection
+
+Do you want to specify the instance types in
+your fleet, or let Amazon EC2 select the instance
+types that meet your application requirements?
+
+Specify attributes for instance
+type selection for EC2 Fleet
+or Spot Fleet
+
+Configuration options
+
+1936
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Configura
+tion
+option
+
+Question
+
+Documentation
+
+Instance
+weighting
+
+Do you want to assign weights to each instance
+type to represent their compute capacity and
+performance, so that Amazon EC2 can select any
+combination of available instance types to fulfil
+your desired target capacity?
+
+Use instance weighting to
+manage cost and performanc
+e of your EC2 Fleet or Spot
+Fleet
+
+Allocation
+strategies
+
+Do you want to decide whether to optimize for
+available capacity, price, or instance types to use
+for the Spot Instances and On-Demand Instances
+in your fleet?
+
+Use allocation strategies to
+determine how EC2 Fleet or
+Spot Fleet fulfills Spot and
+On-Demand capacity
+
+Capacity
+Rebalanci
+ng
+
+Do you want your fleet to automatically replace
+at-risk Spot Instances?
+
+Use Capacity Rebalancing in
+EC2 Fleet and Spot Fleet to
+replace at-risk Spot Instances
+
+OnDemand
+Capacity
+Reservati
+on
+
+Do you want to reserve capacity for the OnDemand Instances in your fleet?
+
+Use Capacity Reservations to
+reserve On-Demand capacity
+in EC2 Fleet
+
+EC2 Fleet and Spot Fleet request types
+The request type for an EC2 Fleet or Spot Fleet determines whether the request is synchronous or
+asynchronous, and whether it is a one-time request for the desired target capacity or an ongoing
+effort to maintain the capacity over time. When configuring your fleet, you must specify the
+request type.
+Both EC2 Fleet and Spot Fleet offer two request types: request and maintain. In addition, EC2
+Fleet offers a third request type called instant.
+
+Request types
+
+1937
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Fleet request types
+instant (EC2 Fleet only)
+If you configure the request type as instant, EC2 Fleet places a synchronous one-time request
+for your desired capacity. In the API response, it returns the instances that launched and
+provides errors for those instances that could not be launched. For more information, see
+Configure an EC2 Fleet of type instant.
+request
+If you configure the request type as request, the fleet places an asynchronous one-time
+request for your desired capacity. If capacity diminishes due to Spot interruptions, the fleet does
+not attempt to replenish Spot Instances, nor does it submit requests in alternative Spot capacity
+pools if capacity is unavailable. When creating a Spot Fleet of type request using the console,
+clear the Maintain target capacity checkbox.
+maintain (default)
+If you configure the request type as maintain, the fleet places an asynchronous request for
+your desired capacity, and maintains it by automatically replenishing any interrupted Spot
+Instances. When creating a Spot Fleet of type maintain using the console, select the Maintain
+target capacity checkbox
+
+Configure an EC2 Fleet of type instant
+The EC2 Fleet of type instant is a synchronous one-time request that makes only one attempt to
+launch your desired capacity. The API response lists the instances that launched, along with errors
+for those instances that could not be launched. There are several benefits to using an EC2 Fleet of
+type instant, which are described in this article. Example configurations are provided at the end of
+the article.
+For workloads that need a launch-only API to launch EC2 instances, you can use the RunInstances
+API. However, with RunInstances, you can only launch On-Demand Instances or Spot Instances, but
+not both in the same request. Furthermore, when you use RunInstances to launch Spot Instances,
+your Spot Instance request is limited to one instance type and one Availability Zone. This targets
+a single Spot capacity pool (a set of unused instances with the same instance type and Availability
+Zone). If the Spot capacity pool does not have sufficient Spot Instance capacity for your request,
+the RunInstances call fails.
+Request types
+
+1938
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Instead of using RunInstances to launch Spot Instances, we recommend that you rather use the
+CreateFleet API with the type parameter set to instant for the following benefits:
+• Launch On-Demand Instances and Spot Instances in one request. An EC2 Fleet can launch OnDemand Instances, Spot Instances, or both. The request for Spot Instances is fulfilled if there is
+available capacity and the maximum price per hour for your request exceeds the Spot price.
+• Increase the availability of Spot Instances. By using an EC2 Fleet of type instant, you can
+launch Spot Instances following Spot best practices with the resulting benefits:
+• Spot best practice: Be flexible about instance types and Availability Zones.
+Benefit: By specifying several instance types and Availability Zones, you increase the number
+of Spot capacity pools. This gives the Spot service a better chance of finding and allocating
+your desired Spot compute capacity. A good rule of thumb is to be flexible across at least 10
+instance types for each workload and make sure that all Availability Zones are configured for
+use in your VPC.
+• Spot best practice: Use the price-capacity-optimized allocation strategy.
+Benefit: The price-capacity-optimized allocation strategy identifies instances from the
+most-available Spot capacity pools, and then automatically provisions instances from the
+lowest priced of these pools. Because your Spot Instance capacity is sourced from pools with
+optimal capacity, this decreases the possibility that your Spot Instances will be interrupted
+when Amazon EC2 needs the capacity back.
+• Get access to a wider set of capabilities. For workloads that need a launch-only API, and where
+you prefer to manage the lifecycle of your instance rather than let EC2 Fleet manage it for
+you, use the EC2 Fleet of type instant instead of the RunInstances API. EC2 Fleet provides
+a wider set of capabilities than RunInstances, as demonstrated in the following examples.
+For all other workloads, you should use Amazon EC2 Auto Scaling because it supplies a more
+comprehensive feature set for a wide variety of workloads, like ELB-backed applications,
+containerized workloads, and queue processing jobs.
+You can use EC2 Fleet of type instant to launch instances into Capacity Blocks. For more
+information, see Tutorial: Configure your EC2 Fleet to launch instances into Capacity Blocks.
+AWS services like Amazon EC2 Auto Scaling and Amazon EMR use EC2 Fleet of type instant to
+launch EC2 instances.
+
+Request types
+
+1939
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Prerequisites for EC2 Fleet of type instant
+For the prerequisites for creating an EC2 Fleet, see EC2 Fleet prerequisites.
+How instant EC2 Fleet works
+When working with an EC2 Fleet of type instant, the sequence of events is as follows:
+1. Configure: Configure the CreateFleet request type as instant. For more information, see
+Create an EC2 Fleet. Note that after you make the API call, you can't modify it.
+2. Request: When you make the API call, Amazon EC2 places a synchronous one-time request for
+your desired capacity.
+3. Response: The API response lists the instances that launched, along with errors for those
+instances that could not be launched.
+4. Describe: You can describe your EC2 Fleet, list the instances associated with your EC2 Fleet, and
+view the history of your EC2 Fleet.
+5. Terminate instances: You can terminate the instances at any time.
+6. Delete fleet request: The fleet request can be deleted either manually or automatically:
+• Manual: You can delete the fleet request after your instances launch.
+Note that a deleted instant fleet with running instances is not supported. When you delete
+an instant fleet, Amazon EC2 automatically terminates all its instances. For fleets with
+more than 1000 instances, the deletion request might fail. If your fleet has more than 1000
+instances, first terminate most of the instances manually, leaving 1000 or fewer. Then delete
+the fleet, and the remaining instances will be terminated automatically.
+• Automatic: Amazon EC2 deletes the fleet request some time after either:
+• All the instances are terminated.
+• The fleet fails to launch any instances.
+Examples
+The following examples show how to use EC2 Fleet of type instant for different use cases. For
+more information about using the EC2 CreateFleet API parameters, see CreateFleet in the Amazon
+EC2 API Reference.
+Examples
+• Example 1: Launch Spot Instances with the capacity-optimized allocation strategy
+Request types
+
+1940
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+Networking in Amazon EC2
+Amazon VPC enables you to launch AWS resources, such as Amazon EC2 instances, into a virtual
+network dedicated to your AWS account, known as a virtual private cloud (VPC). When you launch
+an instance, you can select a subnet from the VPC. The instance is configured with a primary
+network interface, which is a logical virtual network card. The instance receives a primary private IP
+address from the IPv4 address of the subnet, and it is assigned to the primary network interface.
+You can control whether the instance receives a public IP address from Amazon's pool of public
+IP addresses. The public IP address of an instance is associated with your instance only until it is
+stopped or terminated. If you require a persistent public IP address, you can allocate an Elastic IP
+address for your AWS account and associate it with an instance or a network interface. An Elastic IP
+address remains associated with your AWS account until you release it, and you can move it from
+one instance to another as needed. You can bring your own IP address range to your AWS account,
+where it appears as an address pool, and then allocate Elastic IP addresses from your address pool.
+To increase network performance and reduce latency, you can launch instances in a placement
+group. You can get significantly higher packet per second (PPS) performance using enhanced
+networking. You can accelerate high performance computing and machine learning applications
+using an Elastic Fabric Adapter (EFA), which is a network device that you can attach to a supported
+instance type.
+Features
+• Regions and Zones
+• Amazon EC2 instance IP addressing
+• EC2 instance hostnames and domains
+• Bring your own IP addresses (BYOIP) to Amazon EC2
+• Elastic IP addresses
+• Elastic network interfaces
+• Amazon EC2 instance network bandwidth
+• Enhanced networking on Amazon EC2 instances
+• Elastic Fabric Adapter for AI/ML and HPC workloads on Amazon EC2
+• Amazon EC2 instance topology
+• Placement groups for your Amazon EC2 instances
+2176
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+• Network maximum transmission unit (MTU) for your EC2 instance
+• Virtual private clouds for your EC2 instances
+
+Regions and Zones
+Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of AWS
+Regions, Availability Zones, Local Zones, AWS Outposts, and Wavelength Zones.
+• Regions are separate geographic areas.
+• Availability Zones are multiple, isolated locations within each Region.
+• Local Zones provide you with the ability to place resources, such as compute and storage, in
+multiple locations closer to your end users.
+• Wavelength Zones provide you with the ability to build applications that deliver ultra-low
+latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage
+services to the edge of telecommunication carriers' 5G networks.
+• AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any
+data center, colocation space, or on-premises facility.
+AWS operates state-of-the-art, highly available data centers. Although rare, failures can occur that
+affect the availability of instances that are in the same location. If you host all of your instances in a
+single location that is affected by a failure, none of your instances would be available.
+For more information, see AWS Global Infrastructure.
+Contents
+• Regions
+• Availability Zones
+• Local Zones
+• Wavelength Zones
+• AWS Outposts
+
+Regions
+Each Region is designed to be isolated from the other Regions. This achieves the greatest possible
+fault tolerance and stability.
+Regions and Zones
+
+2177
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+When you launch an instance, select a Region that puts your instances close to specific customers,
+or that meets the legal or other requirements that you have. You can launch instances in multiple
+Regions.
+When you view your resources, you see only the resources that are tied to the Region that you
+specified. This is because Regions are isolated from each other, and we don't automatically
+replicate resources across Regions.
+
+Available Regions
+For the list of available Regions, see AWS Regions.
+
+Regional endpoints for Amazon EC2
+When you work with an instance using the command line interface or API actions, you must specify
+its Regional endpoint. For more information about the Regions and endpoints for Amazon EC2, see
+Amazon EC2 service endpoints in the Amazon EC2 Developer Guide.
+For more information, see AWS Regions in the AWS Regions and Availability Zones User Guide.
+
+Availability Zones
+Each Region has multiple, isolated locations known as Availability Zones. The code for an
+Availability Zone is its Region code followed by a letter identifier. For example, us-east-1a.
+By launching EC2 instances in multiple Availability Zones, you can protect your applications from
+the failure of a single location in the Region.
+The following diagram illustrates multiple Availability Zones in an AWS Region. Availability Zone A
+and Availability Zone B each have one subnet, and each subnet has EC2 instances. Availability Zone
+C has no subnets, therefore you can't launch instances into this Availability Zone.
+
+Availability Zones
+
+2178
+
+Amazon Elastic Compute Cloud
+
+User Guide
+
+For more information, see Virtual private clouds for your EC2 instances.
+
+Availability Zones by Region
+For the list of Availability Zones by Region, see AWS Availability Zones.
+
+Instances in Availability Zones
+When you launch an instance, you select a Region and a virtual private cloud (VPC). Then, you
+can either select a subnet from one of the Availability Zones or let us choose a subnet for you.
+When you launch your initial instances, we recommend that you let us select an Availability Zone
+for you based on system health and available capacity. If you launch additional instances, specify
+an Availability Zone only if your new instances must be close to, or separated from, your existing
+instances.
+If you distribute instances across multiple Availability Zones and an instance fails, you can design
+your application so that an instance in another Availability Zone handles requests instead.
+For more information, see AWS Availability Zones in the AWS Regions and Availability Zones User
+Guide.
+Availability Zones
+
+2179
+
 

dataset/docs/ecs-dg.txt

@@ -1,851 +0,0 @@
-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 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 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 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. 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 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 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
-
-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
-
-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 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 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 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, 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. 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 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 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 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 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
-
-

dataset/docs/eks-ug.txt

@@ -1,1221 +0,0 @@
-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 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. 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 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
-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 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 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 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 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 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 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 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 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 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 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 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 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 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 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) 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 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, 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
-
-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 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 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 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 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 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:
-• 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 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 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 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 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 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 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 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
-
-

dataset/docs/fargate.txt

@@ -1,432 +0,0 @@
-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 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 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.
-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 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 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 - 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 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 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 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 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 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 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. 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 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
-
-

dataset/docs/lambda-dg.txt

@@ -1,755 +0,0 @@
-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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: 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. 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 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 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 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
-
-

dataset/docs/wavelength.txt

@@ -175,688 +175,101 @@ VPCs
 
 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 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 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
-
-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 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
+Architect apps for Wavelength
+Wavelength Zones are designed for the following workloads:
+• Applications that require edge resiliency across existing AWS hybrid and edge infrastructure
+deployments
+• Applications that need to connect to compute with low latency
+• Applications that need to run in a certain geography due to legal or regulatory requirements
+• Applications that need consistent data rates from mobile devices to compute in a 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 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.
-
-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 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 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
+Review Quotas and considerations, which includes information about available Wavelength Zones,
+service differences, and Service Quotas.
+Consider the following factors when using Wavelength Zones:
+• AWS recommends that you architect the edge applications in a hub and spoke model with the
+Region to provide the most scalable, resilient, and cost-effective options for components. For
+more information, see the section called “Workload placement”
+• Services that run in Wavelength Zones have different compliance than services in an AWS Region.
+For more information, see the section called “Compliance validation”.
+Most Wavelength Zones have network access that is specific to a telecommunication carrier and
+location. Therefore, you might need to have multiple Wavelength Zones for your latency-sensitive
+applications to meet your latency requirements. For more information, see the section called
+“Networking considerations”.
+
+Discover the closest Wavelength Zone endpoint
+You can use the following procedures to have client devices discover the closest Wavelength Zone
+endpoint, for example an Amazon EC2 instance:
+• Register the instance with a discovery service such as AWS Cloud Map. For information about
+how to register an instance, see Registering Instances in the AWS Cloud Map Developer Guide.
+• Another approach is to use multiple Wavelength Zones across your deployment and utilize
+adjacent Zones, powered by carrier-developed edge discovery services to route mobile traffic.
+Discover the closest Wavelength Zone endpoint
+
+27
 
 AWS Wavelength
 
 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
+For more information, see Deploying dynamic 5G Edge Discovery architectures with 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 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 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
+• Applications that run on client devices can run latency tests such as ping from the client to
+select the best endpoint that is registered in AWS Cloud Map, or can use the geolocation data
+from the mobile device.
+
+Load balancing
+Application Load Balancer (ALB) is supported in select Wavelength Zones. Load balancers distribute
+your incoming traffic across multiple targets, such as Amazon EC2 instances, containers, and IP
+addresses, within the Wavelength Zone. Key considerations include:
+• Network Load Balancer (NLB) is not supported in Wavelength Zones. To learn more, see Enabling
+load-balancing of non-HTTP(s) traffic on AWS Wavelength.
+• Cross-Zone load balancing across multiple Wavelength Zones is not supported.
+ALB is available in the following Wavelength Zones:
+• All Wavelength Zones in the us-east-1 Region.
+• All Wavelength Zones in us-west-2 Region.
+• All Wavelength Zones in the ap-northeast-1 Region.
+• All Wavelength Zones in the eu-central-1 Region.
+
+High availability
+Follow these strategies to deploy highly available architectures at the edge.
+
+Deployment
+Consider the following:
+• Multiple Wavelength Zones within a given VPC: using techniques highlighted in the Discover
+the closest Wavelength Zone endpoint section, you can steer traffic to the optimal Wavelength
+Zone based on latency or application health.
+• Combine Wavelength Zones with other AWS hybrid and edge locations: you can combine
+AWS Local Zones subnets with AWS Wavelength Zones subnets to create highly-available
+Load balancing
+
+28
 
 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 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
+deployments within a given geography. For example, you can create an Atlanta AWS Local Zone
+subnet (us-east-1-atl-2a) alongside an Atlanta Wavelength Zone subnet (us-east-1-wl1atl-wlz-1) within the same VPC.
+
+DNS resolution
+One way to create both physical and logical redundancy across your high-availability edge
+deployments is to utilize the parent Region as the failover, using simple Route 53-based failover
+policies to steer traffic to an available endpoint. For more information, see Configuring DNS
+failover in the Amazon Route 53 Developer Guide.
+
+Workload placement
+Run the following components in the Region:
+• Components that are less latency sensitive
+• Components that do not require data residency
+• Components that need to be shared across Zones
+• Components that need to persist state, such as databases
+Run the application components that need low latency and higher bandwidth over mobile
+networks in Wavelength Zones.
+For optimal throughput, AWS recommends that you use a public service endpoint when
+applications in the Wavelength Zone need to connect to AWS services in the parent Region.
+
+DNS resolution
+
+29
 
 

src/inference/demo_encode.py

@@ -0,0 +1,20 @@
+import torch
+from sentence_transformers import SentenceTransformer
+from src.utils.config import CFG
+
+def main():
+    device = "cuda" if torch.cuda.is_available() else "cpu"
+    model = SentenceTransformer(CFG.output_dir, device=device, truncate_dim=256)
+
+    sentences = [
+        
+    ]
+
+    emb = model.encode(sentences)
+    print("Embeddings shape:", emb.shape)
+
+    sims = model.similarity(emb, emb)
+    print("Similarity row[0]:", sims[0])
+
+if __name__ == "__main__":
+    main()

src/processing/prepare.py

@@ -0,0 +1,27 @@
+from datasets import load_dataset
+from src.utils.paths import TRAIN_JSON, TEST_JSON
+from src.utils.seed import set_seed
+
+REMOVE_COLS = ["chunk_id", "doc_id", "question_id", "answer_span"]
+
+def main():
+    set_seed(42)
+
+    ds = load_dataset("CadenShokat/aws-rag-qa-positives", split="train")
+
+    ds = ds.rename_column("question", "anchor")
+    ds = ds.rename_column("chunk", "positive")
+    ds = ds.remove_columns(REMOVE_COLS)
+
+    ds = ds.add_column("id", list(range(len(ds))))
+
+    ds = ds.shuffle(seed=42)
+    split = ds.train_test_split(test_size=0.1, seed=42)
+
+    split["train"].to_json(str(TRAIN_JSON), orient="records")
+    split["test"].to_json(str(TEST_JSON), orient="records")
+
+    print(f"Wrote:\n- {TRAIN_JSON}\n- {TEST_JSON}")
+
+if __name__ == "__main__":
+    main()

src/training/train.py

@@ -10,27 +10,6 @@ from src.utils.config import CFG
 from src.utils.paths import TRAIN_JSON, TEST_JSON
 from src.eval.ir_eval import build_eval
 
-def _precision_and_optim():
-    """Pick safe precision/optimizer for the current device."""
-    use_cuda = torch.cuda.is_available()
-    use_mps  = getattr(torch.backends, "mps", None) and torch.backends.mps.is_available()
-
-    cfg = dict(fp16=False, bf16=False, tf32=False, optim="adamw_torch")
-
-    if use_cuda:
-        # TF32 + fused adamw only on NVIDIA GPUs
-        cfg["tf32"] = True
-        try:
-            cfg["bf16"] = torch.cuda.is_bf16_supported()
-        except Exception:
-            cfg["bf16"] = False
-        maj, _ = torch.cuda.get_device_capability()
-        cfg["optim"] = "adamw_torch_fused" if maj >= 8 else "adamw_torch"
-
-    # MPS/CPU: stick to fp32; fused/TF32/bf16 unsupported in HF trainer
-    return cfg, use_cuda
-
-
 def main():
     device = "cuda" if torch.cuda.is_available() else ("mps" if getattr(torch.backends, "mps", None) and torch.backends.mps.is_available() else "cpu")
 
@@ -54,12 +33,6 @@ def main():
     base_loss = MultipleNegativesRankingLoss(model)
     train_loss = MatryoshkaLoss(model, base_loss, matryoshka_dims=list(CFG.matryoshka_dims))
 
-    prec_optim, on_cuda = _precision_and_optim()
-    # Smaller batches on CPU/MPS
-    train_bs = 32 if on_cuda else 8
-    eval_bs  = 16 if on_cuda else 8
-    grad_acc = 16 if on_cuda else 4   # keeps global batch reasonable
-
     args = SentenceTransformerTrainingArguments(
         output_dir=CFG.output_dir,
         num_train_epochs=4,
@@ -69,9 +42,9 @@ def main():
         warmup_ratio=0.1,
         learning_rate=2e-5,
         lr_scheduler_type="cosine",
-        optim=prec_optim["optim"],
-        tf32=prec_optim["optim"],
-        bf16=["bf16"],
+        optim="adamw_torch_fused",
+        tf32=True,
+        bf16=True,
         batch_sampler=BatchSamplers.NO_DUPLICATES,
         eval_strategy="epoch",
         save_strategy="epoch",