# 지속 가능성
<a name="sustainability"></a>

지속 가능성 원칙은 환경 영향, 특히 에너지 소비 및 효율성에 중점을 두고 있는데, 이는 건축가가 자원 사용을 줄이기 위한 직접적인 조치를 알아낼 수 있는 중요한 수단이기 때문입니다. 구현 방법에 대한 권장 가이드는 [지속 가능성 원칙 백서에 나와 있습니다](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp). 

**Topics**
+ [설계 원칙](sus-design-principles.md)
+ [정의](sus-def.md)
+ [모범 사례](sus-bp.md)

# 설계 원칙
<a name="sus-design-principles"></a>

 클라우드에는 6가지 지속 가능성 설계 원칙이 있습니다. 
+  **영향 이해:** 클라우드 워크로드의 영향을 측정하고 워크로드의 향후 영향을 모델링합니다. 고객의 제품 사용으로 인한 영향과 최종 폐기 및 사용 중지로 인한 영향을 포함하여 영향의 모든 원인을 포함합니다. 작업 단위당 필요한 리소스 및 배출량을 검토하여 생산량을 클라우드 워크로드의 총 영향과 비교합니다. 이 데이터를 사용하여 핵심 성과 지표(KPI)를 설정하고, 영향을 줄이면서 생산성을 개선하는 방법을 평가하며, 시간 경과에 따른 제안된 변경의 영향을 예측할 수 있습니다. 
+  **지속 가능성 목표 수립:** 각 클라우드 워크로드에 대해 트랜잭션당 필요한 컴퓨팅 및 스토리지 리소스의 절감과 같은 장기적인 지속 가능성 목표를 설정합니다. 기존 워크로드에 대한 지속 가능성 개선의 투자 수익률을 모델링하고 소유자에게 지속 가능성 목표에 투자하는 데 필요한 리소스를 제공합니다. 성장을 계획하고 워크로드를 설계하여 성장으로 인해 사용자당 또는 트랜잭션당 등 적절한 단위에 대해 측정된 영향 강도를 줄입니다. 목표를 통해 비즈니스 또는 조직의 보다 광범위한 지속 가능성 목표를 지원하고, 회귀를 식별하며, 잠재적 개선 영역의 우선 순위를 지정할 수 있습니다. 
+  **활용률 극대화:** 워크로드 크기를 적절하게 조정하고 효율적인 설계를 구현하여 높은 활용률을 보장하고 기본 하드웨어의 에너지 효율성을 극대화합니다. 호스트당 기준 전력 소비로 인해 30% 활용률로 실행되는 호스트 두 개는 60%로 실행되는 호스트 하나보다 효율성이 떨어집니다. 동시에 유휴 리소스, 프로세싱 및 스토리지를 없애거나 최소화하여 워크로드에 전력을 공급하는 데 필요한 총 에너지를 줄입니다. 
+  **보다 효율적인 최신 하드웨어와 소프트웨어 제품 및 서비스 예측 및 도입:** 파트너와 공급업체가 업스트림 개선을 통해 클라우드 워크로드의 영향을 줄일 수 있도록 지원합니다. 새롭고 더 효율적인 하드웨어와 소프트웨어 제품 및 서비스를 지속적으로 모니터링하고 평가합니다. 새롭고 효율적인 기술을 신속하게 도입할 수 있도록 유연성을 고려하여 설계합니다. 
+  **관리형 서비스 사용:** 광범위한 고객 기반에서 서비스를 공유하면 리소스 활용률을 극대화하여 클라우드 워크로드를 지원하는 데 필요한 인프라의 양을 줄일 수 있습니다. 예를 들어, 고객은 워크로드를 AWS 클라우드로 마이그레이션하고 AWS가 대규모로 운영하며 효율적인 운영을 책임지는 서버리스 컨테이너용 AWS Fargate 등 관리형 서비스를 채택하여 전력 및 네트워킹과 같은 일반적인 데이터 센터 구성 요소의 영향을 공유할 수 있습니다. Amazon S3 수명 주기 구성 또는 Amazon EC2 Auto Scaling을 사용하여 자주 액세스하지 않는 데이터를 콜드 스토리지로 자동 이동함으로써 수요에 맞게 용량을 조정하는 등 영향을 최소화할 수 있는 관리형 서비스를 사용합니다.
+  **클라우드 워크로드의 다운스트림 영향 감소:** 서비스를 사용하는 데 필요한 에너지 또는 리소스의 양을 줄입니다. 고객이 서비스를 사용하기 위해 디바이스를 업그레이드할 필요가 없도록 하거나 필요성을 줄입니다. Device Farm을 사용하여 테스트함으로써 예상되는 영향을 파악하고 고객과의 테스트를 통해 서비스 사용으로 인한 실제 영향을 이해합니다. 

