    Amazon ECS Express Mode now supports AWS Graviton (ARM64) workloads 0 views Eyal Estrin unread, 6:48 AM (20 minutes ago)    to https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ecs-express-mode-arm-architecture/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html Eyal Estrin Author | Cloud Architect | AWS • Azure • GCP Insights Social: @eyalestrin Connect: https://linktr.ee/eyalestrin Blog: https://security-24-7.com Reply all Reply to author Forward

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html now supports seamless communication between services residing in different AWS accounts through integration with https://aws.amazon.com/ram/ (AWS RAM). This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service-to-service communication across environments for organizations with multi-account architectures. Amazon ECS Service Connect leverages AWS Cloud Map namespaces for storing information about ECS services and tasks. To enable seamless cross-account communication between Amazon ECS Service Connect services, you can now share the underlying AWS Cloud Map namespaces using AWS RAM with individual AWS accounts, specific Organizational Units (OUs), or your entire AWS Organization. To get started, create a resource share in AWS RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to use the same namespace to register Amazon ECS Service Connect services residing in multiple AWS accounts, simplifying service discovery and connectivity. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. Cross-account connectivity support improves operational efficiency and makes it easier to scale Amazon ECS workloads as your organization grows by reducing duplication and streamlining access to common services. This feature is available with both Fargate and EC2 launch modes now in https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ via the AWS Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the Amazon ECS Service Connect https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html now supports seamless communication between services residing in different AWS accounts through integration with https://aws.amazon.com/ram/ (AWS RAM). This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service-to-service communication across environments for organizations with multi-account architectures. Amazon ECS Service Connect leverages AWS Cloud Map namespaces for storing information about ECS services and tasks. To enable seamless cross-account communication between Amazon ECS Service Connect services, you can now share the underlying AWS Cloud Map namespaces using AWS RAM with individual AWS accounts, specific Organizational Units (OUs), or your entire AWS Organization. To get started, create a resource share in AWS RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to use the same namespace to register Amazon ECS Service Connect services residing in multiple AWS accounts, simplifying service discovery and connectivity. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. Cross-account connectivity support improves operational efficiency and makes it easier to scale Amazon ECS workloads as your organization grows by reducing duplication and streamlining access to common services. This feature is available with both Fargate and EC2 launch modes in AWS GovCloud (US-West) and AWS GovCloud (US-East) regions via the AWS Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the Amazon ECS Service Connect https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html.

This tutorial (for Mac) will guide you through deploying a Node.js application using AWS Copilot,...

Amazon ECS announces faster service auto scaling 0 views Eyal Estrin unread, 9:55 PM (14 minutes ago)    to https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/ https://aws.amazon.com/blogs/aws/amazon-ecs-introduces-new-high-resolution-metrics-for-faster-service-auto-scaling/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/target-tracking-faster-auto-scaling.html Eyal Estrin Author | Cloud Architect | AWS • Azure • GCP Insights Social: @eyalestrin Connect: https://linktr.ee/eyalestrin Blog: https://security-24-7.com Reply all Reply to author Forward

Amazon Elastic Container Service (Amazon ECS) now supports running tasks in IPv6-only subnets. With this launch, Amazon ECS tasks and services can run using only IPv6 addresses, without requiring IPv4. This enables customers to deploy containerized applications in IPv6-only environments, scale without being limited by IPv4 address availability, and meet IPv6 compliance requirements through native IPv6 support in Amazon ECS. Previously, Amazon ECS tasks always required an IPv4 address, even when launched in dual-stack subnets. This requirement could create scaling and management challenges for customers operating large fleets of containerized applications, where IPv4 address space became a bottleneck. With IPv6-only support, Amazon ECS tasks launched in IPv6-only subnets use only IPv6 addresses. This removes IPv4 as a dependency and helps organizations that must meet IPv6 adoption or regulatory mandates. The feature works across all Amazon ECS launch types and can be used with awsvpc, bridge, and host networking modes. To get started, create IPv6-only subnets in your VPC and launch Amazon ECS services or tasks in those subnets. Amazon ECS automatically detects the configuration and provisions the appropriate networking. To learn more about IPv6-only task networking and supported AWS Regions, see the Amazon ECS task networking documentation for AWS Fargate launch type and EC2 launch type. You can also read our blog post for a detailed walkthrough and migration strategies.

https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-ecs-running-firelens-as-nonroot-user/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html

YouTube video by bwer432

