Tag Archives: Amazon EC2

Burst to Region: Overflow AWS Outposts workloads to Amazon EC2

Post Syndicated from Diya . original https://aws.amazon.com/blogs/compute/burst-to-region-overflow-aws-outposts-workloads-to-amazon-ec2/

AWS Outposts brings AWS infrastructure into your data center, giving on-premises workloads the low latency and data locality they need. But unlike the AWS Region, an Outposts rack has a fixed amount of compute. When your workload needs more instances than the rack can provide, you have two options: drop requests, or overflow them somewhere with room to grow. This post shows you how to automate the second option. You build a Burst to Region pattern that detects capacity constraints on your Outpost, launches Amazon Elastic Compute Cloud (Amazon EC2) instances in the parent Region, gradually shifts traffic to them, and returns traffic to local instances once capacity recovers.

To implement this pattern you configure Amazon CloudWatch, Amazon Simple Notification Service (Amazon SNS), AWS Lambda, Amazon EC2 Auto Scaling, Elastic Load Balancing (Application Load Balancer), and Amazon EventBridge. You trade a moderate latency increase for continued availability during capacity events.

When to use this pattern

This pattern assumes your Outposts workload scales out through Amazon EC2 Auto Scaling. Burst to Region reacts to instance-capacity exhaustion on the rack. It engages when your workload tries to launch more instances than the available Outpost capacity supports. If your fleet is fixed size and degrades under load without scaling out, the capacity alarm never fires and overflow never triggers. For those workloads, monitor per-instance saturation (CPU, latency) separately.

Good candidates prefer local capacity but can tolerate Region latency under pressure. If your application runs on Outposts for proximity yet degrades gracefully when some traffic takes the longer path to the Region, it fits this pattern. Examples include:

  • Internal enterprise applications.
  • Stateless web frontends and API layers.
  • Pre-processing tiers where single-digit to tens-of-milliseconds additional round-trip latency during peaks is acceptable.

Poor candidates cannot absorb any added latency or must stay on the Outpost. Avoid this pattern for:

  • Applications with sub-millisecond requirements.
  • Workloads with strict data residency or sovereignty mandates that prevent traffic from leaving the on-premises environment.
  • Real-time control systems with hard timing constraints.
  • Applications tightly coupled to on-premises data stores with no Region replica.

The core tradeoff is explicit. During capacity events, you accept moderately higher latency to maintain availability. If your workload cannot tolerate any latency increase, keep it pinned to Outposts and reserve capacity through other means, such as Capacity Reservations.

Solution overview

Burst to Region works in three moves: detect capacity pressure on the Outpost, launch overflow compute in the parent Region, and shift traffic gradually until local capacity recovers. Six AWS services coordinate to make this automatic. The following diagram shows the reference architecture for the Burst to Region pattern, illustrating how the six AWS services interact during capacity detection, overflow scaling, traffic distribution, and recovery.

Reference architecture for Burst to Region on AWS Outposts showing capacity detection, overflow scaling, traffic distribution, and recovery

Figure 1: Reference architecture for Burst to Region on AWS Outposts

The pattern uses six AWS services working together:

  • Amazon CloudWatch monitors Outposts capacity utilization and raises alarms.
  • Amazon SNS provides event fan-out from alarm to orchestrator.
  • AWS Lambda orchestrates the burst logic (scale-out, weight adjustment, recovery)
  • Amazon EC2 Auto Scaling manages the overflow fleet lifecycle.
  • Application Load Balancer distributes traffic across both locations using weighted target groups.
  • Amazon EventBridge handles periodic recovery evaluation.

You must configure five phases for this pattern:

  1. Monitor. CloudWatch tracks Outposts capacity utilization metrics in the AWS/Outposts namespace.
  2. Detect. A CloudWatch alarm fires when utilization exceeds a threshold (for example, 80%).
  3. Overflow. The alarm triggers a Lambda function through Amazon SNS. Lambda scales out a Region-based Amazon EC2 Auto Scaling group and adjusts ALB target group weights.
  4. Distribute. The ALB splits traffic between Outposts instances and Region instances using weighted forwarding.
  5. Recover. An Amazon EventBridge scheduled rule periodically evaluates capacity. When Outposts recovers, Lambda scales down the overflow fleet and returns all traffic to local instances.

Design decisions

We chose Application Load Balancer with weighted forwarding over Amazon Route 53 weighted routing for traffic distribution. ALB provides health-aware routing to only healthy overflow instances and target group stickiness for session consistency. Weight changes take effect for new connections after calling the ModifyRule API. DNS-based shifting through Route 53 provides too coarse control for rapid weight adjustments, and TTL propagation delays make recovery slower.

The burst orchestrator runs as a Lambda function rather than a long-running service. It executes only during state transitions, so there is no steady-state compute cost. Lambda integrates natively with Amazon SNS and Amazon EventBridge for event-driven invocation without additional infrastructure.

You implement recovery with an Amazon EventBridge scheduled rule (every 5 minutes) rather than relying solely on the CloudWatch alarm to return to OK state. The alarm confirms capacity is available, but does not confirm that overflow instances have drained active connections. The scheduled rule provides gradual, safe scale-down.

Implementation

This section walks through the key components of the Burst to Region pattern. For the complete deployable AWS SAM template, see the GitHub repository.

Prerequisites

To deploy this pattern, you need:

  • An AWS account with a configured AWS Outposts rack.
  • An Amazon Virtual Private Cloud (Amazon VPC) with subnets associated with your Outposts and subnets in the parent AWS Region.
  • IAM permissions to create CloudWatch alarms, Lambda functions, Auto Scaling groups, and ALB resources.
  • AWS Serverless Application Model (AWS SAM) CLI installed and configured.
  • Existing Amazon EC2 Auto Scaling group running on your Outpost (these become your baseline fleet)
  • A custom domain name with a DNS record (Route 53 alias or CNAME) pointing to your Application Load Balancer, and an AWS Certificate Manager (ACM) certificate for that domain to enable HTTPS.

Capacity monitoring and alarm

The CloudWatch alarm monitors instance utilization on the Outpost and triggers the burst workflow when capacity is constrained.

The InstanceTypeCapacityUtilization metric reports the percentage of a given instance type’s capacity in use. Note that this metric includes capacity consumed by managed services such as Amazon Relational Database Service (Amazon RDS) or Application Load Balancer running on the Outpost — not only your application’s EC2 instances. Factor this into your threshold planning.

OutpostsCapacityAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: outposts-capacity-high
    Namespace: AWS/Outposts
    MetricName: InstanceTypeCapacityUtilization
    Dimensions:
      - Name: OutpostId
        Value: !Ref OutpostId
      - Name: InstanceType
        Value: !Ref OutpostInstanceType
    Statistic: Average
    Period: 300
    EvaluationPeriods: 2
    Threshold: !Ref CapacityThreshold
    ComparisonOperator: GreaterThanOrEqualToThreshold
    AlarmActions:
      - !Ref BurstSNSTopic
    TreatMissingData: notBreaching

Why these values matter:

  • Period: 300 and EvaluationPeriods: 2 require 10 minutes of sustained high utilization before triggering. This avoids false alarms from transient spikes.
  • Threshold: 80 (recommended starting point) leaves a 20% buffer. A threshold set too high (95%) risks launch failures before the overflow fleet is ready. A threshold set too low (50%) causes unnecessary bursts.
  • TreatMissingData: notBreaching prevents false alarms when data points are missing. Since this alarm is scoped to a single instance type, treating missing data as breaching could trigger unnecessary bursts when the instance type is simply not in use.
  • Separate scale-out from scale-in: This alarm triggers burst scale-out at 80%. Recovery is handled separately by the Amazon EventBridge scheduled rule, which uses a lower threshold (for example, 60%) before scaling in. This hysteresis gap prevents flapping where scaling down immediately pushes utilization back above the alarm threshold.

Burst orchestrator (Lambda)

The Lambda function handles two event paths: alarm-triggered scale-out and scheduled recovery evaluation. The following pseudocode shows the orchestration flow:

def handler(event, context):
    # Route based on event source
    if is_scheduled_recovery(event):
        return handle_recovery_check()

    alarm_state = parse_sns_alarm_state(event)

    if alarm_state == 'ALARM':
        # Scale out the overflow Auto Scaling group
        scale_out_overflow(desired=OVERFLOW_CAPACITY)
        # Don't shift traffic yet --- wait for healthy instances
        publish_burst_metric(active=True)


def handle_recovery_check():
    """Called every 5 minutes by EventBridge."""
    # Check if burst is active
    if not is_burst_active():
        return

    # If overflow instances are healthy and registered, shift traffic
    if overflow_targets_healthy():
        current_weights = get_current_alb_weights()
        if current_weights['region'] == 0:
            # First shift --- instances are now warm
            set_alb_weights(outposts=90, region=10)
        elif needs_more_overflow():
            step_up_region_weight()

    # If Outposts capacity has recovered, begin scale-down
    if outposts_capacity_recovered():
        step_down_region_weight()
        if get_current_alb_weights()['region'] == 0:
            # All traffic back to Outposts, drain and terminate overflow
            wait_for_connection_draining()
            scale_down_overflow(desired=0)
            publish_burst_metric(active=False)

The key actions the function performs:

  • scale_out_overflow — Sets the overflow Auto Scaling group desired capacity from 0 to your configured burst size.
  • set_alb_weights — Calls the ModifyListener API to adjust weighted forwarding between the Outposts and Region target groups.
  • publish_burst_metric — Writes a custom CloudWatch metric (BurstActive) for dashboard visibility.
  • handle_recovery_check — Called every 5 minutes by Amazon EventBridge. Confirms Outposts capacity has recovered, steps weights back gradually, waits for connection draining, then scales down the overflow fleet.

Important: The orchestrator does not shift ALB weights immediately upon scale-out. It waits for the next Amazon EventBridge invocation (up to 5 minutes) to confirm that overflow instances have passed health checks and are registered as healthy in the target group. This helps prevent routing traffic to instances that have not finished launching.

For the production-ready implementation with error handling, gradual weight stepping, and connection draining verification, see the GitHub repository.

Overflow Auto Scaling group

The overflow fleet starts at zero and scales only when the Lambda function sets desired capacity during a burst event:

OverflowASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    AutoScalingGroupName: burst-overflow-fleet
    LaunchTemplate:
      LaunchTemplateId: !Ref OverflowLaunchTemplate
      Version: !GetAtt OverflowLaunchTemplate.LatestVersionNumber
    MinSize: 0
    MaxSize: !Ref MaxOverflowCapacity
    DesiredCapacity: 0
    VPCZoneIdentifier:
      - !Ref RegionSubnet1
      - !Ref RegionSubnet2
    TargetGroupARNs:
      - !Ref RegionTargetGroup
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120
    MetricsCollection:
      - Granularity: 1Minute

The overflow fleet starts at zero capacity and incurs no cost at rest. During a burst event, the Lambda function calls the SetDesiredCapacity API to launch overflow instances. During recovery, it sets desired capacity back to zero.

The launch template mirrors your Outposts instance type to maintain consistent performance characteristics across both locations.

ALB weighted forwarding

The ALB listener uses weighted forwarding across two target groups. In steady state, all traffic goes to Outposts (weight 100/0). During burst, the Lambda function adjusts these weights dynamically using the ModifyListener API. Clients reach the ALB through a DNS record — either a Route 53 alias or a CNAME pointing to the ALB’s DNS name.

ALBListener:
  Type: AWS::ElasticLoadBalancingV2::Listener
  Properties:
    LoadBalancerArn: !Ref ApplicationLoadBalancer
    Port: 443
    Protocol: HTTPS
    SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06
    Certificates:
      - CertificateArn: !Ref CertificateArn
    DefaultAction:
      Type: forward
      ForwardConfig:
        TargetGroups:
          - TargetGroupArn: !Ref OutpostsTargetGroup
            Weight: 100
          - TargetGroupArn: !Ref RegionTargetGroup
            Weight: 0
        TargetGroupStickinessConfig:
          Enabled: true
          DurationSeconds: 300

RegionTargetGroup:
  Type: AWS::ElasticLoadBalancingV2::TargetGroup
  Properties:
    Name: burst-region-targets
    Protocol: HTTP
    Port: 80
    VpcId: !Ref VpcId
    HealthCheckEnabled: true
    HealthCheckIntervalSeconds: 30
    HealthCheckPath: /health
    HealthyThresholdCount: 2
    UnhealthyThresholdCount: 3
    TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: "300"
      - Key: slow_start.duration_seconds
        Value: "120"

Note on stickiness: Target group stickiness keeps a client pinned to whichever target group served its first request for DurationSeconds. We set this to 300 seconds (5 minutes) to match the Amazon EventBridge evaluation interval. This balances session consistency for stateful workloads against the need for weight changes to take effect within a reasonable window. For purely stateless workloads, you can disable stickiness entirely to allow immediate weight convergence. For workloads requiring longer session affinity, increase the duration but understand that weight transitions will converge more slowly — existing sticky sessions continue going to the original target group until they expire.

Traffic weight progression

Use stepped transitions rather than abrupt weight changes. The following table shows the recommended progression:

Phase Outposts weight Region weight Condition to advance
Normal 100 0 Steady state
Burst step 1 90 10 Region target group has at least 1 healthy host
Burst step 2 70 30 Region target group healthy for 2 consecutive checks
Burst step 3 50 50 Only if Outposts capacity exceeds 95% used
Recovery step 1 80 20 Outposts capacity below 70%
Recovery step 2 100 0 Outposts capacity below 60% for 2 checks

Avoid jumping directly from 0% to 50% Region traffic. Cold overflow instances need time to warm caches and stabilize before absorbing significant load.

Best practices

Apply these best practices to get the most from this pattern while avoiding common pitfalls.

Traffic tiering

Classify your workloads into two tiers at the ALB listener level. Latency-critical paths use routing rules with the Outposts target group only. These never overflow regardless of capacity state. Overflow-eligible paths use the weighted forwarding rule. This separation helps make sure that your most latency-sensitive flows are not impacted by the burst mechanism.

Managing data gravity

For stateless workloads, Burst to Region requires no special data handling. For workloads with session state or shared data:

Anti-pattern: Do not burst workloads that write to Outposts-local storage and expect synchronous consistency. The latency and complexity of cross-location writes defeats the purpose of the pattern.

Cost optimization

The overflow fleet consumes On-Demand pricing by default since it starts at zero and scales only during peaks.

Burst profile Recommended pricing Rationale
Unpredictable spikes (minutes) On-Demand Maximum flexibility, no commitment waste
Predictable daily peaks (hours) Savings Plans (Compute) Covers overflow hours at discount
Frequent, long bursts Reserved capacity plus On-Demand Baseline discount plus burst flexibility

Monitor your BurstActive custom metric over time. If overflow is active more than 30% of the time, you likely need additional Outposts capacity rather than relying on Region overflow.

Security consistency

Maintain identical security posture across both environments:

  • Use the same security group rules for Outposts and Region instances.
  • Deploy with AWS CloudFormation StackSets to support consistency.
  • Share the same IAM instance profile. The overflow launch template references the same role as your Outposts instances.
  • Apply the same AWS Systems Manager patch baselines and compliance rules to both fleets.

Observability

Build a CloudWatch dashboard that provides visibility into burst state and performance. The SAM template in the repository deploys a pre-configured dashboard tracking:

  • Burst status: Custom BurstActive metric (1 = active, 0 = normal)
  • Capacity headroom: UsedInstanceType_Count compared to AvailableInstanceType_Count. Note that UsedInstanceType_Count includes instances consumed by managed services (Amazon RDS, ALB), so your available application capacity may be lower than the raw availability count suggests.
  • Overflow fleet size: Auto Scaling group GroupInServiceInstances.
  • Latency comparison: TargetResponseTime per target group (Outposts compared to Region)
  • Traffic distribution: RequestCount per target group.

Set a CloudWatch alarm on Region target group TargetResponseTime exceeding your acceptable threshold. This provides early warning if overflow latency degrades beyond your tolerance.

Because the ALB resides in the Region, all traffic to Outposts targets traverses the service link. Keep the following in mind:

Bandwidth planning: Steady-state traffic to Outposts targets flows over the service link. Verify that your connection meets the minimum 500 Mbps per compute rack recommended by AWS, with sufficient headroom for both application traffic and Outposts control plane communication. Monitor service link VIF throughput using IfTrafficIn and IfTrafficOut metrics (on service link VIFs) to detect saturation before it impacts performance.

Latency impact: The service link adds latency compared to a locally deployed load balancer. The exact impact depends on your service link connection type and distance to the parent Region (AWS specifies a maximum of 175 ms round-trip for service link). For internet-facing workloads, this is typically negligible relative to the client-to-Region round trip. For workloads serving on-premises users through the Local Gateway, consider Route 53 weighted routing between an ALB on Outposts and a separate ALB in the Region instead.

Connection draining: When scaling down the overflow fleet, allow sufficient time for in-flight requests to complete. The deregistration delay configured on the target group (default 300 seconds) and the Auto Scaling scale-in cool-down period work together to help provide graceful termination and minimize the risk of dropping active connections.

Failure modes: If the service link goes down, the ALB cannot reach Outposts targets. Health checks fail, and all traffic automatically shifts to Region targets. This provides an unintentional but useful failover behavior. However, note that the overflow fleet is sized for burst capacity, not for sustaining 100% of production traffic. Monitor the ConnectedStatus metric (under the AWS/Outposts namespace, dimension OutpostId) and alert on degradation. If you need full failover capability, architect a separate disaster recovery solution with appropriately sized Region capacity.

Limitations

Be aware of these constraints when implementing this pattern:

  • ALB requirement: The pattern requires an Application Load Balancer in the Region. Workloads that rely on direct IP access through the Local Gateway (without an ALB) cannot use this pattern without an architecture change.
  • Stateful workloads: Applications with local disk state or in-memory sessions require external session stores (ElastiCache, DynamoDB) before they can burst. Without this, overflow instances serve requests without session context.
  • Database coupling: If your application writes to a database running exclusively on the Outpost, overflow instances in the Region cannot reach it without a cross-location replica or proxy. Read-heavy workloads with a Region read replica are ideal candidates.
  • Service link as single path: All ALB-to-Outpost traffic shares the service link with AWS control plane operations. Under extreme load, bandwidth contention can degrade both application traffic and management operations.
  • ALB on Outposts: As of this writing, ALB on Outposts does not support weighted target groups spanning both locations. The ALB must reside in the Region for this pattern to work.

Testing the pattern

Validate the burst mechanism before relying on it in production:

Simulate capacity pressure:

aws cloudwatch set-alarm-state \
  --alarm-name outposts-capacity-high \
  --state-value ALARM \
  --state-reason "Testing burst mechanism"

Verify overflow fleet launched:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names burst-overflow-fleet \
  --query "AutoScalingGroups[0].DesiredCapacity"

Verify ALB weights shifted (after recovery check runs):

aws elbv2 describe-listeners \
  --listener-arns <your-listener-arn> \
  --query "Listeners[0].DefaultActions[0].ForwardConfig.TargetGroups[*].[TargetGroupArn,Weight]"

Trigger recovery:

aws cloudwatch set-alarm-state \
  --alarm-name outposts-capacity-high \
  --state-value OK \
  --state-reason "Testing recovery"

Confirm overflow fleet scales back to zero and all traffic returns to Outposts targets. Recovery is gradual — the Amazon EventBridge rule evaluates every 5 minutes and steps weights back before scaling down, so full recovery may take 10–15 minutes depending on your weight progression configuration.

Clean up

To avoid ongoing charges, verify that the overflow Auto Scaling group has scaled to zero, then delete the stack:

sam delete --stack-name burst-to-region-stack

This removes all resources created by the template, including the Lambda function, CloudWatch alarm, SNS topic, Amazon EventBridge rule, and the overflow Auto Scaling group.

Conclusion

This Burst to Region pattern extends AWS Outposts capacity into the parent Region during peak demand. You trade a moderate latency increase for continued availability when local capacity is exhausted.

The pattern works best when you clearly classify which workloads can overflow, implement gradual traffic transitions, and maintain security and observability parity across both environments.

For the complete deployable AWS SAM template including the Lambda orchestrator, CloudWatch dashboard, and all IAM roles, see the GitHub repository. To learn more about capacity planning for Outposts, see Managing your AWS Outposts capacity using Amazon CloudWatch and AWS Lambda and AWS Outposts monitoring and reporting: A comprehensive Amazon EventBridge solution.

For more information, see the AWS Outposts User Guide and the Amazon EC2 Auto Scaling User Guide.

Scaling patterns for self-organizing multi-agent clusters with Kiro

Post Syndicated from Ivo Kammerath original https://aws.amazon.com/blogs/architecture/scaling-patterns-for-self-organizing-multi-agent-clusters-with-kiro/

Most multi-agent systems today follow the same shape: a supervisor agent breaks a task down, hands the pieces to subagents, and stitches the results back together. This is how Kiro CLI delegates to subagents, and what the Strands Agents SDK gives you primitives for with graphs and agents-as-tools. It is a good default. One process holds the plan, so behavior stays predictable and every result passes through a single gate.

That one process is also the limit. Every assignment and every result flows through the supervisor, so its context window caps how much work the system can hold at once. If it dies, the run dies with it. And because a single planner fixes the decomposition upfront, you get one take on the problem, multiplied by N workers.

Plenty of distributed systems still coordinate centrally, and should. But the alternative has been around for decades: let participants converge through shared state instead. We wanted to know what happens when you apply that move to artificial intelligence (AI) agents, so we built kiro-flock, an open-source reference implementation. It runs clusters of Kiro CLI agents on Amazon Elastic Compute Cloud (Amazon EC2) with nothing between them but an Amazon Simple Storage Service (Amazon S3) bucket. No orchestrator, no message bus. Agents coordinate by reading each other’s append-only logs. This post explains the pattern and gives you enough to deploy the sample and watch a cluster converge yourself.

When to use this pattern

Architecture has to match the task. In the 2025 study “Towards a Science of Scaling Agent Systems” of 260 agent-system configurations they found exactly that: task performance ran from +80.8 percent on decomposable financial
reasoning to -70.0 percent on sequential planning, against a single-agent baseline.
Neither the supervisor nor this pattern wins everywhere.

A self-organizing cluster fits work that splits into many quasi-independent contributions toward one goal: reviewing a large code base, migrating hundreds of modules against a known target, generating tests or design alternatives at scale. It also suits brainstorming where you want real variety instead of one planner’s take. Parallelism matters more than ordering. Agents can join, fail, and leave without ceremony.

A supervisor fits the opposite profile. The task tree is known upfront, steps depend on each other, or you need a verification gate before results ship. The same study found that architectures without centralized verification propagate more errors. That is a real cost of removing the arbiter, though you can still gate the finished result the way the migration example ends in a full test pass. What a cluster will not give you is a gate between every step, and if you need that, the supervisor earns its bottleneck.

Workload profile Better fit
Many independent contributions, one goal Cluster
Decomposition should emerge from the work Cluster
Diversity of approaches is an asset Cluster
Long-running, agents come and go Cluster
Known task tree, strict ordering Supervisor
Central verification gate required Supervisor
Interactive, latency-sensitive Supervisor

The pattern

The core decision: coordination lives in shared state. No component plans, assigns, or aggregates for the rest. Three parts make it work:

  • Agents. Independent processes that read and write a shared store and never connect to each other. One agent failing stops only its own log.
  • A shared environment. A single store holds a direction file, one append-only log per agent, and a working area for artifacts.
  • A direction. A markdown file that states the goal and leaves the path to the agents.

Each agent runs a loop. It starts a fresh session, reads the direction and the logs of a bounded set of peers, decides on one contribution that moves the goal forward, writes its artifacts, and appends one line to its own log:

{"ts":"2026-07-21T14:12:42Z","iteration":0,"action":"wrote discussion on coordination topologies","result":"Created discussion-coordination-topologies.md covering ring vs mesh vs swarm trade-offs with analysis of convergence/diversity tension.","next_intent":"read neighbour contributions and either deepen topology discussion or explore a second angle"}

That line is the entire coordination message. No broker delivers it, no acknowledgment comes back. The next agent that reads it decides for itself what to do about it. Remove an agent and its neighbors read one fewer log. Add one mid-run and it joins the division of labor already underway.

The bounded peer set is deliberate. Agents sit in a logical ring and each reads a fixed number of neighbors on either side, set by a radius parameter. Give every agent full visibility and the cluster collapses onto whatever the first agent wrote, because each later agent reads that as consensus. Limited visibility lets signals spread gradually, and agents working from different context get room to develop alternatives.

In kiro-flock, each agent is a headless Kiro CLI session on its own Amazon EC2 instance, and the shared environment is an Amazon S3 bucket. Which tools an agent may use without review, and what each iteration reads and writes, are design decisions you make once per cluster. We think of them as harness engineering and loop engineering, and the drift failure mode in the following section shows why the fresh session per iteration matters.

What a run looks like

Reference architecture: EC2 agent instances, an S3 shared environment holding the direction, logs, and artifacts, an API Gateway and Lambda control plane behind Amazon Cognito, CloudWatch metrics, and Amazon Bedrock post-run analysis.

Figure 1. Reference architecture for a kiro-flock cluster on AWS.

Agents run as headless Kiro CLI sessions on EC2 instances, each reading and writing the S3 bucket that holds the direction, one log per agent, and the shared artifacts. An Amazon API Gateway and AWS Lambda control plane behind Amazon Cognito starts, stops, and steers clusters from the dashboard. Agents publish metrics to Amazon CloudWatch, and Amazon Bedrock backs the post-run analysis.

Take a concrete run: sixteen agents in a ring, directed to hold a distributed discussion on AI agent clustering and converge on a shared synthesis. The operator writes one direction file and starts the cluster. Nothing else is assigned.

The following lines are from that run (result fields shortened for print). In the first iteration the agents fanned out with no assignment: failure modes, coordination topologies, distributed-systems parallels, and several overlapping stigmergy pieces, all written in parallel within one minute of start. The later lines show an agent correcting course after reading its neighbors, the synthesis forming, and the cluster winding itself down:

{"ts":"2026-07-21T14:12:42Z","iteration":0,"action":"wrote discussion-failure-modes.md","result":"covered 5 failure modes (premature convergence, echo chambers, hot-spot collapse, idle cascades, stale reads) with mitigations","next_intent":"read neighbours next iteration, look for topics to challenge or extend"}
{"ts":"2026-07-21T14:14:31Z","iteration":1,"action":"wrote discussion-scaling-laws.md","result":"explored scaling regimes and communication cost vs value; diverged from neighbours who all wrote stigmergy in iteration 0","next_intent":"read neighbour updates, check if any uncovered angles remain"}
{"ts":"2026-07-21T14:16:04Z","iteration":2,"action":"wrote synthesis.md","result":"structured synthesis: 5 core claims, 3 key tensions, 5 open questions; integrated topologies, scaling, economics, failure modes","next_intent":"read neighbours' reactions to synthesis, refine, move toward idle if coverage is solid"}
{"ts":"2026-07-21T14:22:24Z","iteration":7,"action":"idle","result":"All 6 visible neighbours idle (iterations 4-6). Synthesis.md stable and comprehensive. Direction unchanged. Cluster fully converged.","next_intent":"remain idle unless direction changes or operator requests further work"}

The cluster converged on a shared synthesis covering the angles in the direction, and by iteration 7 all sixteen agents had declared themselves idle. Nobody assigned the topics, arbitrated the synthesis, or told the cluster it was done. Even done is only a signal read from the logs, since an agent goes idle when its neighbors are idle and the output is stable.

kiro-flock dashboard showing a single six-agent cluster running the amorphous algorithm at radius 1, each agent card listing its neighbors, health, and iteration log, with the shared environment and direction on the right.

