# Architect for Amazon ECS Managed Instances Amazon ECS Managed Instances Amazon ECS Managed Instances is a fully managed compute option for Amazon ECS that enables you to run containerized workloads on the full range of Amazon EC2 instance types while offloading infrastructure management to AWS. With Amazon ECS Managed Instances, you can access specific compute capabilities such as GPU acceleration, particular CPU architectures, high network performance, and specialized instance types, while AWS handles provisioning, scaling, patching, and maintenance of the underlying infrastructure. When you use Amazon ECS Managed Instances, you package your application in containers and specify your compute requirements. AWS automatically selects the most cost-optimized general-purpose Amazon EC2 instance types that meet your workload needs, or you can specify desired instance attributes including instance types, CPU manufacturers, and accelerators. Amazon ECS Managed Instances completely manage all aspects of infrastructure including, scaling, patching, and cost optimization - without trading off access to AWS capabilities and Amazon EC2 integrations. Amazon ECS Managed Instances support Linux containers with platform-specific optimizations and security configurations. By default, Amazon ECS Managed Instances optimizes infrastructure utilization by placing multiple smaller tasks on larger instances, helping to reduce costs and improve task launch times. This topic describes the different components of Amazon ECS Managed Instances tasks and services, and calls out special considerations for using Amazon ECS Managed Instances with Amazon ECS. ## Getting started To get started with Amazon ECS Managed Instances, you create the required IAM roles and enable Amazon ECS Managed Instances in your AWS account. Then you can create a capacity provider and launch tasks or services using the Amazon ECS Managed Instances capacity provider. For detailed instructions on getting started, see: + [Learn how to create a task for Amazon ECS Managed Instances](getting-started-managed-instances.md) + [Learn how to create a task for Amazon ECS Managed Instances with the AWS CLI](getting-started-managed-instances-cli.md) ## Capacity providers Amazon ECS Managed Instances uses capacity providers to manage compute capacity for your workloads. When you create a capacity provider, you can use default instance selection or specify custom instance requirements using `instanceRequirements`. The following capacity provider options are available: + **Default capacity provider** - Automatically selects the most cost-optimized general-purpose instance types for your workload requirements. + **Custom capacity providers** - Allow you to specify instance attributes using attribute-based instance type selection, including vCPU count, memory, CPU manufacturers, accelerator types, and specific instance types. A capacity provider strategy can only contain one capacity provider type from the following list: + Amazon ECS Managed Instances + Auto Scaling group + Fargate/Fargate\$1SPOT ## Instance selection and optimization Amazon ECS chooses instance types for your Amazon ECS Managed Instances workloads using one of the following methods: + **Automatic selection** - When using the default capacity provider, Amazon ECS automatically selects the most cost-optimized general-purpose instance types that meet the CPU and memory requirements specified in your task definition. + **Attribute-based selection** - When using custom capacity providers, you can specify instance attributes such as vCPU count, memory size, CPU manufacturers, accelerator types, and specific instance types. Amazon ECS selects from all instance types that match your specified attributes. Amazon ECS Managed Instances optimizes infrastructure utilization and cost through several mechanisms: + Multi-task placement - By default, Amazon ECS places multiple smaller tasks on larger instances to maximize utilization and reduce costs. + Active workload consolidation - Amazon ECS identifies when container instances are truly idle while trying to avoid premature termination that could impact application availability or deployment performance. The system respects the minimum and maximum number of tasks set for a service, the start before stop behavior, and the task protection behavior. + Right-sizing - As workload requirements change, Amazon ECS launches replacement instances that are appropriately sized for current needs. Amazon ECS uses Amazon EC2 event windows to schedule maintenance activities during your preferred time periods. Event windows allow you to define recurring time periods when AWS can perform maintenance on your instances, helping you minimize disruption to your workloads by aligning maintenance with your operational schedule. For more information, see [Scheduled events for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) in the *Amazon EC2 User Guide*. If you require strong isolation, you can configure Amazon ECS Managed Instances to run each task on a separate instance with VM-level security isolation boundaries. ## Task definitions Tasks that use Amazon ECS Managed Instances support most Amazon ECS task definition parameters. Amazon ECS Managed Instances is compatible with existing Fargate task definitions using platform version 1.4.0, making migration straightforward. To use Amazon ECS Managed Instances, set the `requiresCompatibilities` task definition parameter to include `MANAGED_INSTANCES`. Your task definitions can specify both Fargate and Amazon ECS Managed Instances compatibility for flexibility in deployment options. ## Operating system and CPU architecture The following operating systems are supported: + Bottlerocket There are 2 architectures available for the Amazon ECS task definition, ARM and X86\$164. When you run Linux containers on Amazon ECS Managed Instances, you can use the X86\$164 CPU architecture, or the ARM64 architecture for your ARM-based applications. ## Key features The following are key features of Amazon ECS Managed Instances: + Select specific EC2 instance types to meet your application's requirements, enabling access to specialized hardware capabilities such as GPU-accelerated compute, specific CPU capabilities, and large memory sizes. + Optimize resource utilization and cost with multiple tasks on a single instance by default, unlike Fargate which runs each task in its own isolated environment. + Ensure security compliance and regular instance patching. ECS Managed Instances initiates instance draining after 14 days and automatically replaces service-based tasks to new instances. + Enable advanced networking and system administration functions within containers using privileged Linux capabilities, including CAP\$1NET\$1ADMIN, CAP\$1SYS\$1ADMIN, and CAP\$1BPF. ## IAM roles Amazon ECS Managed Instances requires two IAM roles: + *Infrastructure Role*: This role allows AWS to manage the Amazon ECS Managed Instances on your behalf. + *Instance profile*: An instance profile is a way to pass an IAM role to Amazon ECS Managed Instances. This profile is used to: + Define the IAM permissions for the Amazon ECS Managed Instances that run your container workloads. + Allow AWS to manage these instances on your behalf. + Enable the instances to access AWS services according to the permissions defined in the profile. ## Security and compliance Amazon ECS Managed Instances implements multiple layers of security to protect your workloads: + **Secure configuration** - Amazon ECS Managed Instances follow AWS security best practices including no SSH access, immutable root filesystem, and kernel-level mandatory access controls via SELinux. + **Automatic patching** - AWS regularly updates Amazon ECS Managed Instances with the latest security patches, respecting maintenance windows that you configure. + **Limited instance lifetime** - ECS automatically initiates instance draining after 14 days, ensuring your applications run on appropriately configured instances with up-to-date security patches. + **Privileged capabilities** - You can optionally enable privileged Linux capabilities for workloads that require them, such as network monitoring and observability solutions. Amazon ECS Managed Instances support the same compliance programs as Amazon ECS, including PCI-DSS, HIPAA, and FedRAMP. In supported regions, you can configure FIPS endpoints at the capacity provider level to help achieve FedRAMP compliance. ## Networking Amazon ECS Managed Instances support the `awsvpc` and `host` network modes. The `awsvpc` network mode provides each task with its own elastic network interface and private IP address within your VPC. This enables fine-grained security group and network ACL controls at the task level. In the `host` network mode, tasks share the host Amazon ECS Managed Instance's network namespace. For more information about task networking on Amazon ECS Managed Instances, see [Amazon ECS task networking for Amazon ECS Managed Instances](managed-instance-networking.md). ## Instance storage Amazon ECS Managed Instances supports configuring the size of the Amazon EBS data volume that's attached to the instance. This storage is shared between all tasks that run on the instance and can be used for bind mounds. The volume can be shared and mounted among containers that use the `volumes`, `mountPoint`, and `volumesFrom` parameters in the task definition. The volume is attached during instance creation. You can specify the size of the volume, in GiB, when you create a Amazon ECS Managed Instances capacity provider by using the `storageConfiguration` parameter. ``` { ... "managedInstancesProvider": { "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole", "instanceLaunchTemplate": { "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile", "networkConfiguration": { "subnets": [ "subnet-abcdef01234567", "subnet-bcdefa98765432" ], "securityGroups": [ "sg-0123456789abcdef" ] }, "storageConfiguration": { "storageSizeinGiB" : 100 } } } ... } ``` The minimum size of this volume is 30 GiB and the maximum size is 16,384 GiB. By default, the size of this volume is 80 GiB. The pulled, compressed, and the uncompressed container image for the task is stored in the volume. To determine the total amount of instance storage your task has to use as bind mount, you must subtract the amount of storage your container image uses from the total amount of instance storage your task is allocated. The performance of Amazon EBS volumes attached to Amazon ECS Managed Instances matches the performance of corresponding Amazon EC2 instances, as outlined in the [Amazon EBS-optimized instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) documentation in the *Amazon EC2 User Guide*. You can create snapshots of the volume to perform a forensic analysis of security issues or to debug your application. For more information about creating snapshots of Amazon EBS volumes, see [Amazon EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) in the *Amazon EBS User Guide*. If you have Amazon EBS encryption by default enabled, the volume will be encrypted with the AWS KMS key specified for encryption by default. For more information about encryption by default, see [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) in the *Amazon EBS User Guide*. In addition to using the data volume attached to the instance, you can also configure data volumes for each task that runs on Amazon ECS Managed Instances. For more information about available task-level storage options, see [Storage options for Amazon ECS tasks](using_data_volumes.md). ## Local Storage [Amazon EC2 instance store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) provides temporary block-level storage for your Amazon EC2 instances. The storage provided by Amazon EC2 instance store is accessible through disks that are physically attached to the hosts. You can configure Amazon ECS Managed Instances to use instance store as a data volume for tasks running on the container instance. When you enable local storage and the instance has instance store volumes, Amazon ECS uses the instance store volumes instead of provisioning an Amazon EBS data volume. This can reduce storage costs and improve I/O performance for latency-sensitive workloads. There is no additional charge for using instance store volumes with Amazon ECS Managed Instances. When an instance has multiple instance store volumes, Amazon ECS automatically combines them into a single RAID 0 volume and presents it as contiguous storage for tasks. When an instance doesn't have instance store volumes, or when local storage is disabled, Amazon ECS provisions an Amazon EBS data volume with the size specified in `storageSizeGiB`. Instance store volumes are ephemeral. Data on instance store volumes is lost when the instance is stopped, terminated, or when hardware fails. Do not use instance store for data that must persist. To enable local storage, [create a new capacity provider](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-capacity-provider-managed-instances.html) with the `localStorageConfiguration` parameter and set `useLocalStorage` to `true`. You can also use the `instanceRequirements` parameter to ensure that provisioned instances include local storage of a specific size. **Note** When you create a cluster using the AWS Management Console, the default managed instances capacity provider that Amazon ECS creates doesn't include `localStorageConfiguration`. The following example shows a capacity provider configuration with local storage enabled and instance requirements that specify SSD-based instance store with a minimum of 50 GiB. ``` { ... "managedInstancesProvider": { "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole", "instanceLaunchTemplate": { "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile", "networkConfiguration": { "subnets": [ "subnet-abcdef01234567", "subnet-bcdefa98765432" ], "securityGroups": [ "sg-0123456789abcdef" ] }, "storageConfiguration": { "storageSizeGiB": 50 }, "localStorageConfiguration": { "useLocalStorage": true }, "instanceRequirements": { "vCpuCount": { "min": 0 }, "memoryMiB": { "min": 0 }, "localStorage": "REQUIRED", "totalLocalStorageGB": { "min": 50 }, "localStorageTypes": ["ssd"] } } } } ``` When you omit the `instanceRequirements` configuration, Amazon ECS defaults `localStorage` to `INCLUDED`. In this case, Amazon ECS considers instances both with and without instance store volumes for provisioning. Instances with instance store volumes use an instance store for data volume, while instances without instance store volumes use an Amazon EBS data volume. When `totalLocalStorageGB` is not specified, Amazon ECS uses all available instance storage, with no minimum size enforced. The `storageSizeGiB` value in `storageConfiguration` defines only the Amazon EBS data volume size and is used when instance storage is unavailable. The `totalLocalStorageGB` value in `instanceRequirements` controls the minimum instance storage size required on provisioned instances. To guarantee that all instances use local storage, set `localStorage` to `REQUIRED` and specify a minimum size by using `totalLocalStorageGB`. To verify whether a specific provisioned container instance is using local storage, check for the `ecs.capability.storage.local-storage-enabled` attribute on the container instance. ## Service load balancing Your Amazon ECS services using Amazon ECS Managed Instances can be configured to use Elastic Load Balancing to distribute traffic evenly across the tasks in your service. Amazon ECS services on Amazon ECS Managed Instances support Application Load Balancer, Network Load Balancer, and Gateway Load Balancer load balancer types. Application Load Balancers route HTTP/HTTPS (layer 7) traffic, while Network Load Balancers route TCP or UDP (layer 4) traffic. When you create a target group for these services, you must choose `ip` as the target type, not `instance`. This is because tasks using the `awsvpc` network mode are associated with an elastic network interface, not directly with an Amazon EC2 instance. ## Monitoring and observability Amazon ECS Managed Instances provides comprehensive monitoring capabilities through CloudWatch metrics and integration with observability tools: + **CloudWatch metrics** - Monitor CPU, memory, network, and storage utilization at both the task and instance level. + **Container Insights** - Get detailed performance metrics and logs for your containerized applications. + **Third-party integrations** - With privileged capabilities enabled, you can run advanced monitoring and observability solutions that require elevated Linux permissions. ## Pricing and cost optimization With Amazon ECS Managed Instances, you are billed for the entire Amazon EC2 instance that runs your tasks. The pricing depends on the instance types selected for your workloads. Amazon ECS Managed Instances provides several cost optimization features: + **Multi-task optimization** - Maximize instance utilization by running multiple tasks on appropriately sized instances. Your Compute and Instance Savings Plans also apply to Amazon ECS Managed Instances workloads. ## Service quotas Amazon ECS Managed Instances workloads are subject to your Amazon EC2 On-Demand instance service quotas. Your Amazon ECS services using Amazon ECS Managed Instances are subject to Amazon ECS service quotas. For more information about service quotas, see: + [Amazon EC2 endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ec2-service.html) in the *Amazon Web Services General Reference* + [Amazon ECS service quotas](service-quotas.md) ## Migration considerations Migrating to Amazon ECS Managed Instances is straightforward for most workloads: + **From Fargate** - Requires only a capacity provider configuration change and redeployment. Existing task definitions using platform version 1.4.0 are fully compatible. + **From EC2** - Similar to migrating to Fargate, but you retain access to Amazon EC2 capabilities such as specific instance types. Consider the following when planning your migration: + Applications should tolerate the 14-day instance lifetime and planned maintenance windows. + Long-running tasks (exceeding 14 days) are not suitable for Amazon ECS Managed Instances. + Custom AMIs are not supported - Amazon ECS Managed Instances use AWS-managed, security-optimized AMIs. ## Limitations and considerations The following limitations apply to Amazon ECS Managed Instances: + Custom AMIs - The AMI is owned and managed by AWS + Instance lifetime - Maximum runtime of 14 days per instance to ensure security patching and compliance. + SSH access - Not available for security reasons. Use Amazon ECS Exec for debugging and troubleshooting. Management operations through Amazon ECS APIs only. ## Organization controls Some organization controls can prevent Amazon ECS Managed Instances from functioning correctly. If so, you must update these controls to allow Amazon ECS to have the permissions required to manage EC2 instances on your behalf. Amazon ECS uses an infrastructure role for launching the EC2 instances that back Amazon ECS Managed Instances. This infrastructure role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) which is created in your account that allows Amazon ECS to manage the Amazon ECS Managed Instances on your behalf. [Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) always apply to actions performed with infrastructure roles. This allows an SCP to inhibit Amazon ECS Managed Instances operations. The most common occurrence is when an SCP is used to restrict the Amazon Machine Images (AMIs) that can be launched. To allow Amazon ECS Managed Instances to function, modify the SCP to permit launching AMIs from Amazon ECS Managed Instances AMI accounts. You can also use the [EC2 Allowed AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) feature to limit the visibility of AMIs in other accounts. If you use this feature, you must expand the image criteria to also include the Amazon ECS Managed Instances AMI accounts in the regions of interest. ### Example SCP to block all AMIs except for Amazon ECS Managed Instances AMIs The SCP below prevents calling `ec2:RunInstances` unless the AMI belongs to the Amazon ECS Managed Instances AMI account for us-west-2 or us-east-1. **Note** It's important **not** to use the `ec2:Owner` context key. Amazon owns the Amazon ECS Managed Instances AMI accounts and the value for this key will always be `amazon`. Constructing an SCP that allows launching AMIs if the `ec2:Owner` is `amazon` will allow launching any Amazon owned AMI, not just those for Amazon ECS Managed Instances. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAMI", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:*:ec2:*::image/ami-*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "187296253231", "260073348889" ] } } } ] } ``` ### Amazon ECS Managed Instances AMI accounts AWS accounts that vary by region host Amazon ECS Managed Instances public AMIs. | AWS Region | Account | | --- | --- | | af-south-1 | 070957084703 | | ap-east-1 | 587573215167 | | ap-northeast-1 | 679336465495 | | ap-northeast-2 | 309903600357 | | ap-northeast-3 | 384570461223 | | ap-south-1 | 062344138989 | | ap-south-2 | 624198668379 | | ap-southeast-1 | 832199679391 | | ap-southeast-2 | 552073033681 | | ap-southeast-3 | 368903466070 | | ap-southeast-4 | 696793786439 | | ap-southeast-5 | 003457290689 | | ap-southeast-6 | 465836752572 | | ap-southeast-7 | 622515864387 | | ca-central-1 | 853167153192 | | ca-west-1 | 899469777611 | | eu-central-1 | 832570432258 | | eu-central-2 | 041659148495 | | eu-north-1 | 851563870067 | | eu-south-1 | 766433696616 | | eu-south-2 | 003380494496 | | eu-west-1 | 986619735082 | | eu-west-2 | 591706807364 | | eu-west-3 | 108582616801 | | il-central-1 | 009537862704 | | me-central-1 | 540883425316 | | me-south-1 | 181438624895 | | mx-central-1 | 210749644920 | | sa-east-1 | 591338347621 | | us-east-1 | 260073348889 | | us-east-2 | 292185169523 | | us-west-1 | 187296253231 | | us-west-2 | 491085424538 | # Amazon ECS Managed Instances instance types Amazon ECS Managed Instances allows you to select specific EC2 instance types for your containerized applications. ## Amazon ECS Managed Instances Instance Families The following instance types are supported: ### General Purpose + m5, m5a, m5ad, m5d, m5dn, m5n, m5zn: Balanced compute, memory, and networking + m6a, m6g, m6gd, m6i, m6id, m6idn, m6in: Latest generation with improved performance + m7a, m7g, m7gd, m7i, m7i-flex: Next generation general purpose instances + m8g, m8gd: Latest generation ARM general purpose instances + t3, t3a, t4g: Burstable performance instances (excluding nano and micro instance sizes) ### Compute Optimized + c5, c5a, c5ad, c5d, c5n: High-performance processors for compute-intensive applications + c6a, c6g, c6gd, c6i, c6id, c6in: Latest generation compute-optimized instances + c7a, c7g, c7gd, c7gn, c7i, c7i-flex: Next generation compute optimized instances + c8g, c8gd, c8gn: Latest generation ARM compute optimized instances + hpc6a, hpc6id, hpc7a: High performance computing instances ### Memory Optimized + r5, r5a, r5ad, r5b, r5d, r5dn, r5n: High memory-to-vCPU ratio for memory-intensive applications + r6a, r6g, r6gd, r6i, r6id, r6idn, r6in: Latest generation memory-optimized instances + r7a, r7g, r7gd, r7i, r7iz: Next generation memory optimized instances + r8g, r8gd: Latest generation ARM memory optimized instances + u-3tb1, u7i-6tb, u7i-8tb, u7i-12tb, u7in-24tb, u7in-32tb: High memory instances with up to 32 TB RAM + x2gd, x2idn, x2iedn, x2iezn: Extreme memory for in-memory databases and analytics + x8g: Latest generation extreme memory instances + z1d: High frequency and NVMe SSD storage ### Storage Optimized + d3, d3en: Dense HDD storage for distributed file systems + i4g, i4i: Latest generation storage optimized instances + i7i, i7ie, i8g: Next generation high-performance storage instances + im4gn, is4gen: Network optimized storage instances ### Accelerated Computing + g4dn: NVIDIA T4 GPUs for machine learning inference and graphics + g5, g5g: NVIDIA A10G GPUs for high-performance graphics and ML + g6, g6e, g6f: Latest generation GPU instances + gr6, gr6f: GPU instances with NVIDIA L4 Tensor Core GPUs and 1:8 vCPU:RAM ratio for graphics workloads + p3dn: NVIDIA V100 GPUs for deep learning training and HPC + p4d: NVIDIA A100 GPUs for highest performance ML training + p5: Latest generation with NVIDIA H100 GPUs + p6-b200: Next generation with NVIDIA B200 GPUs ## Instance selection methods Amazon ECS Managed Instances provides two methods for selecting instance types: + *Specific instance type selection*: You explicitly specify the EC2 instance type to use for your tasks. + *Attribute-based instance type selection*: You specify the attributes (such as vCPU, memory, and architecture) that your application requires, and Amazon ECS Managed Instances selects an appropriate instance type. ## Specific instance type selection With specific instance type selection, you explicitly specify the EC2 instance type to use for your Amazon ECS Managed Instances tasks. This is useful when your application requires a specific instance type with particular hardware characteristics. ## Attribute-based instance type selection With attribute-based instance type selection, you specify the attributes that your application requires, and Amazon ECS Managed Instances selects an appropriate instance type that meets those requirements. This provides more flexibility and can help ensure that your tasks are placed successfully even if specific instance types are not available. When you specify multiple attributes, you get instance types that satisfy all of the specified attributes. If you specify multiple values for an attribute, you get instance types that satisfy any of the specified values. The following attributes are supported for attribute-based instance type selection: **cpuArchitecture** The CPU architecture. Valid values: `X86_64` \$1 `ARM64` **instanceGeneration** Indicates whether current or previous generation instance types are included. + For current generation instance types, specify `current`. The current generation includes EC2 instance types currently recommended for use. This typically includes the latest two to three generations in each instance family. For more information, see [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) in the *Amazon EC2 User Guide*. + For previous generation instance types, specify `previous`. + To include both current and previous generation instance types, specify `all`. Valid values: `current` \$1 `previous` \$1 `all` Default: Any current or previous generation. **burstablePerformance** Indicates whether burstable performance instance types are included, excluded, or required. For more information, see [Burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) in the *Amazon EC2 User Guide*. Valid values: `included` \$1 `excluded` \$1 `required` Default: `excluded` **cpuManufacturer** Lists which specific CPU manufacturers to include. + For instance types with Intel CPUs, specify `intel`. + For instance types with AMD CPUs, specify `amd`. + For instance types with AWS CPUs (such as AWS Graviton), specify `amazon-web-services`. Don't confuse the CPU hardware manufacturer with the CPU hardware architecture. Instances will be launched with a compatible CPU architecture based on the Amazon Machine Image (AMI) that you specify. Valid values: `intel` \$1 `amd` \$1 `amazon-web-services` Default: Any manufacturer. **networkBandwidth** The minimum and maximum amount of network bandwidth, in gigabits per second (Gbps). Default: No minimum or maximum limits. **networkInterfaceCount** The minimum and maximum number of network interfaces. Default: No minimum or maximum limits. **localStorage** Indicates whether instance types with instance store volumes are included, excluded, or required. For more information, see [Amazon EC2 instance store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) in the *Amazon EC2 User Guide*. Valid values: `included` \$1 `excluded` \$1 `required` Default: `included` **localStorageType** Indicates the type of local storage that is required. + For instance types with hard disk drive (HDD) storage, specify `hdd`. + For instance types with solid state drive (SSD) storage, specify `ssd`. Valid values: `hdd` \$1 `ssd` Default: Any local storage type. ## Billing and purchase options Amazon ECS Managed Instances supports several features to help optimize the cost of your containerized workloads: + *Savings Plans (SPs)*: Amazon ECS Managed Instances benefit from Savings Plans that you've purchased for the instance types used by your tasks. No additional configuration is required. + *Reserved Instances (RIs)*: Amazon ECS Managed Instances tasks can benefit from RIs that you've purchased for the instance types used by your tasks. No additional configuration is required. + *Spot Instances*: You can configure Amazon ECS Managed Instances capacity provider to use EC2 Spot instances by setting `capacityOptionType=Spot` + *Capacity Reservations*: You can configure Amazon ECS Managed Instances capacity provider to use your EC2 Capacity Reservations by setting `capacityOptionType=Reserved` and providing a [capacity reservation group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-cr-group.html). You can also specify following reservation preferences: use `reservations-only` to ensure instances launch exclusively in reserved capacity for maximum predictability, `reservations-first` to prefer reservations while maintaining flexibility to fall back to on-demand capacity when needed, or `reservations-excluded` to prevent your capacity provider from using reservations altogether. # Instance selection best practices for Amazon ECS Managed Instances Selecting the right instance configuration for your Amazon ECS Managed Instances workloads is crucial for optimizing performance, cost, and resource utilization. Amazon ECS provides flexible instance selection options that allow you to balance your application requirements with cost efficiency. The following best practices help you make informed decisions about instance selection for your containerized workloads. 1. Use default instance selection When you don't specify `instanceRequirements`, Amazon ECS chooses the most cost-effective instances that meet the following task definition and service parameter requirements: Task definition + operatingSystemFamily + cpuArchitecture + cpu + memory Service definition + placementConstraints + placementStrategy 1. Use attribute-based selection for most workloads to provide flexibility and improve placement success rates Attribute-based instance selection allows Amazon ECS to choose from a broader range of instance types that meet your specified requirements. This approach increases the likelihood of successful task placement and provides better cost optimization by allowing Amazon ECS to select the most cost-effective instances available at launch time. 1. Use specific instance types only when applications have specific hardware requirements Reserve specific instance type selection for workloads that require particular hardware features, such as GPU acceleration, high-frequency processors, or specialized networking capabilities. For general-purpose applications, attribute-based selection typically provides better flexibility and cost optimization. 1. Choose balanced resources to avoid over-provisioning and unnecessary costs Select instance configurations that closely match your application's CPU and memory requirements. Avoid significantly over-provisioning resources, as this leads to higher costs and reduced efficiency. Use monitoring data to understand your actual resource utilization patterns and adjust instance selection accordingly. 1. Mix instance types for applications with varying workloads to balance performance and cost For applications with diverse performance requirements or varying workload patterns, consider using multiple capacity providers with different instance configurations. This approach allows you to optimize costs by using appropriate instance types for different components of your application while maintaining performance where needed. 1. When using an Amazon ECS Managed Instances capacity provider configured with `capacityOptionType=Reserved`, be aware that ECS services use a default deployment configuration of `minimumHealthyPercent=100%` and `maximumPercent=200%`, meaning ECS deployments attempt to start new tasks before stopping old ones and temporarily require up to 200% of your steady-state capacity. If your service consumes all available capacity in your EC2 Capacity Reservations at steady state, deployments will fail because there is no additional capacity available to launch new tasks during the deployment process. To avoid this, set `minimumHealthyPercent` to less than 100% (e.g., 75%) and consider setting `maximumPercent` to 100% to ensure the service stops tasks before starting new ones, allowing deployments to complete successfully by freeing capacity before launching replacement tasks. Additionally, consider monitoring your capacity utilization regularly to maintain headroom in your reservations to accommodate deployments and handle traffic spikes. # Amazon ECS Managed Instances container image pull behavior Amazon ECS Managed Instances pull behavior The time that it takes a container to start up varies, based on the underlying container image. For example, a fatter image (full versions of Debian, Ubuntu, and Amazon2) might take longer to start up because there are a more services that run in the containers compared to their respective slim versions (Debian-slim, Ubuntu-slim, and Amazon-slim) or smaller base images (Alpine). When Amazon ECS starts a task that runs on Amazon ECS Managed Instances, Amazon ECS pulls the image remotely only if it wasn't pulled by a previous task on the same container instance or if the cached image was removed by the automated image cleanup process. Otherwise, the cached image on the Amazon ECS Managed Instance is used. This ensures that no unnecessary image pulls are attempted. # Patching in Amazon ECS Managed Instances Patching in Amazon ECS Managed Instances In Amazon ECS Managed Instances, patching is a critical maintenance process where AWS automatically manages and updates software on managed container instances to ensure security and compliance while maintaining workload availability through a controlled, configurable process. ## Instance lifecycle By default, Amazon ECS managed container instances operate on a standardized 14–21 day lifecycle. Amazon ECS initiates graceful workload draining at day 14 from instance launch, with final termination occurring no later than day 21. Amazon ECS accommodates early draining under specific circumstances: + Detection of security vulnerabilities on the software + Hardware health degradation + To honor customer-configured event windows This approach maintains system compliance while respecting customer-defined maintenance requirements. ## Event windows and maintenance scheduling AWS manages a managed container instance lifecycle through automated background processes that monitor a node's creation timestamp and maintenance schedules. Upon instance launch, AWS sets a default 14-day draining schedule and evaluates any customer-configured event windows. You can schedule maintenance activities for Amazon ECS Managed Instances by configuring event windows. You can associate one or more Amazon ECS Managed Instances with an event window by using either instance IDs or instance tags. When an event window is tagged with a specific value, Amazon ECS maps these tags to the corresponding Amazon ECS Managed Instances of the corresponding clusters and schedules instance maintenance during the defined time periods on a best effort basis. For more information about event windows see [Create custom event windows for scheduled events that affect your Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) in the *Amazon EC2 User Guide*. If event windows exist, AWS adjusts the draining schedule to align with these windows, which may result in earlier draining than the default 14-day period to honor the specified event window. Event window modifications only affect newly launched managed container instances, ensuring predictable maintenance scheduling. Until the scheduled draining time, Amazon ECS continues normal task placement operations on the managed container instances as per the customer's configuration. ## Maintenance sequence At the designated maintenance time, Amazon ECS begins its maintenance sequence by invoking the `UpdateContainerInstancesState` API to initiate graceful workload draining. During the graceful termination period, Amazon ECS attempts to stop the workload on the instance marked for draining. Amazon ECS employs a start-before-stop strategy for service tasks (or as per the Amazon ECS service configuration), ensuring replacement tasks are launched before stopping existing ones, minimizing service disruption. Throughout this process, Amazon ECS services honor all service deployment configurations while continuing draining attempts until day 21 from the instance launch. If draining has not completed by day 21, Amazon ECS executes the `DeregisterContainerInstance` API to stop the managed container instance and its remaining workloads to maintain compliance and patch the managed instance with the latest software. # Security considerations for Amazon ECS Managed Instances Amazon ECS Managed Instances provides a fully managed container compute experience that enables you to run workloads on specific Amazon EC2 instance types while offloading security responsibilities to AWS. This topic describes the security model, features, and considerations when using Amazon ECS Managed Instances. ## Security model Amazon ECS Managed Instances implements a comprehensive security model that balances flexibility with protection: + **AWS-managed infrastructure** - AWS controls the lifecycle of managed instances and handles security patching, eliminating the possibility of human error and tampering. + **No administrative access** - The security model is locked down and prohibits administrative access to managed instances. + **Multi-task placement** - By default, Amazon ECS Managed Instances places multiple tasks on a single instance to optimize cost and utilization, which relaxes the workload-isolation constraint compared to Fargate. + **Data isolation** - Although AWS controls instance lifecycle and task placement, AWS cannot login to managed instances or access customer data. ## Security features Amazon ECS Managed Instances includes several built-in security features designed to protect your workloads and maintain a strong security posture. These features range from automated security patching to support for privileged Linux capabilities when needed. ### Security best practices Managed instances are configured according to AWS security best practices, including: + **No SSH access** - Remote shell access is disabled to prevent unauthorized access. + **Immutable root filesystem** - The root filesystem cannot be modified, ensuring system integrity. + **Kernel-level mandatory access controls** - SELinux provides additional security enforcement at the kernel level. ### Automatic security patching Amazon ECS Managed Instances helps improve the security posture of your workloads through automated patching: + **Regular security updates** - Instances are regularly updated with the latest security patches by AWS, with respect to the maintenance windows that you configure. + **Limited instance lifetime** - The maximum lifetime of a running instance is limited to 14 days to ensure applications run on appropriately configured instances with up-to-date security patches. + **Maintenance window control** - You can use Amazon EC2 event windows capability to specify when Amazon ECS should replace your instances with patched ones. ### Privileged Linux capabilities Amazon ECS Managed Instances supports software that requires elevated Linux privileges, enabling advanced monitoring and security solutions: + **Supported capabilities** - You can opt-in to all privileged Linux capabilities, including `CAP_NET_ADMIN`, `CAP_SYS_ADMIN`, and `CAP_BPF`. + **Popular solutions** - This enables you to run popular network monitoring and observability solutions such as Wireshark and Datadog. + **Explicit configuration required** - You must explicitly configure your Amazon ECS Managed Instances capacity provider to enable privileged Linux capabilities, as it may pose additional security risks to your applications. **Important** Enabling privileged Linux capabilities may expose your tasks to additional security risks. Only enable these capabilities when required by your applications and ensure you understand the security implications. ## Compliance and regulatory support Amazon ECS Managed Instances maintains the same compliance posture as Amazon ECS: + **Compliance programs** - Amazon ECS Managed Instances is in scope of the same AWS Assurance Programs as Amazon ECS, including PCI-DSS, HIPAA, and FedRAMP. + **FIPS endpoints** - Amazon ECS Managed Instances supports FIPS endpoint configuration at the capacity provider level. Unlike Fargate, which uses an account-level setting, Amazon ECS Managed Instances uses a per-capacity-provider setting because FIPS is a per-instance configuration. You configure FIPS when creating or updating a capacity provider. + **Customer Managed Keys** - It supports security features required for achieving compliance, such as Customer Managed Keys for encryption. ## Amazon ECS Managed Instances FIPS-140 Considerations Consider the following when using FIPS-140 compliance on Amazon ECS Managed Instances: + FIPS-140-compliant Managed Instances AMIs are available in the AWS GovCloud (US) Regions only. + Amazon ECS Managed Instances supports FIPS-140-3 + FIPS-140 compliance is enabled by default in the AWS GovCloud (US) Regions. If you need to run workloads without FIPS compliance, turn off FIPS compliance in the Managed Instances Capacity Provider configuration. + The `cpuArchitecture` for your tasks must be `X86_64` for FIPS-140 compliance. ## Disable FIPS on Amazon ECS Managed Instances By default, Amazon ECS Managed Instances Capacity Providers in AWS GovCloud (US) Regions launch FIPS-compliant AMIs. You choose to disable FIPS-140 compliance when creating a new Amazon ECS Managed Instances Capacity Provider. Follow these steps to create a new Capacity Provider without FIPS compliance. 1. Disable FIPS-140 compliance on Capacity Provider. ``` aws ecs create-capacity-provider \ --cluster cluster-name \ --name capacity-provider-name \ --managed-instances-provider '{ "infrastructureRoleArn": "infrastructure-role-arn", "instanceLaunchTemplate": { "ec2InstanceProfileArn": "instance-profile-arn", "fipsEnabled": false, "networkConfiguration": { "subnets": ["subnet-id"], "securityGroups": ["security-group-id"] } } }' ``` 1. You can optionally use ECS Exec to run the following command to verify the FIPS-140 compliance status for a capacity provider. Replace *cluster-name* with the name of your cluster, *task-id* with the ID or ARN of your task, and *container-name* with the name of the container in your task you want to run the command against. A return value of "1" indicates that you are using FIPS. ``` aws ecs execute-command \ --cluster cluster-name \ --task task-id \ --container container-name \ --interactive \ --command "cat /proc/sys/crypto/fips_enabled" ``` ## Security considerations When using Amazon ECS Managed Instances, there are several important security considerations to understand and plan for. These considerations help you make informed decisions about your workload architecture and security requirements. ### Multi-task security model The default multi-task placement model in Amazon ECS Managed Instances differs from Fargate's single-task isolation: + **Shared instance resources** - Multiple tasks may run on the same instance, potentially exposing a task to vulnerabilities from other tasks running on the same instance or in the same ECS cluster. + **Single-task option** - You can configure Amazon ECS Managed Instances to use single-task mode for customers requiring the default Fargate security model with VM-level security isolation boundary. + **Cost vs. security trade-off** - Multi-task mode provides cost optimization and faster task startup times, while single-task mode provides stronger isolation. ### Handling instance interruptions It's important to design your applications to tolerate interruptions when using Amazon ECS Managed Instances: + **Interruption tolerance** - Use Amazon ECS Managed Instances with applications that tolerate interruption to underlying services or tasks. + **Service-based workloads** - Use Amazon ECS services for automatic task replacement, or run workloads with controlled and limited duration not exceeding 14 days on standalone tasks. + **Graceful shutdown** - Configure task shutdown grace period to control the impact of interruptions. ### Data access and privacy Amazon ECS Managed Instances maintains strict data access controls: + **No customer data access** - Although AWS controls the lifecycle of managed instances and the placement of tasks on the instances, AWS cannot login to managed instances or access customer data. + **Metrics and logs only** - AWS captures only metrics and related logs required to provide the Amazon ECS Managed Instances capabilities. + **Locked-down security model** - The security model prohibits administrative access, eliminating the possibility of human error and tampering. ## Security best practices Follow these best practices when using Amazon ECS Managed Instances: + **Evaluate security model** - Make a conscious decision about adopting Amazon ECS Managed Instances based on your security requirements, particularly regarding the multi-task placement model. + **Use single-task mode when needed** - If your workloads require stronger isolation, configure Amazon ECS Managed Instances to use single-task mode. + **Minimize privileged capabilities** - Only enable privileged Linux capabilities when absolutely necessary and understand the associated security risks. + **Plan for interruptions** - Design applications to handle instance replacements gracefully, especially considering the 14-day maximum instance lifetime. + **Configure maintenance windows** - Use EC2 event windows to control when instance replacements occur to minimize impact on your workloads. + **Monitor and audit** - Regularly review your Amazon ECS Managed Instances configuration and monitor for any security-related events or changes. # Enabling VPC Encryption control for Amazon ECS Managed Instances Amazon ECS Managed Instances supports VPC Encryption Controls, a security and compliance feature that provides centralized control to monitor and enforce encryption in transit for all traffic flows within and across your VPCs in a region. When VPC Encryption Controls is enabled on your subnet, you can specify instance types that support encryption in transit in your Amazon ECS Managed Instances custom capacity provider, guaranteeing that Amazon ECS Managed Instances workloads run with encryption in transit. ## Prerequisites Before you begin, you need: + A VPC with encryption in transit enabled on subnets. For more information, see [VPC encryption controls documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html). + An Amazon ECS Managed Instances custom capacity provider. For more information, see [Architect for Amazon ECS Managed Instances](ManagedInstances.md). ## Identify compatible instance types Amazon EC2 instance types must meet two requirements: 1. **Support VPC encryption in transit** - Use the following AWS CLI command to list Amazon EC2 instance types that support encryption in transit: ``` aws ec2 describe-instance-types \ --filters Name=network-info.encryption-in-transit-supported,Values=true \ --query "InstanceTypes[*].[InstanceType]" \ --output text | sort ``` 1. **Supported by Amazon ECS Managed Instances** - All Amazon EC2 instance types supported by Amazon ECS Managed Instances are documented in [Amazon ECS Managed Instances instance types](managed-instances-instance-types.md). If you have additional requirements (such as specific CPU, memory, or architecture needs), filter the compatible instance types further based on your workload requirements. ## Create a cluster with VPC encryption support To configure Amazon ECS Managed Instances for VPC encryption in transit: 1. Create a new cluster and select **Fargate and Managed Instances** for the infrastructure. 1. Select **Use custom – advanced** to access additional configuration parameters. 1. In **Allowed Instance types**, add only the specific instance types that support VPC encryption in transit. When configured this way, Amazon ECS Managed Instances will launch only Amazon EC2 instance types that support VPC encryption in transit. ## Considerations + **Burstable performance instances** - T3, T3a, and T4g instance types do not support VPC encryption in transit and cannot be used in subnets with encryption control enabled in Enforced mode. + **Mode transitions** - You can transition your VPC subnet from Monitor mode to Enforced mode only if all running instances support VPC encryption in transit. + **Task launch failures** - In Enforced mode, tasks will fail to launch if you specify instance types that don't support encryption in transit. ## Troubleshooting Task launch failures in Enforced mode If tasks fail to launch, verify that all specified instance types support VPC encryption in transit using the AWS CLI command provided above. Cannot transition to Enforced mode Use the console or `GetVpcResourcesBlockingEncryptionEnforcement` command to identify resources that are not enforcing encryption in transit. For more information about VPC Encryption Controls, see the [VPC encryption controls documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html). # Amazon ECS Managed Instances infrastructure optimization Infrastructure optimization Amazon ECS Managed Instances automatically provisions right-sized EC2 instances based on your Capacity Provider configuration and current workload demands, ensuring your containerized applications have the appropriate compute resources from the moment they're deployed. As your application traffic patterns evolve and workload requirements change over time, Amazon ECS Managed Instances continuously monitors and optimizes your infrastructure by intelligently adjusting instance sizes to match current needs, proactively replacing instances that have drifted from optimal configurations, and dynamically balancing cost efficiency, application performance, and system reliability. This resource management system operates without any manual intervention, reducing infrastructure cost while maintaining high availability for your applications. Infrastructure optimization has the following benefits: + Cost optimization - Reduces infrastructure costs by maximizing resource utilization and eliminating idle capacity + Performance improvement - Optimizes workload placement based on resource requirements and performance characteristics + Operational simplicity - Automates complex resource management decisions without requiring manual intervention + Reliability enhancement - Maintains high availability through intelligent workload distribution and health monitoring Amazon ECS Managed Instances performs two types of infrastructure optimizations to maximize efficiency and reduce costs: ## Idle Instance Detection Identifies and removes EC2 instances that have no running tasks, eliminating unnecessary infrastructure costs from unused capacity. When an idle instance is detected, the optimization process marks the container instance as DEREGISTERING, which initiates the cleanup sequence that safely terminates the underlying EC2 instance. ## Underutilized Instance Detection Analyzes task distribution across instances to identify opportunities for better resource allocation. When tasks are running sub-optimally across multiple instances, Amazon ECS Managed Instances consolidates workloads onto fewer, more efficiently utilized instances, reducing overall costs while maintaining performance. The optimization process marks underutilized container instances as DRAINING, which triggers task replacement to move workloads to existing or new, more efficient instances. Once all tasks are safely migrated, the instance transitions to DEREGISTERING state and is cleaned up. This optimization applies to instances running service tasks and ensures safe consolidation by respecting your service's minimum and maximum task limits, honoring start-before-stop deployment behavior, and maintaining any task protection settings throughout the draining process. Instances running standalone tasks are not considered for optimization since ECS Managed instances does not replace standalone tasks. These optimizations work together to ensure your infrastructure continuously adapts to actual workload demands, automatically eliminating waste and improving resource utilization without impacting application availability. Both mechanisms use event-driven monitoring that responds to task and instance lifecycle events to identify optimization opportunities in real-time. Amazon ECS Managed Instances detects when the last task stops on a container instance, indicating a potential idle condition for cost optimization. For underutilized instances, any task stop or new instance launch triggers analysis to identify opportunities for workload consolidation and improved resource efficiency. ## ScaleInAfter Both infrastructure optimizations look for opportunities to terminate running instances to improve utilization and reduce costs. You can control the timing of these actions using the ScaleInAfter configuration in Amazon ECS Managed Instances capacity provider settings, which applies to both idle and underutilized instances. ScaleInAfter allows you to specify the delay, in seconds, between the instance becomes idle or underutilized and the moment Amazon ECS Managed Instances starts optimizing your infrastructure. You can set the delay between 0 and 3600 seconds. You can also specify -1 to disable infrastructure optimization. **Idle Instances** + ECS waits for the specified duration after the last task stops before deregistering the instance + If a new task starts during the waiting period, the instance is no longer considered idle and termination is cancelled **Underutilized Instances** + ECS waits for the specified duration after a task stop event that results in the instance becoming underutilized before draining the instance + If a new task is launched or an existing task is stopped on a particular instance during the waiting period, the timer resets from either the most recent task stop or new task creation time, and Amazon ECS Managed Instances re-evaluates for inefficiencies and takes actions if necessary after the new waiting period expires This configuration is optional. When not specified, ECS Managed Instances automatically determines optimal timing based on ECS Managed Instances default configuration. # Migrate from AWS Fargate to Amazon ECS Managed Instances Migrate from Fargate to Amazon ECS Managed Instances You can migrate existing workloads from Fargate to Amazon ECS Managed Instances. This migration allows you to access the full range of Amazon EC2 instance types, capacity reservations, and advanced capabilities while maintaining AWS-managed infrastructure. ## Migration considerations Keep the following considerations in mind when migrating from Fargate to Amazon ECS Managed Instances: Task compatibility Existing task definitions configured for Fargate are mostly compatible with Amazon ECS Managed Instances. For more information about task definition differences, see [Amazon ECS task definition differences for Amazon ECS Managed Instances](managed-instances-tasks-services.md). Security model changes Amazon ECS Managed Instances allows multiple tasks per instance by default. Consider enabling single-task mode if your workloads require stronger isolation. Instance lifecycle Amazon ECS Managed Instances have a maximum lifetime of 14 days. Plan for task replacement and use Amazon ECS services for automatic task management. Pricing changes With Amazon ECS Managed Instances, you pay for the entire instance plus a management fee, rather than per-task resources as with Fargate. Maintenance windows Configure maintenance windows using Amazon EC2 event windows to control when Amazon ECS Managed Instances are replaced for patching. ## Prerequisites Before migrating to Amazon ECS Managed Instances, ensure you have: + Existing Fargate tasks running on platform version 1.4.0 or later + You have the required IAM roles for Amazon ECS Managed Instances. This includes: + **Infrastructure role** - Allows Amazon ECS to make calls to AWS services on your behalf to manage Amazon ECS Managed Instances infrastructure. For more information, see [Amazon ECS infrastructure IAM role](infrastructure_IAM_role.md). + **Instance profile** - Provides permissions for the Amazon ECS container agent and Docker daemon running on managed instances. For more information, see [Amazon ECS Managed Instances instance profile](managed-instances-instance-profile.md). + Understanding of the security model differences between Fargate and Amazon ECS Managed Instances **Important** Amazon ECS Managed Instances uses a different security model than Fargate. By default, multiple tasks can run on the same instance, which might expose tasks to vulnerabilities from other tasks. Review your security requirements before migrating. ## Step 1: Update the cluster to use Amazon ECS Managed Instances Create a capacity provider. When you create a capacity provider with Amazon ECS Managed Instances, it becomes available only within the specified cluster. For more information, see [Creating a capacity provider for Amazon ECS Managed Instances](create-capacity-provider-managed-instances.md). ## Step 2: Update the task definition to have the Amazon ECS Managed Instances capability Update the task definition so that it has the requiresCapabilities for Amazon ECS Managed Instances. For more information, see [Updating an Amazon ECS task definition using the console](update-task-definition-console-v2.md). ## Step 3: Update the service to use the Amazon ECS Managed Instances capacity provider Update your existing Amazon ECS service to use the Amazon ECS Managed Instances capacity provider. For more information, see [Updating an Amazon ECS service to use a capacity provider](update-service-managed-instances.md). ## Step 4: Migrate standalone tasks For standalone tasks, specify the Amazon ECS Managed Instances capacity provider when running the task. For more information, see [Running an application as an Amazon ECS task](standalone-task-create.md). # Migrate from Amazon EC2 to Amazon ECS Managed Instances Migrate from EC2 to Amazon ECS Managed Instances Migrate existing workloads from Amazon EC2 to Amazon ECS Managed Instances. This migration allows you to access the full range of Amazon EC2 instance types, capacity reservations, and advanced capabilities while maintaining AWS-managed infrastructure. ## Migration considerations Keep the following considerations in mind when migrating from Amazon EC2 to Amazon ECS Managed Instances: Task compatibility Existing task definitions configured for Amazon EC2 are mostly compatible with Amazon ECS Managed Instances. For a list of task definition differences, see [Amazon ECS task definition differences for Amazon ECS Managed Instances](managed-instances-tasks-services.md). Security model changes Amazon ECS Managed Instances allows multiple tasks per instance by default. Consider enabling single-task mode if your workloads require stronger isolation. Instance lifecycle Amazon ECS Managed Instances have a maximum lifetime of 14 days. Plan for task replacement and use Amazon ECS services for automatic task management. Pricing changes With Amazon ECS Managed Instances, you pay for the entire instance plus a management fee, with AWS handling the infrastructure management overhead. Maintenance windows Configure maintenance windows using Amazon EC2 event windows to control when Amazon ECS Managed Instances are replaced for patching. ## Prerequisites Before migrating to Amazon ECS Managed Instances, ensure you have: + You have the required IAM roles for Amazon ECS Managed Instances. This includes: + **Infrastructure role** - Allows Amazon ECS to make calls to AWS services on your behalf to manage Amazon ECS Managed Instances infrastructure. For more information, see [Amazon ECS infrastructure IAM role](infrastructure_IAM_role.md). + **Instance profile** - Provides permissions for the Amazon ECS container agent and Docker daemon running on managed instances. For more information, see [Amazon ECS Managed Instances instance profile](managed-instances-instance-profile.md). + Understanding of the security model differences between Amazon EC2 and Amazon ECS Managed Instances ## Step 1: Update the cluster to use Amazon ECS Managed Instances Create a capacity provider. When you create a capacity provider with Amazon ECS Managed Instances, it becomes available only within the specified cluster. For more information, see [Creating a capacity provider for Amazon ECS Managed Instances](create-capacity-provider-managed-instances.md). ## Step 2: Update the task definition to have the Amazon ECS Managed Instances capability Update the task definition so that it has the requiresCapabilities for Amazon ECS Managed Instances. For more information, see [Updating an Amazon ECS task definition using the console](update-task-definition-console-v2.md). ## Step 3: Update the service to use the Amazon ECS Managed Instances capacity provider Update your existing Amazon ECS service to use the Amazon ECS Managed Instances capacity provider. For more information, see [Updating an Amazon ECS service to use a capacity provider](update-service-managed-instances.md). ## Step 4: Migrate standalone tasks For standalone tasks, specify the Amazon ECS Managed Instances capacity provider when running the task. For more information, see [Running an application as an Amazon ECS task](standalone-task-create.md).