aws-cloudwatch

3 posts

aws

Amazon EC2 C9g and C9gd instances powered by AWS Graviton5 processors are now available | Amazon Web Services (opens in new tab)

Amazon EC2 C9g and C9gd instances, powered by AWS Graviton5, are now generally available for compute-intensive workloads. They provide up to 25% better performance per vCPU than C8g, faster DDR5 memory, larger caches, and improved networking and EBS bandwidth. C9gd adds local NVMe SSD storage, making it suitable for workloads requiring both high CPU performance and low-latency temporary storage. ## Graviton5 Performance Improvements - Up to 25% higher performance per vCPU than previous-generation C8g instances. - DDR5 memory running at 8800 MT/s, described as the fastest memory available in a cloud processor instance. - Five times more L3 cache than Graviton4-based instances. - Up to three times higher packet-processing performance than Graviton4. - Benefits include faster in-memory analytics, higher throughput, and more responsive real-time applications. ## C9g and C9gd Workloads - C9g is designed for compute-heavy applications using Amazon EBS, including: - Batch processing - Video encoding - Distributed analytics - CPU-based machine learning inference - Agentic AI workloads - C9gd adds local NVMe SSD storage for: - HPC simulation scratch space - Machine learning inference caches - Ad-serving buffers - Other low-latency temporary-storage use cases - C9gd delivers up to 30% higher local storage performance than the previous generation. ## Networking, Storage, and Configuration - Available in 11 sizes from medium through 48xlarge, plus bare metal. - Up to 15% higher network bandwidth and 20% higher EBS bandwidth on average compared with the prior generation. - The largest instances provide up to 100 Gbps networking and 72 Gbps EBS bandwidth. - Instance Bandwidth Configuration allows up to 25% of bandwidth to be shifted between EBS and VPC networking. - Support includes ENA Express, up to 128 EBS volumes, and On-Demand, Spot, Savings Plans, Dedicated Instances, and Dedicated Hosts. - NVMe-equipped instances expose detailed I/O statistics, including latency histograms by I/O size at one-second granularity through CloudWatch or `nvme-cli`. ## Nitro Isolation Engine - C9g and C9gd are the first compute-optimized EC2 instances to use the AWS Nitro Isolation Engine. - The Rust-based Nitro System component isolates virtual machines by mediating access to memory, CPU register state, and I/O devices through a minimal API set. - AWS provides additional technical documentation covering the engine and its formal verification results. ## Availability - The instances are available in US East (Ohio and Northern Virginia), US West (Oregon), and Europe (Frankfurt). - They can be launched through the AWS Management Console, CLI, or SDKs, with more regions planned. For compute-intensive workloads, C9g is the general-purpose choice, while C9gd is preferable when fast local NVMe storage is also required.

aws

Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs | Amazon Web Services (opens in new tab)