Figure 2. A single cluster in the kiro-flock dashboard. Six agents run at radius 1, each on its own EC2 instance. Every agent card shows its neighbors and its latest log line, the “did / result / next intent” message its neighbors read. The right panel shows the shared environment in S3 and the direction the cluster works toward.

Three ways to answer “whose work do I read?”

Every iteration starts with that question, and the answer defines the coordination algorithm. kiro-flock ships three, swappable at runtime.

Amorphous (ring). Each agent reads a fixed window of neighbors set by radius R. An agent at radius 2 reads four neighbors whether the cluster holds 8 agents or 800, so per-agent work stays constant as the cluster grows. The ceiling is your EC2 vCPU quota, not the algorithm. The largest system we have run so far totaled 184 agents across 11 cooperating clusters, creating a programming language. Rings beyond the low hundreds are extrapolation from that constant per-agent cost, not tested territory. The price is speed: a signal moves one hop per iteration. That slowness is also what lets dissenting agents mature alternatives before the neighborhood locks in. Use it for parallel work, or as the opening phase before consensus.

Mesh (full visibility). Every agent reads every other agent’s latest entry. Alignment is fast and context grows linearly with the cluster, so mesh stays comfortable to about 30 agents and workable to about 50. Diversity collapses, because agents reacting to the same first signal agree instead of exploring. Use it when a small group must converge quickly.

Swarm (recency). Each agent reads the K most recently active peers, so the cluster reorganizes around where the action is. Good for ideation, runs well past 100 agents. If K stays small while N grows, most agents read the same few peers and pile onto one subtask. Raise K or switch to amorphous.

A productive sequence uses all three: open amorphous to explore, switch to swarm as a direction forms, finish in mesh to align on the output.

How long does convergence take? In a ring, one iteration carries a signal 2R positions, so full propagation takes ceil(N / 2R) iterations, and consensus roughly two to three times that, because agents observe, react, and confirm. The wall-clock column assumes an iteration interval of 30 seconds per agent loop, the default interval in the reference implementation. The interval is configurable per cluster.

Agents (N) Radius (R) Propagation ceil(N/2R) Consensus (2-3x) Wall clock to propagate
8 1 4 iterations 8-12 iterations about 2 minutes
100 2 25 iterations 50-75 iterations about 12 minutes
1,000 4 125 iterations 250-375 iterations about 62 minutes
1,000 20 25 iterations 50-75 iterations about 12 minutes

Radius trades per-agent context for convergence speed, as the last two rows show. For parallel map-style work, propagation barely matters. Agents only need to avoid duplicating each other. It costs you when the task needs consensus, so match radius and cluster size to the context you are in. The cost model follows the same logic: no always-on orchestrator and no broker. You pay for Kiro credits and the EC2 instances while they run, plus S3 storage and requests. You also pay for the AWS Lambda, Amazon API Gateway, and Amazon Bedrock usage the control plane and post-run analysis incur. See AWS Pricing.

None of this is new theory. Identical unreliable parts producing coherent global behavior through local reads is amorphous computing. Coordinating through traces left in a shared medium instead of messages is stigmergy, described by Grassé for termites in 1959 and formalized for artificial systems by Theraulaz and Bonabeau. And a set of append-only logs is a grow-only conflict-free replicated data type (CRDT) spreading gossip-style: replicas converge without locks, which is all the consistency this workload needs.

Where it breaks

Self-organizing clusters fail in ways orchestrated systems do not. With no supervisor to arbitrate, a bad signal can spread before anyone corrects it. Four failure modes recur, and each maps to a design choice rather than a safeguard bolted on afterward.

Failure mode Where it comes from Design choice that addresses it
Groupthink Mesh visibility collapses the cluster onto the first signal Open amorphous to build diversity, switch to mesh only to align
Drift Persistent session history builds behavioral momentum Fresh session per iteration. State lives only in shared logs
Hot spots Swarm with K too small for N starves subtasks Raise K, or switch to amorphous
Carry-over Stale files from a previous run read as current context Archive environment/ and store/ to history/ on every start

Drift deserves one more sentence, because it is the least obvious. An agent that keeps its session history carries a narrow reading of the direction forward even after its neighbors move on. Starting every iteration with no conversational memory sounds wasteful. It is actually the control that keeps a thousand independent loops steerable. The only state an agent carries is what it reads back from the shared logs.

Composing clusters

The same decision works one level up: clusters coordinate by reading each other’s shared environment, the way agents read each other’s logs. We run a structure we call WeltenBuilder: a feature cluster implements against an agreed interface, a shared-infrastructure cluster owns common services, a QA cluster reads across the others and reports inconsistencies as artifacts. A coordinator cluster writes conflict-resolution notes the others pick up on their next iteration. A resolution note is a trace, not a command. Remove the coordinator and you remove a signal, not a dependency.

Because the shared environment is the coordination plane, all clusters launch at the same time with no dependency graph to sequence. Contract bottlenecks dissolve the same way: a small mesh cluster converges on interface definitions in a few iterations while other clusters build against its latest stable output. This is where the pattern points: standing clusters, each producing one class of artifact, composed into a factory whose unit of work is a direction file and a topology.

kiro-flock WeltenBuilder dashboard showing several specialized clusters running at once, each with its own algorithm and agent count, beside the shared environment tree on the right.

Figure 3. Multiple specialized clusters in the WeltenBuilder dashboard, each with its own algorithm and agent count, coordinating only through the shared S3 environment on the right.

Try it

The kiro-flock reference implementation is open source under Apache 2.0. It is a sample to study and adapt, not a production system.

One setup script provisions the stack with the AWS Cloud Development Kit (AWS CDK): Amazon S3 for the shared environment, Amazon EC2 for the agents, and AWS Lambda with Amazon API Gateway as a control plane behind a dashboard. The dashboard starts and stops clusters, changes the algorithm, and updates the direction mid-run. Amazon Cognito handles access, and Amazon Bedrock backs a post-run analysis that summarizes how the cluster converged.

You need an AWS account with the AWS CDK bootstrapped. Install kiro-cli and create a Kiro API key for headless mode (requires a Kiro subscription). Then:

cp install.config.template install.config   # set REGION and PROFILE
./setup.sh

Direct a cluster in plain language: “Start a flock of 8 agents to review the files in my project and suggest improvements.” The default runs 8 agents at radius 1 and converged in 5 to 7 iterations in our runs. Before wider use, scope each agent’s EC2 AWS Identity and Access Management (IAM) role, restrict security-group egress to the endpoints agents should call, and add AWS Budgets alerts.

Conclusion

The supervisor pattern remains the right default for bounded task trees, whether you build it with Strands, Kiro CLI subagents, or any of the coding agents that delegate this way. When the work decomposes into many independent contributions and diversity matters more than a central gate, moving coordination into shared state helps remove the throughput ceiling and the single point of failure in one move. The convergence math and the failure modes both follow from that decision, and the distributed-systems results they rest on have been known for decades. Deploy the sample, read the logs as a cluster converges, and decide where your own multi-agent workloads belong.

About the authors

Accelerate multiplayer game hosting with AWS m8azn instances

Post Syndicated from Spencer Myers original https://aws.amazon.com/blogs/compute/accelerate-multiplayer-game-hosting-with-aws-m8azn-instances/

Online multiplayer gaming continues to grow, with players demanding lower latency, higher concurrency, and more immersive experiences than ever before. For game studios hosting dedicated multiplayer servers on AWS, infrastructure decisions directly impact player experience and retention, server tick rates, and ultimately, revenue.

Games are becoming more computationally demanding while offering richer gameplay experiences. Studios need instances that maintain consistent player experiences in increasingly complex and dense computational game experiences.

In this post, we explore how AWS m8azn instances powered by AMD’s 5th gen EPYC processors perform with a real game: Mob Rush. M8azn instances offer up to 2x compute performance and 5 GHz CPU frequency compared to previous generation M5zn instances, and up to 24% higher performance than M8a instances. M8azn instances deliver up to 4.3x higher memory bandwidth and 10x larger L3 cache compared to M5zn instances allowing latency-sensitive and compute-intensive workloads to achieve results faster. These instances also offer up to 2x networking throughput and up to 3x EBS throughput versus M5zn instances. This post walks through the deployment of the game and reviews the performance metrics across varying player counts.

When to choose m8azn for multiplayer hosting

Not every workload requires m8azn. Game modes that require high performance and low latency computation are ideal matches for m8azn instances. M8azn instances are ideal for games that benefit from higher compute performance, larger L3 cache, and higher memory bandwidth.

Ideal use cases

  • Session-based high density multiplayer games: Games with discrete match sessions that spin up and tear down servers dynamically benefit from the fast startup performance of m8azn and high player density per instance.
  • Physics-intensive game servers: Titles relying heavily on PhysX collision detection, rigid-body simulation, and real-time raycast operations see significant gains from improved FPU throughput.
  • Variable player load scenarios: Live service games with daily peak hours or seasonal events benefit from the cost efficiency at both low and high utilization levels.
  • High-density hosting: Studios seeking to maximize concurrent game sessions per instance to reduce per-player infrastructure cost.

Mob Rush

In this post, we run the game Mob Rush. Mob Rush is a multiplayer game where players collect and grow a crowd in a war of numbers style competition. Mob Rush is built with the Unity game engine. Our test infrastructure includes a local test orchestrator, two game servers, and a series of load generation servers. The following diagram shows our testing setup:

Figure 1: Mob Rush Load Testing Diagram

Load testing configuration

Our load testing scenario compares the m5zn instance that our game currently runs on with the new m8azn to decide if the new instance is a migration candidate. We compare player experience metrics (FPS, tick-rate, and others) and instance performance metrics (CPU utilization, tick-rate, players per server, and others) to see how well Mob Rush runs on newer hardware.

Methodology

Benchmarks were conducted using a Unity multiplayer game server build, simulating concurrent player connections with synthetic load generation. Our current game servers perform well to around 4,000 simultaneous player connections before the player experience started to degrade as the server was overloaded. For our benchmarks we have tested each instance type at the 3,000 player threshold, and then increased to 4,000 players, 6,000 players and 8,000 players and recorded how each instance performed.

Parameter Configuration
Instance Types m8azn.xlarge (4 vCPU, 16 GB) vs. m5zn.xlarge (4 vCPU, 16GB)
OS / AMI Ubuntu 22.04 LTS
Unity Version Unity 2020.3.12f1, headless Linux build
Concurrency Scenarios Gradual ramp from zero players to number of players that overload the instance causing player experience impact
Metrics Collected Connection success rate, connection latency (avg/P50/P95/P99/max), batch processing time, run queue depth, context switches/second, softirq/second, TCP retransmits, listen overflows
Test Duration 562 seconds total (202 s ramp at 100 connections/sec + 360 s sustained hold)

Results

Our testing results are displayed in the following charts. The new m8azn instances start to shine as load increases. M5zn instances start to have significant latency spikes and max latency numbers once we get to around 6,000 CCU, which severely impacts the player experience. We can push the m8azn instances to 8,000 CCU before experiencing player impact or introducing any latency spikes >500ms.

Metric m5zn.2xlarge m8azn.2xlarge
Player Count 3,000
Average Latency 9.7ms 8ms
P99 Latency 22ms 28ms
Max Latency 43ms 23ms
Peak Run Queue 575 14
TCP Re-transmits 0 0
Latency Spikes > 500ms 0 0
Errors 0 0
Metric m5zn.2xlarge m8azn.2xlarge
Player Count 4,000
Average Latency 8.6ms 7.2ms
P99 Latency 29ms 24ms
Max Latency 76ms 29ms
Peak Run Queue 451 24
TCP Re-transmits 0 0
Latency Spikes > 500ms 0 0
Errors 0 0
Metric m5zn.2xlarge m8azn.2xlarge
Player Count 6,000
Average Latency 6.8ms 6.5ms
P99 Latency 22ms 22ms
Max Latency 29ms 27ms
Peak Run Queue 318 27
TCP Re-transmits 0 0
Latency Spikes > 500ms 0 0
Errors 0 0
Metric m5zn.2xlarge m8azn.2xlarge
Player Count 8,000
Average Latency 25ms 9.7ms
P99 Latency 542ms 27ms
Max Latency 2386ms 238ms
Peak Run Queue 651 87
TCP Re-transmits 0 0
Latency Spikes > 500ms 97 0
Errors 0 0

Price-performance comparison for 100k CCU

One methodology to calculating price/performance of these instances is to compare the cost of running enough instances to serve 100,000 players while maintaining an optimal and minimal latency player experience. All prices discussed in this section are based on us-east-1 OnDemand Linux pricing at the time of writing.

To serve 100k CCU with m5zn.xlarge instances, we would need to provision approximately 20 m5zn.xlarge instances (each instance can support 5,000 CCU before player experience degrades). Each m5zn.xlarge costs $0.3303/hr. That brings our hourly cost to $6.606/hr per 100k CCU.

In comparison, we only need 13 m8azn.xlarge instances to serve 100k CCU, thanks to the ~61% performance improvement of average latency of m8azn at 8,000 CCU per instance. Each m8azn.xlarge costs $0.4129/hr. Our hourly cost for 100k CCU in this scenario is $5.3677/hr. M8azn instances clearly demonstrate better price performance when compared to m5zn instances.

Conclusion

M8azn instances represent a compelling upgrade path for multiplayer game studios currently running on older generation instances. The combination of AMD EPYC processor improvements, enhanced memory bandwidth, and superior network performance delivers measurable benefits across the workloads that matter most for game hosting.

Try out m8azn in your development environment and calculate price/performance gains to see if m8azn is right for your workload. The Optimizing EC2: Hands-on Strategies for Cost-effective Performance workshop can guide you in comparing performance and calculating your overall price/performance savings across different instances.

Additional Resources

Uncover new performance insights using Amazon detailed performance statistics on Windows

Post Syndicated from Xinze Zhang original https://aws.amazon.com/blogs/compute/uncover-new-performance-insights-using-amazon-detailed-performance-statistics-on-windows/

The primary storage solutions for EC2 Windows instances, Amazon EC2 Instance Store and Amazon Elastic Block Store (Amazon EBS) , now provide detailed performance statistics for real-time monitoring. Real-time monitoring enables you to gain visibility into key performance metrics, such as latency, throughput, and IOPS, allowing you to detect and address potential bottlenecks or issues proactively.

In this post, we explore how to use detailed performance statistics for both Amazon EBS and Instance Storage on Windows environments. These new metrics provide sub-minute granularity, offering real-time visibility into storage volume performance across both storage types. You can access these statistics directly from your Amazon EBS NVMe/Amazon Instance Storage NVMe device attached to the Amazon Elastic Compute Cloud (Amazon EC2) instance and use them to monitor I/O performance at the storage level. We also provide examples of how to use these statistics to quickly assess EBS volume/Storage health and identify performance bottlenecks, which improve both the reliability and performance of your applications. When creating or attaching EBS volumes, enable encryption at rest using AWS Key Management Service (AWS KMS) to protect your data. For more information, see Amazon EBS encryption in the Amazon EC2 User Guide.

Solution overview

Using the new Amazon EC2 Instance Store/Amazon Elastic Block Store (Amazon EBS) detailed performance statistics at the instance-level, this sample solution enhances observability and troubleshooting capabilities for latency-sensitive applications running on EC2 Nitro instances. We use the new nvme_amzn.exe tool to collect high-frequency statistics on I/O operations, latency, and queue length, enabling proactive troubleshooting.

As examples of how to use these granular metrics, this solution demonstrates how to validate the responsiveness of local storage and EBS volume, so that you can quickly identify any I/O interruptions. This solution helps you identify storage performance bottlenecks, which can be used to optimize the local storage and EC2 instance configurations for your workloads.

Prerequisites

This solution involves setting up an EC2 Nitro instance and an attached local storage to access detailed performance statistics for the local storage. This is a setup you likely already have if using Amazon EC2. To deploy the required components, you must complete the following steps:

  1. Launch an EC2 Nitro instance (or use an existing Nitro instance), and connect to it via Remote Desktop Protocol (RDP).
  2. Verify that your EC2 Windows instance includes AWS NVMe driver version 1.7.0 or later installed by following identify your driver type
  3. Identify the NVMe device associated with the local storage/EBS volume for which you want to query the stats. You can run the Get-Disk command in PowerShell to output all NVMe devices on the instance. For more information, see Map NVMe disks on Amazon EC2 Windows instance to volumes.

For this demonstration, we’ll monitor two storage volumes:

  • EBS volume (Disk 0): Serial Number vol01234567890abcdef_00000001.
  • Local storage (Disk 1): Serial Number AWSEXAMPLE1234567890_00000001.
  1. Ensure that nvme_amzn.exe is present in C:\ProgramData\Amazon\Tools by default.
  2. Use the nvme_amzn.exe tool, with administrator privileges, and pass the disk number as a parameter with different command. The returned output looks like the following.

Administrator: Windows PowerShell:

.\nvme_amzn.exe --help or nvme_amzn.exe /help

Users can see the EBS volumes devices mapping by default without passing the disk number as a parameter

.\nvme_amzn.exe

Users can view the specific device mapping by passing disk numbers or a single disk number as a parameter.

.\nvme_amzn.exe 0 1 2 3 4

Users can see the nvme controller details by using id-ctrl and pass the disk number as a parameter (JSON output can be retrieved by providing the --json or /json parameter to the tool)

# EBS volume
.\nvme_amzn.exe id-ctrl 0

# EC2 local storage
.\nvme_amzn.exe id-ctrl 1

.\nvme_amzn.exe id-ctrl 0 --json

Users can see the performance statistics for EBS/EC2 local storage volume by using stats and pass the disk number as a parameter (provide the --json or /json parameter to retrieve JSON output).

# EBS volume
.\nvme_amzn.exe stats 0
# Json format
.\nvme_amzn.exe stats 0 --json

# EC2 Local storage volume
.\nvme_amzn.exe stats 1
# Json format
.\nvme_amzn.exe stats 1 --json

In addition, for EC2 local storage volume, by providing the --details/-d option, you can see the histogram of 5 different IO bands: (0, 512 Byte], (512B, 4KiB], (4KiB, 8KiB], (8KiB, 32KiB], (32 KiB, MAX].

.\nvme_amzn.exe stats 0 --details

The following example shows NVMe log output with cumulative statistics. The statistics indicate read/write operations, bytes transferred, and time spent processing operations (in microseconds). They also show the number of microseconds in which the application attempted to exceed the Amazon EBS or Amazon EC2 Instance Local Storage IOPS/throughput limits

EBS volume:

EC2 local storage volume:

Also included in the following figures are read and write I/O latency histograms, with each row representing the total number of I/O operations completed so far within a specific bin of time (in microseconds).

These statistics are presented as cumulative counters up to the time at which the command is executed. The command can be run at the desired interval, for example, every 15 seconds, with each subsequent output reflecting the updated cumulative totals for the metrics. Calculating the difference in the statistics across the last two outputs allows you to derive insight into the instance storage profile over the given 15 second period.

Deriving insights from the Amazon Instance Storage/EBS volume detailed performance statistics

You have set up monitoring using these detailed performance statistics, now we can demonstrate the different ways you can use these statistics.

As mentioned in the preceding section, you can use the detailed statistics to view I/O latency histograms to observe the spread of I/O latency within the period. You can use the read/write operations and time spent statistics to calculate the average latency. Using the detailed statistics allows you to view the average latency at a sub-minute granularity.

Here are four examples for you to use the statistics to shed light on key performance metrics.

Scenario 1: Identifying unresponsive state of an EBS volume

In this scenario, we discuss how to use Amazon EBS detailed performance statistics to observe when an EBS volume isn’t responding to I/O operations. If you observe multiple intervals where your volume is unresponsive, then you can take actions, such as replacing the affected volume or stopping and restarting the instance to which the volume is attached. In most cases, when your volume becomes unresponsive, Amazon EBS automatically diagnoses and recovers your volume within a few minutes.

To identify if your volume is unresponsive, you can use the following steps to determine whether I/O disrupted on your volume:

  1. Identify the EBS volume’s NVMe device to troubleshoot
  2. Collect stats for the device at the desired intervals
  3. Compare the stats to check if the EBS volume is unresponsive

Step 1: Identify the EBS volume’s NVMe device to troubleshoot

1. Identify the NVMe device associated with the EBS volume on the instance by using the nvme_amzn.exe tool.

.\nvme_amzn.exe

Step 2: Collect stats for the device at the desired intervals

1. Collect the Amazon EBS detailed performance statistics directly from the device by using the nvme_amzn.exe tool:

# EBS volume disk0
.\nvme_amzn.exe stats 0

Step 3: Compare the stats to check if the EBS volume is unresponsive

1. From the output, consider the following three fields for this scenario: Total Read Ops, Total Write Ops, and Queue Length.

2. Issue the same ebsnvme command after a desired interval (for example: after 15 seconds), so that you can compare how Total Read/Write I/Os have progressed at the Amazon EBS level.

3. From the detailed performance statistics collected approximately 15 seconds apart, we make the following key observations

  • Total Read Ops increased from 1421153 to 1423480, indicating 2327 Read operations completed in the 15 second span.
  • Total Write Ops increased from 13835137 to 13846338, indicating 11201 Read operations completed in the 15 second span.
  • Queue Length stayed between 0 and 6, indicating that the application was issuing I/Os to the EBS volume. If you see a gradual increase in the Queue Length, then it would reflect a buildup in queued I/Os.

This shows that the EBS volume is still driving I/Os that it is receiving, which rules out the EBS volume as the source of observed degradation in application performance. If we had seen an increase in the Queue Length along with 0 Read/Write Ops processed during the period, then it would reflect an unresponsive EBS volume.

If you would like to validate your mechanisms of identifying unresponsive EBS volumes, refer to the Conducting chaos engineering experiments on Amazon EBS using AWS Fault Injection Service blog post, which walks through how to set up an AWS Fault Injection Service Pause I/O experiment.

Scenario 2: Identifying bottlenecks in storage performance on EBS

Amazon EBS detailed performance statistics can also be used to configure the appropriate performance characteristics for your EBS volume and EC2 instance based on the performance needs of your application. The EBS Volume Performance Exceeded and EC2 Instance EBS Performance Exceeded statistics indicate the duration for which your workload consistently attempted to drive IOPS or throughput that is greater than your volume or your instance’s provisioned performance in a given period. Exceeding either the volume’s or instance’s provisioned performance can result in elevated latency on your workload. For this scenario, consider the same application as the one used in scenario 1.

Complete the following steps to check if EBS volume performance is correctly provisioned:

1. Select the EBS volume’s NVMe device to check
2. Collect stats for the device at the desired intervals
3. Compare the stats to check if the EBS volume is exceeding provisioned performance

Step 1. Select the EBS volume’s NVMe device to check

1. This step is the same as Step 1 discussed previously in scenario 1.

Step 2. Collect stats for the device at the desired intervals

1. Similar to Step 2 discussed in scenario 1, access the detailed performance statistics across two points in time.

2. Consider the EBS Volume Performance Exceeded and EC2 Instance EBS Performance Exceeded statistics from the EBS NVMe device.

$DiskNumber = 0
$Interval = 15

while ($true) {
    Write-Host "=== $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') ===" -ForegroundColor Cyan; & "C:\ProgramData\Amazon\Tools\nvme_amzn.exe" stats $DiskNumber
    Write-Host ""
    Start-Sleep -Seconds $Interval
}

Step 3: Compare the stats to check if the EBS volume is exceeding provisioned performance

1. In the following example output, you can see the EBS Volume Performance Exceeded statistic increasing by 26813772 microseconds. This shows the workload running on EBS volume vol-EXAMPLEabcd1234 has attempted to drive more IOPS than provisioned on the underlying EBS volume, which can impact the volume’s I/O latency. We recommend that you increase the performance of your volume to make sure that you have sufficient provisioned performance for your application’s needs.

2. In the following example output, driving a different workload on the instance allows us to see that the volume has exceeded the provisioned IOPS performance at the attached EC2 instance level. In this case, up-sizing to a larger instance size can improve the performance of your application.

3. A synthetic load generator for Oracle called Silly Little Oracle Benchmark (SLOB) could also be used to simulate workloads on Oracle databases, while monitoring the Amazon EBS statistics to see which volume or instance is becoming the bottleneck.

It’s important to have the right instance and volume configurations to avoid performance bottlenecks to your application. Refer to the EBS volume types documentation for more information on the different EBS volume types, and the Amazon EBS-optimized documentation to understand how to select the optimal combination of EC2 instance and EBS volume suited for your application. These statistics are available at up to a one-second granularity, which allows you to effectively perform these checks in real-time and initiate volume modifications to optimize volume characteristics as needed.

Scenario 3: Identifying bottlenecks in storage performance on instance storage volume

Amazon Instance Storage detailed performance statistics can be used to configure the appropriate performance characteristics for your application. The “EC2 Instance local storage Performance Exceeded” statistics indicate the duration for which your workload consistently attempted to drive IOPS or throughput that is greater than your rate limit in a given period. Exceeding the throttle value can result in elevated latency on your workload.

For example, i3en.xlarge can support up to 85,000 read IOPS, 65,000 write IOPS, 634,765 KiB/S for read and 317,382 KiB/S for write. By using the detailed IO metrics, you can more efficiently determine if the instance meets your requirements.

Complete the following steps to check if the device meets your application needs:

  1. Select the instance storage device to check.
  2. Collect stats for the device at the desired intervals
  3. Compare the stats to check if the instance storage is exceeding the throttled value

Step 1. Select the Instance Storage NVMe device to check

Use the nvme_amzn tool and identify the NVMe device associated with the instance storage.

Step 2: Collect stats for the device at the desired intervals

$DiskNumber = 0
$Interval = 15

while ($true) {
    Write-Host "=== $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') ===" -ForegroundColor Cyan; & "C:\ProgramData\Amazon\Tools\nvme_amzn.exe" stats $DiskNumber
    Write-Host ""
    Start-Sleep -Seconds $Interval
}

Step 3: Compare the stats to check if the instance storage is exceeding throttle value

Take the following scenario as an example. At the very beginning, after the instance launch, both the IOPS and Throughput under “EC2 Instance local storage Performance Exceeded (us)” are 0s.

You start your applications and find that the application write does not meet your expectation. You can check the IO metrics afterwards. You see a lot of IO falls into the 1 ms to 2 ms range, which is unexpected.

By further checking the “EC2 Instance local storage Performance Exceeded (us)”. You found that the IO reached the allowed upper limit for up to 8 seconds, which indicates the i3en.xlarge would not meet your expectations. Select a larger instance size to address this.

It’s important to have the right instance size to avoid performance bottlenecks to your application. Refer to the ec2-instance-type-specifications documentation for more information on the different instance storage size to understand how to select the optimal instance size suited for your application. This tool helps you to effectively perform these checks in real-time.

Scenario 4: Identifying which block size caused the long latency on instance storage volume

You may have a mixed workload:

  • Data (either read or write) pattern with different block sizes like 4K and 128K.
  • Mixed read and write data pattern.

By using the --detail/-d switch from the NVMe CLI, you can identify the issue quickly and readjust the workload.

Example 1: High write latency from a workload

By further looking at the histogram of the block size range larger than 32 KiB, you can see that the larger IO caused high application latency, while other block sizes (like 8K) show no latency abnormality.

Example 2: Mixed read and write traffic

Some users will have a mix of read and write traffic. For example, some applications will do light read traffic (for example to read out some metadata) and heavy write. This may inadvertently impact the read latency. For example, an application is doing a read operation with a single IO of small block size. However, the user experiences high read latency. Examining the histogram breakdown, you could reasonably believe the heavy larger IO write may interfere with the read.

