AWS Recent Announcements Note

AWS Recent Announcements

AWS (Amazon Web Services) provides various services under its umbrella including compute, storage, security, and application services. Here are some recent announcements and updates: 1. AWS Outposts: AWS Outposts is a fully managed service that offers infrastructure consisting of compute, storage, and database capabilities. The latest update includes launch of Outposts in various countries. 2. AWS Lambda: Provides a compute service on-demand resource. Recent updates include enhancements for concurrency control and integration with Amazon API Gateway. 3. Amazon S3: Offers durable storage. Recent updates include the launch of the application migration API and encryption for snapshots. 4. AWS Billing: Allows you to view detailed billing information, and recent updates include improvements in billing details. 5. AWS Config: Provides resource monitoring, reporting, and auto-remediation for AWS resources. Recent updates include a notification action and AWS Step Functions. 6. AWS Multi-Region Access Point for Amazon S3: Multi-Region Access Points for S3 provide a global namespace to deliver a fast, secure, and resilient storage service. 7. Amazon Route 53: Provides domain registration and DNS service. Recent updates include support for multi-Region Access Points for S3. 8. AWS Lake Formation: A data engineering, data transformation and data governance service. Recent updates include creation of workflows and database credentials connection using JDBC drivers. 9. Amazon EMR: A big data processing service used for data processing, analytics, machine learning (ML) etc. Recent updates include cluster versioning and bug fixes. 10. AWS Step Functions: A service for coordinating the components of distributed applications and microservice-oriented architectures. Recent updates include enhanced task token input handling and auto-replace.

Thread Of Notes