# 정의
<a name="sus-def"></a>

 클라우드의 지속 가능성에는 6가지 모범 사례 영역이 있습니다. 
+ 리전 선택
+ 사용자 행동 패턴
+ 소프트웨어 및 아키텍처 패턴
+ 데이터 패턴
+ 하드웨어 패턴
+ 개발 및 배포 프로세스

 클라우드에서의 지속 가능성이란 주로 프로비저닝된 리소스의 이점을 극대화하고 필요한 총 리소스를 최소화하면서 워크로드의 모든 구성 요소에서 에너지 절감과 효율성에 초점을 맞춘 지속적인 노력을 말합니다. 이러한 노력은 초기에 효율적인 프로그래밍 언어를 선택하고, 현대적인 알고리즘을 채택하고, 능률적인 데이터 스토리지 기술을 사용하여 적절한 규모의 효과적인 컴퓨팅 인프라를 배포하고 고성능 최종 사용자 하드웨어 요구 사항을 최소화하는 등 다양하게 나타날 수 있습니다. 

# 모범 사례
<a name="sus-bp"></a>

**Topics**
+ [리전 선택](sus-region-selection.md)
+ [사용자 행동 패턴](sus-user-behavior-patterns.md)
+ [소프트웨어 및 아키텍처 패턴](sus-software-architecture-patterns.md)
+ [데이터 패턴](sus-data-patterns.md)
+ [하드웨어 패턴](sus-hardware-patterns.md)
+ [개발 및 배포 패턴](sus-development-deployment-patterns.md)
+ [리소스](sus-resources.md)

# 리전 선택
<a name="sus-region-selection"></a>

비즈니스 요구 사항과 지속 가능성 목표를 기반으로 워크로드를 구현할 리전을 선택합니다.

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다. 지속 가능성 관련 질문 및 모범 사례 목록은 [부록](a-sustainability.md)을 참조하십시오.)


| SUS 1: 지속 가능성 목표를 지원하기 위한 리전은 어떻게 선택합니까? | 
| --- | 
| Amazon 재생 에너지 프로젝트 근처의 리전 및 그리드의 탄소 집약도가 다른 위치(또는 리전)보다 낮은 리전을 선택합니다. | 

# 사용자 행동 패턴
<a name="sus-user-behavior-patterns"></a>

사용자가 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 사용자 로드에 지속적으로 일치하도록 인프라 크기를 조정하고 사용자를 지원하는 데 필요한 최소 리소스만 배포되도록 합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용하지 않는 기존 자산을 제거합니다. 생성된 자산 중 사용되지 않는 자산을 식별하고 생성을 중지합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.


| SUS 2: 사용자 행동 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까? | 
| --- | 
|  사용자가 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 사용자 로드에 지속적으로 일치하도록 인프라 크기를 조정하고 사용자를 지원하는 데 필요한 최소 리소스만 배포되도록 합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용하지 않는 기존 자산을 제거합니다. 생성된 자산 중 사용되지 않는 자산을 식별하고 생성을 중지합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.   | 

사용자 로드에 맞게 인프라 크기 조정: 활용률이 낮거나 없는 기간을 식별하고 리소스의 크기를 조정하여 초과 용량을 제거하고 효율성을 개선합니다.