The detailed IO histogram for IO size larger than 512B but less than or equal to 4KB

The detailed IO histogram for IO size larger than 32 KiB

The user should consider smoothing out the write pattern to alleviate the read latency.

Cleaning up

If you created an EC2 instance and EBS volume for this exercise, then terminate and delete the appropriate instance and volumes to avoid future costs.

Conclusion

In this post, we presented a solution for accessing high-resolution performance statistics for Amazon EBS volumes and EC2 Instance Store at the instance level. These detailed metrics provide a real-time view into your underlying storage performance at sub-minute granularity, helping you to quickly root cause disruptions to your applications.

This approach also helps you identify performance bottlenecks caused by workloads exceeding your provisioned IOPS or throughput limits on Amazon EC2, EBS volumes, or EC2 Instance Store. Combined with Amazon CloudWatch metrics, which provide volume-level insights at one-minute granularity, these tools help give you the visibility you need to confidently diagnose and resolve storage-related performance issues.

AWS Weekly Roundup: Claude Sonnet 5 on AWS, Amazon WorkSpaces for AI agents, AWS service availability updates, and more (July 6, 2026)

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-claude-sonnet-5-on-aws-amazon-workspaces-for-ai-agents-aws-service-availability-updates-and-more-july-6-2026/

A couple of editions ago I wrote about what I find so energizing about working with startups. Last week I got a fresh dose of it: I spent a few days with the AWS Startups team, listening to stories of founders talking about the problems they’re actually solving. One story that stayed with me came from Marco Negreiros, founder of EyeCare Health, a Brazilian healthtech expanding access to eye care. He shared a striking fact: more than 70% of Brazilian municipalities don’t have a single ophthalmologist. His answer was to put a vision test on the one device almost everyone already carries, the smartphone, so a basic eye screening no longer depends on living near a clinic. Watching a founder turn a gap that big into something that concrete is exactly why I love this space.

AWS Startups team get-together with founders in Brazil

This week, I’ll take a closer look at some key launches, and then cover the quarterly AWS Service Availability updates.

Last week’s launches
Here are some of the launches covered from this past week in the AWS News Blog:

Here are some launches and updates that caught my attention:

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

AWS Service Availability Updates
When the availability of an AWS service or feature changes, we provide customers guidance in AWS Product Lifecycle Changes on available alternatives and support for migration so that disruptions to your operations are minimized. The following lifecycle changes were updated on June 30, 2026.

Services moving to Maintenance (no longer accessible to new customers starting July 30, 2026):

Services entering Sunset:

Services reaching End of Support (as of June 30, 2026):

  • Amazon Chime SDK – Carrier Voice Focus
  • Amazon SageMaker AI – Ground Truth Plus

We understand that changes in availability can impact your operations. For specific guidance, consult the relevant service documentation or contact AWS Support.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

  • AWS Summits – AWS Summits are free events that bring the cloud and AI community together to connect, learn, and explore the latest technologies. Browse the full calendar to find a Summit near you in the second half of 2026.
  • AWS Community Days – Community-led conferences where content is planned, sourced, and delivered by community leaders. If you’re in Latin America, don’t miss AWS Community Day Belo Horizonte on August 22. Registration is open at awscommunityday.com.br.

Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

– Daniel Abib

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

Amazon EC2 C9g and C9gd instances powered by AWS Graviton5 processors are now available

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/amazon-ec2-c9g-and-c9gd-instances-powered-by-aws-graviton5-processors-are-now-available/

When you run compute-intensive workloads like real-time analytics, batch processing, video encoding, scientific modeling, or CPU-based machine learning inference, every percentage point of performance matters. You need instances that deliver higher throughput per vCPU, faster memory access, and more network bandwidth, all while keeping your costs in check.

Today I am happy to announce the general availability of Amazon Elastic Compute Cloud (Amazon EC2) C9g and C9gd instances, powered by AWS Graviton5 processors. C9g instances are compute-optimized and deliver up to 25% higher performance per vCPU compared to previous-generation C8g instances. They feature the fastest memory of any processor instance in the cloud, with DDR5 8800MT/s DIMMs, 5x more L3 cache, and up to 3x higher packet-processing performance compared to Graviton4-based instances. The faster memory and larger caches mean your workloads spend less time waiting on data, translating into higher throughput for in-memory analytics, faster agentic loops, and more responsive real-time applications.

C9g instances are ideal for batch jobs, video encoding pipelines, or distributed analytics that can utilize Amazon Elastic Block Store (Amazon EBS) for storage. It is also a natural fit for agentic AI workloads, where concurrent environments and CPU-bound reasoning steps benefit from Graviton5’s higher core count and larger caches. As AI shifts from answering questions to taking actions, running code, and orchestrating multi-step tasks, the demand for CPU compute is growing, and C9g instances are built for this shift.

Some workloads also need fast local storage alongside that compute power. Choose C9gd when your application benefits from high-speed, low-latency local NVMe SSD storage, for example scratch space during HPC simulations, temporary caches for ML inference, or local buffers for ad-serving engines.

Graviton5-based instances with NVMe instance store volumes also support detailed performance statistics, providing high-resolution I/O metrics, including latency histograms broken down by I/O size, up to 1-second granularity and accessible via Amazon CloudWatch or nvme-cli at no additional cost.

C9g and C9gd instances at a glance
C9g and C9gd instances are available in 11 sizes ranging from medium to 48xlarge, plus a bare metal option. They offer up to 15% higher network bandwidth and 20% higher EBS bandwidth on average across sizes compared to the previous generation, with the largest 48xlarge size delivering up to 100 Gbps of network bandwidth and up to 72 Gbps of EBS bandwidth, a 2x increase.

C9g vCPUs Memory
(GiB)		 Network Bandwidth
(Gbps)		 EBS Bandwidth
(Gbps)
medium 1 2 Up to 15 Up to 12
large 2 4 Up to 15 Up to 12
xlarge 4 8 Up to 15 Up to 12
2xlarge 8 16 Up to 17 Up to 12
4xlarge 16 32 Up to 17 Up to 12
8xlarge 32 64 17 12
12xlarge 48 96 25 18
16xlarge 64 128 34 24
24xlarge 96 192 50 36
48xlarge 192 384 100 72
metal-48xl 192 384 100 72

C9gd instances add local NVMe SSD storage with up to 30% higher storage performance compared to previous-generation local storage instances.

C9gd vCPUs Memory
(GiB)		 Instance Storage
(GB)		 Network Bandwidth
(Gbps)		 EBS Bandwidth
(Gbps)
medium 1 2 1 x 59 Up to 15 Up to 12
large 2 4 1 x 118 Up to 15 Up to 12
xlarge 4 8 1 x 237 Up to 15 Up to 12
2xlarge 8 16 1 x 474 Up to 17 Up to 12
4xlarge 16 32 1 x 950 Up to 17 Up to 12
8xlarge 32 64 1 x 1900 17 12
12xlarge 48 96 3 x 950 25 18
16xlarge 64 128 1 x 3800 34 24
24xlarge 96 192 3 x 1900 50 36
48xlarge 192 384 3 x 3800 100 72
metal-48xl 192 384 3 x 3800 100 72

Both families are well-suited for high-performance computing (HPC), batch processing, gaming, video encoding, scientific modeling, distributed analytics, CPU-based machine learning inference, and ad serving.

Here are some additional capabilities:

  • Instance Bandwidth Configuration (IBC) lets you adjust the allocation of bandwidth between Amazon EBS and Amazon VPC networking by up to 25%, helping you optimize performance for workloads with specific bandwidth requirements such as databases and caching.
  • ENA Express support for enhanced networking.
  • Up to 128 EBS volumes can be attached to virtual instances.
  • Support for Savings Plans, On-Demand, Spot Instances, Dedicated Instances, and Dedicated Hosts.

Nitro Isolation Engine
C9g and C9gd instances are the first compute optimized Amazon EC2 instances to feature the AWS Nitro Isolation Engine, a new capability of the AWS Nitro System. The Nitro Isolation Engine is a purpose-built component of the Nitro Hypervisor, implemented in Rust, that enforces isolation between virtual machines. It mediates all access to VM memory, CPU register state, and I/O devices through a minimal set of APIs.

To learn more about the Nitro Isolation Engine, visit the blog post. For details on the formal verification results, including scope and assumptions, see our technical white paper.

Now available
Amazon EC2 C9g and C9gd instances are now available in US East (Ohio, N. Virginia), US West (Oregon), and Europe (Frankfurt). Additional regions will follow.

You can launch C9g and C9gd instances today using the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDKs. For pricing information, visit the Amazon EC2 Pricing page.

To learn more, visit the Amazon EC2 C9g and C9gd instances page and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— seb

Maximize Amazon EC2 Capacity Reservations with Capacity Manager data exports

Post Syndicated from Venu Geddam original https://aws.amazon.com/blogs/compute/maximize-amazon-ec2-capacity-reservations-with-capacity-manager-data-exports/

In our previous post, we introduced Amazon EC2 Capacity Manager and its data export capability. Amazon EC2 Capacity Manager provides centralized visibility into your Amazon Elastic Compute Cloud (Amazon EC2) capacity usage across all accounts and Regions in your organization. It tracks capacity usage for three types of EC2 capacity: On-Demand instances, Spot instances, and On-Demand Capacity Reservations (ODCR). On the AWS Management Console, it provides 90 days of historical capacity data. With data exports to Amazon Simple Storage Service (Amazon S3), you can retain and analyze capacity trends beyond this period using your preferred analytics tools.

In this post, we demonstrate how to configure EC2 Capacity Manager data exports to Amazon S3 and query historical capacity data using Amazon Athena. This approach helps you identify long-term usage patterns, plan capacity needs, and optimize resource allocation across your organization.

Solution overview

The following diagram illustrates the solution architecture. EC2 Capacity Manager exports capacity data to Amazon S3, where Amazon Athena queries it using SQL with automatic partition discovery.

Architecture diagram showing EC2 Capacity Manager exporting capacity data to Amazon S3 on a scheduled basis, and Amazon Athena querying the data directly from S3 using SQL with partition projection for automatic partition discovery

The solution involves the following steps:

  1. Set up an S3 bucket for capacity data export.
  2. Configure EC2 Capacity Manager data export.
  3. Set up Amazon Athena to query the exported data.
  4. Run queries to analyze capacity patterns.

Prerequisites:

  • An AWS account with permissions to create S3 buckets and configure EC2 Capacity Manager.
  • AWS Command Line Interface (AWS CLI) installed and configured (optional, for CLI-based setup).
  • Familiarity with SQL for querying data in Athena.

Setting up data export to Amazon S3

EC2 Capacity Manager can export capacity data in compressed CSV (Gzip) or compressed Parquet (Snappy) format. Use Parquet format for query performance in Athena (Parquet’s columnar format is designed to optimize analytical queries).

Configure the data export

You can configure data export through the EC2 Capacity Manager console or AWS CLI.

To configure data export using the console:

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. In the navigation pane, choose Capacity Manager.
  3. Choose the Data exports tab.
  4. Choose Create data export.
  5. For Output format, select Parquet.
  6. For S3 bucket, choose Create bucket for me to create a new bucket with the required permissions, or select an existing bucket from the list.
  7. If you selected an existing bucket, add the bucket policy shown in the following section to grant EC2 Capacity Manager write access.
  8. (Optional) For S3 prefix, enter a prefix to organize your exported files (for example, capacity-data/).
  9. For Schedule, select Hourly.
  10. Choose Create.

Screenshot of EC2 Capacity Manager Create data export page in AWS Console showing export properties: Data export name, output format set to Parquet, S3 location for export delivery and Tags

After you create the data export, EC2 Capacity Manager displays the export details.

Screenshot showing EC2 Capacity Manager data export status with ‘Latest Delivery’ column displaying ‘delivered’ status, indicating the export is ready for Athena setup

Update the S3 bucket policy (existing buckets only)

If you use an existing S3 bucket, you must add the bucket policy shown in the following example to grant EC2 Capacity Manager write access.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.capacitymanager.amazonaws.com"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<BUCKET_NAME>",
                "arn:aws:s3:::<BUCKET_NAME>/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "<AWS_ACCOUNT_NUMBER>"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:ec2:<AWS_REGION>:<AWS_ACCOUNT_NUMBER>:capacity-manager-data-export/*"
                }
            }
        }
    ]
}

Replace <AWS_ACCOUNT_NUMBER> with your AWS account number, <AWS_REGION> with your AWS Region (for example, us-west-2), and <BUCKET_NAME> with your bucket name.

To configure data export using the AWS CLI :

aws ec2 create-capacity-manager-data-export \
    --s3-bucket-name <BUCKET_NAME> \
    --s3-bucket-prefix <BUCKET_PREFIX>/ \
    --schedule hourly \
    --output-format <FORMAT> \
    --region <AWS_REGION>

# Replace:
# <BUCKET_NAME> with your bucket name,
# <BUCKET_PREFIX> with your bucket prefix (for example, capacity-data/),
# <FORMAT> with parquet or csv, and
# <AWS_REGION> with your AWS Region (for example, us-west-2)

# The output of the above command would give you a Data Export ID

{ "CapacityManagerDataExportId": "cmde-00a7d0e64e43889f1" }

After creating the data export, wait for the first export to complete before proceeding to set up Athena. You can check the export status using the following command:

aws ec2 describe-capacity-manager-data-exports --region <AWS_REGION>

The command returns details about your data export configuration, including the delivery status:

{
    "CapacityManagerDataExports": [
        {
            "CapacityManagerDataExportId": "cmde-00a7d0e64e43889f1",
            "S3BucketName": "capacity-manager-exports-123456789012",
            "S3BucketPrefix": "capacity-data/",
            "Schedule": "hourly",
            "OutputFormat": "parquet",
            "CreateTime": "2026-04-10T19:04:36.824000+00:00",
            "LatestDeliveryStatus": "delivered",
            "LatestDeliveryStatusMessage": "Successfully delivered to s3://capacity-manager-exports-123456789012/y=2026/m=04/d=10/h=15/...",
            "LatestDeliveryTime": "2026-04-10T19:05:39.176000+00:00"
        }
    ]
}

Wait until LatestDeliveryStatus shows "delivered" before proceeding to the next section. The first export typically appears in your S3 bucket in a couple of hours. Subsequent exports follow your configured schedule.

Setting up Amazon Athena to query capacity data

After EC2 Capacity Manager exports data to your S3 bucket, you can use Amazon Athena to query the data using standard SQL. Athena uses AWS Glue as its metadata store. Specifically, it relies on the AWS Glue Data Catalog, which contains table definitions that tell Athena where you have stored your data in S3 and how you have structured it. When you create tables in Athena, you’re actually creating metadata entries in the Data Catalog that Athena references when running queries.

Create an Athena database and table

You can create the table using AWS Glue crawler or manually with SQL. AWS Glue crawler automatically discovers the complete schema from your exported Parquet files, including optional fields like resource tags if enabled. It helps minimize manual schema definition efforts. If the export format changes in the future, you can re-run the crawler to update the table definition. For detailed instructions on creating a Glue Crawler, see Use a crawler to add a table in the Amazon Athena User Guide.

In this post, we create the table manually using a SQL statement. We also use partition projection for automatic partition discovery. We do this because EC2 Capacity Manager continuously adds new partitions to the S3 bucket according to your configured schedule. As new partitions arrive in S3, Athena doesn’t know about them until you run MSCK REPAIR TABLE or ALTER TABLE ADD PARTITION to update the AWS Glue Data Catalog. This becomes an overhead when data arrives frequently.

With partition projection, you define the partition scheme and specify its range/rules in the table properties. Athena then computes the partitions at query time instead of looking them up in the Glue Data Catalog. So partition projection automatically makes new partitions visible as soon as EC2 Capacity Manager exports the data to S3, eliminating the need for you to update metadata. The CREATE TABLE statement that follows defines the schema for EC2 Capacity Manager exports. If your capacity reservations are already tagged, add the corresponding tag columns (for example, tag_environment string or tag_costcenter string). Alternatively, use an AWS Glue crawler to automatically discover your complete schema, including tag columns.

  1. Open the Athena console at https://console.aws.amazon.com/athena/
  2. If prompted, configure a query result location in S3. This is where Athena writes query output. It is separate from the S3 bucket that stores your capacity data.
  3. Run the following query to create a database:
CREATE DATABASE IF NOT EXISTS capacity_manager_db;
  1. Create a table for Parquet format data:
CREATE EXTERNAL TABLE IF NOT EXISTS capacity_manager_db.capacity_data (
    metricgroupname string,
    periodstarttimestamp string,
    periodendtimestamp string,
    orgid string,
    accountid string,
    region string,
    `az-id` string,
    instancefamily string,
    instancetype string,
    platform string,
    tenancy string,
    reservationid string,
    `reservation arn` string,
    unusedfinancialowner string,
    reservationtype string,
    instancematchcriteria string,
    reservationcreatetimestamp string,
    reservationstarttimestamp string,
    reservationendtimestamp string,
    reservationenddatetype string,
    reservationstate string,
    reservationtotalcapacityhrsvcpu string,
    reservationtotalcapacityhrsinst string,
    reservationtotalestimatedcost string,
    reservationmaxsizevcpu string,
    reservationmaxsizeinst string,
    reservationminsizevcpu string,
    reservationminsizeinst string,
    reservationunusedtotalcapacityhrsvcpu string,
    reservationunusedtotalcapacityhrsinst string,
    reservationunusedtotalestimatedcost string,
    reservationmaxunusedsizevcpu string,
    reservationmaxunusedsizeinst string,
    reservationminunusedsizevcpu string,
    reservationminunusedsizeinst string,
    reservationmaxutilization string,
    reservationminutilization string,
    reservationavgutilizationvcpu string,
    reservationavgutilizationinst string,
    reservationavgfuturesizevcpu string,
    reservationavgfuturesizeinst string,
    reservationmaxfuturesizevcpu string,
    reservationmaxfuturesizeinst string,
    reservationminfuturesizevcpu string,
    reservationminfuturesizeinst string,
    reservationavgcommittedsizevcpu string,
    reservationavgcommittedsizeinst string,
    reservationmaxcommittedsizevcpu string,
    reservationmaxcommittedsizeinst string,
    reservationmincommittedsizevcpu string,
    reservationmincommittedsizeinst string,
    reservedtotalusagehrsvcpu string,
    reservedtotalusagehrsinst string,
    unreservedtotalusagehrsvcpu string,
    unreservedtotalusagehrsinst string,
    reservedtotalestimatedcost string,
    unreservedtotalestimatedcost string,
    spottotalusagehrsvcpu string,
    spottotalusagehrsinst string,
    spottotalestimatedcost string,
    spotavgruntimebeforeinterruptioninst string,
    spotmaxruntimebeforeinterruptioninst string,
    spotminruntimebeforeinterruptioninst string,
    spottotalinterruptionsinst string,
    spottotalinterruptionsvcpu string,
    spottotalcountinst string,
    spottotalcountvcpu string,
    spotinterruptionrateinst string,
    spotinterruptionratevcpu string
)
PARTITIONED BY (
    y string,
    m string,
    d string,
    h string
)
ROW FORMAT SERDE
    'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
    'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat'
OUTPUTFORMAT
    'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
    's3://<BUCKET_NAME>/'
TBLPROPERTIES (
    'projection.enabled' = 'true',
    'projection.y.type' = 'integer',
    'projection.y.range' = '2024,2030',
    'projection.y.digits' = '4',
    'projection.m.type' = 'integer',
    'projection.m.range' = '01,12',
    'projection.m.digits' = '2',
    'projection.d.type' = 'integer',
    'projection.d.range' = '01,31',
    'projection.d.digits' = '2',
    'projection.h.type' = 'integer',
    'projection.h.range' = '00,23',
    'projection.h.digits' = '2',
    'storage.location.template' = 's3://<BUCKET_NAME>/y=${y}/m=${m}/d=${d}/h=${h}/'
);

Replace <BUCKET_NAME> in the LOCATION clause and storage.location.template property with your bucket name, and capacity-data/ with table name of your choice.

Now that your table is set up, you can explore how to query the exported data.

Example queries for common use cases

The following queries demonstrate how to analyze your EC2 capacity data for cost optimization and capacity planning. The queries use date values (year=‘2026’, month=‘04’) and table name capacity_data. Adjust the partition values to match your actual data’s time period and table name to match your value. When querying EC2 Capacity Manager export data:

  1. Metric group filtering: EC2 Capacity Manager exports contain two types of data that the metricgroupname column identifies: Reservation Usage for analyzing ODCR utilization and optimization opportunities, and Instance Usage for analyzing overall capacity consumption across reserved, unreserved, and Spot instances. Always filter by the appropriate metric group for your analysis needs.
  2. Partition filtering: Always include partition filters (y, m, d, h) to improve query performance.
  3. Numeric operations: Use CAST to convert string columns to numeric types for proper comparison and sorting (for example, CAST(reservationavgutilizationinst AS double)).
  4. NULL handling: Use COALESCE to handle NULL values in calculations (for example, COALESCE(CAST(column AS double), 0)) to prevent NULL results in totals. Without COALESCE, when you add a column value NULL to a non-NULL value, the result is NULL.

Use case 1: Identify underutilized ODCRs

Discover On-Demand Capacity Reservations with low utilization that are generating cost waste. Identify specific reservations to downsize, cancel, or share with other teams to reduce unnecessary spending.

SELECT
    reservationid,
    instancetype,
    region,
    "az-id",
    reservationstate,
    ROUND(CAST(reservationavgutilizationinst AS double) * 100, 2) AS utilization_pct,
    CAST(reservationtotalcapacityhrsinst AS double) AS total_capacity_hrs,
    CAST(reservationunusedtotalcapacityhrsinst AS double) AS unused_capacity_hrs,
    ROUND(CAST(reservationunusedtotalestimatedcost AS double), 4) AS wasted_cost_usd
FROM capacity_data
WHERE metricgroupname = 'Reservation Usage'
    AND CAST(reservationavgutilizationinst AS double) < 0.5
    AND reservationavgutilizationinst IS NOT NULL
    AND y = '2026'
    AND m = '04'
ORDER BY wasted_cost_usd DESC
LIMIT 3;

Sample output:

reservationid instancetype region az-id reservationstate utilization_pct total_capacity_hrs unused_capacity_hrs wasted_cost_usd
cr-041aedfba865106c1 m5.8xlarge us-west-2 usw2-az2 active 0 1 1 1.536
cr-089f17dc178e993a8 m5.8xlarge us-west-2 usw2-az1 active 0 1 1 1.536
cr-089f17dc178e993a8 m5.8xlarge us-west-2 usw2-az1 active 0 1 1 1.536

Use case 2: ODCR utilization summary by instance type

Get a comprehensive view of ODCR utilization across instance types to identify which instance families have the worst utilization rates. This helps prioritize optimization efforts on the reservations with the highest cost impact.

SELECT
    instancetype,
    COUNT(DISTINCT accountid) AS account_count,
    COUNT(DISTINCT reservationid) AS reservation_count,
    ROUND(SUM(COALESCE(CAST(reservationtotalcapacityhrsinst AS double), 0)), 2) AS total_odcr_capacity,
    ROUND(SUM(COALESCE(CAST(reservationunusedtotalcapacityhrsinst AS double), 0)), 2) AS total_unused_capacity,
    ROUND(AVG(COALESCE(CAST(reservationavgutilizationinst AS double), 0)) * 100, 2) AS avg_utilization_pct,
    ROUND(SUM(COALESCE(CAST(reservationunusedtotalestimatedcost AS double), 0)), 2) AS total_unused_cost_usd
FROM capacity_data
WHERE metricgroupname = 'Reservation Usage'
    AND y = '2026'
    AND m = '04'
GROUP BY instancetype
ORDER BY total_unused_cost_usd DESC
LIMIT 3;

Sample output:

instancetype account_count reservation_count total_odcr_capacity total_unused_capacity avg_utilization_pct total_unused_cost_usd
m5.8xlarge 1 2 311.99 311.99 0.0 479.22
c5.9xlarge 1 1 211.0 211.0 0.0 322.83
t3.micro 1 1 1055.0 1055.0 0.0 10.97

Use case 3: Identify peak usage patterns

Analyze average hourly usage patterns across reserved, unreserved, and Spot capacity to identify when your workloads typically hit peak demand. This breakdown helps you understand your capacity mix, plan for peak periods, and optimize your purchasing strategy.

SELECT
    h AS hour,
    ROUND(AVG(COALESCE(CAST(reservedtotalusagehrsinst AS double), 0)), 2) AS avg_reserved_usage_hours,
    ROUND(AVG(COALESCE(CAST(unreservedtotalusagehrsinst AS double), 0)), 2) AS avg_unreserved_usage_hours,
    ROUND(AVG(COALESCE(CAST(spottotalusagehrsinst AS double), 0)), 2) AS avg_spot_usage_hours,
    ROUND(AVG(COALESCE(CAST(reservedtotalusagehrsinst AS double), 0) + COALESCE(CAST(unreservedtotalusagehrsinst AS double), 0) + COALESCE(CAST(spottotalusagehrsinst AS double), 0)), 2) AS avg_total_usage_hours
FROM capacity_data
WHERE metricgroupname = 'Instance Usage'
    AND y = '2026'
    AND m = '04'
GROUP BY h
ORDER BY avg_total_usage_hours DESC
LIMIT 3;

Sample output:

hour avg_reserved_usage_hours avg_unreserved_usage_hours avg_spot_usage_hours avg_total_usage_hours
09 0.75 0.5 0 1.25
10 0.75 0.5 0 1.25
15 0.75 0.5 0 1.25

Use case 4: Regional capacity distribution

Understand how your ODCR capacity is distributed across AWS Regions and instance types. This geographic view helps you identify Regions with excess capacity that could be redistributed or consolidated to improve utilization and reduce costs.

SELECT
    region,
    instancetype,
    ROUND(SUM(COALESCE(CAST(reservationtotalcapacityhrsinst AS double), 0)), 2) AS total_reserved_capacity,
    ROUND(SUM(COALESCE(CAST(reservationunusedtotalcapacityhrsinst AS double), 0)), 2) AS unused_reserved_capacity,
    ROUND(AVG(COALESCE(CAST(reservationavgutilizationinst AS double), 0)) * 100, 2) AS avg_utilization_pct
FROM capacity_data
WHERE metricgroupname = 'Reservation Usage'
    AND y = '2026'
    AND m = '04'
GROUP BY region, instancetype
ORDER BY region, total_reserved_capacity DESC
LIMIT 3;

Sample output:

region instancetype total_reserved_capacity unused_reserved_capacity avg_utilization_pct
us-west-2 t2.nano 1484.0 1060.0 33.34
us-west-2 t3.micro 1060.0 1060.0 0.0
us-west-2 t2.micro 848.0 636.0 25.0

Use case 5: Unused capacity reservations by Region and Availability Zone

Pinpoint exactly where you have unused ODCR capacity at the Availability Zone level. This granular view enables you to share unused capacity with other teams in the same AZ or modify reservations to better match actual usage patterns.

SELECT
    region,
    "az-id",
    instancetype,
    ROUND(SUM(COALESCE(CAST(reservationunusedtotalcapacityhrsinst AS double), 0)), 2) AS unused_capacity_instances,
    ROUND(AVG(COALESCE(CAST(reservationavgutilizationinst AS double), 0)) * 100, 2) AS avg_utilization_pct,
    ROUND(SUM(COALESCE(CAST(reservationunusedtotalestimatedcost AS double), 0)), 2) AS unused_cost_usd
FROM capacity_data
WHERE metricgroupname = 'Reservation Usage'
    AND y = '2026'
    AND m = '04'
    AND CAST(reservationunusedtotalcapacityhrsinst AS double) > 0