AWS Lambda MicroVMs provide isolated, stateful execution environments for running untrusted user- or AI-generated code without managing virtual machine infrastructure. Built on Firecracker, they combine VM-level isolation, near-instant startup and resume, and persistent memory and disk state. The post concludes that MicroVMs fill the gap between slow, isolated VMs, less-secure containers, and stateless event-driven Lambda functions. ## The Need for Isolated, Stateful Execution - AI coding assistants, online development environments, analytics tools, vulnerability scanners, and game servers increasingly need a dedicated environment for each user or session. - Traditional options involve tradeoffs: - VMs provide strong isolation but often take minutes to start. - Containers launch quickly but share a kernel and require extensive hardening for untrusted workloads. - Standard serverless functions are designed for short, request-response workloads rather than long-running interactive sessions. - Building custom virtualization infrastructure requires significant security, operations, and virtualization expertise. ## What Lambda MicroVMs Provide - Each user or session receives its own Firecracker-powered MicroVM. - MicroVMs offer: - Dedicated VM-level isolation with no shared kernel between users. - Rapid launch and resume from a pre-initialized snapshot. - Persistent memory, disk state, and running processes during a session. - Automatic suspension during inactivity to reduce idle costs. - Automatic resume when new traffic arrives. - Firecracker already powers AWS Lambda at large scale, providing an established virtualization foundation. ## Creating a MicroVM Image - The example packages a Flask application and Dockerfile into a ZIP archive and uploads it to Amazon S3. - The Dockerfile uses: ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal ``` - It installs Python and dependencies, copies the Flask application, and starts it with Gunicorn on port 5000. - An image is created with the `aws lambda-microvms create-microvm-image` command, specifying: - The S3 code artifact - An image name - An AWS-provided base image ARN - An IAM build role - Lambda builds the image, initializes the application, and captures its memory and disk state in a Firecracker snapshot. - Build logs are available in CloudWatch under `/aws/lambda/microvms/<image-name>`. ## Launching and Managing a MicroVM - A MicroVM is launched from the image ARN with `run-microvm`. - The example configures an idle policy that: - Suspends the MicroVM after 15 minutes of inactivity. - Keeps it suspended for up to 5 minutes. - Automatically resumes it when traffic returns. - Lambda assigns a unique MicroVM ID and provides a dedicated HTTPS endpoint. - No separate networking setup is required. - The application is already running when the MicroVM becomes available because it resumes from the image snapshot. ## Request Handling and State Preservation - Clients authenticate requests using a short-lived token in the `X-aws-proxy-auth` header. - The Flask API responds immediately after launch. - When the MicroVM becomes idle, Lambda snapshots and stores its memory and disk state. - A later request resumes the environment with the application state intact, making suspension effectively invisible to the client. ## Underlying Execution Model - Lambda MicroVMs use an image-then-launch workflow: - Build and initialize an environment once. - Snapshot the initialized state. - Launch future MicroVMs by resuming that snapshot. - This avoids repeating operating-system and application startup work. - The combination of Firecracker isolation, snapshot-based startup, and suspend/resume lifecycle control makes MicroVMs suitable for secure, interactive, multi-tenant workloads. For applications that must safely execute untrusted code while preserving session state and responsive startup times, Lambda MicroVMs offer a managed alternative to building custom VM infrastructure.

aws

Amazon ECS introduces new high-resolution metrics for faster service auto scaling | Amazon Web Services (opens in new tab)

Amazon ECS now supports 20-second high-resolution metrics for faster service auto scaling. AWS reports that scale-out triggers improved from 363 to 86 seconds, while total scaling and task provisioning dropped from 386 to 109 seconds. The update helps applications handle traffic spikes more reliably, reduce excess baseline capacity, and achieve aggressive scaling with simpler target-tracking policies. ## Faster Scaling with High-Resolution Metrics - ECS service auto scaling can use predictive, scheduled, or reactive target-tracking policies. - New 20-second metrics allow ECS to detect workload changes faster than standard 60-second metrics. - AWS benchmarking showed: - 76% faster scale-out triggering, or 4.2× improvement. - 72% faster total scaling and task provisioning, or 3.5× improvement. - Faster scaling can reduce latency and failures during sudden demand increases. ## Lower Costs and Simpler Configuration - Applications may reduce baseline task counts because capacity can be added quickly during spikes. - This can lower compute costs without sacrificing availability. - High-resolution target tracking can provide aggressive scaling behavior that previously required custom step-scaling policies. ## Configuration and Supported Metrics - Enable high-resolution metrics for the ECS service, then configure a target-tracking scaling policy. - New options include: - `ECSServiceAverageCPUUtilizationHighResolution` - `ECSServiceAverageMemoryUtilizationHighResolution` - The feature works with AWS Fargate, ECS Managed Instances, and Amazon EC2. - It can be configured through the ECS console, AWS SDKs, AWS CLI, Application Auto Scaling, or CloudFormation. - Existing services must first enable high-resolution metrics and complete deployment before their scaling policy can be updated. ## Cost and Availability - The ECS feature itself has no additional charge. - High-resolution CloudWatch metrics incur additional CloudWatch costs, unlike standard 60-second metrics. - The capability is available now. For workloads with unpredictable or rapid traffic changes, enabling high-resolution metrics with target tracking can improve responsiveness while reducing the need for overprovisioned ECS tasks.