Amazon ECS Service Connect now supports Zone-Aware routing 0 views Eyal Estrin unread,    to https://aws.amazon.com/about-aws/whats-new/2026/07/ecs-service-connect-zone-aware/ https://aws.amazon.com/blogs/containers/announcing-zone-aware-routing-in-amazon-ecs-service-connect/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-zone-aware-routing.html Eyal Estrin Author | Cloud Architect | AWS • Azure • GCP Insights Social: @eyalestrin Connect: https://linktr.ee/eyalestrin Blog: https://security-24-7.com Reply all Reply to author Forward

Amazon Elastic Container Service (Amazon ECS) now provides real-time service deployment observability in the Amazon ECS Console for native Linear, Canary, and Blue/Green deployment strategies. With this launch, deployment monitoring and troubleshooting come together in one place in the console, so you can track deployment progress, monitor health, and diagnose failures without switching between tools. Real-time service deployment observability includes a live deployment timeline that narrates each service deployment as it happens, showing every deployment phase, service events, and task launch and termination progress, always reflecting the current state. As a deployment moves forward, you can follow the traffic shift distribution across your source and target revisions and see the current lifecycle stage at a glance, whether it is scaling up green tasks, waiting on a lifecycle hook, or sitting through bake time. Deployment health signals that you would otherwise gather from separate tools now sit alongside the timeline: circuit breaker status with live task failure and threshold tracking, deployment alarm state, container and load-balancer health checks, and lifecycle hook status. When something goes wrong, failed tasks surface right in the timeline with diagnostic context and deep links to services such as AWS CloudTrail, so you can pinpoint the root cause and act on it quickly. Regions for all Amazon ECS services using the Amazon ECS native Linear, Canary, and Blue/Green deployment types. To get started, navigate to any Amazon ECS service in the Amazon ECS Console and select the Deployments tab.

Today, AWS announces support for predictive scaling for https://aws.amazon.com/ecs/ (Amazon ECS). Predictive scaling leverages advanced machine learning algorithms to proactively scale your Amazon ECS services ahead of demand surges, reducing overprovisioning costs while improving application responsiveness and availability. Amazon ECS offers a rich set of https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.htmloptions, including target tracking and step scaling policies, that automatically adjust task counts in response to observed load, as well as scheduled scaling to manually define rules to adjust capacity for routine demand patterns. Many applications observe recurring patterns of steep demand changes, such as early morning spikes when business resumes, wherein a reactive scaling policy can be slow to respond. Predictive scaling is a new capability that harnesses advanced machine learning algorithms, pre-trained on millions of data points, to proactively scale out ECS services ahead of anticipated demand surges. You can use predictive scaling alongside your existing auto scaling policies, such as target tracking or step scaling, so that your applications scale based on both real-time and historic patterns. You can also choose a “forecast only” mode to evaluate its accuracy and suitability, before enabling it to “forecast and scale“. Predictive scaling enhances responsiveness and availability for applications with recurring demand patterns, while also reducing the operational effort of manually configuring scaling policies and the costs from overprovisioning. You can use AWS management console, SDK, CLI, CloudFormation, and CDK to configure predictive auto scaling for your ECS services. For a list of supported AWS Regions, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/predictive-auto-scaling.html. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.htmlTo learn more, visit this https://aws.amazon.com/blogs/containers/optimize-compute-resources-on-amazon-ecs-with-predictive-scaling/and https://docs.aws.amazon.com/AmazonECS/latest/developerguide/predictive-auto-scaling.html.

本動画の資料はこちらAWSSAWAWSSupportAutomationWorkflowsはAWSサポートエンジニアリングチームが作成した安全で高速なセルフサービス自動化を使用してAWS環境の一般的な問題を解決やログの収集分析などを行います本セッションではAmazonElasticContainerServiceAmazonECSで利用可能なつのSAWについて概要や利用ユースケースなどの詳細を解説します動画の対象者・AmazonECSを利用した運用を実施されている方・AmazonECSのトラブルシューティングの効率化に興味のある方スピーカー古野俊広アマゾンウェブサービスジャパン合同会社クラウドサポートエンジニア目次AWSBlackBeltOnlineセミナーとは受講対象者アジェンダAmazonECSのよくあるお問い合わせとSAWの紹介AWSSupportTroubleshootECSTaskFailedToStartAWSSupportTroubleshootECSContainerInstanceAWSSupportCollectECSInstanceLogsまとめ関連リンクAWS個別相談会AWSSAW公式ページAWSSupportTroubleshootECSTaskFailedToStartAWSSupportTroubleshootECSContainerInstanceAWSSupportCollectECSInstanceLogsAWSBlackBeltについてサービス別ソリューション別業種別のそれぞれのテーマに分けアマゾンウェブサービスジャパン合同会社が主催するオンラインセミナーシリーズですBlackBeltの他の動画はこちら過去の資料はこちら関連ハッシュタグAmazonECSAWSSAWSupportAutomationWorkflowsAWSSupportAutomationWorkflowsアマゾンウェブサービスクラウドAWSJapanAmazonWebServicesAWSBlackBeltAWS