GROUP BY region, "az-id", instancetype
ORDER BY unused_cost_usd DESC
LIMIT 3;

Sample output:

region az-id instancetype unused_capacity_instances avg_utilization_pct unused_cost_usd
us-west-2 usw2-az1 c5.9xlarge 212.0 0.0 324.36
us-west-2 usw2-az2 m5.8xlarge 157.0 0.0 241.15
us-west-2 usw2-az1 m5.8xlarge 157.0 0.0 241.15

Clean up

To avoid incurring future charges, delete the resources you created:

Warning: This permanently deletes the table definition. Verify that you no longer need to query this data before proceeding.

  1. Delete the Athena table by running the following query: DROP TABLE IF EXISTS capacity_manager_db.capacity_data;
  2. Delete the database by running the following query: DROP DATABASE IF EXISTS capacity_manager_db;
  3. Navigate to the Athena console settings.
  4. Note the query result location S3 bucket.
  5. If you created this bucket specifically for this tutorial:
    1. Empty the S3 bucket by running: aws s3 rm s3://<QUERY_RESULT_BUCKET_NAME> --recursive
    2. Delete the S3 bucket by running: aws s3 rb s3://<QUERY_RESULT_BUCKET_NAME>
  6. Delete the data export configuration by using AWS Management Console or AWS CLI.
    1. If using AWS Console, select the “Delete data export” option in the Actions menu.

Screenshot of AWS Management Console showing the Delete option in the Actions menu for an EC2 Capacity Manager data export configuration

  1. To delete the configuration using AWS CLI: 
    # List your data export configurations to find the export ID.
aws ec2 describe-capacity-manager-data-exports --region <AWS_REGION>

# The output shows details for export configuration which has the Data Export ID
# Sample output is shown in the configure data export section above.

# Then delete the export configuration using the ID from the output
aws ec2 delete-capacity-manager-data-export \
    --data-export-id <EXPORT_ID> \
    --region <AWS_REGION>

    Replace <EXPORT_ID> with your data export ID and <AWS_REGION> with your AWS Region.

    Warning: Deleting the S3 bucket permanently removes all exported capacity data. Verify that you have backed up any data you need before proceeding.

  1. (Optional) Delete the S3 bucket and data: If you no longer need the exported data, complete the following steps:
    1. Empty the S3 bucket by running: aws s3 rm s3://<BUCKET_NAME> --recursive
    2. Delete the S3 bucket by running: aws s3 rb s3://<BUCKET_NAME>

Conclusion

In this post, we demonstrated how to configure EC2 Capacity Manager data exports to Amazon S3 and query historical capacity data using Amazon Athena. This approach enables you to retain capacity data beyond the 90-day console limit.

As you scale your capacity management practices, consider integrating these exports with your existing analytics and monitoring workflows. By combining EC2 Capacity Manager data with your broader infrastructure metrics, you can make data-driven decisions about capacity allocation and optimization across your organization.

To deepen your understanding, explore the EC2 Capacity Manager documentation for additional features, learn more about Amazon Athena for advanced query capabilities, and review EC2 capacity optimization best practices. Share your feedback and tell us how you’re using EC2 Capacity Manager data exports to optimize your capacity planning in the comments.

Announcing Amazon EC2 G7 instances accelerated by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/aws/announcing-amazon-ec2-g7-instances-accelerated-by-nvidia-rtx-pro-4500-blackwell-server-edition-gpus/

Today, we’re announcing the general availability of Amazon Elastic Compute Cloud (Amazon EC2) G7 instances, delivering high performance GPU acceleration for AI inference, graphics, and data analytics workloads.

AWS is the first major cloud provider to support NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs. G7 instances are accelerated by these GPUs with custom sixth-generation Intel Xeon Scalable processors, delivering up to 4.6x AI inference performance and up to 2.1x graphics performance compared to G6 instances. G7 instances also deliver faster performance for GPU-accelerated analytics on Amazon EMR on Amazon Elastic Kubernetes Service (Amazon EKS). G7 instances are well suited for a broad range of GPU-enabled workloads including AI inference, graphics rendering, video transcoding and analytics, spatial computing, virtual desktop infrastructure (VDI), and data analytics.

Here are improvements of G7 instances compared to previous generation:

  • Faster GPU memory – NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs offer 1.33 times the GPU memory capacity and 2.45 times the GPU memory bandwidth compared to G6 instances. With 32 GB of GPU memory per GPU, 5th Gen Tensor Cores, and 4th Gen RT Cores, G7 instances deliver enhanced AI inference and graphics performance.
  • High performance networking and storage – G7 instances come with 700 Gbps of EFA-enabled networking throughput (7x compared to G6) enabling the low-latency, high-bandwidth connectivity that AI inference, graphics-intensive applications, and GPU-accelerated data analytics workloads need to perform at their best. G7 instances support up to 7.6 TB local NVMe SSD storage, enabling you to keep large models and datasets close to compute, reduce data transfer overhead, and improve throughput.
  • Advanced video encoding and decoding engines – Ninth-generation NVENC and sixth-generation NVDEC engines support 4:2:2 encoding and decoding for high-resolution video workflows, delivering 1.5x concurrent video streams compared to previous-generation G6 instances.

EC2 G7 instance specifications
G7 instances feature up to 8 NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs with up to 256 GB of total GPU memory (32 GB of memory per GPU) and custom Intel Xeon Scalable processors. They also are available in 7 sizes and support up to 192 vCPUs, up to 700 Gbps of network bandwidth, up to 768 GiB of system memory, and up to 7.6 TB of local NVMe SSD storage.

Here are the specs:

Instance name GPUs GPU memory (GB) vCPUs Memory (GiB) Storage EBS bandwidth (Gbps) Network bandwidth (Gbps)
g7.2xlarge 1 32 8 32 1 x 600 Up to 8 Up to 60
g7.4xlarge 1 32 16 64 1 x 600 8 Up to 100
g7.8xlarge 1 32 32 128 1 x 950 16 Up to 100
g7.12xlarge 2 64 48 192 1 x 1900 20 175
g7.24xlarge 4 128 96 384 1 x 3800 40 350
g7.48xlarge 8 256 192 768 2 x 3800 80 700
g7.metal* 8 256 192 768 2 x 3800 80 700

* Coming soon

G7 instances support NVIDIA GPUDirect P2P for multi-GPU sizes, NVIDIA GPUDirect RDMA with EFA, and GPUDirect RDMA with EFA for Amazon FSx for Lustre, enabling low-latency GPU-to-GPU communication for multi-GPU and multi-node workloads.

To get started with G7 instances, you can use the AWS Deep Learning AMIs (DLAMI) or NVIDIA Workstation AMIs with prepackaged GPU drivers for your AI inference and graphics workloads. To use G7 instances with Amazon EKS, build EKS AMIs with NVIDIA driver version R595 with EKS-provided automation. G7 instances support multiple operating systems including Amazon Linux, Ubuntu, RHEL, and Windows Server, with comprehensive NVIDIA driver integration providing compatibility with industry-standard graphics libraries including DirectX, Vulkan, and OpenGL.

Get started today
You can start using Amazon EC2 G7 instances today in two AWS regions: US East (Ohio) and US West (Oregon). To check future Regional expansion plans, look up the instance type in the CloudFormation resources tab on the AWS Capabilities by Region page.

G7 instances are offered through multiple purchasing options, including On-Demand, Savings Plans, and Spot Instances. Dedicated Instances are also supported for the 12xlarge, 24xlarge, and 48xlarge sizes. For detailed pricing, visit the Amazon EC2 Pricing page.

Ready to get started? Launch G7 instances from the Amazon EC2 console. For more details, head over to the Amazon EC2 G7 instances page. We’d love to hear your feedback. Share it on AWS re:Post for EC2 or reach out through your usual AWS Support contacts.

– Daniel Abib

Simulating Amazon EC2 EBS burst credits before downsizing an instance

Post Syndicated from Vineedh George original https://aws.amazon.com/blogs/compute/simulating-amazon-ec2-ebs-burst-credits-before-downsizing-an-instance/

When downsizing an Amazon Elastic Compute Cloud (Amazon EC2) instance, teams often evaluate CPU and memory utilization but overlook the instance’s Amazon Elastic Block Store (Amazon EBS) performance limits for throughput and IOPS. Smaller Amazon EBS-optimized instance types have lower baselines and rely on burst credits to handle peaks. If your workload’s I/O pattern drains those credits faster than the instance can refill them, the instance will throttle your workload to baseline. This post applies to burstable EBS-optimized instances with baselines below their maximum.

This post shows how to pull your instance’s Amazon EBS metrics from Amazon CloudWatch, simulate the burst credit balance against a target instance type’s limits, and help evaluate whether the downsize might be appropriate before making the change.

Solution overview

The analysis compares your workload’s actual I/O pattern against the target instance type’s Amazon EBS limits.

  1. Measure your current Amazon EBS usage. Pull instance-level throughput and IOPS from Amazon CloudWatch at 5-minute granularity. You need at least two weeks of data to capture weekly patterns. Four weeks is better if your workload has monthly cycles. While you pull data, check whether your current instance already hits its Amazon EBS-optimized performance limits.
  2. Compare against the target instance’s limits. Look up the baseline and burst ceiling for your target instance type. Simulate the burst credit balance across your observation window: for each 5-minute interval, calculate whether credits are draining or refilling, and track whether the balance ever hits zero. If it does, you will experience throttling on the smaller instance.
  3. Monitor after the move. Watch InstanceEBSThroughputExceededCheck and InstanceEBSIOPSExceededCheck for immediate throttle detection. Track EBSByteBalance% and EBSIOBalance% to gauge how much headroom remains for workload growth.

Note: These balance metrics are only available on burstable instance sizes where the baseline is lower than the maximum.

Prerequisites

An AWS account with permissions for cloudwatch:GetMetricData and ec2:DescribeInstanceTypes. The instance must be Amazon EBS-optimized (AWS enables EBS-optimization by default on most current-generation instance types).

Note: AWS doesn’t provide these instance-level Amazon CloudWatch metrics in AWS Outposts, AWS Local Zones, or AWS Wavelength Zones.

Pulling instance-level Amazon EBS metrics from Amazon CloudWatch

Amazon CloudWatch provides Amazon EBS metrics at the instance level in the AWS/EC2 namespace, using the InstanceId dimension. Here are the metrics that you need:

Metric What it measures
EBSReadBytes Total read bytes in the period
EBSWriteBytes Total write bytes in the period
EBSReadOps Total read operations in the period
EBSWriteOps Total write operations in the period
EBSIOBalance% IOPS burst credit balance (0-100%)
EBSByteBalance% Throughput burst credit balance (0-100%)
InstanceEBSIOPSExceededCheck 1 if instance hit IOPS limit, 0 otherwise
InstanceEBSThroughputExceededCheck 1 if instance hit throughput limit, 0 otherwise

The first four metrics are the inputs for the simulation. The rest are useful context:

  • EBSIOBalance% and EBSByteBalance% show how much of the burst credit pool remains, as a percentage. On the current (larger) instance, these should sit at or near 100 percent. If they’re dipping, the workload is already consuming burst credits at the current size, and a downsize will make it worse.

Note: These metrics only appear on instances where the baseline is lower than the maximum.

  • InstanceEBSIOPSExceededCheck and InstanceEBSThroughputExceededCheck are binary: 1 means the instance hit its EBS-optimized performance limit within the last minute. If either is firing on the current instance, the workload is already throttling and should be addressed before considering a downsize.

Pull these at 5-minute granularity for at least two weeks (four if your workload has monthly cycles). Amazon CloudWatch retains 5-minute data points for 63 days, so that’s your upper bound. You can retrieve the data through the AWS Command Line Interface (AWS CLI) (GetMetricData API), the Amazon CloudWatch console, or any AWS SDK. The metrics live in the AWS/EC2 namespace with your InstanceId as the dimension.

Use the Maximum statistic for the four I/O metrics and Minimum for the balance percentages. Maximum captures the highest 1-minute data point within each 5-minute window, which is the conservative choice for the simulation inputs. The Sum statistic gives a more precise total for each interval, but Maximum is the intentionally conservative choice. It assumes the peak 1-minute rate held for the full 5-minute window, which overstates actual consumption. Minimum on the balance metrics captures the lowest point the balance hit within each window, so you see the actual dips rather than averaging them away. For the ExceededCheck metrics, use Maximum (you want to know if the limit was hit at any point in the window).

Combine read and write values to get totals per interval. To convert to per-second rates:

total_throughput_MBps = (EBSReadBytes + EBSWriteBytes) / (60 * 1024 * 1024)
total_iops            = (EBSReadOps + EBSWriteOps) / 60

The division by 60 (not by the period length) is intentional. The Maximum statistic for a 5-minute period returns the highest 1-minute aggregate within that window, not a 5-minute total. Dividing by 60 converts that 1-minute peak to a per-second rate. The additional divisions by 1,024 convert bytes to mebibytes to match the units in describe-instance-types.

Comparing actual usage against target limits

From the Amazon EBS-optimized instances documentation, find the baseline and maximum (burst ceiling) for both IOPS and throughput on your target instance type. You can also pull these programmatically:

aws ec2 describe-instance-types \
  --instance-types r8i.large \
  --query 'InstanceTypes[0].EbsInfo.EbsOptimizedInfo' \
  --output table

This returns the baseline and maximum bandwidth (MB/s) and IOPS for the instance type. Note that BandwidthInMbps is megabits per second (network-style units), while ThroughputInMBps is megabytes per second. The throughput values are what you compare against your Amazon CloudWatch data.

-------------------------------------------
|          EbsOptimizedInfo               |
+----------------------------+------------+
| BaselineBandwidthInMbps    | 650        |
| BaselineThroughputInMBps   | 81.25      |
| BaselineIops               | 3600       |
| MaximumBandwidthInMbps     | 10000      |
| MaximumThroughputInMBps    | 1250.0     |
| MaximumIops                | 40000      |
+----------------------------+------------+

BaselineThroughputInMBps is the sustained rate the instance can deliver indefinitely. MaximumThroughputInMBps is the burst ceiling, the absolute maximum the instance can deliver while it has burst credits. Same relationship for IOPS. IOPS and throughput have separate burst budgets, tracked by EBSIOBalance% and EBSByteBalance% respectively.

How burst credits work

The instance maintains a credit pool for each budget (IOPS and throughput). The pool capacity is:

credit_pool = (burst_ceiling - baseline) * 1800

The 1800 comes from 30 minutes (1800 seconds) of burst at the maximum rate, which AWS provisions as the pool size for burstable Amazon EBS-optimized instances. Credits drain when usage exceeds baseline and refill when usage is below baseline, at a rate of baseline – effective_usage per second, where effective_usage is min(actual_usage, burst_ceiling). The instance cannot deliver more than the ceiling regardless of credit balance, so credits drain at the ceiling rate, not the requested rate. The pool is capped at its maximum and floored at zero. When credits hit zero, your workload is throttled to baseline performance. AWS resets the pool to full every 24 hours, giving you at least 30 minutes of burst capacity per day.

See Improving application performance and reducing costs with Amazon EBS-optimized instance burst capability for a detailed walkthrough of how burst credits work.

Simulating the credit balance

With the time series data and the target limits, you can simulate what the credit balance would look like on the smaller instance. For each 5-minute interval in your observation window:

effective_usage = min(actual_usage, burst_ceiling)
net_credit_change = (baseline - effective_usage) * interval_seconds
new_balance = previous_balance + net_credit_change
new_balance = clamp(new_balance, 0, credit_pool)

Where interval_seconds is 300 for 5-minute data or 60 for 1-minute data.

When actual usage is below baseline, credits accumulate. When above, they drain. Run this across the full observation window, resetting the pool to full at the start of each 24-hour period to model the AWS top-off guarantee. Start each day with a full pool, then drain and refill through the day’s intervals. If the balance hits zero on any day, the workload will throttle on the smaller instance.

Run the simulation twice: once for IOPS, once for throughput. Throttling happens if either pool hits zero.

A Python script that pulls Amazon CloudWatch data for a given instance ID, looks up the target instance type’s Amazon EBS limits, and runs this simulation end-to-end is available at sample-ec2-ebs-burst-analyzer repository.

This simulation is an approximation

It models credit behavior at 5-minute (or 1-minute) granularity using Amazon CloudWatch aggregates, not the actual per-second I/O stream. Two factors make the simulation more conservative than reality, and two can make reality worse than the simulation.

The Maximum statistic returns the highest 1-minute total within each 5-minute window. The simulation applies that peak rate across the full 300-second interval. This overestimates credit drain by up to 5x for any given interval, because the other 4 minutes likely had lower usage. The tradeoff is intentional. If the simulation says the workload fits, the result is reliable. If it says the workload doesn’t fit, the actual situation might be better than predicted. In that case, re-run with the Average statistic for a less conservative check, or pull 1-minute data (available for the most recent 15 days in Amazon CloudWatch) for higher fidelity.

Working in the other direction, two things can make the real situation worse than the simulation predicts. If the downsize also reduces memory, database workloads (SQL Server buffer pool, PostgreSQL shared_buffers, Oracle SGA) will generate more disk I/O than what you measured because the smaller cache forces more page reads from Amazon EBS. Account for this by including additional headroom in the burst credit budget. And I/O spikes that last milliseconds don’t show up in 5-minute Amazon CloudWatch data. If EBSByteBalance% or EBSIOBalance% are trending down on the current instance but your throughput metrics look fine, the workload is microbursting.

What to look for in the results

The simulation produces two outputs per budget (IOPS and throughput): the low-water mark (lowest credit balance across the observation window) and the number of intervals where the balance hit zero.

  • IOPS credit balance (EBSIOBalance%) – If the simulated low-water mark stays well above zero, the workload’s IOPS pattern fits within the target’s burst budget. A low-water mark of 90 percent means the workload barely touches the IOPS burst pool. A low-water mark of 40 percent means it fits today but has limited room for IOPS growth.
  • Throughput credit balance (EBSByteBalance%) – Same logic for throughput. Check this independently because a workload can be comfortable on IOPS but tight on throughput, or the reverse.
  • Intervals at zero – If either balance hits zero on any day, the workload will throttle to baseline on this instance type.
  • Peak usage vs. burst ceiling – The ceiling is the absolute maximum regardless of credit balance. If your peak throughput exceeds MaximumThroughputInMBps or peak IOPS exceeds MaximumIops, the instance will cap I/O at the ceiling rate during those intervals. This doesn’t mean the workload doesn’t fit overall (credits might still be fine), but the application will experience reduced I/O during those peaks. A handful of brief spikes may be acceptable. Sustained ceiling breaches are a stronger signal to size up.
  • Throttled intervals – The most direct measure of impact. A throttled interval is one where the credit balance is at zero and usage exceeds baseline. During these intervals, the instance cannot deliver what the workload is asking for. A few throttled intervals during a nightly batch may be tolerable. Dozens per day during business hours is a problem.

The following two figures show what these outcomes look like. In the first, the workload bursts above baseline during business hours but credits never fully deplete. The minimum balance stays at 82 percent, well above zero. This workload is safe to downsize.

Figure 1: Chart showing observed IOPS over 24 hours with baseline and ceiling reference lines. IOPS bursts above baseline during business hours. Simulated credit balance dips to a minimum of 82% and recovers, indicating the workload sustains burst credits on this instance type.

Figure 1: Amazon EC2 EBS-optimized instance burst credit simulation: credits sustained

In the second figure, the same workload runs on a smaller instance type with a lower burst pool. Credits deplete within the first burst window and stay near zero for most of the business day. This workload would throttle on the smaller instance.

Figure 2: Chart showing the same IOPS pattern with a smaller burst pool. Simulated credit balance drops to 0% during each burst window, indicating burst credits are depleted and the workload would be throttled on this instance type.

Figure 2: Amazon EC2 EBS-optimized instance burst credit simulation: credits depleted

Worked examples

The following servers are from a customer running SQL Server on EC2. We simulated the burst credit balance for each against the proposed target instance type, using 28 days of Amazon CloudWatch data at 5-minute granularity with the Maximum statistic.

Server A: fits comfortably (current: c6in.4xlarge; proposed: r6i.large)

Target limits: baseline 3,600 IOPS / 81.25 MB/s, burst ceiling 40,000 IOPS / 1,250 MB/s.

Simulating the credit balance across 28 days with a daily pool reset:

IOPS Throughput
Credit pool 65,520,000 2,103,750 MB
Low-water mark 52,084,325 (79.5%) 1,656,415 MB (78.7%)
Intervals at zero 0 0

On the worst day for throughput, here’s what the simulation looks like during the evening burst window, showing how credits drain and recover interval by interval:

Time Throughput (MB/s) Net credit change Balance Balance %
22:00 154.25 -21,900 1,854,076 88.1%
22:05 22.57 +17,603 1,871,679 89.0%
22:10 452.16 -111,273 1,760,406 83.7%
22:15 427.89 -103,991 1,656,415 78.7%
22:20 30.99 +15,077 1,671,492 79.5%

At 22:10 and 22:15, throughput spiked above 400 MB/s, well above the 81.25 MB/s baseline but still under the 1,250 MB/s burst ceiling. Each interval drained roughly 100,000 credits. The pool hit its low-water mark of 78.7 percent at 22:15, then immediately began recovering as throughput dropped. By 23:55, the pool was back to 100 percent.

Assessment: fits, with roughly 20 percent headroom on the worst day.

Server B: fits but tight (same workload as Server A; proposed: r5.large)

Target limits: baseline 3,600 IOPS / 81.25 MB/s, burst ceiling 18,750 IOPS / 593.75 MB/s.

IOPS Throughput
Credit pool 27,270,000 922,500 MB
Low-water mark 13,834,325 (50.7%) 475,165 MB (51.5%)
Intervals at zero 0 0

Same workload, same burst pattern, but the r5.large has a smaller credit pool, so the same spikes drain a larger percentage. The throughput low-water mark drops from 78.7 percent to 51.5 percent. The same evening burst window that used 20 percent of the r6i.large pool now consumes nearly half the r5.large pool:

Time Throughput (MB/s) Net credit change Balance Balance %
22:00 154.25 -21,900 672,826 72.9%
22:05 22.57 +17,603 690,429 74.8%
22:10 452.16 -111,273 579,156 62.8%
22:15 427.89 -103,991 475,165 51.5%
22:20 30.99 +15,077 490,242 53.1%

This still fits, but with limited margin. Any workload growth (more users, larger databases, additional backup jobs) could push the balance toward zero. Separately, a single IOPS interval reached 20,226, exceeding the r5.large burst ceiling of 18,750. The instance can only deliver up to the ceiling while credits remain, so the application received 18,750 IOPS during that interval. That single spike would not cause sustained throttling, but combined with the tight throughput margins, it confirms this workload is at the boundary of what r5.large can handle.

Assessment: fits today, but not a safe long-term choice.

Server C: ceiling breach (current: c6in.4xlarge; proposed: r6i.xlarge)

Target limits: baseline 6,000 IOPS / 156.25 MB/s, burst ceiling 40,000 IOPS / 1,250 MB/s.

Peak throughput: 1,502.94 MB/s. This exceeds the 1,250 MB/s burst ceiling. During those peak intervals, the instance would cap throughput at 1,250 MB/s while credits remain. If credits are exhausted, throughput drops to the 156.25 MB/s baseline. The credit simulation might still show the workload fits (credits never hit zero), but the application would experience reduced I/O during those peaks. For this customer, the peaks coincided with production SQL Server activity, so even brief throttling wasn’t acceptable, and a larger instance type was needed.

Assessment: workload will be throttled during peak intervals. Whether that’s acceptable depends on the application’s sensitivity to I/O latency.

Monitoring after the resize

The pre-migration analysis uses historical data from the larger instance. After you resize, real metrics replace the simulation. Monitor the following three layers:

  1. InstanceEBSThroughputExceededCheck and InstanceEBSIOPSExceededCheck = 1 means the instance is actively throttling. This is the definitive signal. Alarm on Sum > 0 over 3 consecutive 1-minute periods to filter out single-second spikes that resolve on their own.
  2. EBSByteBalance% and EBSIOBalance% trending downward over days or weeks means the workload is growing into the instance’s limits. You’re not throttling yet, but you’re on a trajectory. An instance that dips to 90 percent nightly and recovers is in a different position than one that dips to 40 percent and barely recovers before the next burst. Neither instance is throttling, but the first has headroom while the second doesn’t.
  3. EBSByteBalance% and EBSIOBalance% stay at 100 percent means the workload never exceeds baseline. The instance has unused capacity, and you might even be able to go smaller.

If the workload has weekly patterns, allow at least one full week of data before drawing conclusions.

Conclusion

In this post, we showed how to simulate the EBS-optimized instance burst credit balance against a target instance type’s limits before downsizing an Amazon EC2 instance. The approach pulls Amazon CloudWatch metrics at 5-minute granularity, compares actual throughput and IOPS against the target’s baseline and burst ceiling, and tracks whether the credit balance would hit zero during the observation window.

This covers the Amazon EBS dimension of a right-sizing decision. A complete evaluation also considers CPU utilization, memory usage, and network throughput against the target instance’s limits. For workloads where Amazon EBS utilization is well below baseline, the burst credit simulation might not be necessary.

To run this analysis on your own instances, see the companion script in the sample-ec2-ebs-burst-analyzer repository. For more on how instance-level burst credits work, see Improving application performance and reducing costs with Amazon EBS-optimized instance burst capability. For instance-level EBS baseline and burst limits by instance type, see Amazon EBS-optimized instances.

AWS Weekly Roundup: AWS FinOps Agent in preview, Gemma 4 on Bedrock, Kiro Pro Max, and more (June 15, 2026)

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-aws-finops-agent-in-preview-gemma-4-on-bedrock-kiro-pro-max-and-more-june-15-2026/

This week, New York City is hosting AWS Summit, bringing together builders, customers, and AWS teams for a full day of announcements, demos, and technical sessions at the Javits Center. I wrote blog posts for some of the Summit launches, so I am excited to see them go live this week. I just won’t be watching from the Javits Center. I’ll be at a four-day music festival, following the launches on my phone while trying to figure out how to put up a tent. If you weren’t able to attend in person like me, the keynote livestream is available on June 17, with Dr. Swami Sivasubramanian, VP of Agentic AI, and Chet Kapoor, VP of Security Services and Observability, covering new capabilities across developer tools, AI infrastructure, and security.

Here’s what happened this week.

Headlines
How frontier teams are reinventing AI-native development — Swami published a detailed post this week drawing on data from experiments across hundreds of Amazon engineering teams. The findings are worth reading carefully if you are thinking about how to structure AI adoption on your own team.

A six-engineer team rebuilt the Amazon Bedrock inference engine in 76 days, a project originally scoped for 30 developers over 12 to 18 months. The median productivity gain across structured pilots with Amazon Stores teams was 4.5x in normalized deployment velocity, with some teams exceeding 10x. Perfect Order Experience went from a two-week feature cycle to shipping in an afternoon. WW Grocery cut design document creation from five days to a few hours.

The post distills these results into five practices for becoming a frontier team. First, invest in agent context: build steering files, coding standards, and structured repositories before writing production code. Second, expect an initial slowdown while workflows are restructured, and push through it. Third, maintain a steady backlog of well-scoped tasks so agents can run in parallel without constant supervision. Fourth, make intent explicit through structured specifications before code generation begins. Fifth, shift testing left so agents can self-correct before code reaches the pipeline.

The post closes with a note that commit velocity is only part of the picture, and that a follow-up will cover release management, operations, security operations, and EOL upgrades.