SLA를 지속 가능성 목표에 맞추기: 가용성 또는 데이터 보존 기간과 같은 서비스 수준 계약(SLA)을 정의 및 업데이트하여 워크로드를 지원하는 동시에 비즈니스 요구 사항을 지속적으로 충족하는 데 필요한 리소스 수를 최소화합니다.

사용하지 않는 자산의 생성 및 유지 관리 배제: 애플리케이션 자산(사전 컴파일된 보고서, 데이터 집합, 정적 이미지 등)과 자산 액세스 패턴을 분석하여 중복성, 활용률 저하 및 잠재적 폐기 대상을 식별합니다. 생성된 자산을 중복 콘텐츠(예: 중복되거나 공통된 데이터 집합 및 출력이 포함된 월간 보고서)로 통합하여 출력을 복제할 때 소비되는 리소스를 제거합니다. 사용되지 않는 자산(예: 더 이상 판매되지 않는 제품 이미지)을 폐기하여 리소스를 확보하고 워크로드를 지원하는 데 사용되는 리소스 수를 줄입니다. 

사용자 위치에 대한 워크로드의 지리적 배치 최적화: 네트워크 액세스 패턴을 분석하여 고객이 접속하는 지리적 위치를 식별합니다. 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄이기 위해 네트워크 트래픽이 이동해야 하는 거리가 적은 리전 및 서비스를 선택합니다. 

수행된 활동에 대한 팀원 리소스 최적화: 팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 지속 가능성에 미치는 영향을 최소화합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 공유 클라우드 데스크톱에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.

# 소프트웨어 및 아키텍처 패턴
<a name="sus-software-architecture-patterns"></a>

로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다. 

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.


| SUS 3: 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까? | 
| --- | 
|  로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다.   | 

비동기식 및 예약된 작업을 위한 소프트웨어와 아키텍처 최적화: 효율적인 소프트웨어 설계 및 아키텍처를 사용하여 작업 단위당 필요한 평균 리소스를 최소화합니다. 구성 요소를 균일하게 활용하여 작업 간에 유휴 상태인 리소스를 줄이고 로드 급증의 영향을 최소화하는 메커니즘을 구현합니다. 

사용 빈도가 낮거나 전혀 없는 워크로드 구성 요소 제거 또는 리팩터링: 워크로드 활동을 모니터링하여 시간 경과에 따른 개별 구성 요소의 활용률 변화를 파악합니다. 사용되지 않아 더 이상 필요하지 않은 구성 요소와 활용률이 낮은 구성 요소를 리팩터링하여 낭비되는 리소스를 제한합니다.

가장 많은 시간 또는 리소스를 소모하는 코드 영역 최적화: 워크로드 활동을 모니터링하여 가장 많은 리소스를 사용하는 애플리케이션 구성 요소를 식별합니다. 이러한 구성 요소 내에서 실행되는 코드를 최적화하여 성능을 극대화하면서 리소스 사용을 최소화합니다. 

고객 디바이스 및 장비에 대한 영향 최소화: 고객이 서비스를 사용하기 위해 이용하는 디바이스와 장비, 예상 수명 주기, 이러한 구성 요소 교체가 재정 및 지속 가능성에 미치는 영향을 이해합니다. 소프트웨어 패턴 및 아키텍처를 구현하여 고객이 디바이스를 교체하고 장비를 업그레이드해야 하는 필요성을 최소화합니다. 예를 들어, 이전 하드웨어 및 운영 체제 버전과 역호환되는 코드를 사용하여 새로운 기능을 구현하거나 대상 디바이스의 저장 용량을 초과하지 않도록 페이로드 크기를 관리합니다. 

데이터 액세스 및 저장 패턴을 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처 사용: 데이터가 워크로드 내에서 사용되고, 사용자가 소비하고, 전송 및 저장되는 방식을 이해합니다. 데이터 처리 및 스토리지 요구 사항을 최소화하는 기술을 선택합니다.

# 데이터 패턴
<a name="sus-data-patterns"></a>

로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다. 

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.


