sustainability-optimization

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sustainability Optimization Assessment

可持续性优化评估

Step 1: Gather context

步骤1：收集上下文

Ask the user:

What workload would you like me to assess for sustainability? Please share:

Architecture overview (compute, storage, database, networking services)

Utilization patterns (average CPU/memory utilization, traffic patterns, idle periods)

Region selection rationale (proximity to users, compliance, or legacy?)

Sustainability goals (optional — organizational carbon targets, reporting requirements)

If context is already provided, proceed directly.

询问用户：

您希望我评估哪个工作负载的可持续性？请分享：

架构概述（计算、存储、数据库、网络服务）

使用模式（平均CPU/内存使用率、流量模式、空闲时段）

区域选择依据（靠近用户、合规要求还是遗留系统原因？）

可持续性目标（可选——组织碳目标、报告要求）

如果已提供上下文，直接进入下一步。

Step 2: Assess resource utilization

步骤2：评估资源利用率

Evaluate how effectively provisioned resources are used:

Compute utilization — Average CPU and memory usage across instances/containers. Are instances idle during off-hours?
Storage efficiency — Are old/unused objects retained? Are lifecycle policies in place? Is storage class appropriate for access frequency?
Database utilization — Is provisioned capacity matched to actual demand? Are there idle read replicas?
Network efficiency — Are data transfers minimized? Are endpoints co-located where possible?
Over-provisioning — Are resources sized for peak when demand is variable?

评估已配置资源的使用效率：

计算利用率 — 实例/容器的平均CPU和内存使用率。实例在非工作时段是否处于空闲状态？
存储效率 — 是否保留了旧的/未使用的对象？是否已设置生命周期策略？存储类别是否与访问频率匹配？
数据库利用率 — 配置的容量是否与实际需求匹配？是否存在空闲的只读副本？
网络效率 — 是否已最小化数据传输？是否尽可能实现了端点共置？
过度配置 — 当需求可变时，资源是否按峰值需求进行配置？

Step 3: Evaluate architecture efficiency

步骤3：评估架构效率

Assess:

Serverless adoption — Could provisioned compute be replaced with Lambda, Fargate, or Aurora Serverless to scale to zero?
Managed services — Are there self-managed workloads (Kafka, Elasticsearch, Redis) that could use managed equivalents with better utilization?
Graviton adoption — Are ARM-based instances used where supported? (better performance per watt)
Async patterns — Are synchronous processes that could be event-driven identified? (reduces idle waiting)
Batch optimization — Are batch jobs scheduled during low-carbon grid periods? Are they right-sized?

评估：

Serverless采用情况 — 已配置的计算是否可以替换为Lambda、Fargate或Aurora Serverless以实现缩容至零？
托管服务使用情况 — 是否存在可以使用利用率更高的托管等效服务的自管理工作负载（如Kafka、Elasticsearch、Redis）？
Graviton采用情况 — 是否在支持的场景下使用了基于ARM的实例？（每瓦性能更优）
异步模式应用 — 是否识别出可转换为事件驱动的同步流程？（减少空闲等待）
批处理优化 — 批处理作业是否安排在电网低碳时段运行？是否已合理调整规模？

Step 4: Assess data management practices

步骤4：评估数据管理实践

Evaluate:

Data lifecycle — Are retention policies defined and enforced? Is cold data moved to Glacier/Deep Archive?
Data deduplication — Is redundant data storage eliminated?
Compression — Are stored and transferred payloads compressed?
Tiered storage — Is Intelligent-Tiering used for unpredictable access patterns?
Data proximity — Is data stored close to where it's processed?

评估：

数据生命周期 — 是否定义并执行了保留策略？冷数据是否已迁移至Glacier/Deep Archive？
数据去重 — 是否已消除冗余数据存储？
压缩处理 — 存储和传输的负载是否已压缩？
分层存储 — 是否针对不可预测的访问模式使用了Intelligent-Tiering？
数据就近性 — 数据是否存储在靠近处理位置的区域？

Step 5: Evaluate scaling and scheduling

步骤5：评估伸缩与调度策略

Assess:

Scale-to-zero — Can non-production environments shut down outside business hours?
Scheduled scaling — Are predictable low-traffic periods handled with reduced capacity?
Right-sizing cadence — How often are instance types and sizes reviewed?
Spot Instances — Are fault-tolerant workloads using Spot for better resource pooling?
Region carbon intensity (required finding) — Always assess whether current region selection considers carbon intensity. State whether workloads could benefit from running in lower-carbon regions, or explain why current placement is justified (latency, compliance, data residency).

评估：