AWS FinOps Agent is now available in preview — AWS FinOps Agent is a new agent for FinOps practitioners and engineering teams that answers cost questions, surfaces optimization opportunities, investigates cost anomalies, and runs recurring FinOps workflows on a defined schedule. You can use it to query your AWS costs, generate cost reports for finance and engineering teams, and surface rightsizing, idle resource, and Savings Plans recommendations from AWS Cost Optimization Hub and AWS Compute Optimizer. The agent can open Jira tickets on your behalf based on those recommendations. When a cost anomaly is detected, FinOps Agent can automatically investigate the root cause and post findings to a Slack channel.

Last week’s launches
I’ll start with one I wrote this week, then cover the other launches that caught my attention:

  • Amazon EC2 M9g and M9gd instances are now generally available — Powered by AWS Graviton5 processors and built on the sixth-generation AWS Nitro System, M9g instances deliver up to 25% better compute performance compared to Graviton4-based instances, with up to 35% faster performance for web applications, up to 35% for machine learning inference, and up to 30% for databases. Graviton5 is the first processor in the AWS fleet to support PCIe Gen6 and DDR5-8800 memory, and includes a 5x larger L3 cache compared to the previous generation. M9g and M9gd instances offer up to 15% higher network bandwidth and 20% higher Amazon EBS bandwidth on average across sizes compared to M8g. This release also introduces the Nitro Isolation Engine, an enhancement to the Nitro System that uses formal verification to provide mathematically proven isolation between virtual machines — establishing Nitro as the first formally verified cloud hypervisor. M9gd instances add up to 11.4 TB of NVMe SSD local storage with 30% higher IOPS compared to M8gd. Both instance types support Instance Bandwidth Configuration (IBC) for adjusting bandwidth allocation between EBS and VPC networking by up to 25%.
  • Anthropic Claude Fable 5 on Amazon Bedrock — Claude Fable 5 launched on Amazon Bedrock on June 9, bringing extended asynchronous task execution, advanced vision capabilities across diagrams, charts, and PDFs, and proactive self-verification. Access requires opting into data sharing via the Data Retention API before invoking the model; Anthropic requires 30-day retention of inputs and outputs for Mythos-class models. Important note on availability: On June 12, Anthropic asked AWS to revoke access to Claude Fable 5 and Claude Mythos 5 for all users to support compliance with a US Government export control directive. All other models, including Opus 4.8, are unaffected. Read the Anthropic statement for details. AWS will share further updates as they become available.
  • Gemma 4 models are now available on Amazon Bedrock — The Gemma 4 family from Google DeepMind is now available on Amazon Bedrock across three variants: Gemma 4 31B (dense, 256K-token context window, suited for reasoning and coding workloads), Gemma 4 26B-A4B (mixture-of-experts architecture, targeting cost- and latency-sensitive workloads), and Gemma 4 E2B (smallest variant, designed for low-latency interactive use cases). All three support native function calling, structured output, reasoning, response streaming, multimodal input across text, image, video, and audio, and more than 35 languages.
  • Amazon OpenSearch Service launches MCP Apps for agentic observability — Amazon OpenSearch Service now supports MCP Apps, enabling observability workflows inside compatible agentic IDEs including Claude Desktop and VS Code. An AI agent in your local environment can investigate incidents using logs, traces, metrics, and alerts stored in OpenSearch domains, collections, and Amazon Managed Service for Prometheus. Each MCP App tool call returns a dual response: a text summary for the agent to reason over and an interactive visualization rendered in the same conversation thread. Available MCP App tools cover log, metrics, and trace investigation; service performance; topology; dynamic visualizations; agent health; cluster health; and instrumentation scoring.

Other AWS news
Here are some additional posts and updates you may find useful:

  • AWS CLI v1 enters maintenance mode — When CLI v1 enters maintenance mode, the botocore and s3transfer dependencies will be vendored directly into the CLI v1 codebase rather than installed as separate packages. This means upgrading CLI v1 will no longer update the standalone botocore or s3transfer packages, and installing those packages independently will have no effect on the versions used by CLI v1. Environments with both CLI v1 and boto3 installed will contain separate copies of these libraries. New CLI v1 releases will be limited to critical bug fixes and security issues. The recommended path is to migrate to AWS CLI v2.
  • AWS Workload Credentials Provider is now available — AWS has launched a new Workload Credentials Provider that enables workloads to obtain short-term AWS credentials without requiring long-term access keys. This supports credential management for applications running outside of AWS, giving teams a way to follow least-privilege access patterns for workloads in third-party or on-premises environments.
  • Kiro Pro Max is now available — Kiro has introduced a new Pro Max tier, adding higher usage limits, access to the latest frontier models, and additional agentic capabilities for development teams. Kiro Pro Max is designed for professional developers who need sustained, high-volume use across coding, specification generation, and agent-driven tasks.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

Visit the AWS Builder Center to meet other builders, contribute solutions, and find resources that help you keep building. You can also browse upcoming AWS-led in-person and virtual events, plus developer-focused sessions.

— Esra

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

AWS Nitro Isolation Engine: Formally verifying the hypervisor in the AWS Nitro System

Post Syndicated from Ali Saidi original https://aws.amazon.com/blogs/compute/aws-nitro-isolation-engine-formally-verifying-the-hypervisor-in-the-aws-nitro-system/

Ali Saidi is a VP and Distinguished Engineer at AWS

Millions of customers use the AWS Nitro System to protect their most sensitive workloads, and AWS is an industry leader in innovation to secure customer data. Helping our customers keep their data secure and confidential is our highest priority, and we continue to make investments in purpose-built hardware and software for data isolation and protection.

In 2017, AWS launched the Nitro System, the first major cloud platform designed with zero operator access to customer data. The Nitro System is purpose-built hardware and software that provides the foundation for all modern Amazon EC2 instances, offloading virtualization, storage, and networking functions to dedicated hardware and a minimal hypervisor. With the Nitro System, even the most privileged AWS operators are only able to interact with the system via authenticated, audited administrative APIs that cannot access customer workloads. This architecture has set the industry standard for cloud security, and third parties like NCC Group have independently validated our approach.

Now, we’re raising the bar even further. One of the primary responsibilities of the AWS Nitro System is to isolate instances from each other and from AWS operators. This has been a cornerstone of the Nitro System architecture for over a decade. The AWS Nitro Isolation Engine, first announced at re:Invent 2025 and generally available on all Graviton5-based instances starting today, is a purpose-built component within the Nitro Hypervisor responsible for enforcing this isolation and proving it with mathematical precision. Nitro Isolation Engine uses formal verification, a technique to mathematically demonstrate that the hardware or software behaves as intended, and not only in specific test cases. This intensive verification technique establishes Nitro as the first formally verified cloud hypervisor, setting a new standard for mathematically proven cloud security.

AWS Nitro Isolation Engine

Within the Nitro System, the AWS Nitro Hypervisor is designed so that no unauthorized entity can read or modify customer data across all virtual machines. Nitro Isolation Engine is a purpose-built component of the Nitro Hypervisor that enforces isolation between these virtual machines. It mediates all access to virtual machine memory, CPU register state, and I/O devices through a minimal set of APIs that are exposed to the rest of the Nitro Hypervisor. It is the sole system component that mediates access to customer data. The remaining Nitro Hypervisor components must operate through this restricted interface and cannot access customer workloads directly. The Nitro Isolation Engine’s minimalist code base eases human audit, reduces scope for bugs, and makes it feasible to apply formal verification to its design and implementation.

Formal verification

Formal verification uses mathematical proof to demonstrate that properties of a formal model of a system hold true in all possible system states and over all possible inputs. This contrasts with testing, where a system’s behavior is checked against a (potentially large) subset of possible states and inputs. Formal verification provides far stronger evidence about correctness than traditional testing. In the case of Nitro Isolation Engine, our isolation properties are assured across all possible system behaviors. Testing and verification are complementary. Verification extends testing, and testing covers areas of the system not yet verified and builds an intuition that the system is behaving as intended.

For customers, formal verification of the code responsible for enforcing isolation provides assurance beyond comprehensive testing. Testing remains essential, and we maintain a high bar for it — but testing can only check specific scenarios. Formal verification is complementary: it means that isolation properties are mathematically assured across all possible scenarios, not just those covered by testing.

Formally verified properties

The formal verification of the Nitro Isolation Engine establishes four key properties:

1/ Confidentiality and Integrity – The Nitro Isolation Engine preserves the confidentiality and integrity of guest virtual machines (VM). Confidentiality means that a guest VM’s private data cannot be read by any unauthorized entity and Integrity means that a guest VM’s private data cannot be modified by any unauthorized entity.

2/ Functional Correctness – Every verified hypercall matches the expected behavior defined in the specification. The specification captures the preconditions and postconditions of each hypercall, and the proof establishes that the implementation never deviates from them.

3/ Absence of Runtime Errors – The code never encounters runtime errors and the implementation behaves as specified. Together, formal verification of these properties establishes mathematically rigorous assurance that the Nitro System maintains isolation for any sequence of events covered by the verification. Today, the verification covers the hypercalls for the core VM lifecycle responsible for bringing up, running, and tearing down a VM.

4/ Memory Safety – Establishes the absence of memory safety violations such as buffer overflows, NULL pointer dereferences, and out-of-bound access. As is the case for all verified software, the Nitro Isolation Engine proofs are subject to assumptions, such as the correctness of the Rust compiler and hardware. These assumptions and our approach to engineering and verification are detailed further in the Nitro Isolation Engine whitepaper.

Rust implementation

Nitro Isolation Engine is implemented in Rust, a systems programming language designed to prevent common programming pitfalls that have historically been the root cause of security vulnerabilities in sensitive software. The choice of Rust for the Nitro Isolation Engine eliminates entire classes of bugs by construction. What makes Rust a good fit is its type of system — it enforces a strong ownership discipline, which makes some aspects of formal verification easier and provides a first layer of assurance at compile time.

Conclusion

The Nitro Isolation Engine represents our continued commitment to keeping our customers’ data confidential. This is only the starting point. We will continue to extend formal verification across all major components of the Nitro Isolation Engine that impact security and maintain those proofs as new features are introduced. In addition, we plan to make the Nitro Isolation Engine’s source code and formal proofs available to third parties for independent inspection and review. We believe this level of transparency sets a new standard for how cloud providers can demonstrate openness, code quality, and formal verification.

To learn more about the AWS Nitro System and confidential computing, see the following resources:

About the authors

author name

Ali Saidi

Ali is a vice president and distinguished engineer at Amazon Web Services (AWS). He holds a PhD in computer science and engineering from the University of Michigan. Since joining AWS in 2017, he has focused on the design and development of the AWS Nitro System, AWS Graviton, and the broader portfolio of EC2 instance families.

Optimize EC2 costs with AWS Compute Optimizer right sizing

Post Syndicated from Darshan Patel original https://aws.amazon.com/blogs/compute/optimize-ec2-costs-with-aws-compute-optimizer-right-sizing/

One of the most impactful ways to improve the ROI on your Amazon Elastic Compute Cloud (Amazon EC2) investment is rightsizing — when you match your instance types and sizes to the actual resource demands of your workloads. However, doing this manually across hundreds or thousands of instances is time-consuming and error-prone. AWS Compute Optimizer analyzes your AWS resources’ configuration and utilization metrics to provide rightsizing recommendations designed to help you identify opportunities to reduce cost while helping to maintain performance and capacity requirements.

In this post, we walk you through how to evaluate AWS Compute Optimizer’s EC2 rightsizing recommendations, configure recommendation preferences that align with your organization’s priorities, enrich recommendations with memory utilization data, and assess Graviton-based alternatives — all to help you make more informed, data-driven rightsizing decisions.

Prerequisites

To follow along with the best practices in this post, you need:

  • An AWS account with access to AWS Compute Optimizer
  • At least one running EC2 instance with 30+ hours of Amazon CloudWatch metric data in the past 14 days

Optional (for enhanced recommendations):

The challenge: balancing cost and performance at scale

Most organizations don’t have clear insights into the best performance-cost ratio for their EC2 instances — leading to overprovisioning and wasted spend on one side, or undersized instances and degraded user experience on the other. The key questions engineering and FinOps teams face are:

  • Which instances are oversized? Where are we paying for capacity we don’t use?
  • Which instances are undersized? Where are we risking performance degradation?
  • What’s the right trade-off? How do we optimize cost without introducing performance risk?

AWS Compute Optimizer analyzes up to 93 days of utilization data from Amazon CloudWatch and delivers recommendations classified by savings opportunity and performance risk to help you address these questions.

How Compute Optimizer evaluates EC2 instances

Compute Optimizer analyzes the following CloudWatch metrics for your EC2 instances, with recommendations refreshed daily:

  • CPU utilization — the percentage of allocated EC2 compute units in use on the instance. Metric: CPUUtilization
  • Memory utilization — the percentage of memory in use during the sample period (when enabled — see below). Metric: MemoryUtilization
  • Network I/O — the volume of incoming/outgoing traffic and packets on all network interfaces. Metrics: NetworkIn, NetworkOut, NetworkPacketsIn, NetworkPacketsOut
  • Disk I/O — read/write operations and throughput for instance store volumes. Metrics: DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes
  • EBS throughput and IOPS — read/write throughput and operations for attached EBS volumes. Metrics: VolumeReadBytes, VolumeWriteBytes, VolumeReadOps, VolumeWriteOps
  • GPU utilization — the percentage of allocated GPUs in use, GPU memory usage, and active encoder sessions (when enabled via the CloudWatch Agent with NVIDIA GPU metrics). Metrics: GPUUtilization, GPUMemoryUtilization, GPUEncoderStatsSessionCount

Based on these metrics, Compute Optimizer classifies each instance as:

Finding Meaning
Over-provisioned Instance resources exceed workload needs — downsize opportunity
Under-provisioned Workload demands exceed instance capacity — performance risk
Optimized Current instance is well-matched to workload requirements
Idle Instance has very low utilization — candidate for termination or consolidation (shown on a dedicated Idle Resource Recommendations page; criteria: peak CPU below 5% and network I/O under 5 MB/day over the 14-day lookback period; GPU instances (G/P families) have additional GPU-specific idle criteria)

When AWS Cost Optimization Hub is enabled, Compute Optimizer factors in your existing pricing commitments (AWS Savings Plans, Reserved Instances and other specific pricing discounts) when generating savings estimates — see Best practice 1 below for details.

For each finding, Compute Optimizer lists up to three optimization recommendations for a specific instance, ranked by estimated savings, performance risk, and migration effort.

Note: While this post focuses on EC2 instance rightsizing, Compute Optimizer also generates recommendations for Amazon EC2 Auto Scaling groups (including mixed instance types and scaling policies), Amazon Elastic Block Store (Amazon EBS) volumes, AWS Lambda functions, Amazon Elastic Container Service (Amazon ECS) services on AWS Fargate, commercial software licenses, and Amazon Aurora/Amazon Relational Database Service (Amazon RDS) databases. Idle resource detection extends further — covering EC2 instances, Auto Scaling groups, EBS volumes, ECS on Fargate, Aurora/RDS, and NAT Gateways. For the full list of supported resources, see Supported resources.

Evaluating recommendations in the console

In the Compute Optimizer console, navigate to EC2 Instances and select any instance to view its detail page. From here you can:

  1. Compare utilization metrics — View side-by-side graphs showing how your current instance’s CPU, memory, network, and disk metrics map to the recommended instance’s capacity.
  2. Review estimated savings — See projected monthly cost savings for each recommended option. With AWS Cost Optimization Hub enabled, savings reflect your actual pricing discounts rather than On-Demand rates (see Best practice 1).
  3. Assess performance risk — Understand the likelihood that switching to the recommended instance may result in resource contention.
  4. Evaluate migration effort — Compute Optimizer rates each recommendation from Very low to High based on CPU architecture compatibility and inferred workload type. Same architecture is Very low effort; AWS Graviton (ARM64) recommendation with a known compatible workload (for example, Amazon EMR) is Low; Graviton with an unidentified workload is Medium; and a different architecture with no known compatible version is High effort.
  5. Toggle CPU architecture preferences — Use the architecture drop-down to compare x86-based recommendations against AWS Graviton (ARM64) alternatives for additional price-performance improvements.

Best practice 1: Enable Cost Optimization Hub for after-discount savings

Why this matters: Enabling Cost Optimization Hub gives Compute Optimizer visibility into your Savings Plans, Reserved Instances, and other pricing discounts — so every recommendation reflects what you would actually save given your existing commitments. This is especially valuable for organizations with significant discount coverage, where On-Demand savings estimates may be significantly higher than what you would actually realize after accounting for existing commitments.

When you enable Cost Optimization Hub, Compute Optimizer automatically switches to AfterDiscounts mode and uses your organization-specific pricing discounts to generate recommendations. The console then displays two savings columns — Estimated monthly savings (after discounts) and Estimated monthly savings (On-Demand) — giving you both views side by side. To enable Cost Optimization Hub for your organization, see Getting started with Cost Optimization Hub. The savings estimation mode preference allows Compute Optimizer to analyze specific pricing discounts when generating the estimated cost savings of rightsizing recommendations. You can verify or override the savings estimation mode under Preferences > Savings estimation mode in the Compute Optimizer console. See Savings estimation mode for details.

Best practice 2: Enable memory metrics for accurate recommendations

Why this matters: Memory utilization is not collected by default in CloudWatch. By enabling it, you give Compute Optimizer a complete picture of your workload — CPU, network, disk, and memory together. This is especially valuable for memory-intensive workloads (databases, caching layers, JVM-based applications), where memory is often the critical sizing factor. With full visibility, Compute Optimizer can factor memory needs into every recommendation, resulting in higher-confidence suggestions that your teams can implement with greater assurance.

Option A: CloudWatch Agent

Deploy the unified CloudWatch Agent on your instances to publish memory utilization metrics. Compute Optimizer automatically incorporates these metrics once they’re available in CloudWatch.

Note: Collecting memory metrics with the CloudWatch Agent incurs charges. See Amazon CloudWatch Pricing.

Key steps:

  1. Install the CloudWatch Agent via AWS Systems Manager or manually.
  2. Configure the agent to collect memory metrics.
  3. Verify metrics appear in CloudWatch.
  4. Allow up to 24 hours for Compute Optimizer to incorporate the new data.

Option B: External metrics ingestion

If your organization uses a third-party observability platform, Compute Optimizer supports ingesting EC2 memory utilization metrics from:

  • Datadog
  • Dynatrace
  • Instana
  • New Relic

When external metrics ingestion is enabled, Compute Optimizer analyzes external memory data alongside native CloudWatch metrics to generate enhanced recommendations.

Learn more: Configuring external metrics ingestion

Best practice 3: Configure rightsizing preferences to match your strategy

Why this matters: Compute Optimizer’s defaults — P99.5 threshold (sizes instances to handle 99.5% of observed CPU peaks), 20% headroom (adds a 20% capacity buffer above those peaks for future growth), and 14-day lookback — work well for many workloads. Customizing these preferences lets you go further — extending the lookback to 32 or 93 days captures monthly or seasonal patterns for even more accurate recommendations, while adjusting headroom and threshold lets you fine-tune the balance between savings and performance for each environment. The result: recommendations tailored to your actual risk tolerance and workload patterns, producing suggestions your teams will trust and confidently implement.

Compute Optimizer supports configurable rightsizing preferences that tailor recommendations to your workload requirements. Preferences can be set at the organization level (applies to all member accounts in your AWS Organizations), account level (applies to a specific account — useful when production and dev/test accounts need different settings), or regional level (applies within a specific region — useful when workloads differ across regions). This hierarchy lets you set conservative defaults org-wide and override for specific accounts or regions that need different treatment.

Key preference options include:

Preference Description When to use
CPU utilization threshold Before generating recommendations, Compute Optimizer filters your CPU data through this percentile. Think of it as a noise filter: P99.5 (default) keeps 99.5% of your data and only discards the rarest 0.5% of spikes — so the recommendation is sized to handle almost every peak you’ve ever seen. P90 discards the top 10% of spikes, treating them as anomalies, and produces smaller (cheaper) recommendations. Options: P90, P95, P99.5 Use P99.5 for production where you can’t afford to miss peaks; P90 for dev/test where occasional spikes from deployments or one-off events are acceptable to ignore
CPU utilization headroom After Compute Optimizer determines the right instance size based on your historical peaks, it adds this percentage as a safety cushion for future growth. For example: if your analyzed peak needs 60% of an instance’s CPU, a 20% headroom means the recommended instance will still have 20 percentage points of spare capacity above that peak — room to grow without needing another resize. Options: 30%, 20% (default), 0% Use 30% for workloads with unpredictable or growing traffic; 20% for typical production; 0% for steady-state workloads where you want maximum savings and accept a tight fit
Memory utilization headroom Added memory capacity buffer (30%, 20%, or 10%) above analyzed usage to accommodate future increases. Default is 20% Use 30% for memory-sensitive workloads; 10% for steady-state where you want maximum savings
Lookback period Choose 14 days (default, no additional charge), 32 days (no additional charge), or 93 days (requires Enhanced Infrastructure Metrics (EIM), a paid feature). You can enable EIM at the organization, account, or individual resource level — useful for activating it only on production workloads where the cost is justified Use 32 days for monthly patterns; 93 days for seasonal or quarterly workloads
Preferred instance types Restrict recommendations to specific instance families or types. For example, if you have purchased Savings Plans and Reserved Instances, you can specify instances only covered by those pricing models. Or, if you want to use only instances equipped with certain processors or non-burstable instances because of your application design, you can specify those instances for your recommendation output When organizational standards, procurement commitments (RIs/SPs), or application design require approved instance families

Learn more: How to take advantage of rightsizing recommendation preferences

Best practice 4: Evaluate Graviton recommendations carefully

Why this matters: Compute Optimizer can recommend migrating x86 workloads to AWS Graviton instances, which deliver up to 40% better price-performance. However, unlike same-architecture rightsizing (which is a configuration change), Graviton involves a CPU architecture shift from x86 to ARM64 — so a structured evaluation process helps you validate compatibility and capture the full savings with confidence.

Before migrating to Graviton:

  1. Assess architecture compatibility — Verify that your application binaries, libraries, and dependencies support ARM64. Container-based workloads (using multi-arch images) typically require less modification to migrate.
  2. Check software dependencies — Confirm third-party agents, drivers, and monitoring tools are available for ARM64.
  3. Test in non-production first — Deploy the recommended Graviton instance in a staging environment.
  4. Run load tests — Validate performance parity with the current instance.
  5. Use the Graviton Transition Guide — Follow the AWS Graviton Getting Started guide for a structured migration approach.
  6. How to identify a good target workload — A good candidate for Graviton adoption is a workload running on Linux or BSD, built either using open-source components or source code that you control. Having full access to the source code of every component allows you to make any necessary changes quickly and easily as part of this adoption plan. If you use third-party software, many ISVs already support the Arm64 architecture implemented by AWS Graviton processors.

When to defer Graviton recommendations:

  • Legacy applications compiled for x86 without source code access.
  • Workloads with licensing tied to specific CPU architectures.
  • Applications with untested third-party binary dependencies.

Learn more: AWS Compute Optimizer Graviton migration guidance

Best practice 5: Implement a rightsizing workflow

Why this matters: A structured workflow turns Compute Optimizer’s recommendations into sustained, measurable cost savings. By establishing a regular cadence — reviewing, validating with stakeholders, and tracking results — your organization builds a continuous optimization loop that adapts as workloads evolve, compounds savings over time, and gives finance teams clear visibility into realized cost reductions.

To operationalize Compute Optimizer recommendations across your organization:

  1. Establish a regular review cadence — Schedule weekly or bi-weekly rightsizing reviews with your FinOps or cloud operations team.
  2. Prioritize by savings and confidence — Focus first on Over-provisioned instances with high estimated savings and low performance risk.
  3. Validate with application owners — Share recommendations with workload owners for context on usage patterns that metrics alone may not reveal (for example, seasonal traffic, scheduled batch jobs).
  4. Track implementation — Use AWS Cost Explorer to measure realized savings after rightsizing changes.

Note: Tag instances for effective rightsizing at scale. Compute Optimizer recommendations become more actionable when your instances carry consistent tags. At minimum, tag with Environment (prod/staging/dev) to drive review priority, and Application/Workload and Owner/Team to route recommendations to the right team. Compute Optimizer’s console, exports, and API all support tag-based filtering (tag:key and tag-key filters).

Taking it further — automate your workflow: For organizations ready to move beyond manual reviews, Compute Optimizer offers built-in automation that allows you to create automation rules that continuously clean up unattached volumes and upgrade volume types based on Compute Optimizer’s data-driven recommendations. For EC2 instance rightsizing, AWS provides a reference architecture for automating Compute Optimizer recommendations using AWS Step Functions, Amazon EventBridge, and AWS Lambda. See: Optimize costs by automating AWS Compute Optimizer recommendations

Clean up

If you installed the CloudWatch Agent as part of best practice 2 and no longer need memory metrics, stop and remove the agent to avoid ongoing custom metric charges.

Conclusion

AWS Compute Optimizer provides data-driven recommendations to help you make more informed EC2 rightsizing decisions. By enabling memory metrics, configuring recommendation preferences aligned to your workload needs, carefully evaluating Graviton alternatives, and establishing a systematic review process, you can identify opportunities to help optimize your EC2 fleet and help reduce costs while considering the performance your applications require.

Further reading

Now available: Amazon EC2 M9g and M9gd instances powered by new AWS Graviton5 processors

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/now-available-amazon-ec2-m9g-and-m9gd-instances-powered-by-new-aws-graviton5-processors/

AWS Graviton processors have improved steadily across generations, with each iteration delivering advances in compute performance, price-performance, and energy efficiency. At re:Invent 2025, we announced Amazon EC2 M9g, the first Graviton5-powered instances, in preview. Since then, customers have tested M9g across a wide range of workloads and shared their results. ClickHouse saw a 36% performance boost compared to M8g, with zero code changes. Honeycomb achieved 36% better throughput per core compared to Graviton4, across a 6-month A/B test of production observability workloads. HubSpot deployed M9g for MySQL databases and saw query duration drop by up to 60%. Today, M9g instances are generally available, alongside the new M9gd instances for customers who need high-speed, low-latency local NVMe SSD storage. Both are powered by Graviton5, the most powerful and most energy efficient processor AWS has ever built.

While many Arm-based instances have been introduced across the industry, no one comes close to the breadth and depth of the AWS Graviton footprint. After five generations of custom silicon and eight years of continuous investment, Graviton powers over 350 instance types serving more than 120,000 customers, from startups to large enterprises, a robust ISV partner ecosystem, and a broad set of managed services. You can use Graviton for a broad variety of workloads, including web applications, microservices, analytics, databases, machine learning (ML) inference, electronic design automation (EDA), gaming, and video encoding. As workloads grow more compute-intensive and data-driven, many have asked for more processing power, along with greater network and storage bandwidth to move more data and complete workloads faster. We’ve also designed these instances to efficiently package compute, memory, and I/O to maximize energy utilization.

As AI shifts from answering questions to taking actions, running code, using tools, evaluating results, and orchestrating multi-step tasks, the demand for CPU compute is growing rapidly. Graviton5 is built for this shift. With 192 cores, a 5x larger L3 cache, up to 33% lower inter-core latency, and DDR5 memory delivering high bandwidth, Graviton5 helps agents spend less time waiting on CPU-bound steps, processing more instructions, handling large numbers of concurrent environments, and keeping accelerators moving.

Meta is deploying Graviton at scale starting with tens of millions of cores to support its agentic AI efforts, making Meta one of the largest Graviton customers in the world. Agentic AI workloads, including real-time reasoning, code generation, and the orchestration of multi-step tasks, are CPU-intensive and benefit from the higher compute performance, larger caches, higher memory bandwidth, and core density in Graviton5.

