# SUS03-BP02 - Remove or refactor workload components with low or no use

Best practice: SUS03-BP02
Pillar: Sustainability
Source: https://wellarchitected.cloudvisor.eu/docs/sustainability/sus03-bp02.html

## Implementation Guidance

Use "Remove or refactor workload components with low or no use" to make architecture and operational choices based on evidence rather than assumptions. Define clear criteria, collect current-state data, and compare options against business outcomes and risk tolerance.

For the question "How do you take advantage of software and architecture patterns to support your sustainability goals?", define measurable outcomes, assign owners, and review execution regularly. Integrate this practice into delivery and operations processes so improvements persist as workloads and requirements evolve.

### Key Steps

1. **Define decision criteria and scope**:
   - Document what "Remove or refactor workload components with low or no use" must address in your environment
   - Set quantitative and qualitative criteria for comparing options
   - Identify stakeholders who approve final decisions

2. **Perform analysis with objective evidence**:
   - Collect metrics, constraints, and dependency data from current operations
   - Compare alternatives against reliability, performance, and risk outcomes
   - Record tradeoffs and assumptions in an architecture decision log

3. **Operationalize and revisit decisions**:
   - Implement selected decisions with explicit owner accountability
   - Define review triggers for demand, risk, or architecture changes
   - Update standards and patterns based on observed outcomes

## Risk / Impact

**Level of risk if not implemented**: Medium

**Impact**: Without this best practice, workloads typically accumulate inefficiencies and execution drift that increase failure probability over time. Problems often surface during traffic spikes, major releases, or dependency failures.

**Benefits of implementation**:
- More predictable operational and engineering outcomes
- Better alignment between architecture decisions and business goals
- Continuous improvement through measurable feedback loops

## AWS Services to Consider

<div class="aws-service">
  <div class="aws-service-content">
    <h4>AWS Lambda</h4>
    <p>Runs event-driven automation without managing servers, ideal for remediation workflows.</p>
  </div>
</div>

<div class="aws-service">
  <div class="aws-service-content">
    <h4>Amazon ECS</h4>
    <p>Runs container workloads with managed orchestration and scaling options.</p>
  </div>
</div>

<div class="aws-service">
  <div class="aws-service-content">
    <h4>Amazon EKS</h4>
    <p>Provides managed Kubernetes control planes for containerized application operation.</p>
  </div>
</div>

<div class="aws-service">
  <div class="aws-service-content">
    <h4>Amazon EventBridge</h4>
    <p>Routes events and triggers automation workflows for rapid operational response.</p>
  </div>
</div>

## Related Resources

<div class="related-resources">
  <h2>Related Resources</h2>
  <ul>
    <li><a href="https://docs.aws.amazon.com/wellarchitected/latest/framework/sus-03.html">SUS03: How do you take advantage of software and architecture patterns to support your sustainability goals?</a></li>
    <li><a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/welcome.html">AWS Well-Architected Framework - Sustainability Pillar</a></li>
    <li><a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/design-principles.html">Sustainability Design Principles</a></li>
  </ul>
</div>