缩容至零 — 非生产环境能否在工作时间外关闭？
调度式伸缩 — 是否针对可预测的低流量时段配置了缩减的容量？
合理调整规模的频率 — 实例类型和大小的审核频率是多少？
Spot Instances使用 — 容错工作负载是否使用Spot实例以实现更优的资源池化？
区域碳强度（必填评估项） — 始终评估当前区域选择是否考虑了碳强度。说明工作负载是否能从运行在低碳区域中获益，或解释当前部署位置的合理性（延迟、合规、数据驻留要求）。

Step 6: Assess software and code efficiency

步骤6：评估软件与代码效率

Evaluate:

Algorithmic efficiency — Are there known inefficient algorithms or unnecessary computation?
Caching — Does caching reduce redundant computation and data retrieval?
Payload optimization — Are API responses, assets, and transfers minimized?
Framework efficiency — Are lightweight runtimes used where possible? (compiled languages vs interpreted for compute-heavy tasks)
Client-side impact (required finding) — Always assess downstream/end-user energy impact: page weight, unnecessary API calls, unoptimized assets, client-side computation. Even for well-optimized backends, there are usually client-side opportunities. If not applicable (headless/API-only), state why.

评估：

算法效率 — 是否存在已知的低效算法或不必要的计算？
缓存机制 — 缓存是否减少了重复计算和数据检索？
负载优化 — API响应、资源和传输数据是否已最小化？
框架效率 — 是否在可行场景下使用了轻量级运行时？（计算密集型任务中编译型语言对比解释型语言）
客户端影响（必填评估项） — 始终评估下游/终端用户的能耗影响：页面大小、不必要的API调用、未优化的资源、客户端计算。即使后端优化良好，通常也存在客户端优化机会。如果不适用（如无头/仅API服务），请说明原因。

Step 7: Produce findings

步骤7：生成评估结果

Output:

markdown

undefined

输出：

markdown

undefined

Sustainability Assessment: {Workload Name}

Summary

Estimated utilization efficiency: {percentage}
Key waste areas: {top 2-3}
Findings: {X} High Impact, {Y} Medium Impact, {Z} Improvements

Estimated utilization efficiency: {percentage}
Key waste areas: {top 2-3}
Findings: {X} High Impact, {Y} Medium Impact, {Z} Improvements

High-Impact Findings

{Each: what's wasteful, estimated carbon/resource impact, how to fix, effort required}

Optimization Opportunities

Resource Utilization

Resource	Current Utilization	Target	Action
{resource}	{current %}	{target %}	{action to take}

Resource	Current Utilization	Target	Action
{resource}	{current %}	{target %}	{action to take}

Architecture Efficiency

{Each: current approach, sustainable alternative, expected improvement}

Data Management

{Each: current practice, optimized practice, storage/transfer reduction}

Scheduling & Scaling

{Each: current behavior, optimized behavior, resource hours saved}

Sustainability Scorecard

Domain	Score	Key Gap
Resource Utilization	{1-5}	{gap}
Architecture Efficiency	{1-5}	{gap}
Data Management	{1-5}	{gap}
Scaling & Scheduling	{1-5}	{gap}
Software Efficiency	{1-5}	{gap}

Domain	Score	Key Gap
Resource Utilization	{1-5}	{gap}
Architecture Efficiency	{1-5}	{gap}
Data Management	{1-5}	{gap}
Scaling & Scheduling	{1-5}	{gap}
Software Efficiency	{1-5}	{gap}

Prioritized Remediation Plan

Quick Wins (< 1 week)

{Scheduling, lifecycle policies, enabling Intelligent-Tiering}

Foundation (1-4 weeks)

{Right-sizing, Graviton migration, scale-to-zero for non-prod}

Strategic (1-3 months)

{Architecture changes, serverless migration, region optimization}

AWS Sustainability Tools

Customer Carbon Footprint Tool — Track emissions in the AWS console
Compute Optimizer — Right-size recommendations
S3 Storage Lens — Storage efficiency insights
Trusted Advisor — Idle resource detection

Customer Carbon Footprint Tool — Track emissions in the AWS console
Compute Optimizer — Right-size recommendations
S3 Storage Lens — Storage efficiency insights
Trusted Advisor — Idle resource detection

Next Steps

{Concrete actions: quick wins to implement now, architectural changes to plan}

undefined

{Concrete actions: quick wins to implement now, architectural changes to plan}

undefined

Step 8: Offer follow-up

步骤8：提供后续服务

After delivering the assessment, offer:

Would you like me to:

Quantify the carbon impact of a specific optimization?

Design a scale-to-zero strategy for non-production environments?

Create a resource right-sizing implementation plan?

Evaluate Graviton migration feasibility for your workloads?

完成评估后，向用户提供以下选项：

您是否需要我：

量化特定优化措施的碳影响？

为非生产环境设计缩容至零的策略？

创建资源合理调整规模的实施计划？

评估您的工作负载迁移至Graviton的可行性？