The next generation of AWS Resilience Hub is a central location in the AWS that helps platform engineering and site reliability teams assess and strengthen the resilience of their workloads running on AWS. It provides automated dependency discovery, generative AI-powered failure mode analysis, modular resilience policies, resilience testing, and organization-wide resilience posture reporting. Today, AWS Resilience Hub adds three new capabilities: EKS labels support for service input sources, dependency insights, and resilience policy sharing through AWS Organizations. EKS labels support for service input sources. Resilience Hub now supports EKS labels within a namespace as a service input source, allowing customers to use their existing Kubernetes labeling conventions to scope exactly which resources Resilience Hub discovers and uses during failure mode analysis. This ensures assessments stay aligned with how teams organize their EKS workloads. Dependency insights. Customers who enable dependency discovery can now generate dependency insights, a new generative AI-powered capability that analyzes discovered application dependencies and highlights meaningful patterns. Dependency insights surfaces new dependencies, identifies cross-Region dependencies, and flags unusual usage patterns. This helps teams accelerate dependency analysis and identify potential new risks. Resilience policy sharing through AWS Organizations. Resilience Hub now supports sharing resilience policies through AWS Organizations, enabling central teams to build and manage policies that can be applied across multiple accounts. This provides organization-wide observability into which services are using each policy, making it easier to monitor adoption and ensure consistent resilience posture across the organization. To get started, visit the  AWS console. To learn more, see the product page or visit the documentation.
AWS RTB Fabric now supports configurable Availability Zone (AZ) affinity for responder gateways. With this capability, you can configure how your partners connect to your responder gateway: either in their own Availability Zone or to any Availability Zone that the gateway spans. This launch helps advertising technology (AdTech) companies use their infrastructure more efficiently—with no extra charges on RTB Fabric. Demand-side platforms (DSPs) and supply-side platforms (SSPs) run their bidding systems across multiple Availability Zones. Previously, AWS RTB Fabric sent each request to available gateway capacity in the requester's own Availability Zone (AZ), so capacity in other AZs could go unused. Now you can set a client routing policy to control this: prefer the requester's own AZ to avoid added latency of crossing a boundary, or use every AZ that the responder gateway spans to give each requester access to more gateway capacity. Configurable Availability Zone affinity is available in all AWS Regions where AWS RTB Fabric is available. See the AWS RTB Fabric User Guide for fleet requirements before enabling. AWS RTB Fabric helps you connect with your AdTech partners such as Amazon Ads, GumGum, Kargo, MobileFuse, Sovrn, TripleLift, Viant, Yieldmo, and more in three steps while delivering single-digit millisecond latency through a private, high-performance network environment. RTB Fabric reduces standard cloud networking costs by up to 80% and does not require upfront commitments. AWS RTB Fabric is generally available in the following AWS Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). See the AWS RTB Fabric Product Page to learn more.
Today, AWS announces the availability of the next generation of AgentCore Runtime, the serverless microVM compute within Amazon Bedrock AgentCore. The new Runtime delivers elastic memory management that reclaims unused memory throughout the session so you pay for actual usage rather than the peak, and consistent cold start times regardless of container image size or concurrency. You get the serverless model you already rely on: no pre-provisioning, scale to zero, hardware-enforced session isolation, and pay only for what you use - now with lower costs and faster starts. With the new Runtime, each session starts with a small, efficient memory profile. Additional memory is allocated on demand as the workload needs it, and memory that is no longer actively used is reclaimed rather than held until the session ends. For cold starts, the new Runtime prepares the agent environment once and snapshots it. Every new instance restores from that snapshot instead of repeating the full startup sequence, keeping start times consistent regardless of image size. In testing, the new Runtime delivered a P75 cold start of 1.9 to 2.0 seconds for container images from 200 MB to 2 GB, compared to 5.4–30 seconds with V1. The new AgentCore Runtime is available in the following regions: us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1. To get started, set platformVersion to V2 when creating or updating a runtime. To learn more, visit the AgentCore Runtime documentation or the AWS News Blog. For pricing details, visit AgentCore pricing.
AWS PrivateLink customers can now use VPC endpoint to privately and securely access network segments in another VPC/account. They can use a ‘tunnel’ endpoint, a new type of VPC endpoint, to tunnel into the network segment and access resources located within it. AWS PrivateLink is a highly available and scalable technology that enables private access across VPC and account boundaries to load balanced services, appliances, and resources such as databases and domains. Prior to this launch, customers who wanted to share their resources with another party such as an external vendor had to do it one at a time by creating a Resource Configuration for every resource. Now, customers can create a Resource Configuration to represent a CIDR range in their network, and share it with a vendor via AWS Resource Access Manager (RAM). The vendor can then create a tunnel endpoint and use GENEVE encapsulation to tunnel through it into the customer’s VPC to access resources located in CIDR range specified by the customer. There is an hourly charge for the tunnel endpoint and a per-GB charge for data processed through it. Please refer to the pricing page for AWS PrivateLink.   The capability is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Africa (Cape Town), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Canada West (Calgary), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Spain), Europe (Stockholm), Europe (Zurich), Mexico (Central), South America (São Paulo). To learn more about this capability and get started, please refer to the AWS PrivateLink documentation.
AWS HealthOmics now supports IAM session policies, enabling you to restrict permissions for individual runs without creating and managing multiple IAM roles. Until now, there was no way to dynamically scope down permissions for a single run, requiring you to create a separate IAM role for each tenant or run. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs with fully managed bioinformatics workflows. An IAM session policy is an inline policy that limits the maximum permissions of a run without modifying the underlying service role. Your effective permissions during a run are the intersection of permissions allowed by both the underlying identity-based policy and the temporary session policy. For example, if you operate a multi-tenant application, you can pass a session policy that limits a run's access to only that tenant's Amazon S3 buckets, without provisioning a dedicated IAM role for that tenant. You can also use IAM session policies to grant temporary access to specific Amazon S3 objects for a single run, and isolate access to sensitive resources on a per-run basis. IAM session policy support is available in all AWS Regions where AWS HealthOmics is available: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Tokyo, Singapore, Seoul). To learn how to configure IAM session policies for your runs, visit the Permissions section of the  AWS HealthOmics User Guide. To learn more about the service, visit  AWS HealthOmics.
AWS is announcing the general availability of new low-cost burstable Amazon EC2 T8i instances. These instances are powered by custom sixth generation Intel Xeon 6 processors, available exclusively on AWS, and built on the latest sixth generation AWS Nitro cards. T8i instances deliver up to 30% better price performance compared to previous generation T3 instances, and offer four sizes: nano, micro, small, and medium. These instances are designed for workloads requiring low to moderate CPU utilization, including data processing, login gateways, small databases, batch processing, event driven functions, CI/CD pipelines, microservices, and low traffic websites.   T8i instances deliver up to 70% higher compute performance, 1.25x higher network bandwidth, and 2.4x higher EBS bandwidth compared to T3 instances. They use the same CPU credit system as T3 with Standard and Unlimited modes, so existing T3 customers can upgrade to T8i and immediately benefit from better price performance, enabling them to lower their TCO. For customers new to AWS or migrating from on-premises, T8i instances provide one of the most cost-effective entry points to run a variety of workloads. T8i.micro and T8i.small are available under the AWS Free Tier. T8i instances are available in US East (N. Virginia, Ohio), US West (Oregon, N. California), Europe (Frankfurt, Ireland, London, Paris), Asia Pacific (Hyderabad, Malaysia, Mumbai, Seoul, Singapore, Sydney, Tokyo), and Canada (Central) regions. T8i instances are available to purchase via On-Demand instances, and Spot instances with Savings Plan option coming soon. To learn more, visit the Amazon EC2 T8i instances page.
Amazon SageMaker AI now supports serverless model customization for the NVIDIA Nemotron 3.5 Lightning model using supervised fine-tuning (SFT), Direct Preference Optimization (DPO), and reinforcement fine-tuning (RFT). This is one of the latest open-weight models from NVIDIA and employs a hybrid Mixture-of-Experts architecture with 3B active parameters and 30B parameters in total. In addition to deploying this model on SageMaker AI, you can now adapt it to your specific domains and workflows. Model customization enables you to tailor foundation models with your proprietary data so a smaller, right-sized model can match frontier-model quality on your tasks, reducing cost and latency. You can use labeled data with SFT to improve accuracy on domain-specific tasks, preference data with DPO to align outputs with your organization's tone, or reward signals with RFT to enhance performance on new tasks. With serverless customization, SageMaker AI handles all infrastructure provisioning and training orchestration, so you can focus on your data and evaluation rather than cluster management, and only pay for what you use. Serverless model customization for NVIDIA Nemotron 3.5 Lightning on SageMaker AI is available in US East (N. Virginia), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). To get started, navigate to the Models page in Amazon SageMaker Studio to launch a customization job, or use the SageMaker Python SDK for programmatic access. To learn more, see the Amazon SageMaker AI model customization documentation.
Amazon Elastic Container Service (Amazon ECS) now provides a consolidated deployment view for Amazon ECS Managed Daemons, giving you a single place to see how far a deployment has progressed, what is failing, and what could stop it. This helps you monitor Managed Daemon deployments at a glance and resolve issues faster, whether a rollout is in progress or you are reviewing what happened after it completed, eliminating the need to piece together deployment status from multiple sources. The deployment view presents a lifecycle timeline with timestamps at each step and the total deployment duration, including the rollback path if a deployment is interrupted. Progress bars for each capacity provider track instances completed, in progress, and remaining, as well as instances draining and being replaced when a capacity provider is removed. A monitoring panel shows deployment circuit breaker, deployment alarm, and container health check state, each with live Amazon CloudWatch alarm detail and whether it can stop the deployment. If a daemon task fails, the affected capacity provider shows the stop reason with links to the task, its logs, and the matching troubleshooting guide, including the failure that caused a rollback. The view also displays target and source revisions with instance counts, drain percentage, and bake time. This enhancement is available as a console-only view in all AWS Commercial Regions at no additional cost. To get started with Amazon ECS Managed Daemons, refer to our documentation.
AWS Elemental MediaTailor now supports two additional lifecycle hooks for monetization functions: post ad decision server (ADS) response, and pre manifest insertion. MediaTailor is a video service that personalizes and inserts ads into live and on-demand streams. Monetization functions run customer-defined logic at defined points in an ad-personalized playback session, removing the need for a middleware tier between MediaTailor and the ADS. The post ADS response hook runs after MediaTailor parses an ADS response and resolves all Video Ad Serving Template (VAST) wrappers, before ads are selected and transcoded. Customers use it to call a secondary ad source when the primary ADS returns less demand than the ad break can hold, remove ads that their content or brand policies do not permit, and add house ads or promotions from their own marketing systems. The pre manifest insertion hook runs at the last point before MediaTailor returns the ad pod to the viewer, and receives every newly personalized ad break in a single invocation. Customers use it as a final check on what is about to play, including inserting a personalized slate when a break cannot be filled any other way. Pre-built recipes in the MediaTailor console give customers a starting point for each of these use cases. Both hooks are fail-open: on a timeout, expression error, or resource limit, MediaTailor discards the function output and continues with default ad insertion, so viewer playback is unaffected. The new hooks are available in all AWS Regions where AWS Elemental MediaTailor is available. To learn more, see Monetization Functions in the AWS Elemental MediaTailor User Guide and the MediaTailor pricing page. To get started, sign in to the AWS Elemental MediaTailor console.
Today, AWS Billing and Cost Management (BCM) announces support for the Detected Anomalies widget in BCM Dashboards. You can now review cost anomalies alongside cost and usage, budgets, cost efficiency, and reports for Savings Plans and Reserved Instance coverage and utilization. This provides a unified view of your spending, commitments, and cost anomalies in a single, tailored dashboard. The Detected Anomalies widget displays the number of anomalies detected and their total cost impact relative to your month-to-date spend, giving you immediate context on each anomaly's scale. For each anomaly, you can review the cost impact, root cause, and duration. Choose a look-back period of 30, 60, or 90 days, and filter by severity, service, account, and region so that each dashboard shows the anomalies most relevant to that account. By adding one or more Detected Anomalies widget to a BCM Dashboard, finance teams and cloud administrators can monitor anomalies from their existing cost management workflows. The widget links directly to the AWS Cost Anomaly Detection console so you can easily investigate an anomaly and record your assessment. It is fully integrated with dashboard exports and can be included in scheduled email reports or downloaded as a CSV or PDF for offline analysis. It is also included with cross-account dashboard sharing. The Detected Anomalies widget for BCM Dashboards is available in all commercial AWS Regions at no additional charge. To learn more, visit our User Guide.
AWS Step Functions now automatically adds AWS SDK integrations for new AWS services and capabilities within weeks of their release, starting with AWS Lambda MicroVMs, AWS Lambda Core and others. Now, you can orchestrate the latest AWS services from your workflows without waiting for updates.    AWS Step Functions is a visual workflow service capable of orchestrating over 220 AWS services to help customers build distributed applications at scale. With the AWS Lambda Core and AWS Lambda MicroVMs service integrations, you can orchestrate agentic workflows without writing custom coordination code. You can use Step Functions to launch Lambda MicroVMs, which provide isolated, secure execution environments for each agent task with built-in retries if an environment fails to start. You can run multiple tasks simultaneously using Step Functions Parallel or Map states and automatically terminate environments when the task completes. You can use Lambda Core to configure the private networking those MicroVM environments need to securely reach your internal databases or APIs in the same workflow.   This expansion also includes AWS Partner Central Revenue Measurement, AWS Resilience Hub V2, AWS Support Authorization and Amazon SageMaker Job Runtime. Going forward, new AWS services will automatically appear as Step Functions integrations within weeks of their release with no additional configuration or action required. As updates will be continuous, we will no longer publish What's New posts to highlight new AWS SDK service integration updates.   These enhancements are now generally available in all AWS Regions where AWS Step Functions is available. Specific services and API actions are subject to the availability of the target service in the AWS Region. To learn more about AWS Step Functions SDK integrations, visit the Developer Guide, or see the full list of supported services at AWS SDK service integrations, and integration release history.
Today, Amazon SageMaker AI announces instance preference lists for training and processing jobs, making it easier and faster to find compute capacity for your workloads. Many AI training, fine-tuning, and data processing workloads run comparably well on any of several instance types or sizes. However, before now, you had to name only one instance type at the time of job submission and wait for SageMaker to find that specific instance for your job. For high-demand GPUs during peak periods, where wait times can be unpredictable, customers sometimes had to build complex retry logic or concurrently submit multiple jobs with different instance types to find the first available option. Now you can simply provide a prioritized list of the instance types your workload accepts, and SageMaker automatically runs your job on the first available configuration from your preferences. With this solution, your training or processing job will likely start sooner. To use this feature, you specify your instance type and count preferences in priority order when submitting the training or processing job. For example, your list might contain a preference of two instances of ml.g6.48xlarge or four instances of ml.g5.48xlarge. SageMaker works through the list and launches your job on the first configuration where capacity is available. You can also configure the capacity sourcing from on-demand sources or from your reserved SageMaker Flexible Training Plans within the same job submission. This feature simplifies the process of getting compute for your jobs during high-demand periods and reduces the undifferentiated manual retrying you would otherwise do, all within the SageMaker training and processing job APIs you already use. Instance preference lists for SageMaker training and processing jobs is available today in all AWS Regions where SageMaker is available through the SageMaker CLIs, APIs, SDKs and Console UI. To learn more, see our documentation or our launch blog.
AWS CloudTrail, a service that records API activity across your AWS account for security auditing, compliance, and operational troubleshooting, now integrates with Amazon Q Console to help you investigate your AWS account activity using natural language. You can ask Amazon Q Console questions about your CloudTrail configuration, query your logged events for security investigations, and troubleshoot operational issues without writing queries or manually parsing log files. With this integration, you can ask Amazon Q Console to check whether your CloudTrail trails are properly configured, identify gaps in your logging coverage, and confirm which data event sources you are tracking. You can investigate security concerns by asking who accessed a specific IAM role, what changes were made to your VPC configuration, or whether there were unauthorized access attempts in the past week. For operational troubleshooting, you can ask Amazon Q Console to find who created or deleted specific resources, identify which API calls are generating errors, trace activity from a specific IP address, or determine why your bill spiked. Amazon Q Console can query your CloudTrail trails, associated CloudWatch log groups, and event data stores on your behalf, providing answers grounded in your actual account activity rather than generic documentation.  This integration is available in all AWS commercial regions where Amazon Q Console is supported. To get started, open Amazon Q in AWS Management Console and ask questions about your CloudTrail configuration or account activity. For more information, visit the AWS CloudTrail documentation.
Amazon SageMaker HyperPod now supports model caching, an inference optimization that pre-loads model weights and container images onto cluster nodes so pods start in seconds instead of minutes. When running LLM inference at scale for workloads like chat assistants, agentic pipelines, RAG, and document analysis, cold start is a real bottleneck. Deployments and scale-out events spend most of their time downloading container images and model weights. As model size increases, this gets worse, with large models taking tens of minutes before they can serve traffic. Model caching solves this with two independent capabilities. The weights cache stores model weights on local NVMe so pods read from fast local storage instead of pulling from S3 or FSx over the network. The image cache pre-pulls the container image so pods skip the ECR download entirely. If a pod lands on a node without a warm cache, it falls back to pulling from the original source automatically, so there is no risk of pods getting stuck or failing. Benchmarks across models from 57 GB to 145 GB show around 60% faster scale-out, and the image cache cuts over two minutes of image-pull time (97% reduction). The benefit grows with model size while retaining the reliability of the original source path. Customers enable model caching through the HyperPod Inference Operator by adding a modelCacheConfig section to their InferenceEndpointConfig or JumpStartModel resource. The operator handles the full lifecycle with no manual setup or cleanup. Model caching is now generally available in all regions where SageMaker HyperPod is available. To get started, see the SageMaker HyperPod documentation.