| SUS 4: 데이터 액세스 및 사용 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까? | 
| --- | 
|  데이터 관리 원칙을 구현하여 워크로드를 지원하는 데 필요한 프로비저닝된 스토리지와 이를 사용하는 데 필요한 리소스를 줄입니다. 데이터를 이해하고 데이터의 비즈니스 가치와 데이터 사용 방식을 가장 잘 지원하는 스토리지 기술과 구성을 사용합니다. 요구 사항이 감소하면 데이터를 더 효율적이고 성능이 낮은 스토리지로 수명 주기를 변경하고 더 이상 필요하지 않은 데이터는 삭제합니다.   | 

데이터 분류 정책 구현: 데이터를 분류하여 비즈니스 성과에 미치는 분류의 영향을 파악합니다. 이 정보를 사용하여 데이터를 보다 에너지 효율적인 스토리지로 이동하거나 안전하게 삭제할 수 있는 시기를 결정합니다. 

데이터 액세스 및 스토리지 패턴을 지원하는 기술 사용: 데이터 액세스 및 저장 방법을 가장 잘 지원하는 스토리지를 사용하여 워크로드를 지원하면서 프로비저닝된 리소스를 최소화합니다. 예를 들어, SSD(Solid State Device)는 자기 드라이브보다 에너지 집약적이므로 활성 데이터 사용 사례에만 사용해야 합니다. 자주 액세스하지 않는 데이터에는 에너지 효율적인 아카이빙 클래스 스토리지를 사용합니다. 

수명 주기 정책을 사용하여 불필요한 데이터 삭제: 모든 데이터의 수명 주기를 관리하고 삭제 일정을 자동으로 적용하여 워크로드의 총 스토리지 요구 사항을 최소화합니다.

블록 스토리지에서 과다 프로비저닝 최소화: 프로비저닝된 스토리지의 총량을 최소화하려면 워크로드에 적합한 크기가 할당된 블록 스토리지를 생성하면 됩니다. 탄력적 볼륨을 사용하면 컴퓨팅 리소스에 연결된 스토리지의 크기를 조정할 필요 없이 데이터가 증가함에 따라 스토리지를 확장할 수 있습니다. 탄력적 볼륨을 정기적으로 검토하고 과다 프로비저닝된 볼륨을 현재 데이터 크기에 맞게 축소합니다. 

불필요하거나 중복된 데이터 제거: 필요한 경우에만 데이터를 복제하여 총 스토리지 사용을 최소화합니다. 파일 및 블록 수준에서 데이터를 중복 제거하는 백업 기술을 사용합니다. SLA를 충족하는 데 필요한 경우를 제외하고 RAID(Redundant Array of Independent Drives) 구성의 사용을 제한합니다.

공유 파일 시스템 또는 객체 스토리지를 사용하여 공용 데이터에 액세스: 공유 스토리지와 단일 정보 소스를 도입하여 데이터 중복을 방지하고 워크로드의 총 스토리지 요구 사항을 줄입니다. 필요한 경우에만 공유 스토리지에서 데이터를 가져옵니다. 사용하지 않는 볼륨을 분리하여 리소스를 확보합니다. 네트워크 간 데이터 이동을 최소화합니다. 공유 스토리지를 사용하고 리전 데이터 스토어의 데이터에 액세스하여 워크로드의 데이터 이동을 지원하는 데 필요한 총 네트워킹 리소스를 최소화할 수 있습니다. 

다시 생성하기 어려운 경우에만 데이터 백업: 스토리지 소비를 최소화하려면 비즈니스 가치가 있거나 규정 준수 요구 사항을 충족하는 데 필요한 데이터만 백업하면 됩니다. 백업 정책을 검토하고 복구 시나리오에서 가치를 제공하지 않는 임시 스토리지는 제외합니다. 

# 하드웨어 패턴
<a name="sus-hardware-patterns"></a>

하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어를 선택합니다. 

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.


| SUS 5: 하드웨어 관리 및 사용 방식이 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까? | 
| --- | 
|  하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어를 선택합니다.   | 

요구 사항을 충족하는 데 필요한 최소한의 하드웨어 사용: 클라우드의 기능을 사용하여 워크로드 구현을 자주 변경할 수 있습니다. 변화하는 요구 사항에 따라 배포된 구성 요소를 업데이트합니다. 