What’s new in M9g and M9gd
Built on the sixth-generation AWS Nitro System, M9g instances are powered by AWS Graviton5 processors that deliver higher compute performance, larger caches, and improved memory and I/O scalability compared to Graviton4 processors. Graviton5 offers up to 25% better compute performance compared to Graviton4-based instances, with up to 35% faster performance for web applications, up to 35% for machine learning inference, and up to 30% for databases. As the first CPU in the AWS fleet to support the latest generation of PCIe Gen6 and DDR5-8800 memory, AWS Graviton5 instances deliver the fastest memory of any processor instances in the cloud, and 5 times more L3 cache compared to the previous generation. These improvements also come with better energy efficiency, helping you meet sustainability targets without compromising capability.

Networking and storage bandwidth have been expanded to keep pace with compute growth. M9g and M9gd instances offer up to 15% higher network bandwidth and 20% higher Amazon Elastic Block Store (Amazon EBS) bandwidth on average across sizes, with up to twice the network bandwidth for the largest instance size. M9g and M9gd instances also support Instance Bandwidth Configuration (IBC), a feature that helps you adjust the allocation of bandwidth between Amazon EBS and Amazon Virtual Private Cloud (Amazon VPC) networking for an Amazon EC2 instance by up to 25%. IBC can help optimize performance for workloads with specific bandwidth requirements, such as database read and write performance, query processing, and logging. These enhancements support faster data movement and improved throughput for workloads that rely on high I/O performance.

Security and isolation are foundational requirements for running workloads in the cloud. Within the Nitro System, the AWS Nitro Hypervisor is designed to isolate instances from each other as well as AWS operators. With M9g and M9gd instances we are raising the bar on security even further with the introduction of Nitro Isolation Engine. Nitro Isolation Engine is an enhancement to the Nitro System, which enforces isolation of instances and harnesses formal verification to provide assurances of isolation with mathematical precision. Nitro Isolation Engine is a purpose-built component that is responsible for enforcing isolation between virtual machines, including mediation of all access to virtual machine memory, CPU register state, and I/O devices through a minimal set of APIs. Nitro Isolation Engine leverages formal verification, a technique to mathematically demonstrate that the hardware or software behaves as intended, and not just in specific test cases. This intensive verification technique establishes Nitro as the first formally verified cloud hypervisor, pioneering a new standard for mathematically proven cloud security.

M9g instances provide one vCPU for every four GiB of memory and are well suited for a broad range of general-purpose workloads, including application servers, microservices, midsize data stores, gaming servers, caching fleets, containerized applications, large-scale Java applications, code repositories, web applications, and agentic AI.

For workloads that need high-speed, low-latency local storage, M9gd instances provide up to 11.4 TB of NVMe SSD storage and 30% higher IOPS and storage performance compared to Graviton4-based M8gd instances. M9gd instances are well suited for general-purpose workloads that require a balance of compute and memory with high-speed, low-latency local storage, including application servers, microservices, gaming servers, midsize key-value data stores, caching fleets, data logging, media processing, batch and log processing, and applications that need temporary storage such as caches and scratch files.

Here are the key specifications across the family:

M9g vCPUs Memory (GiB) Network bandwidth (Gbps) EBS bandwidth (Gbps)
medium 1 4 Up to 15 Up to 12
large 2 8 Up to 15 Up to 12
xlarge 4 16 Up to 15 Up to 12
2xlarge 8 32 Up to 17 Up to 12
4xlarge 16 64 Up to 17 Up to 12
8xlarge 32 128 17 12
12xlarge 48 192 25 18
16xlarge 64 256 34 24
24xlarge 96 384 50 36
48xlarge 192 768 100 72
metal-48xl 192 768 100 72

M9gd instances include local NVMe SSD storage. The table below shows the instance storage for each size. Compute, memory, network, and EBS bandwidth specifications are the same as M9g.

M9gd vCPUs Memory (GiB) Instance storage (GB) Network bandwidth (Gbps) EBS bandwidth (Gbps)
medium 1 4 1 x 59 NVMe SSD Up to 15 Up to 12
large 2 8 1 x 118 NVMe SSD Up to 15 Up to 12
xlarge 4 16 1 x 237 NVMe SSD Up to 15 Up to 12
2xlarge 8 32 1 x 475 NVMe SSD Up to 17 Up to 12
4xlarge 16 64 1 x 950 NVMe SSD Up to 17 Up to 12
8xlarge 32 128 1 x 1900 NVMe SSD 17 12
12xlarge 48 192 3 x 950 NVMe SSD 25 18
16xlarge 64 256 1 x 3800 NVMe SSD 34 24
24xlarge 96 384 3 x 1900 NVMe SSD 50 36
48xlarge 192 768 3 x 3800 NVMe SSD 100 72
metal-48xl 192 768 3 x 3800 NVMe SSD 100 72

Now available
M9g and M9gd instances are available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Frankfurt) Regions. M9g and M9gd instances are available for purchase through Savings Plans, On-Demand, Spot Instances, Dedicated Instances, or Dedicated Hosts. For more information, visit Amazon EC2 pricing.

To get started with M9g and M9gd instances, several resources are available. The AWS Graviton Getting Started Guide is a technical guide covering how to build, run, and optimize workloads on Graviton-based instances. The Graviton Savings Dashboard helps you track and measure the cost savings from running workloads on Graviton-based instances. And AWS Transform is an AI-powered service that automates code transformations for migrating Java applications from x86 to Graviton-based Amazon EC2 instances, handling compatibility analysis, automated recompilation, dependency updates, and validation.

To learn more about Graviton-based instances, visit AWS Graviton Processors or Level up your compute with AWS Graviton.

— Esra

Debug deployment failures faster with the Deployments tab in AWS Elastic Beanstalk

Post Syndicated from Ben Lazar original https://aws.amazon.com/blogs/devops/debug-deployment-failures-faster-with-the-deployments-tab-in-aws-elastic-beanstalk/

Introduction

When a deployment fails, finding the root cause often means piecing together information from multiple sources. You wait for the deployment to finish, request a log bundle, download it, and then search through files like eb-engine.log and cfn-init.log to find the error. If you’re not familiar with Elastic Beanstalk’s log file structure, you might not know which file to check first, and the process can take longer than fixing the actual problem.

Elastic Beanstalk now provides a Deployments tab in the environment dashboard that gives you a consolidated view of your deployment history and real-time deployment logs. You can see what’s happening during a deployment as it runs, and when something fails, the deployment log shows you the error output directly in the console.

In this post, you create an Elastic Beanstalk environment, trigger different types of deployments, deploy a broken application to see how the Deployments tab surfaces errors, and then fix and redeploy. By the end, you’ll know how to use deployment logs to diagnose failures without connecting to instances over SSH or downloading log bundles.

Solution overview

The Deployments tab displays a history of recent deployments for your environment, including application deployments, configuration updates, and environment launches. Each deployment has a detail page with two tabs: Events, which shows a filtered timeline of events for that deployment, and Deployment Logs, which shows a consolidated log from the instance.

Deployment logs capture each step of the deployment process: dependency installation, application builds, .ebextensions commands, platform hooks, and application startup output. The logs are designed to be concise. On success, you see summary messages showing which steps ran and completed. On failure, the log includes up to 50 lines of output from the failed step, so you can see what went wrong without searching through verbose output.

During a deployment, one instance uploads its log to Amazon Simple Storage Service (Amazon S3) as the deployment progresses. The Elastic Beanstalk console reads from Amazon S3, which means you can monitor progress in real time without connecting to the instance. After the deployment completes, the console fetches the final log to ensure you see the complete output. For environments with multiple instances, the deployment log is captured from one representative instance. To view logs from all instances, use the Request Logs feature.

Prerequisites

Before getting started, ensure that you have the following:

  • An AWS account with permissions to create Elastic Beanstalk environments and associated resources (Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon S3 buckets, security groups). For the minimum AWS Identity and Access Management (IAM) permissions required, see Managing Elastic Beanstalk service roles. Follow the principle of least privilege and avoid using AWS account root or unrestricted administrator credentials.
  • The default Elastic Beanstalk instance profile, aws-elasticbeanstalk-ec2-role. New AWS accounts may not have this role created automatically. If your environment fails to launch because the role is missing, see Instance profile for Amazon EC2 instances in your Elastic Beanstalk environment.
  • A supported Elastic Beanstalk platform version. Deployment logs are available on Amazon Linux 2 and Amazon Linux 2023 platform versions released on or after March 11, 2026, and on Windows Server platform versions 2.23.0 and later.
  • AWS Command Line Interface (AWS CLI) installed and configured with appropriate permissions. See Installing the AWS CLI.
  • A Bash-compatible shell (Bash or Zsh). The commands in this walkthrough use Bash syntax (heredocs, &&, and shell variables).

Walkthrough

Follow the steps below to create an environment, explore the Deployments tab, deploy a broken application, and then fix it.

Open your terminal and set the following variables. Replace the values with your own unique Amazon S3 bucket name and the latest Node.js solution stack for your Region. This walkthrough uses us-east-1. You can substitute your preferred Region, but use the same Region consistently across all commands in the walkthrough. To find the latest solution stack, run aws elasticbeanstalk list-available-solution-stacks.

S3_BUCKET="your-unique-bucket-name"

# Replace with the latest Node.js solution stack for your Region
SOLUTION_STACK_NAME="64bit Amazon Linux 2023 v6.11.1 running Node.js 22"

Setting up the application

This walkthrough uses two versions of a Node.js application. The first version is a working HTTP server. The second version introduces a dependency on a non-existent npm package, simulating a common deployment failure where a dependency cannot be installed.

Create a project directory:

mkdir deployments-tab-demo && cd deployments-tab-demo

Create the working application file:

cat << 'EOF' > workingapp.js
const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify({ status: 'healthy', message: 'App is running' }));
});

const port = process.env.PORT || 8080;
server.listen(port, () => {
  console.log(`Server running on port ${port}`);
});
EOF

Create the working package.json:

cat << 'EOF' > working-package.json
{
  "name": "deployments-tab-demo",
  "version": "1.0.0",
  "description": "Sample app for Deployments tab walkthrough",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  }
}
EOF

Create the broken package.json with a non-existent dependency:

cat << 'EOF' > broken-package.json
{
  "name": "deployments-tab-demo",
  "version": "2.0.0",
  "description": "Sample app for Deployments tab walkthrough",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "this-package-does-not-exist-abc123": "^1.0.0"
  }
}
EOF

Create the working application source bundle:

cp workingapp.js app.js
cp working-package.json package.json
zip -r nodejs-working-app.zip app.js package.json

Create the broken application source bundle:

cp broken-package.json package.json
zip -r nodejs-broken-app.zip app.js package.json

Step 1: Create an environment and explore the Deployments tab

Create an Amazon S3 bucket and upload the source bundles. This walkthrough uses default bucket settings for simplicity. For production workloads, enable server-side encryption and restrict bucket access to only the principals that need it.

aws s3 mb s3://$S3_BUCKET --region us-east-1

aws s3 cp nodejs-working-app.zip s3://$S3_BUCKET/nodejs-working-app.zip
aws s3 cp nodejs-broken-app.zip s3://$S3_BUCKET/nodejs-broken-app.zip

Create the Elastic Beanstalk application and the working version:

aws elasticbeanstalk create-application \
--application-name deployments-tab-demo \
--description "Deployments tab walkthrough" \
--region us-east-1

aws elasticbeanstalk create-application-version \
--application-name deployments-tab-demo \
--version-label v1-working \
--source-bundle S3Bucket="$S3_BUCKET",S3Key="nodejs-working-app.zip" \
--region us-east-1

Create the environment:

aws elasticbeanstalk create-environment \
--application-name deployments-tab-demo \
--environment-name deployments-tab-demo-env \
--solution-stack-name "$SOLUTION_STACK_NAME" \
--version-label v1-working \
--option-settings \
Namespace=aws:elasticbeanstalk:environment,OptionName=EnvironmentType,Value=SingleInstance \
Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role \
--region us-east-1

Don’t wait for the environment to finish creating. Instead, open the Elastic Beanstalk console right away, navigate to your environment, and choose the Deployments tab.

You should see one deployment in the history table with a status of In Progress and a type of Environment Creation. The table also shows the request ID, start time, and duration (which updates as the deployment runs). Choose the Request ID link to open the deployment detail page.

Elastic Beanstalk environment overview page showing the new Deployments tab selected, with a Deployment history table listing one in-progress Environment Creation deployment.

Figure 1 – Deployments tab history table showing the in-progress Environment Creation deployment

The detail page has a summary section with the deployment metadata and two tabs below it:

  • Events shows a filtered timeline of events for this deployment. As the environment creation progresses, new events appear automatically.
  • Deployment Logs shows the consolidated deployment log from the instance.

Select the Deployment Logs tab. At first, the tab may show a message indicating that the log is not yet available. This is expected. The deployment log is written on the EC2 instance and uploaded to Amazon S3, so it won’t appear until the instance launches and begins the deployment process. Once the instance is running, log entries start appearing and the tab refreshes automatically to show new entries as they are written. You can watch dependency installation, platform hooks, and application startup happen in real time.

Deployment details page showing a Deployment summary card (Request ID, Status: In progress, Type: Environment Creation) with the Deployment Logs tab selected and a "Waiting for logs..." placeholder.

Figure 2 – Deployment Logs tab showing “log not yet available” message during early environment creation

After the environment creation completes, the deployment status changes to Succeeded and the log shows the final state. Because this deployment succeeded, the log contains only summary messages for each step. Take notice of how the log captures each phase of the deployment in order: .ebextensions commands, dependency installation (npm), container commands, and then the application startup. Pay attention to the Application Output section near the end of the log. It shows the initial stdout from your application process, confirming that it started and is listening on the expected port. This section is useful for verifying that your application launched correctly after a deployment.

You can also check the environment status from the CLI:

aws elasticbeanstalk describe-environments \
--environment-names deployments-tab-demo-env \
--query 'Environments[0].{Status:Status,Health:Health}' \
--region us-east-1
Successful deployment details page with green "Environment successfully launched" banner, Deployment summary showing Status: Succeeded, and the Deployment Logs tab displaying streamed eb-engine and eb-hooks log entries.

Figure 3 – Deployment detail page showing the completed Deployment Logs tab with successful log output

Step 2: Trigger a configuration update

To see how different deployment types appear in the Deployments tab, add an environment variable to your environment:

aws elasticbeanstalk update-environment \
--environment-name deployments-tab-demo-env \
--option-settings \
Namespace=aws:elasticbeanstalk:application:environment,OptionName=APP_ENV,Value=production \
--region us-east-1

While the update is in progress, go back to the Deployments tab in the console. You should see a second deployment appear in the history with a status of In Progress and a type of Environment Update. Choose the request ID to open the detail page, and select the Deployment Logs tab. The log updates automatically as new entries are written, so you can watch the deployment progress in real time.

After the update completes, the deployment status changes to Succeeded. You now have two deployments in your history, each with its own type and duration.

Elastic Beanstalk environment page after a successful configuration update, showing Health: Ok and a Deployment history table with two Succeeded entries: a Configuration Update and an Environment Creation.

Figure 4 – Deployments tab showing two deployments: Environment Creation and Environment Update

Step 3: Deploy a broken application

This is where the Deployments tab shows its value. Create and deploy a broken application version that references a non-existent npm package:

aws elasticbeanstalk create-application-version \
--application-name deployments-tab-demo \
--version-label v2-broken \
--source-bundle S3Bucket="$S3_BUCKET",S3Key="nodejs-broken-app.zip" \
--region us-east-1

aws elasticbeanstalk update-environment \
--environment-name deployments-tab-demo-env \
--version-label v2-broken \
--region us-east-1

As soon as the deployment starts, go back to the Deployments tab in the console. You should see a new Application Deployment with a status of In Progress. Choose the request ID to open the deployment detail page and select the Deployment Logs tab.

Watch as the log streams in real time. You will see the deployment start, .ebextensions commands run, and then npm install begin. Shortly after, the error appears with the relevant output from the failed step, showing the exact npm error indicating that the package could not be found. The deployment status changes to Failed.

Elastic Beanstalk automatically rolls back to the previous working version, so your environment returns to a healthy state. Without the Deployments tab, diagnosing what went wrong would still require requesting a log bundle, downloading it, extracting it, and searching through the log files. With the Deployments tab, the diagnosis is immediate. There is no need to connect to the instance via SSH or download log bundles. The error is right there in the console.

Deployment details page for a failed Application Deployment, showing Status: Failed in the summary and Deployment Logs containing yum package errors ("No package eb-noti-abc123-1.0.0 available").

Figure 5 – Deployment detail page showing the failed deployment error and npm install output

Compare this to the successful deployment logs from Step 1. The successful log showed only summary messages. The failed log automatically includes the detailed error output. This smart verbosity means you don’t have to search through verbose logs on success, but you get the detail you need on failure.

Step 4: Deploy a fixed version

Although Elastic Beanstalk rolled back to the working version automatically, let’s deploy it explicitly to see what a successful application deployment log looks like after a failure:

aws elasticbeanstalk update-environment \
--environment-name deployments-tab-demo-env \
--version-label v1-working \
--region us-east-1

After the deployment completes, open the deployment detail page from the Deployments tab. The deployment log shows only summary messages for each step. The npm step completes without errors, the application starts, and the deployment finishes. Compare this to the failed deployment log from Step 3, where the error and detailed npm output appeared automatically.

Elastic Beanstalk environment Deployments tab showing a Deployment history of four entries — two Application Deployments (one Succeeded, one Failed), one Configuration Update, and one Environment Creation.

Figure 6 – Deployments tab showing all four deployments with their statuses

Cleaning up

To avoid ongoing charges, terminate the environment and delete the associated resources.

Terminate the environment:

aws elasticbeanstalk terminate-environment \
--environment-name deployments-tab-demo-env \
--region us-east-1

Delete the application (after the environment is terminated):

aws elasticbeanstalk delete-application \
--application-name deployments-tab-demo \
--terminate-env-by-force \
--region us-east-1

Delete the S3 bucket used for source bundles:

aws s3 rb s3://$S3_BUCKET --force --region us-east-1

Remove the local project directory. Before running the following command, make sure your current working directory is not inside deployments-tab-demo:

rm -rf deployments-tab-demo

Conclusion

The Deployments tab in AWS Elastic Beanstalk gives you a single place to view your deployment history and read deployment logs, including while a deployment is still running. When a deployment fails, the log shows you the error output from the failed step directly in the console, so you can identify the root cause without connecting to instances over SSH or downloading log bundles.

Deployment logs are available on Amazon Linux 2 and Amazon Linux 2023 platform versions released on or after March 11, 2026, and on Windows Server platform versions 2.23.0 and later, in all AWS Commercial Regions and AWS GovCloud (US) Regions. To get started, update your environment to a supported platform version and navigate to the Deployments tab in the Elastic Beanstalk console.

To learn more about deployment logs, see Viewing deployment logs in the AWS Elastic Beanstalk Developer Guide. For more information about AWS Elastic Beanstalk, visit the product page.

Ben Lazar

Ben Lazar is a Software Development Engineer II at Amazon Web Services (AWS) on the Elastic Beanstalk team. He maintains the Elastic Beanstalk platforms that customers use to run their web applications.

Building highly available Oracle databases with Amazon FSx for NetApp ONTAP

Post Syndicated from Vignyanand Penumatcha original https://aws.amazon.com/blogs/architecture/building-highly-available-oracle-databases-with-amazon-fsx-for-netapp-ontap/

Oracle databases power mission-critical enterprise applications, making their continuous availability essential for business operations. Traditional Oracle high availability (HA) solutions require complex clustering software, expensive shared storage arrays, and specialized database administration teams. These conventional approaches often introduce single points of failure while demanding significant operational overhead.

Modern cloud architectures offer a transformative approach that combines Amazon FSx for NetApp ONTAP (FSxN) with Amazon EC2 Auto Scaling groups, automated AMI creation, AWS Lambda-driven orchestration, and AWS Systems Manager Parameter Store (SSM Parameter). This solution removes traditional Oracle HA complexities while delivering enterprise-grade availability, automated recovery, and makes sure new instances launch with the latest Oracle configuration.

This post shows how to build a highly available Oracle database architecture using FSxN shared storage, Auto Scaling groups with dynamic AMI updates, and serverless orchestration to help reduce recovery times with current configurations.

Solution overview

The solution uses multiple AWS services working together to create a comprehensive high availability architecture. FSxN Multi-AZ provides persistent shared storage spanning availability zones for Oracle database files, software, and configurations, so that data remains accessible when EC2 instances are replaced. Auto Scaling groups deliver automated instance lifecycle management with the latest AMI configurations, so failed instances are quickly replaced with identical configurations that can immediately access the existing Oracle database files on FSxN. AWS Backup creates AMIs that capture the latest Oracle host configurations including patches and settings, preserving the complete server state for consistent deployments. AWS Lambda extracts the AMI ID from backup recovery points and updates the SSM Parameter, orchestrating the entire configuration management workflow. Systems Manager Parameter Store stores the current AMI ID for Auto Scaling group launch templates, so new instances always launch with the most recent configuration and can immediately connect to the Oracle database on shared storage.

The following diagram shows the complete architecture with all AWS services and their interactions:

AWS architecture diagram showing Oracle Database disaster recovery across two Availability Zones using FSx for ONTAP synchronous replication, AWS Backup automation with EventBridge and Lambda, and Auto Scaling group with SSM Parameter Store for AMI management.

Key benefits include:

  • Recovery Time Objective (RTO): Can help achieve 2–5 minutes with latest Oracle configuration
  • Recovery Point Objective (RPO): Near-zero through synchronous Multi-AZ replication
  • Configuration consistency: New instances launch with identical Oracle host setup
  • Automated AMI management: Scheduled AMI creation with Parameter Store updates

Walkthrough

This walkthrough demonstrates implementing Oracle HA using Amazon FSx for NetApp ONTAP shared storage, AWS Backup-driven AMI creation, Lambda orchestration, and Auto Scaling groups with Parameter Store integration for configuration consistency and automated failover.

Prerequisites

For this walkthrough, you should have the following prerequisites:

  • An AWS account with appropriate permissions for Amazon FSx, Auto Scaling, EC2, Lambda, and Systems Manager
  • A VPC with subnets in at least two Availability Zones
  • Oracle database software

Keep in mind that customers are responsible for their own Oracle licensing compliance.

  • An EC2 instance with Oracle database installed and configured
  • AWS Identity and Access Management (IAM) roles for AMI creation and cross-service communication
  • Basic knowledge of Oracle database administration and AWS automation

Assumptions

This post is a conceptual illustration of the architecture. Your specific implementation will vary based on your VPC layout, Oracle version, storage requirements, and organizational security policies.

We assume the reader is familiar with:

  • Creating and configuring Amazon FSx for NetApp ONTAP file systems through the AWS console
  • iSCSI concepts including initiators, targets, and multipath I/O
  • Oracle database startup and shutdown procedures
  • AWS Backup, Lambda, and Auto Scaling group fundamentals

For detailed step-by-step instructions on specific AWS services, refer to the additional resources section.

Step 1: Create an Amazon FSx for NetApp ONTAP file system

FSxN Multi-AZ provides the persistent shared storage foundation for this architecture. Unlike Amazon Elastic Block Store (Amazon EBS) volumes, which are bound to a single AZ, FSxN Multi-AZ replicates data synchronously across two AZs with automatic failover. This means that when an EC2 instance is replaced (whether in the same AZ or a different one), the new instance can immediately access the existing Oracle database files without restoring from backup.

To create the file system, navigate to the Amazon FSx console and select Amazon FSx for NetApp ONTAP as the file system type.

The critical configuration choice is selecting Multi-AZ deployment, which places an active file server in one AZ and a standby in another.

Amazon FSx console showing oracle-fsxn-multi-az file system configuration with ONTAP Multi-AZ 1 deployment, 1024 GiB SSD storage, 512 MB/s throughput, spanning us-east-1a preferred and us-east-1b standby subnets.

FSxN console showing Multi-AZ deployment type selection with preferred and standby subnets in separate availability zones.

After the file system is created, you need to set up a Storage Virtual Machine (SVM), which acts as a logical storage container providing data access to your Oracle instances. The SVM creation is done from the FSx console under your file system’s details.With the SVM in place, the next step is configuring iSCSI access. FSxN exposes iSCSI endpoints—these are IP addresses (one per AZ) that your EC2 instances use to connect to the storage over the iSCSI protocol. You can find these endpoint addresses in the FSx console under your SVM’s Endpoints tab.

Amazon FSx Storage Virtual Machine configuration page showing oracle-svm with Created lifecycle state, NFS, iSCSI, and management endpoints for Oracle Database storage connectivity.

SVM Endpoints tab showing iSCSI endpoint IP addresses for each availability zone. These addresses are used in the EC2 instance’s iSCSI discovery configuration.

The iSCSI setup involves creating iGroups (which define which EC2 instances can access the storage) and LUNs (logical storage units mapped to those groups) through the NetApp ONTAP CLI. On the EC2 side, you configure the iSCSI initiator to discover and connect to the FSxN endpoints, then mount the resulting block devices. Using multipath I/O with both endpoints makes sure that Oracle data remains accessible even during an AZ failover. For detailed iSCSI configuration steps, see mounting iSCSI LUNs on Linux clients.

A dedicated security group is required for FSxN access. At minimum, the security group must allow inbound traffic on ports 111 (NFS portmapper), 635 (NFS mountd), 2049 (NFS), 3260 (iSCSI), 4045–4046 (NFS lock), 443 (HTTPS for management), and 22 (SSH for ONTAP CLI). Restrict the source to only your Oracle EC2 instances’ security group.

Step 2: Set up AWS Backup for EC2 instance protection

AWS Backup captures the complete state of your Oracle EC2 instance. The key design choice here is using tag-based resource selection rather than specifying instance IDs directly. Because Auto Scaling groups replace instances (and generate new instance IDs), tag-based selection makes sure that any new instance with the correct tags are automatically included in the backup plan.Configure a backup plan with a frequency appropriate for your environment and set the resource assignment to select EC2 instances matching your application tag (for example, ‘Application: Oracle’).

AWS Backup console showing blog-test backup plan with hourly backup rule targeting Oracle EC2 instances identified by the Application:oracle-db tag.

AWS Backup resource assignment configured with tag-based selection. Any EC2 instances tagged with the application tag are automatically included in the backup plan.

Step 3: Configure Lambda for AMI management

When AWS Backup completes an EC2 backup, it creates an AMI as the recovery point. An Amazon EventBridge rule detects this completion event and triggers a Lambda function. The function extracts the AMI ID from the backup recovery point, updates the SSM Parameter Store parameter with the new AMI ID, and cleans up older AMIs to control storage costs.

AWS Lambda function configuration for oracle-backup-handler showing Python 3.11 runtime, EventBridge trigger, and description indicating it processes AWS Backup completion events and updates AMI in SSM.

Lambda function overview showing the EventBridge trigger, Python 3.11 runtime, and function description indicating its role in processing backup completions and updating AMI references in SSM.

This event-driven approach means the latest AMI is available without manual intervention. The Lambda function needs IAM permissions for EC2 (to manage AMIs), SSM (to update the parameter), and Backup (to read recovery point metadata).

Amazon EventBridge rule oracle-backup-completion configured to trigger the oracle-backup-handler Lambda function when AWS Backup completes an EC2 backup job, with event pattern filtering for COMPLETED state.

EventBridge rule configured to match AWS Backup job completion events for EC2 resources, with the Lambda function as the target.