Perform safer container application deployments without custom deployment tooling, enabling you to ship software updates more frequently with near-instantaneous rollback capability.

Amazon ECS Managed Instances is a new compute option that eliminates infrastructure management overhead while giving you access to the broad suite of EC2 capabilities including the flexibility to select...

https://aws.amazon.com/ecs/ (Amazon ECS) now provides real-time service deployment observability in the Amazon ECS Console for native Linear, Canary, and Blue/Green deployment strategies. With this launch, deployment monitoring and troubleshooting come together in one place in the console, so you can track deployment progress, monitor health, and diagnose failures without switching between tools. Real-time service deployment observability includes a live deployment timeline that narrates each service deployment as it happens, showing every deployment phase, service events, and task launch and termination progress, always reflecting the current state. As a deployment moves forward, you can follow the traffic shift distribution across your source and target revisions and see the current lifecycle stage at a glance, whether it is scaling up green tasks, waiting on a lifecycle hook, or sitting through bake time. Deployment health signals that you would otherwise gather from separate tools now sit alongside the timeline: circuit breaker status with live task failure and threshold tracking, deployment alarm state, container and load-balancer health checks, and lifecycle hook status. When something goes wrong, failed tasks surface right in the timeline with diagnostic context and deep links to services such as AWS CloudTrail, so you can pinpoint the root cause and act on it quickly. These capabilities are available at no additional charge in all AWS commercial Regions, and AWS GovCloud (US) https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ for all Amazon ECS services using the Amazon ECS native Linear, Canary, and Blue/Green deployment types. To get started, navigate to any Amazon ECS service in the https://console.aws.amazon.com/ecs and select the Deployments tab.

Amazon ECS Express Mode simplifies containerized application deployment by automating infrastructure setup through a single command, allowing developers to focus on building applications while following...

https://aws.amazon.com/ecs/ (Amazon ECS) now includes enhancements that improve service availability during rolling deployments. These enhancements help maintain availability when new application version tasks are failing, when current tasks are unexpectedly terminated, or when scale-out is triggered during deployments. Previously, when tasks in your currently running version became unhealthy or were terminated during a rolling deployment, ECS would attempt to replace them with the new version to prioritize deployment progress. If the new version could not launch successfully—such as when new tasks fail health checks or fail to start—these replacements would fail and your service availability could drop. ECS now replaces unhealthy or terminated tasks using the same service revision they belong to. Unhealthy tasks in your currently running version are replaced with healthy tasks from that same version, independent of the new version's status. Additionally, when Application Auto Scaling triggers during a rolling deployment, ECS applies scale-out to both service revisions, ensuring your currently running version can handle increased load even if the new version is failing. These improvements respect your service's maximumPercent and minimumHealthyPercent settings. These enhancements are enabled by default for all services using the rolling deployment strategy and are available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/. To learn more about rolling-update deployments, refer https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html.

Pausá despliegues en Amazon ECS para aprobaciones manuales o automáticas. Configurá lifecycle hooks con EventBridge y timeouts de hasta 14 días.

AWS App Runner now supports IPv6-based inbound and outbound traffic on both public and private App Runner service endpoints. This helps customers meet IPv6 compliance requirements, and removes the need for handling address translation between IPv4 and IPv6. App Runner is a fully-managed service that makes it easier for developers to quickly deploy containerized web applications and APIs to the cloud, at scale, and without managing infrastructure. Previously, IPv6 was only supported on incoming traffic through public endpoints. You can configure IPv6 by selecting the dual-stack option in your networking configuration on new or existing services.  AWS App Runner support for IPv6 is available in all AWS Regions where AWS App Runner is available. For more information about how to manage dual-stack support for your App Runner service, see Networking with App Runner in the AWS App Runner Developer Guide.