영향이 가장 적은 인스턴스 유형 사용: 새로운 인스턴스 유형의 릴리스를 지속적으로 모니터링하고 기계 학습 훈련 및 추론, 비디오 트랜스코딩과 같은 특정 워크로드를 지원하도록 설계된 인스턴스 유형을 포함하여 에너지 효율성 개선의 이점을 활용합니다.

관리형 서비스 사용: 관리형 서비스는 배포된 하드웨어의 높은 평균 활용률과 지속 가능성 최적화를 유지하는 책임을 AWS로 이전합니다. 관리형 서비스를 사용하여 지속 가능성에 미치는 서비스의 영향을 서비스의 모든 테넌트에 분산하여 개인의 기여도를 낮춥니다. 

GPU 사용 최적화: 그래픽 처리 장치(GPU)는 높은 전력 소비의 원인이 될 수 있으며 렌더링, 트랜스코딩, 기계 학습 훈련 및 모델링과 같은 많은 GPU 워크로드는 매우 가변적입니다. 필요한 시간 동안만 GPU 인스턴스를 실행하고 필요하지 않은 경우 자동화를 통해 GPU 인스턴스를 폐기하여 리소스 사용을 최소화합니다. 

# 개발 및 배포 패턴
<a name="sus-development-deployment-patterns"></a>

개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다. 

 다음은 지속 가능성 고려 사항에 중점을 둔 질문입니다.


| SUS 6: 개발 및 배포 프로세스가 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까? | 
| --- | 
|  개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다.   | 

지속 가능성 개선을 신속하게 도입할 수 있는 방법 채택: 잠재적 개선 사항을 프로덕션 환경에 배포하기 전에 테스트하고 검증합니다. 개선 사항으로 실현될 미래의 잠재적 이익을 계산할 때 테스트 비용을 고려합니다. 소규모 개선 사항을 제공할 수 있도록 저비용 테스트 방법을 개발합니다. 

워크로드를 최신 상태로 유지: 최신 운영 체제, 라이브러리 및 애플리케이션을 통해 워크로드 효율성을 개선하고 보다 효율적인 기술을 더 쉽게 도입할 수 있습니다. 공급 업체가 자체적인 지속 가능성 목표를 충족할 수 있는 기능을 제공함에 따라, 최신 소프트웨어에는 워크로드의 지속 가능성에 미치는 영향을 보다 정확하게 측정하는 기능이 포함될 수도 있습니다.

구축 환경의 사용률 제고: 자동화와 코드형 인프라를 사용하여 필요 시 사전 프로덕션 환경을 가동하고 사용하지 않을 때는 해당 환경을 종료합니다. 일반적인 패턴은 개발 담당 팀원의 근무 시간과 일치하는 가용 기간을 예약하는 것입니다. 최대 절전 모드는 상태를 유지하고 필요할 때만 인스턴스를 빠르게 온라인으로 전환할 수 있는 유용한 도구입니다. 버스트 용량이 포함된 인스턴스 유형, 스팟 인스턴스, 탄력적 데이터베이스 서비스, 컨테이너 및 기타 기술을 사용하여 사용량에 따라 개발 및 테스트 용량을 조정합니다. 

테스트에 관리형 Device Farm 사용: 관리형 Device Farm은 하드웨어 제조 및 리소스 사용이 지속 가능성에 미치는 영향을 여러 테넌트에 분산시킵니다. 관리형 Device Farm은 다양한 디바이스 유형을 제공하며, 사용 빈도가 낮은 오래된 하드웨어를 지원하고 불필요한 디바이스 업그레이드로 인한 고객의 지속 가능성에 미치는 영향을 방지할 수 있습니다.

# 리소스
<a name="sus-resources"></a>

 지속 가능성 관련 AWS 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하십시오. 

## 백서
<a name="sus-wp"></a>
+  [지속 가능성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp) 

## 동영상
<a name="sus-video"></a>
+  [The Climate Pledge(기후 협약)](https://www.youtube.com/watch?v=oz9iO0EOpI0&ref=wellarchitected-wp)