Step 4: Configure the Systems Manager Parameter Store

The SSM Parameter Store holds the current AMI ID that the Auto Scaling group’s launch template references. The parameter is created with the aws:ec2:image data type, which enables the launch template’s resolve:ssm: functionality, a feature that allows the launch template to dynamically resolve the AMI ID at instance launch time without requiring a template version update.

AWS Systems Manager Parameter Store showing /oracle/ec2/ami-id parameter with AMI value ami-0a705a7d5523c555, version 857, last modified by the oracle-backup-lambda-role on April 25, 2026.

SSM Parameter Store showing the /oracle/ec2/ami-id parameter with aws:ec2:image data type. The “Last modified user” confirms the Lambda function is automatically updating this parameter after each backup cycle.

When Lambda updates this parameter after each backup cycle, the next instance launched by the Auto Scaling group will automatically use the latest AMI. This removes the operational burden of manually updating launch template versions.

Step 5: Set up an Auto Scaling Group with dynamic AMI

The launch template references the SSM parameter using the resolve:ssm: prefix for the AMI ID field. This is the mechanism that ties the entire automation pipeline together. The mechanism backups trigger AMI creation, AMI IDs flow into Parameter Store, and the launch template resolves the latest AMI at launch time.

EC2 Launch Template oracle-db-launch-template version 75 showing AMI ID resolved from SSM parameter resolve:ssm:/oracle/ec2/ami-id with r7i.large instance type for Oracle Database deployment.

Launch template AMI configuration showing the ‘resolve:ssm:’ prefix, which dynamically retrieves the latest AMI ID from Parameter Store at instance launch time.

The Auto Scaling group is configured with minimum, maximum, and desired capacity all set to 1. This is not traditional auto-scaling, it’s a self-healing pattern. The sole purpose is to detect when the Oracle instance becomes unhealthy and automatically launch a replacement. The health check grace period should be set to at least 300 seconds (5 minutes) to allow Oracle sufficient time to start before health checks begin evaluating the new instance.

The launch template also includes a User Data script that runs on each new instance. This script configures the iSCSI initiator, discovers and connects to the FSxN endpoints, mounts the Oracle data volumes, and starts the Oracle database through a systemd service. This automation makes sure that a replacement instance is fully operational without manual intervention.

EC2 Auto Scaling group oracle-db-asg configuration showing desired capacity of 1, scaling limits 1-1, r7i.large instance type, oracle-db-launch-template with Latest version, spanning two availability zone subnets.

Auto Scaling group configured with min=max=desired=1 across two availability zones, providing self-healing capability.

Test the complete workflow

To validate the architecture, simulate an instance failure by terminating the current Oracle EC2 instance.

The expected sequence is:

  1. The Auto Scaling group detects the instance is unhealthy (within approximately 30 seconds)
  2. A new instance launches from the latest AMI resolved from Parameter Store (approximately 2 minutes)
  3. The User Data script connects to FSxN using iSCSI and starts Oracle (approximately 2–3 minutes)
  4. The Oracle database is available and accepting connections (total elapsed: approximately 5 minutes)

Auto Scaling group Activity History showing the self-healing sequence — the unhealthy instance is terminated, and a replacement is launched automatically within seconds.

The new instance automatically inherits the application tags from the Auto Scaling group, which means AWS Backup includes it in the next backup cycle without manual configuration.

Cleaning up

To avoid incurring future charges, delete the resources:

  • Delete Lambda functions and EventBridge rules
  • Remove Parameters from Systems Manager Parameter Store
  • Delete AWS Backup plans and backup vault
  • Deregister created AMIs
  • Terminate Auto Scaling group instances
  • Delete the Amazon FSx for NetApp ONTAP file system

Conclusion

This architecture facilitates Oracle high availability with configuration consistency by combining FSxN persistent shared storage with automated AMI management and AWS Backup protection. The Lambda-driven AMI management from backup recovery points and Parameter Store integration helps make sure that replacement instances launched by Auto Scaling groups always use the latest Oracle host configuration and can immediately connect to the existing Oracle database files stored on FSxN. Replacements occur only when health checks fail. Organizations can target high availability while maintaining configuration consistency across instance replacements. The automated AMI management alleviates configuration drift and makes sure that disaster recovery scenarios restore Oracle instances with identical host-level configurations that can immediately access the persistent Oracle database on shared storage. Healthy instances continue running unchanged, with replacements occurring only, when necessary, because of health check failures.Next steps include implementing cross-Region AMI replication, adding AMI validation testing, and developing custom health checks that verify both Oracle database and host configuration consistency.

Additional resources

Streamline your infrastructure: Automating AMI creation with Kiro CLI and EC2 Image Builder

Post Syndicated from Malini Chatterjee original https://aws.amazon.com/blogs/compute/streamline-your-infrastructure-automating-ami-creation-with-kiro-cli-and-ec2-image-builder/

Managing infrastructure at scale requires robust automation tools that reduce manual effort while maintaining consistency and security. The combination of Kiro CLI and AWS EC2 Image Builder offers a powerful solution for automating the creation, testing, and deployment of Amazon Machine Images (AMIs).

The challenge of manual image management

Traditional approaches of creating and maintaining AMIs often involve manual processes that are time-consuming, error-prone, and difficult to scale. Teams struggle with:

  • Inconsistent configurations across development, testing, and production environments
  • Security vulnerabilities from outdated base images and missing patches
  • Compliance gaps due to manual validation processes
  • Slow deployment cycles caused by repetitive manual tasks

With EC2 Image Builder and Kiro CLI, teams can replace these manual workflows with automated, and secure AMI pipelines. EC2 Image Builder provides the fully managed automation engine, while Kiro CLI brings AI-powered assistance to help you build, iterate, and troubleshoot those pipelines faster — using natural language.

EC2 Image Builder

EC2 Image Builder is a fully managed AWS service that simplifies the creation, maintenance, and deployment of customized, secure, and up-to-date server images. The service provides the following key capabilities:

  • Automated build pipelines: Define your image configuration once, automatically build images on a schedule or trigger basis, and manage the lifecycle of the AMI. Image Builder handles the entire lifecycle of custom AMI creation, testing, distributing and managing the lifecycle of the AMIs.
  • Built-in security: Automatically apply the latest security patches and validate images against AWS security best practices. EC2 Image Builder can enforce security with every created AMI using update-linux/update-windows components patch OS vulnerabilities at build time, IMDSv2 can be enforced at the pipeline level, and Amazon Inspector validates CVE posture before image distribution — all automated, no manual intervention
  • Testing and validation: Run automated tests to verify your images meet functional and security requirements before deployment. This ensures only validated images reach production environments.
  • Multi-region distribution: Automatically distribute your AMIs across multiple AWS regions and share them with specific AWS accounts, streamlining deployment across complex organizational structures.

Kiro CLI: AI-powered infrastructure automation

Kiro CLI brings generative AI capabilities directly to your terminal, enabling natural language interactions with AWS services. This AI-powered command-line interface transforms how developers and operators interact with infrastructure automation tools.

What makes Kiro CLI powerful

  • Natural language commands: Instead of memorizing complex CLI syntax or hand-authoring CloudFormation templates, simply describe what you want to accomplish. Kiro CLI interprets your intent and generates Infrastructure as Code — such as CloudFormation or CDK — that you can review, version-control, and deploy through your existing CI/CD pipelines. For quick, non-destructive exploration (e.g., listing resources or describing configurations), Kiro can also execute AWS API calls directly.
  • Context-aware assistance: Kiro understands your AWS environment and provides intelligent suggestions based on your current context, resources, and best practices. You can connect Kiro CLI to remote tools and systems via Model Context Protocol (MCP), for example, you can connect to AWS MCP servers for and documentation and troubleshooting assistance.
  • Workflow automation: Chain multiple operations together using conversational commands, reducing the cognitive load of managing complex infrastructure tasks.
  • Integration with AWS services: Seamlessly interact with EC2 Image Builder, Systems Manager, and other AWS services without switching between different tools or interfaces.

The synergy: Kiro CLI + EC2 Image Builder, automated pipeline creation

When combined, these tools create a streamlined workflow infrastructure automation:

  • Faster onboarding: Seamless AMI creation and faster maintenance with Kiro CLI. Rather than switching between the AWS Console and AWS CloudFormation documentation during initial exploration, Kiro CLI lets you describe your requirements conversationally — giving you a fast path to a working pipeline that you can then manage and refine through the Console or CloudFormation as your production needs mature.
  • Improved security posture: Automated patching and compliance validation built into every image. Describe your patching requirements conversationally, and Kiro CLI includes the appropriate build components that apply OS-level patches, kernel updates, and CVE fixes directly into the AMI at build time.
  • Consistent deployments: Version-controlled AMI pipelines that produce identical, pre-tested images promoted across dev, staging, and production without manual changes. EC2 Image Builder ensures every build follows the same recipe, components, and validation steps.
  • Reduced operational overhead: Eliminates manual, repetitive tasks around image creation, distribution, and lifecycle management accelerating iteration cycles for pipeline builds.
  • Faster troubleshooting: Kiro CLI parses error output and explains root cause in plain language, cutting the time spent deciphering CloudFormation stack traces and Image Builder build logs.

Getting started

Before implementing this solution, ensure you have the pre-requisites:

  1. Kiro CLI installed (installation guide: for Linux, macOS or Windows) and configured.
  2. Configure the AWS Documentation MCP server , refer the detailed steps here.
  3. AWS account with access permissions for the following services:
    • EC2 Image Builder
    • IAM (for role creation and policy attachment)
    • EC2 (for AMI management)
    • Systems Manager
    • VPC (for network configuration)
  4. An existing VPC with public/private subnets configured

To begin automating your infrastructure using Kiro-CLI, here are some sample prompts that you can use as a baseline:

Example 1: Amazon Linux for EKS nodes

Use case: Teams running Kubernetes on Amazon EKS need custom node AMIs that include the correct container runtime, kubelet version, and security hardening — and that stay current with weekly base image updates. This prompt automates that pipeline and keeps your EKS node groups up to date automatically.

Prompt:

Create a production-ready EC2 Image Builder pipeline using a direct APIs 
for custom EKS-optimized Amazon Linux 2023 AMIs with the following requirements:

- Weekly automated builds triggered by base AMI updates
- AWS managed components for container runtime, kubelet and CloudWatch agent
- Automatic launch template updates for EKS managed node groups

What Kiro CLI generates:

Kiro CLI produces the API calls and supporting configuration to set up:

  • An EC2 Image Builder pipeline with a weekly schedule and base AMI change detection
  • Image recipe based on the EKS-optimized Amazon Linux 2023 AMI
  • Component definitions for container runtime (containerd), kubelet, and CloudWatch Agent
  • Automation to update EKS managed node group launch templates with the new AMI ID after each build
  • If we use a short prompt, Kiro will pick the default values, which customer can definitely change/edit accordingly. However, if we want to be more presriptive, then one can follow a detailed prompt like Example 2 below.

Example 2: Windows server golden image

Use case: Enterprise teams running Windows-based workloads often need a standardized, hardened base image that meets compliance requirements (such as CIS benchmarks) and includes approved software. Manually maintaining this image is error-prone and time-consuming. This prompt automates the full pipeline — from build to distribution.

Prompt:

Create a production-ready EC2 Image Builder pipeline for a Windows Server 2025 
golden image as a single CloudFormation template:

- Monthly automated builds via cron schedule
- Using latest public Windows Server 2025 AMI from AWS
- Components: AWS-managed CloudWatch Agent, AWS CLI, Windows Updates
- Apply AWS-managed STIG components (stig-build-windows) for build-time hardening 
  and corresponding stig-validate-windows for validation.
- For the EC2 instance profile role, use only these AWS-managed policies: 
  EC2InstanceProfileForImageBuilder, EC2InstanceProfileForImageBuilderECRContainerBuilds,
  and AmazonSSMManagedInstanceCore. Do NOT use any policy containing "FullAccess".
- Create a KMS multi-region primary key (MRK) in the pipeline region for AMI
  encryption, with a key policy granting cross-account access to
  [ACCOUNT_1, ACCOUNT_2, ACCOUNT_3] for kms:CreateGrant, kms:DescribeKey,
  and kms:Decrypt. Include a KMS alias. Output the key ARN for replica
  creation in target regions.
- Amazon Inspector vulnerability scanning
- Single pipeline deployed in one region. Use EC2 Image Builder
  DistributionConfiguration to share the output AMI to accounts
  [ACCOUNT_1, ACCOUNT_2, ACCOUNT_3] in regions us-east-1 and us-west-2.
  Do NOT create separate pipelines or stacks per region.
- In the DistributionConfiguration, use AmiDistributionConfiguration's
  built-in SsmParameterConfigurations to write the output AMI ID to
  /golden-image/windows-server-2025/latest in each distribution region.
  Do NOT use Lambda functions or custom resources for SSM parameter updates.
- Create an SNS topic for build notifications. Use the
  InfrastructureConfiguration's built-in SnsTopicArn property for pipeline
  status notifications. Do NOT create EventBridge rules for notifications.
- Lifecycle policy: Disable AMIs after 180 days, delete after 360 days
- Least-privilege IAM roles for Image Builder, EC2 instance profile,
  and lifecycle
- All resource names (KMS alias, IAM roles, SNS topics, Image Builder
  components, recipes, pipelines, infrastructure configs, distribution
  configs, lifecycle policies, EventBridge rules, and SSM parameter paths)
  must include !Sub "${AWS::StackName}" or a parameterized prefix to ensure
  uniqueness. This prevents conflicts if the template is deployed multiple
  times in the same account/region.
- Use AWS-managed components where available
- Parameterize account IDs and regions
- Do NOT create multiple stacks or deploy resources in multiple regions

What Kiro CLI generates:

Kiro CLI interprets this prompt and produces a complete CloudFormation template that includes:

  • An EC2 Image Builder pipeline with a monthly build schedule
  • Image recipe referencing the latest Windows Server 2025 AMI from AWS Systems Manager public parameter
  • AWS-managed components for CloudWatch Agent, AWS CLI, and Windows Updates
  • STIG hardening build component with corresponding validation component
  • KMS key and encryption settings applied to the output AMI
  • Amazon Inspector integration for CVE scanning before distribution
  • Distribution configuration targeting 3 AWS accounts across 2 regions
  • Built-in SsmParameterConfigurations writing the AMI ID to /golden-image/windows-server-2025/latest in each distribution region
  • SNS topic and subscriptions for build success/failure notifications
  • Lifecycle policy: disable AMIs after 180 days, delete after 360 days
  • Least-privilege IAM roles for Image Builder service, EC2 instance profile, and lifecycle management

Once the execution is complete, you can navigate to the EC2 Image Builder  console. Once you are in the AWS Console EC2 Image Builder, you will be on the page for Image Pipelines. You will see in the screenshot below that the new pipeline is now Enabled.

Please note that the name of the pipeline will vary based on your specific inputs. This image is just a sample “enabled” pipeline looks like in EC2 Image Builder  console.

Fig 1: Sample EC2 Image Builder console, after the pipeline is “enabled”

Fig 1: Sample EC2 Image Builder console, after the pipeline is “enabled”.

For more examples and scenarios, you can check Infrastructure Automation with Kiro CLI and EC2 Image Builder workshop.

Cleanup

To avoid ongoing charges, remove all resources created during this walkthrough. The cleanup steps depend on which example you followed.

Example 1: Amazon Linux for EKS nodes cleanup

If you created resources via direct API calls, delete them in the following order:

  • Disable and delete the Image Builder pipeline — this stops the weekly automated builds triggered by base AMI updates.
  • Delete the image recipe based on the EKS-optimized Amazon Linux 2023 AMI.
  • Delete the component definitions for container runtime (containerd), kubelet, and CloudWatch Agent.
  • Delete the infrastructure configuration and distribution configuration.
  • Revert your EKS managed node group launch templates to their previous AMI ID, or point them to a known-good image, before removing the custom AMIs.
  • Deregister any AMIs produced by the pipeline and delete their associated EBS snapshots.
  • Remove IAM roles and instance profiles created for Image Builder and the EC2 instance profile.

Example 2: Windows server golden image cleanup

If you deployed the CloudFormation template, navigate to the AWS CloudFormation console, select your stack, and choose Delete. This removes the pipeline, recipe, components, IAM roles, KMS resources, SNS topic, and lifecycle policy in a single operation.

After the stack is deleted, manually clean up these resources that CloudFormation does not remove:

  • Deregister distributed AMIs — In each target account (ACCOUNT_1, ACCOUNT_2, ACCOUNT_3) and region (us-east-1, us-west-2), deregister the shared Windows Server 2025 AMIs and delete their associated EBS snapshots.
  • Delete SSM parameters — Remove /golden-image/windows-server-2025/latest in each distribution region where it was written by the SsmParameterConfigurations.
  • Schedule KMS key deletion — If the multi-region primary key (MRK) was replicated to other regions, delete the replica keys first, then schedule deletion of the primary key. Revoke any cross-account grants issued to ACCOUNT_1, ACCOUNT_2, and ACCOUNT_3.
  • Remove Amazon Inspector associations — If Inspector was enabled solely for this pipeline, disable it to avoid ongoing scanning charges.
  • Verify lifecycle policy cleanup — Confirm that the lifecycle policy (disable after 180 days, delete after 360 days) was removed with the stack. If any AMIs were already marked for lifecycle action, manually deregister and delete them.

Please note that AMI de-registration and snapshot deletion must be performed in every account and region where images were distributed. Ensure receiving accounts also deregister their copies to stop incurring storage costs.

Conclusion

The combination of AI-powered tools like Kiro CLI with robust automation services like EC2 Image Builder represents the future of infrastructure management. Whether you’re managing dozens or thousands of instances, automating your AMI creation pipeline is no longer optional—it’s essential for maintaining security, consistency, and agility in modern cloud environments.

In this post, we highlighted the benefits of AI-assisted infrastructure management using Kiro CLI. You can start using the workshop Infrastructure Automation with Kiro CLI and EC2 Image Builder for detailed prompts for building production-ready golden AMI pipeline with minimal manual coding.

How Synthesia optimizes generative AI video inference on Amazon EC2 G7e instances

Post Syndicated from Moises Hernandez original https://aws.amazon.com/blogs/architecture/how-synthesia-optimizes-generative-ai-video-inference-on-amazon-ec2-g7e-instances/

Synthesia, an enterprise-focused AI video platform, has transformed content creation, helping everyone to create video content without cameras or microphones. To achieve this, Synthesia allows its users to create video avatars that synthesize the likeness and voice of real people. Synthesia achieves this through a series of in-house developed models based on various architectures, including latent diffusion video generation models.
Customers like Synthesia often choose to host their models on Amazon Elastic Compute Cloud (Amazon EC2) instances because of the flexibility and control over the underlying hardware that the service provides, and among them they find the G7e instance family to be a cost-efficient option to serve GPU-memory intensive generative AI video models, giving customers access to NVIDIA RTX PRO 6000 Blackwell GPUs, with 96GB of GPU memory.

When generating videos using AI models with a Variational Auto Encoder (VAE) Decoder in the architecture, customers often find the GPU utilization is bottlenecked by the saving rate of the video frames to a file held on storage. This causes GPU stalls and reduces average GPU kernel utilization, which is the percentage of time the GPU is actively executing compute kernels rather than idle.

This post introduces a video decoding optimization technique that we have ideated in collaboration with Synthesia Research Engineering team, which we call Asynchronous Frame Generation Pipeline. Adopting this technique allows you to overlap GPU compute, device-to-host (D2H) data transfer, and host-side post-processing. In this post, we apply this technique to the VAE decoder of a Wan video generation model as an example, where our benchmarks on G7e show increased GPU kernel utilization from 82% to 99.9%, in turn leading to an 8.2% decrease in latency (and increase in throughput) for video decoding. We expect this technique to benefit any customer with a chunked video generation pipeline that transfers frames to host memory.

You can find an end-to-end example implementation of the Asynchronous Generation Pipeline applied to the Hugging Face Diffusers format of the Wan 2.2 14B Model in the associated GitHub repository.

In the following section, you will see how latent diffusion models generate video and why the traditional sequential decoding approach can lead to inefficient GPU utilization.

Understanding the sequential decoding bottleneck

Latent diffusion video generation models have emerged as powerful tools for generating temporally coherent video sequences. To reduce compute and memory requirements, these models perform the diffusion process in a compressed latent space of a variational auto-encoder (VAE), as depicted in the below figure, which has generally a much lower dimensionality than the originating video pixel space.

Fig. 1 High-level architecture of a VAE model. The depicted frames are taken from the Wan 2.2 repository sample video used in the example implementation in the next sections.

At inference time, a latent representation is initialized with noise and iteratively denoised via a Diffusion Process. To make sure that the output follows the text prompt, every denoising step is conditioned on the text input if present. After the final denoising step, the Diffusion Process yields a generated video that is still represented in the latent space of the VAE. The last step therefore consists in decoding the latent video back into a human-readable pixel video using the decoder part of the VAE.

Processing the whole latent or pixel video at once is usually too resource-intensive, even on large GPUs. It is therefore common to split the video along the temporal dimension and to decode video frames one latent frame at a time, resulting in a chunk of, for example, 4 consecutive pixel frames, as shown in Fig 2.

Fig.2 Decoding one latent results in a chunk of 4 time-consecutive pixel frames which are transferred from the GPU to the host.

Once a chunk has been decoded and processed on the GPU, the corresponding pixel frames must be transferred back to host (CPU) memory with a D2H transfer, so they can be written to a file or further processed. If you wait to transfer the video frames once the entire video has been decoded, the full decoded video must fit in GPU memory before being transferred, making this strategy hard to scale for arbitrarily long videos. A more memory-efficient alternative is to transfer the decoded frames every time a chunk is decoded, so that the GPU memory footprint of the decoder scales with the size of the chunk instead of the full video.

Traditionally, a newly generated set of frames in a chunk N is passed from GPU memory to CPU RAM synchronously, and it is committed to storage before the CPU can launch the CUDA kernels (referred to as kernels from now on) that process the N+1 chunk. This leads to systematic GPU stalls between chunks, as the copy from device to host prevents the GPU from immediately starting work on the next chunk, reducing overall hardware utilization, and in turn increasing processing time. We will refer to this synchronous process as Sequential Frame Generation Pipeline, which is depicted in Fig. 3.


Fig.3 Schematic representation of the Sequential Frame Generation Pipeline. Launching the kernels processing Chunk N+1 needs to wait for the full copy and storage of the frames in Chunk N.

In the following section, you will learn how to overcome this bottleneck using an asynchronous pipeline that overlaps GPU computation with data transfers and host-side processing.

Asynchronous Frame Generation Pipeline

To minimize GPU stalling, and in turn increase GPU utilization, you need to modify the Sequential Frame Generation Pipeline introduced in the previous section, so that all host-side CPU work (such as appending decoded frames to a file) runs in parallel with a stream of uninterrupted device-side kernels. This section shows you how to achieve this using as an example the implementation of an Asynchronous Wan VAE Decoder, which is implemented with PyTorch and you can find in the associated GitHub repository.

By default, PyTorch schedules work on a single (default) CUDA stream per device which executes the operations in issue order unless additional streams are explicitly created. To decouple compute and D2H copies, the implementation uses two CUDA streams so that the GPU is allowed to overlap compute kernels, which are enqueued on the default stream, and D2H copies on a dedicated copy stream. Compute kernels are enqueued on the default stream, which from now on can be referred to as Compute Stream, and D2H copies on a dedicated copy stream, namely the Copy Stream. In Fig. 4 you can find the full setup on a GPU accelerated instance (G7e in our example) depicted.


Fig. 4 High level diagram of the key components in our implementation of the Asynchronous Frame Generation Pipeline.

On the host side, kernel submissions are interleaved with D2H transfers and post-transfer processing and, to avoid host-side blocking calls and maximize GPU utilization the Asynchronous Frame Generation Pipeline introduces two mechanics:

  • A dedicated Worker CPU thread responsible for reading chunks from Host Memory (RAM), and writing them to file, leaving the main Python thread to focus on launching kernels and scheduling D2H transfers.
  • Two in-memory Buffers on the GPU Memory (VRAM), and on the Host Memory (RAM), and page-lock the required Host Memory buffers to make sure D2H copies are performed fully asynchronously.

Using a double-buffer strategy makes sure that for adjacent chunks the compute, D2H transfer, and host processing can overlap safely as they operate on distinct memory buffers.


Fig. 5 Schematic representation of the interplay between Events, Streams, Buffers, and Worker component in the Asynchronous Frame Generation Pipeline implementation. Events are depicted as left and right conditions, expressing what the process WAITs for, and ISSUEs when it has completed. The size of the boxes representing operations has been scaled to fit the text, and therefore not representative of the actual processing time.

Since buffers can be accessed concurrently by different components, the implementation introduces a synchronization mechanism to avoid different kernels and threads corrupting data held in the buffer. This can be achieved using CUDA Events which are used as a barrier that clears if it can answer closed questions such as: Has decoding of chunk N completed? You can find the interplay between Streams, Threads and Events depicted in Fig. 5.

G7e benchmark results

To quantify the impact of the Asynchronous Frame Generation pipeline, you can benchmark the decoding of a single 41 latent-frames test video for both the Synchronous and Asynchronous pipeline on a g7e.2xlarge EC2 instance using this sample notebook. To have a common baseline, the benchmarks are based on the unoptimized Hugging Face Diffusers Wan 2.2 14B model, and, in both cases, the benchmarking loop performs an initial full decoding cycle to let CUDA and PyTorch initialize and allocate memory pools and cache. After warmup, the benchmarking session carries out 10 consecutive full video decoding cycles. We have run an end-to-end run as an example and present the results in Table 1.

Metric Synchronous (time s /video) Asynchronous (time s / video)
min 21.98 20.16
mean 21.99 20.17
P99 22.01 20.20

Table. 1 Benchmark results for 10 consecutive decoding runs for the Synchronous and Asynchronous pipelines.

The example results show a speed gain of up to 8.2% on this benchmark, decreasing the Real Time Factor of the decoder from 3.21 to 2.95. Considering the g7e.2xlarge pricing as of writing this post ($3.36 per GPU on-demand in the Ohio region), this leads to an average saving of $896 for decoding 1,000 hours of video on a single GPU. This is a theoretical saving, calculated assuming that the underlying model operates at full computational efficiency without bottlenecks.

To have a qualitative understanding of how this performance boost is achieved, you can profile both the Synchronous and Asynchronous pipelines using this sample notebook. The results for an example run are reported in Fig. 6 and Fig. 7, showing the absence of GPU stalls in the Asynchronous pipeline as opposed to the Synchronous pipeline.


Fig. 6 Profile of the Synchronous pipeline single thread and stream. As the main CPU thread is writing Chunk N frames to disk, the GPU stream stalls, waiting for the CPU to launch the kernels needed to process Chunk N+1


Fig.7 In the Asynchronous pipeline, the Compute Stream is not interrupted by the copying and writing of the frames to disk. The Main Thread is free to launch the processing kernels. This figure is displayed with a different zoom level than Fig. 6 to highlight the qualitative differences.

By focusing on the temporal axis for two consecutive chunks in the steady state, you can quantify the GPU kernel utilization increase, which, in our example run was 82% for the Synchronous case, increasing to 99.9% for the Asynchronous case.

Conclusion

In this post, we demonstrated how the Asynchronous Frame Generation Pipeline can improve GPU utilization when decoding latent videos on Amazon EC2 G7e instances. By decoupling GPU compute from device-to-host transfers and host-side I/O using dual CUDA streams, pinned memory buffers, and a dedicated worker thread, we eliminated the GPU stalls inherent in traditional synchronous decoding pipelines.

The sample benchmarks on the Wan 2.2 14B VAE decoder show an 8.2% reduction in decoding latency, translating to approximately $896 in savings per 1,000 hours of decoded video on a single GPU when considering the g7e.2xlarge pricing as of writing this post ($3.36 per GPU on-demand in the Ohio region). These gains come without any changes to model weights or inference quality, purely from better hardware utilization. We expect the kernel utilization gain to be even more impactful on optimized and compiled models, which make more efficient use of the GPU.

The techniques presented here are not specific to the Wan architecture, nor to the specific GPU utilized. Any chunked video generation pipeline that transfers frames to host memory can benefit from this approach. We encourage you to explore the associated sample implementation to experiment with how the Asynchronous Frame Generation Pipeline could be integrated into your own video generation workloads.

To get started with G7e instances for your generative AI video workloads, visit the Amazon EC2 G7e instance page.

About the authors

Sharing Capacity Blocks for ML Across Your AWS Organization

Post Syndicated from Tyler Klimas original https://aws.amazon.com/blogs/compute/sharing-capacity-blocks-for-ml-across-your-aws-organization/

When your data science team reserves GPU instances for a two-week training job but completes it in four days, that capacity has the potential to sit unused while your computer vision team waits another week to start their project. Now you can eliminate this GPU waste and scheduling conflict by sharing Capacity Blocks for ML across your AWS Organization. This scheduling mismatch between teams creates bottlenecks that delay product launches, increase infrastructure costs, and slow your ability to deliver machine learning (ML) powered features to customers. With cross-account sharing for Amazon Elastic Compute Cloud (Amazon EC2) Capacity Blocks for ML, you can now distribute reserved graphics processing unit (GPU) capacity across teams based on actual demand rather than rigid scheduling predictions. This means your computer vision team can use the capacity as soon as the data science team is done.

In this post, we’ll show you how to configure cross-account sharing for Capacity Blocks for ML, set up monitoring for your shared resources, and optimize instance utilization through alerting. By increasing the utilization rates and reducing over-provisioning, you improve your resource efficiency and cost optimization for your organization.

You can reduce idle resources in your ML team’s account by sharing capacity with other teams waiting for GPUs. Additionally, you can maintain Capacity Blocks for ML centrally. This lets you control which teams have access to the capacity and helps you reduce waste and bottlenecks in your organization. Before starting into the tutorial, let’s review how Capacity Blocks for ML and AWS RAM work together.

Overview

Capacity Blocks for ML let you reserve GPU-based accelerated compute instances ahead of time for short duration ML workloads. When you launch instances in Capacity Blocks for ML, Amazon EC2 automatically places the instances in Amazon EC2 UltraClusters, giving you low-latency, petabit scale networking. UltraClusters provide the high performance networking your training workloads require.

You see exactly when GPU capacity is available and schedule your Capacity Blocks for ML to start when it makes sense for your project. You pay upfront for the entire reservation period. This makes Capacity Blocks for ML useful when you need GPUs for days to months. It provides predictable capacity without long-term commitments.

When you purchase Capacity Blocks for ML, you can share it with other accounts in your AWS Organization using AWS Resource Access Manager (AWS RAM). With AWS RAM, you can share AWS resources across accounts within your organization. When you share with other accounts, those accounts become consumer accounts that can launch instances using your capacity. As the owner account, you pay the upfront reservation cost and retain ownership. If you’re launching instances from a consumer account, you are responsible for additional costs such as operating system licensing charges. Capacity Blocks can be shared to multiple accounts simultaneously, with the entire Capacity Block reservation being shared on a first come, first served basis.

Overview of AWS Organizations showing an owner account sharing to two consumer accounts using an AWS RAM resource share.

Figure 1: Capacity Block sharing using Resource Access Manager.

With the share feature, you benefit from flexible GPU capacity management when your priorities shift, or teams finish work at different times. Now, when your data science team completes experimentation early, your other teams can use that capacity for production training. If priorities shift mid-quarter, you can move capacity where it’s needed most.

In this tutorial, you’ll share a Capacity Block for ML across accounts and then create an alarm to monitor utilization when it drops below a threshold. Before you start, complete the following prerequisites.

Prerequisites

To share Capacity Blocks for ML, you must first find and purchase a Capacity Block. Only standard Capacity Blocks for ML can be shared using AWS RAM. UltraServer Capacity Blocks are not eligible for sharing.

You can share Capacity Blocks only within your AWS Organization. Verify the owner of the Capacity Blocks as well as the consumer(s) are within the same organization. For guidance, see Creating and configuring an organization.

Before sharing Capacity Blocks, you must configure resource sharing with AWS Organizations. Only the management account with the following required AWS Identity and Access Management (IAM) permissions can enable resource sharing within an Organization:

ram:EnableSharingWithAwsOrganization

iam:CreateServiceLinkedRole

organizations:EnableAWSServiceAccess

organizations:DescribeOrganization

Using the AWS Management Console of the management account:

  1. Navigate to the AWS RAM console.
  2. In the left navigation pane, choose Settings.
  3. Select Enable sharing with AWS Organizations.

Enable sharing with AWS Organizations in Settings of Resource Access Manager.

Figure 2: Enable sharing with AWS Organizations in AWS RAM.

Using the AWS Command Line Interface (CLI):

  1. Run this command to give AWS RAM trusted access to your organization’s account structure: 
        aws organizations enable-aws-service-access --service-principal ram.amazonaws.com
  2. Turn on resource sharing within your organization so accounts and OUs can access shared resources without manual acceptance: 
        aws ram enable-sharing-with-aws-organization

After you turn on sharing in your organization, you need the following IAM permissions to create resource shares:

ram:CreateResourceShare

ram:AssociateResourceShare

ram:GetResourceShares

Now that you’ve completed the prerequisites, you’ll learn how to share the Capacity Blocks for ML to other accounts of your organization.

Tutorial

You’ll complete this sharing process in four steps:

  1. Create a resource share.
  2. Attach Capacity Block to the resource share.
  3. Verify the share in your consumer account.
  4. Monitor the resource share.

Verify Capacity Reservation (console)

  1. In your Capacity Block owner’s account, navigate to the Amazon EC2 console.
  2. In the left navigation pane, choose Capacity Reservations.
  3. Confirm your Capacity Blocks for ML is in Active or Scheduled state.
  4. If you have a Resource share already configured, choose Actions, Share and select your Resource share.

Figure 3: EC2 Capacity Reservation

Share Capacity Blocks for ML (console)

You now will create a Resource Share and associate the following resources.

  1. Navigate to the AWS RAM console in your Capacity Block owner’s account.
  2. In the left navigation pane, choose Resource shares.
  3. Choose Create resource share.

Create Resource share in AWS RAM Console

Figure 4: Create Resource share in AWS RAM

  1. Enter a name for your resource share.
  2. Under Select resource type, choose Capacity Reservations.
  3. Select your Capacity Block from the list.
  4. Under Principals, specify the accounts, organizational units, or organization to share with.Select principals to share resources in AWS RAM.Figure 5: Select principals to share resources with
  5. Choose Create resource share.

Share Capacity Blocks for ML (AWS CLI)

Replace the placeholder values in the following CLI commands below with your actual values:

  • arn:aws:ec2:us-east-2:123456789012:capacity-reservation/cr-1234abcd56EXAMPLE → Your Capacity Reservation ARN
  • 111122223333 → The AWS account ID of the principal you’re sharing with
  • arn:aws:ram:us-east-2:123456789012:resource-share/7ab63972-b505-7e2a-420d-6f5d3EXAMPLE → Your RAM resource share ARN

 

  1. Create resource share with Capacity Block and principals:
    aws ram create-resource-share \
         --name capacity-block-share \
         --resource-arns arn:aws:ec2:us-east-2:123456789012:capacity-reservation/cr-1234abcd56EXAMPLE \ 
         --principals 111122223333
  1. To add a Capacity Block to existing resource share:
    aws ram associate-resource-share \
         --resource-share-arn arn:aws:ram:us-east-2:123456789012:resource-share/7ab63972-b505-7e2a-420d-6f5d3EXAMPLE \
         --resource-arns arn:aws:ec2:us-east-2:123456789012:capacity-reservation/cr-1234abcd56EXAMPLE

Access and Launch shared Capacity Blocks (console)

After you add the Capacity Block to a resource share, your consumer accounts automatically gain access when you share the Capacity Block within the same AWS Organization.

  1. Navigate to the AWS RAM console in your consumer account.
  2. In the left navigation pane, choose Shared with me, Resource shares. Verify the Resource share is Active.Within your consumer account, verify resource share.Figure 6: In your consumer account, verify the resource share
  3. Navigate to the Amazon EC2 console. In the left navigation pane, choose Capacity Reservations.
  4. Confirm the shared Capacity Block appears and is in Active or Scheduled state. Because sharing is asynchronous, the Capacity Block may take a few moments to appear even after the resource share shows Active.
  5. Navigate to the Amazon EC2 console and choose Launch instance.
  6. Configure your instance as required (AMI, instance type, key pair, etc.).
  7. Under Advanced details, for Purchasing option, choose Capacity Blocks.
  8. For Capacity reservation, choose Specify Capacity Reservation.
  9. For Capacity reservation targeted ID, select or enter your Capacity Block reservation ID.
  10. Launch the instance.

Access shared Capacity Blocks (AWS CLI)

Replace the placeholder values in the following CLI commands below with your actual values:

  • ami-0abcdef1234567890 → Your AMI ID
  • cr-0c54f6734d944345a → Your Capacity Reservation ID
  1. List resource shares in your consumer account:
    aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS
  1. Verify that capacity reservation is available:
    aws ec2 describe-capacity-reservations
  1. Launch EC2 instance from Capacity Block:
    aws ec2 run-instances \
         --image-id ami-0abcdef1234567890 \
         --count 1 \
         --instance-type p5.48xlarge \
         --key-name my-key-pair \
         --subnet-id subnet-0abcdef1234567890 \
         --instance-market-options MarketType='capacity-block' \
         --capacity-reservation-specification CapacityReservationTarget={CapacityReservationId=cr-0c54f6734d944345a}

Monitor usage (console)

You can create Amazon CloudWatch alarms to proactively identify low utilization of your Capacity Block. This helps you to improve the usage of your capacity reservation. This section shows you how to create an Amazon Simple Notification Service (Amazon SNS) email notification when the number of running instances drops below a certain threshold.

In addition to monitoring usage, AWS CloudTrail logs capture API events related to your Capacity Block, including the CapacityReservationId. As the owner, you can see which accounts are consuming instances and when.

Step 1: Create an SNS Topic for Notifications

  1. Open the Amazon SNS console.
  2. In the left navigation pane, choose Topics.
  3. Choose Create topic.
  4. For Type, select Standard.

Create SNS Topic for CloudWatch alarm.

Figure 7: Create SNS Topic

  1. For Name, enter capacity-block-alerts.
  2. Choose Create topic.

Step 2: Create an SNS Subscription:

  1. In the left navigation pane, choose Create subscription.Create SNS SubscriptionFigure 8: Create SNS Subscription
  2. For Protocol, choose Email.
  3. For Endpoint, enter your email address.
  4. Choose Create subscription.

Step 3: Create the CloudWatch Alarm

  1. Navigate to the Amazon CloudWatch console.
  2. In the left navigation pane, choose Alarms, All alarms.
  3. Choose Create alarm.
  4. Choose Select metric.
  5. Choose EC2 Capacity Reservations.
  6. Choose By Capacity Reservation.
  7. Find your Capacity Block ID (e.g., cr-12345678abcdef).
  8. Select the checkbox next to InstanceUtilization.
  9. Choose Select metric.

Step 4: Configure the Metric

  1. Under Metric:
  2. For Statistic: Select Average.
  3. For Period: Select 5 minutes.
  4. Under Conditions choose Threshold type: Select Static.
  5. Whenever InstanceUtilization is…: Select Lower than…: Enter 20 (This metric is measured in percentage).
  6. Choose Next.

Step 5: Configure Actions

  1. Under Notifications:
  2. Alarm state trigger: Select In alarm.
  3. Select an SNS topic: Choose Select an existing SNS topic.
  4. Send a notification to…: Select capacity-block-alerts.Configure CloudWatch AlarmFigure 9: Configure CloudWatch Alarm
  5. Choose Next.

Step 6: Name and Create Alarm

  1. For Alarm name, enter: CapacityBlock-LowUtilization-cr-123456789abcdef.
  2. For Alarm description, enter: Alert when Capacity Block utilization drops below 20%.
  3. Choose Next.
  4. Review your configuration and choose Create alarm.

Monitor usage (AWS CLI)

Replace the placeholder values in the following CLI commands below with your actual values:

  • 123456789012 → Your 12-digit AWS account number
  • cr-0c54f6734d944345a → Your Capacity Reservation ID
  • 7ab63972-b505-7e2a-420d-6f5d3EXAMPLE → Your RAM resource share ID
  • [email protected] → Your email address for notifications

 

  1. Create the SNS topic:
    aws sns create-topic \
        --name capacity-block-alerts
  1. Using the TopicArn from the output, subscribe your email:
    aws sns subscribe \
        --topic-arn arn:aws:sns:us-east-2:123456789012:capacity-block-alerts \
        --protocol email \
        --notification-endpoint [email protected]
  1. Create the full CloudWatch alarm:
    aws cloudwatch put-metric-alarm \
        --alarm-name "CapacityBlock-LowUtilization-cr-1234EXAMPLE" \
        --alarm-description "Alert when Capacity Block utilization drops below 20%" \
        --namespace "AWS/EC2CapacityReservations" \
        --metric-name "InstanceUtilization" \
        --dimensions Name=CapacityReservationId,Value=cr-0c54f6734d944345a \
        --statistic Average \
        --period 300 \
        --evaluation-periods 1 \
        --threshold 20 \
        --comparison-operator LessThanThreshold \
        --alarm-actions arn:aws:sns:us-east-2:123456789012:capacity-block-alerts

Clean up (console)

As the owner of the Capacity Block, you retain the ability to modify the resource share. However, owners cannot modify instances that consumers launch into Capacity Blocks they have shared. This section outlines how to clean up your previous work.

Using the AWS Management Console:

Stop sharing the Capacity Block

  1. Navigate to AWS RAM console.
  2. In the left navigation, choose Shared by me, Resource shares.
  3. Select your resource share.
  4. Choose Modify.
  5. Remove the Capacity Block from the resource share or delete the entire resource share.

Delete the CloudWatch Alarm

  1. Navigate to the Amazon CloudWatch console.
  2. In the left navigation, choose Alarms, All alarms.
  3. Select the alarm you created.
  4. Choose Actions, Delete.
  5. Confirm deletion.

Delete the SNS Topic and Subscription

  1. Navigate to the Amazon SNS console.
  2. In the left navigation, choose Subscriptions.
  3. Select the subscription and choose Delete.
  4. In the left navigation, choose Topics.
  5. Select capacity-block-alerts and choose Delete.
  6. Confirm deletion.

Clean up (AWS CLI)

Replace the placeholder values in the following CLI commands below with your actual values:

  • 123456789012 → Your 12-digit AWS account number
  • 7ab63972-b505-7e2a-420d-6f5d3EXAMPLE → Your RAM resource share ID
  • cr-0c54f6734d944345a → Your Capacity Reservation ID
  • a1b2c3d4-5678-90ab-cdef-EXAMPLE → Your SNS subscription ID
  1. Remove the Capacity Block from the resource share 
        aws ram disassociate-resource-share \
        --resource-share-arn arn:aws:ram:us-east-2:123456789012:resource-share/7ab63972-b505-7e2a-420d-6f5d3EXAMPLE \
        --resource-arns arn:aws:ec2:us-east-2:123456789012:capacity-reservation/cr-0c54f6734d944345a
  2. Delete the resource share 
        aws ram delete-resource-share \
        --resource-share-arn arn:aws:ram:us-east-2:123456789012:resource-share/7ab63972-b505-7e2a-420d-6f5d3EXAMPLE
  3. Delete the CloudWatch Alarm 
        aws cloudwatch delete-alarms \
         --alarm-names "CapacityBlock-LowUtilization-cr-123456789"
  4. Delete the SNS Topic and Subscription
    1. List subscriptions to get the subscription ARN 
          aws sns list-subscriptions-by-topic \
         --topic-arn arn:aws:sns:us-east-2:123456789012:capacity-block-alerts
    2. Delete the subscription 
          aws sns unsubscribe \
         --subscription-arn arn:aws:sns:us-east-2:123456789012:capacity-block-alerts:a1b2c3d4-5678-90ab-cdef-EXAMPLE
    3. Delete the Topic 
          aws sns delete-topic \
         --topic-arn arn:aws:sns:us-east-2:123456789012:capacity-block-alerts

Conclusion

In this post, we showed you how to share Capacity Blocks for ML across your AWS Organization using AWS RAM. We covered configuring the AWS RAM integration with Organizations, creating resource shares, and accessing shared Capacity Blocks for ML from consumer accounts. Finally, we showed you how to monitor and alert on low instance utilization.

By sharing Capacity Blocks across your organization, you can reduce idle GPU capacity, eliminate scheduling bottlenecks between teams, and maximize the return on your reserved compute investment. To take this further, consider building dashboards in Amazon CloudWatch to track utilization trends across multiple Capacity Blocks.

You can get started by purchasing Capacity Blocks for ML and sharing it across your organization today. For more details on other resources you can share with AWS RAM, visit the Shareable AWS resources in the user guide. If you have questions, contact your AWS account team or leave a comment below.

AWS Weekly Roundup: Amazon Bedrock AgentCore payments, Agent Toolkit for AWS, and more (May 11, 2026)

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-amazon-bedrock-agentcore-payments-agent-toolkit-for-aws-and-more-may-11-2026/

My most exciting news of last week: Amazon Bedrock AgentCore previewed the first managed payment capabilities enabling AI agents to autonomously access and pay for APIs, MCP servers, web content, and other agents. Built in partnership with Coinbase and Stripe, it removes the undifferentiated heavy lifting of building customized systems for billing, credential management, and compliance.

You can connect a Coinbase CDP wallet or Stripe Privy wallet as a payment connection, set session-level spending limits, and your agent transacts autonomously during execution. What excites me most is what AgentCore payments can unlock—like a research agent that can pay for real-time market data on the fly, or a coding agent calling paid APIs mid-task.

To learn more, visit the blog post, dive deeper using the documentation, and get started with the AgentCore CLI.

Last week’s launches
Here are last week’s launches that caught my attention:

  • Agent Toolkit for AWS – A production-ready suite of tools and guidance, available at no additional charge, that helps AI coding agents build on AWS with fewer errors, lower token costs, and enterprise-grade security controls. The Agent Toolkit for AWS is the successor to the MCP servers, plugins, and skills available on AWS Labs. To get started, visit the quick start guide or browse the available skills and plugins on GitHub.
  • AWS MCP Server GA – You can use a managed remote Model Context Protocol (MCP) server that gives AI agents and coding assistants secure, authenticated access to all AWS services through a small, fixed set of tools. It is part of the Agent Toolkit for AWS. To learn more, visit Seb Stormacq’s blog post.
  • Amazon WorkSpaces for AI agents (Preview) – You can use AI agents to securely access and operate desktop applications through managed WorkSpaces environments. This capability allows organizations to automate everyday workflows at scale while maintaining full enterprise-grade governance and compliance. To learn more, visit Micah Walter’s blog post.
  • Amazon EC2 M8idn/M8idb and R8idn/R8idb instances – These instances are powered by custom sixth-generation Intel Xeon Scalable processors available only on AWS and the latest sixth-generation AWS Nitro cards. These instances deliver up to 43% better compute performance per vCPU compared to previous-generation instances. M8idn/R8idn instances offer up to 600 Gbps network bandwidth, and M8idb/R8idb instances deliver up to 300 Gbps EBS bandwidth.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Additional updates
Here are some additional news items that you might find interesting:

  • Valkey turns two – Valkey stands as proof that open, community-driven technology innovates faster, scales further, and delivers more value than any single-vendor model. Valkey has surpassed 100 million Docker pulls (up 17x year over year) and attracted more than 225 contributors who have submitted over 1,500 pull requests, roughly double the development pace of Redis over the same period. You can also use the latest Valkey 9.0 in Amazon ElastiCache.
  • Query billion-scale vectors with SQL – You can learn how to query Amazon S3 Vectors from Amazon Aurora PostgreSQL-Compatible Edition using standard SQL, and how to combine vector similarity results with relational filters in a single query, for example, finding the most semantically similar products and then filtering by price, stock status, or tenant in one SQL statement.
  • Building an end-to-end agentic SRE using AWS DevOps Agent – Learn how to configure DevOps Agent Spaces that define an investigation scope, integrating seamlessly with Amazon CloudWatch, Splunk, GitHub, and Slack. You can also learn how to trigger automated investigations via webhooks, generate mitigation plans, and hand off agent-ready specs to coding agents like Kiro for implementation.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events as well as AWS Summits and AWS Community Days. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— Channy

Securing open proxies in your AWS environment

Post Syndicated from Dodd Mitchell original https://aws.amazon.com/blogs/security/securing-open-proxies-in-your-aws-environment/

This article shows you how to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP address reputation, and control costs.

An open proxy is a server that forwards traffic on behalf of internet users without requiring authentication. While proxies can support legitimate use cases such as load balancing or caching, open proxies allow unrestricted access that threat actors can use to hide harmful activity. In Amazon Web Services (AWS) environments, open proxies often result from misconfigured Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, or compute resources such as AWS Lambda functions. These resources expose proxy functionality without access controls.

Open proxies come in several forms. Common open proxies can include:

  • HTTP proxies: HTTP proxies forward HTTP requests to web servers, making them useful for web traffic management. These proxies can create potential issues when they’re unsecured.
  • SOCKS proxies: SOCKS proxies support a wider range of traffic types and provide more flexibility. These proxies create a broader potential for misuse.
  • Transparent proxies: Transparent proxies intercept traffic without the client’s knowledge and are often used to filter content. These proxies can become security liabilities when misconfigured.
  • Reverse proxies: Reverse proxies help with internal routing. Unauthorized users can misuse these proxies if they’re exposed.

Knowing these risks can help you better protect your AWS environment.

Security risks

Because of the unrestricted configuration of open proxy servers, threat actors target them to conduct denial of service (DoS) events, intrusion attempts, distribute spam, and other forms of unauthorized activity. These open proxy servers allow threat actors to hide their actual IP address and other forms of identification from the intended targets.

When your AWS infrastructure hosts an open proxy, several risks emerge that can affect both your operations and customers:

  • Threat actors can misuse your resources, which can result in your IP address being added to security service and reputation system block lists. This can affect your legitimate business operations and customer access. When external parties use your infrastructure for harmful activities, the reputation damage extends beyond immediate technical concerns to affect your ability to reach customers and partners.
  • Unexpected costs from resource consumption occur when threat actors use your bandwidth and compute capacity. The traffic patterns that proxy abuse generate can also alert AWS security monitoring systems and create additional operational overhead as you investigate and respond to these alerts.
  • Service disruptions might affect your legitimate workloads because unauthorized traffic competes for resources with your business-critical applications. This competition for resources can potentially degrade performance or cause availability issues for your customers.

Implementing security measures

To prevent the risks associated with open proxies, it’s essential to implement proper security controls for proxy services in AWS environments. The following guidance is a comprehensive approach that you can follow to secure your proxy infrastructure.

Access control implementation

An important security step is to use passwords and authentication mechanisms to restrict access to proxy services. Configure your proxies to accept connections only from known, trusted IP address ranges. For Elastic Load Balancing (ELB), limit access based on source IP addresses and add authentication to proxies behind the load balancers. When you create new instances in Amazon Elastic Kubernetes Service (Amazon EKS), limit access to your balancer in each instance. If instances don’t have public IP addresses, then you can limit access to the balancer instead. If instances have public IP addresses, then you must limit access to those IP addresses.

When possible, use AWS PrivateLink virtual private cloud (VPC) endpoints to provide private connectivity to AWS services without exposing them to the internet. Deploy proxy services in private subnets with controlled outbound access through NAT gateways or other controlled channels. For Amazon EC2 and Amazon Lightsail resources, update the attached security group to prevent public internet access. To secure the proxy, you must either limit access to specific IP addresses or implement authentication on the endpoint.

Authentication and authorization

Turn on authentication for the proxy software and use strong credentials, certificates, or integration with AWS Identity and Access Management (IAM) and AWS Directory Service. Apply IAM policies with the principle of least privilege to limit access to only what users need to perform their tasks. This approach reduces the potential effects of credential compromise and helps maintain clear accountability for resource access.

Monitoring and detection

To detect unusual proxy activity, configure Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty. Use Amazon CloudWatch alarms to notify you of abnormal traffic patterns that might indicate unauthorized use of your proxy services. These monitoring capabilities provide visibility into your network traffic patterns and help you identify both legitimate usage and potential security concerns.

Deployment best practices

Use HTTPS for ELB traffic to protect data in transit, and restrict security groups to necessary ports to minimize the surface area for potential misuse. Integrate AWS WAF with balancers to filter web traffic based on rules that you define. You can also use AWS Network Firewall for advanced traffic filtering capabilities. For APIs, deploy Amazon API Gateway with authentication and authorization controls to manage access to your backend services. This layered approach to security helps protect your infrastructure at multiple points in the traffic flow.

Regular security assessments

Run Amazon Inspector to scan for misconfigurations in your infrastructure, and use AWS Security Hub to centralize security findings across your AWS environment. Conduct penetration tests in accordance with AWS policy to identify potential security issues before they can result in unintended access.

Incident response planning

Automate remediation with AWS Config rules and Automation, a capability of AWS Systems Manager, to respond rapidly to security events. Maintain incident response runbooks that outline clear steps for addressing proxy-related security incidents, and decommission unused resources that could become security liabilities.

Documented procedures and automated responses reduce the time between detection and remediation and minimizes the potential effects of security incidents on your operations.

Benefits of proper proxy security

When you implement these security measures, you gain the following advantages for your AWS environment:

  • Protection of your IP address reputation helps maintain customer trust and prevents security services from blocking your legitimate traffic. When your infrastructure maintains a positive reputation, your business communications reach their intended recipients without interference.
  • Cost control prevents unauthorized users from consuming your AWS resources and generating unexpected charges on your account. When you restrict access to legitimate users and use cases, you maintain predictable costs that align with your business needs.
  • Operational stability reduces the risk of service disruptions that abuse of your proxy infrastructure can cause. When you dedicate your resources to serving your customers rather than supporting unauthorized activity, you can deliver consistent performance and availability.
  • Enhanced visibility into your network traffic patterns helps you identify both legitimate usage and potential security concerns. This awareness allows you to make informed decisions about capacity planning, security improvements, and operational optimizations.

Conclusion

Open proxies present a serious risk in AWS environments, but you can effectively secure proxies with the right measures. By implementing strict access controls and additional security practices such as authentication, monitoring, and regular assessments, you can prevent misuse, protect your infrastructure, and maintain your IP address reputation.

Taking proactive steps strengthens your own environment and supports the broader security of the internet ecosystem. Under the AWS shared responsibility model, you’re responsible for the configuration and maintenance of these security controls, while AWS provides the underlying secure infrastructure. By following the guidance in this article, you can build a robust security posture that protects your proxy infrastructure while supporting your legitimate business needs.

If you have feedback about this post, submit comments in the Comments section below.

Dodd Mitchell

Dodd Mitchell

Dodd is a member of the AWS Trust and Safety team in Virginia, supporting customers in navigating abuse, phishing, and content-related risks. He works closely with partners to strengthen response processes and build more resilient, trustworthy platforms.