# 지속 가능성
**Topics**
+ [리전 선택](a-region-selection.md)
+ [사용자 행동 패턴](a-user-behavior-patterns.md)
+ [소프트웨어 및 아키텍처 패턴](a-sus-software-architecture-patterns.md)
+ [데이터 패턴](a-sus-data-patterns.md)
+ [하드웨어 패턴](a-sus-hardware-patterns.md)
+ [개발 및 배포 프로세스](a-sus-development-deployment.md)
# 리전 선택
**Topics**
+ [SUS 1 지속 가능성 목표를 지원하기 위한 리전은 어떻게 선택합니까?](w2aac19c15b5b5.md)
# SUS 1 지속 가능성 목표를 지원하기 위한 리전은 어떻게 선택합니까?
비즈니스 요구 사항과 지속 가능성 목표를 기반으로 워크로드를 구현할 리전을 선택합니다.
모범 사례:
# SUS01-BP01 Amazon 재생 에너지 프로젝트 근처의 리전 및 그리드의 탄소 집약도가 다른 위치(또는 리전)보다 낮은 리전 선택
Amazon 재생 에너지 프로젝트 근처의 리전 및 그리드의 탄소 집약도가 다른 위치(또는 리전)보다 낮은 리전을 선택합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
Amazon 재생 에너지 프로젝트 근처의 리전 및 그리드의 탄소 집약도가 다른 위치(또는 리전)보다 낮은 리전을 선택합니다.
## 리소스
**관련 문서:**
+ [세계 속의 Amazon](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true)
+ [Renewable Energy Methodology(재생 에너지 방법론)](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology)
+ [워크로드의 리전을 선택할 때 고려해야 할 사항](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
# 사용자 행동 패턴
**Topics**
+ [SUS 2 사용자 행동 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?](w2aac19c15b7b5.md)
# SUS 2 사용자 행동 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?
사용자가 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 사용자 로드에 지속적으로 일치하도록 인프라 크기를 조정하고 사용자를 지원하는 데 필요한 최소 리소스만 배포되도록 합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용하지 않는 기존 자산을 제거합니다. 생성된 자산 중 사용되지 않는 자산을 식별하고 생성을 중지합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.
모범 사례:
# SUS02-BP01 사용자 로드에 맞게 인프라 크기 조정
활용률이 낮거나 없는 기간을 식별하고 리소스를 스케일 다운하여 용량이 초과되지 않도록 하고 효율성을 개선합니다.
**일반적인 안티 패턴:**
+ 사용자 로드에 따라 인프라를 확장하지 않습니다.
+ 항상 인프라를 수동으로 확장합니다.
+ 조정 이벤트 후에 다시 축소하는 대신 증가된 용량을 그대로 둡니다.
**이 모범 사례 확립의 이점:** 워크로드 탄력성을 구성하고 테스트하면 워크로드가 환경에 미치는 영향을 줄이고 비용을 절감하며 성능 벤치마크를 유지할 수 있습니다. 클라우드에서 탄력성을 활용하여 사용자 로드 급증 기간 및 이후에 용량을 자동으로 확장하여 고객의 필요를 충족하는 데 필요한 정확한 수의 리소스만 사용할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
+ 탄력성은 보유한 리소스의 공급을 해당 리소스의 수요에 맞춥니다. 인스턴스, 컨테이너 및 함수를 자동 조정과 함께 사용하거나 서비스의 기능으로 사용하는 경우 탄력성 개선을 위한 메커니즘이 제공됩니다. 아키텍처에서 탄력성을 사용하면 사용자 로드가 적은 기간에 빠르고 워크로드를 쉽게 스케일 다운할 수 있습니다.
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 을(를) 사용하면 애플리케이션의 사용자 로드를 처리하는 데 사용할 수 있는 적절한 수의 Amazon EC2 인스턴스가 있는지 확인할 수 있습니다.
+ [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) 을(를) 사용하면 Amazon EC2을(를) 벗어난 개별 AWS 서비스(예: Lambda 기능 또는 Amazon Elastic Container Service (Amazon ECS) 서비스)에 대한 리소스를 자동으로 확장할 수 있습니다.
+ [Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 를 사용하면 AWS에서 Kubernetes 클러스터를 자동으로 확장할 수 있습니다.
+ 스케일 업 또는 스케일 다운 대한 지표가 배포 중인 워크로드 유형에 대해 검증되었는지 확인합니다. 동영상 트랜스코딩 애플리케이션을 배포하는 경우 100%의 CPU 활용률이 예상되므로, 기본 지표로 사용해서는 안 됩니다. 필요한 경우 스케일링 정책에 대해 [맞춤형 지표](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (예: 메모리 사용률)를 사용할 수 있습니다. 올바른 지표를 선택하려면 Amazon EC2에 대한 다음 지침을 고려하세요.
+ 지표는 유효한 사용률 지표여야 하며 인스턴스가 얼마나 많이 사용되는지를 설명해야 합니다.
+ 지표 값은 Auto Scaling 그룹 내 인스턴스 수에 비례하여 늘거나 줄어야 합니다.
+ [수동 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) 대신 [동적 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) 을 Auto Scaling 그룹에 사용합니다. 또한 동적 스케일링에 [대상 추적 스케일링 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) 을 사용하는 것이 좋습니다.
+ 워크로드 배포에서 확장 및 축소 이벤트를 모두 처리할 수 있는지 확인합니다. 축소 이벤트에 대한 테스트 시나리오를 생성하여 워크로드가 예상대로 작동하는지 확인하세요. **활동 기록** 을 사용하여 Auto Scaling 그룹에 대한 스케일링 활동을 테스트 및 확인할 수 있습니다.
+ 워크로드의 예측 가능한 패턴을 평가하고 예측 및 계획된 수요 변화에 따라 사전 예방적으로 확장합니다. [Amazon EC2 Auto Scaling으로 예측 스케일링](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 을 사용하여 용량을 과도하게 예측할 필요를 제거할 수 있습니다.
## 리소스
**관련 문서:**
+ [Amazon EC2 Auto Scaling 시작하기](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and Kibana(Amazon OpenSearch Service, Amazon Kinesis Data Firehose 및 Kibana를 사용하여 사용자 행동 분석)](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [Amazon CloudWatch란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS X-Ray란 무엇인가요?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [Monitoring DB load with Performance Insights on Amazon RDS(Amazon RDS의 성능 개선 도우미로 DB 로드 모니터링)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling(Amazon EC2 Auto Scaling을 사용한 예측 확장에 대한 기본 지원 소개)](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [How to create an Amazon EC2 Auto Scaling policy based on a memory utilization metric(메모리 사용률 지표를 기반으로 Amazon EC2 Auto Scaling 정책을 생성하는 방법)(Linux)](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/)
+ [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler(Karpenter - 고성능 오픈 소스 Kubernetes Cluster Autoscaler 소개)](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
**관련 동영상:**
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2(더 정확하고, 더 빠르고, 더 저렴한 컴퓨팅: Amazon EC2 비용 최적화)CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw)
**관련 예시:**
+ 실습: Amazon EC2 Auto Scaling 그룹 예시
+ [실습: Karpenter를 사용하여 오토스케일링 구현](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정
가용성 또는 데이터 보존 기간과 같은 서비스 수준 계약(SLA)을 정의 및 업데이트하여 워크로드를 지원하는 동시에 비즈니스 요구 사항을 지속적으로 충족하는 데 필요한 리소스 수를 최소화합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 비즈니스 요구 사항을 충족하는 동시에 지속 가능성 목표를 지원하는 SLA를 정의합니다.
+ 비즈니스 요구 사항을 초과하지 않고 충족하도록 SLA를 재정의합니다.
+ 허용 가능한 수준으로 서비스를 줄여 지속 가능성에 미치는 영향을 크게 줄이는 절충안을 제시합니다.
+ 비즈니스에 중요한 기능에 우선순위를 두고 중요하지 않은 기능에 대해 더 낮은 서비스 수준(예: 응답 시간 또는 복구 시간 목표)을 허용하는 설계 패턴을 사용합니다.
## 리소스
**관련 문서:**
+ [AWS 서비스 수준 계약(SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)
+ [SaaS 공급자의 서비스 수준 계약 중요성](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지
애플리케이션 자산(예: 사전 컴파일된 보고서, 데이터 집합, 정적 이미지 등)과 자산 액세스 패턴을 분석하여 중복성, 활용률 저하 및 잠재적 폐기 대상을 식별합니다. 생성된 자산을 중복 콘텐츠(예: 중복되거나 공통된 데이터 집합 및 출력이 포함된 월간 보고서)로 통합하여 출력을 복제할 때 소비되는 리소스를 제거합니다. 사용되지 않는 자산(예: 더 이상 판매되지 않는 제품 이미지)을 폐기하여 리소스를 확보하고 워크로드를 지원하는 데 사용되는 리소스 수를 줄입니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 정적 자산을 관리하고 더 이상 필요하지 않은 자산을 제거합니다.
+ 생성된 자산을 관리하고 더 이상 필요하지 않은 자산 생성을 중지하고 제거합니다.
+ 중복 생성 자산을 통합하여 중복 처리를 제거합니다.
+ 더 이상 필요하지 않은 관리 자산의 생산 및 저장을 중단하도록 제3자에게 지시합니다.
+ 생성된 중복 자산을 통합하도록 제3자에게 지시합니다.
## 리소스
**관련 문서:**
+ [지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 스토리지](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS02-BP04 사용자 위치에 맞게 워크로드의 지리적 배치 최적화
네트워크 액세스 패턴을 분석하여 고객이 접속하는 지리적 위치를 식별합니다. 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄이기 위해 네트워크 트래픽이 이동해야 하는 거리가 짧은 리전 및 서비스를 선택합니다.
** 일반적인 안티 패턴: **
+ 자신의 고유한 위치를 기준으로 워크로드의 리전을 선택합니다.
**이 모범 사례 확립의 이점:** 고객에게 가깝게 워크로드를 배치하면 지연 시간을 최대한 단축할 수 있고 동시에 네트워크 간 데이터 이동을 줄이고 환경에 미치는 영향을 줄일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
+ 다음과 같은 주요 요소를 토대로 하여 워크로드 배포용 리전을 선택합니다.
+ **지속 가능성 목표:** 리전 선택 [에 설명되어 있습니다](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html).
+ **데이터 위치:** 데이터를 많이 사용하는 애플리케이션의 경우(예: 빅 데이터 및 기계 학습) 애플리케이션 코드는 최대한 데이터와 가까운 위치에서 실행되어야 합니다.
+ **사용자의 위치:** 사용자가 직접 사용하는 애플리케이션의 경우 워크로드의 사용자 기반과 가까운 리전을 선택합니다.
+ **기타 제약 조건:** 워크로드의 리전을 선택할 때 고려해야 할 사항에서 설명한 것처럼 [보안 및 규정 준수 등의 제약을 고려해야 합니다](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/).
+ [AWS 로컬 영역](https://aws.amazon.com/global-infrastructure/localzones/) 을 사용하여 비디오 렌더링 및 그래픽 집약적 가상 데스크톱 애플리케이션과 같은 워크로드를 실행합니다. 로컬 영역에서는 최종 사용자와 가까운 위치에 컴퓨팅 및 스토리지 리소스를 배치함으로써 이점을 얻을 수 있습니다.
+ 자주 사용되는 리소스에 로컬 캐싱 또는 [AWS 캐싱 솔루션](https://aws.amazon.com/caching/aws-caching/) 을 사용하여 성능을 개선하고 데이터 이동을 줄이며 환경에 미치는 영향을 줄입니다.
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 을(를) 사용하여 이미지, 스크립트, 비디오 등의 정적 콘텐츠와 API 응답 또는 웹 애플리케이션 등의 동적 콘텐츠를 캐시합니다.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 을(를) 사용하여 웹 애플리케이션의 콘텐츠를 캐시합니다.
+ [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) 을(를) 사용하여 DynamoDB 테이블에 인 메모리 가속화를 추가합니다.
+ 워크로드 사용자에게 더 가까운 위치에서 코드를 실행할 수 있는 서비스를 사용합니다.
+ [Lambda@Edge](https://aws.amazon.com/lambda/edge/) 는 객체가 캐시에 없는 경우 실행되는 컴퓨팅 집약적 작업에 사용합니다.
+ [Amazon CloudFront 함수](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) 는 HTTP(s) 요청 또는 응답 조작 등과 같이 단기 실행 함수로 실행할 수 있는 간단한 사용 사례에 사용할 수 있습니다.
+ [AWS IoT Greengrass](https://aws.amazon.com/greengrass/) 을(를) 사용하여 커넥티드 디바이스를 위한 로컬 컴퓨팅, 메시징 및 데이터 캐시를 실행합니다.
+ 연결 풀을 사용하여 연결을 재사용하고 필요한 리소스를 줄입니다.
+ 지속적 연결 및 동기식 업데이트에 의존하지 않는 분산 데이터 스토어를 사용하여 리전별 사용자 집단을 일관되게 지원합니다.
+ 사전 프로비저닝된 정적 네트워크 용량을 공유 동적 용량으로 교체하고 네트워크 용량의 지속 가능성에 미치는 영향을 다른 구독자와 공유합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking(지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 네트워킹)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache 설명서](https://docs.aws.amazon.com/elasticache/index.html)
+ [Amazon CloudFront란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
+ [Lambda@Edge](https://aws.amazon.com/lambda/edge/)
+ [CloudFront 함수](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html)
+ [AWS IoT Greengrass](https://aws.amazon.com/greengrass/)
**관련 동영상:**
+ [Building Sustainably on AWS(AWS에서의 지속 가능한 구축)](https://www.youtube.com/watch?v=ARAitMSIxc8)
**관련 예시:**
+ [AWS 네트워킹 워크숍](https://catalog.workshops.aws/networking/en-US)
# SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화
팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 지속 가능성에 미치는 영향을 최소화합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 공유 클라우드 데스크톱에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 사용 방식에 맞게 워크스테이션 및 기타 디바이스를 프로비저닝합니다.
+ 가상 데스크톱 및 애플리케이션 스트리밍을 사용하여 업그레이드 및 디바이스 요구 사항을 제한합니다.
+ 프로세서 또는 메모리 집약적인 작업을 클라우드로 이동합니다.
+ 디바이스 수명 주기에 대한 프로세스 및 시스템의 영향을 평가하고 비즈니스 요구 사항을 충족하면서 디바이스 교체 요구 사항을 최소화하는 솔루션을 선택합니다.
+ 디바이스에 대한 원격 관리를 구현하여 필요한 출장을 줄입니다.
## 리소스
**관련 문서:**
+ [Amazon WorkSpaces란 무엇입니까?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html)
**관련 동영상:**
+ [Building Sustainably on AWS(AWS에서의 지속 가능한 구축)](https://www.youtube.com/watch?v=ARAitMSIxc8)
# 소프트웨어 및 아키텍처 패턴
**Topics**
+ [SUS 3 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?](w2aac19c15b9b5.md)
# SUS 3 소프트웨어 및 아키텍처 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?
로드 평준화를 수행하고 배포된 리소스의 높은 활용률을 일관되게 유지하여 소비되는 리소스를 최소화하기 위한 패턴을 구현합니다. 구성 요소는 시간 경과에 따른 사용자 행동의 변화로 인해 사용 부족으로 인해 유휴 상태가 될 수 있습니다. 패턴과 아키텍처를 수정하여 활용률이 낮은 구성 요소를 통합함으로써 전체 활용률을 높입니다. 더 이상 필요하지 않은 구성 요소를 폐기합니다. 워크로드 구성 요소의 성능을 이해하고 리소스를 가장 많이 사용하는 구성 요소를 최적화합니다. 고객이 서비스에 액세스하고 패턴을 구현하는 데 사용하는 디바이스를 숙지하여 디바이스 업그레이드 필요성을 최소화합니다.
모범 사례:
# SUS03-BP01 비동기식 및 예약된 작업을 위한 소프트웨어 및 아키텍처 최적화
효율적인 소프트웨어 설계 및 아키텍처를 사용하여 작업 단위당 필요한 평균 리소스를 최소화합니다. 구성 요소를 균일하게 활용하여 작업 간에 유휴 상태인 리소스를 줄이고 로드 급증의 영향을 최소화하는 메커니즘을 구현합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 즉각적인 처리가 필요하지 않은 요청을 대기열로 보냅니다.
+ 직렬화를 늘려 파이프라인 전체의 활용률을 균등하게 만듭니다.
+ 입력 대기 중인 유휴 리소스를 방지하기 위해 개별 구성 요소의 용량을 수정합니다.
+ 버퍼를 생성하고 속도 제한을 설정하여 외부 서비스 사용을 원활하게 합니다.
+ 소프트웨어 최적화에 사용할 수 있는 가장 효율적인 하드웨어를 사용합니다.
+ 대기열 기반 아키텍처, 파이프라인 관리 및 온디맨드 인스턴스 작업자를 사용하여 배치 처리의 활용률을 극대화합니다.
+ 동시 실행으로 인한 로드 급증 및 리소스 경합을 방지하기 위해 작업을 예약합니다.
+ 하루 중 전력의 탄소 집약도가 가장 낮은 시간에 작업을 예약합니다.
## 리소스
**관련 문서:**
+ [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Amazon MQ란 무엇일까요?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [Amazon SQS 기반 크기 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Amazon SQS에서 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
+ [이벤트 기반 아키텍처로의 전환](https://www.youtube.com/watch?v=h46IquqjF3E)
# SUS03-BP02 사용 빈도가 낮거나 전혀 없는 워크로드 구성 요소 제거 또는 리팩터링
워크로드 활동을 모니터링하여 시간 경과에 따른 개별 구성 요소의 활용률 변화를 파악합니다. 사용되지 않아 더 이상 필요하지 않은 구성 요소와 사용률이 낮은 구성 요소를 리팩터링하여 낭비되는 리소스를 제한합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 기능 구성 요소에 대한 로드(트랜잭션 흐름 및 API 호출과 같은 지표 사용)를 분석하여 사용되지 않아 사용률이 낮은 구성 요소를 식별합니다.
+ 더 이상 필요하지 않은 구성 요소를 폐기합니다.
+ 사용률이 낮은 구성 요소를 리팩터링합니다.
+ 사용률이 낮은 구성 요소를 다른 리소스와 통합하여 사용 효율성을 개선합니다.
## 리소스
**관련 문서:**
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ServiceLens를 사용하여 애플리케이션의 상태 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [Amazon ECR에서 사용되지 않는 이미지 자동 정리](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP03 가장 많은 시간 또는 리소스를 소모하는 코드 영역 최적화
워크로드 활동을 모니터링하여 가장 많은 리소스를 사용하는 애플리케이션 구성 요소를 식별합니다. 이러한 구성 요소 내에서 실행되는 코드를 최적화하여 성능을 극대화하면서 리소스 사용을 최소화합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 리소스 사용량에 따라 성능을 모니터링하여 작업 단위당 리소스 요구 사항이 높은 구성 요소를 최적화 대상으로 식별합니다.
+ 코드 프로파일러를 사용하여 가장 많은 시간 또는 리소스를 사용하는 코드 영역을 최적화 대상으로 식별합니다.
+ 알고리즘을 동일한 결과를 산출하면서 더 효율적인 버전으로 바꿉니다.
+ 하드웨어 가속 기술을 사용하여 실행 시간이 긴 코드 블록의 효율성을 개선합니다.
+ 워크로드에 가장 효율적인 운영 체제 및 프로그래밍 언어를 사용합니다.
+ 불필요한 정렬 및 서식을 제거합니다.
+ 데이터의 변경 빈도와 사용 빈도에 따라 사용되는 리소스를 최소화하는 데이터 전송 패턴을 사용합니다. 예를 들어, 상태 변경 정보가 리소스를 소비하여 폴링하고 가치 없는 '변경 없음' 메시지를 수신하지 않도록 클라이언트에 푸시합니다.
## 리소스
**관련 문서:**
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CodeGuru Profiler란 무엇입니까?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [AWS에서의 구축을 위한 도구의 AWS SDK](https://aws.amazon.com/tools/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP04 고객 디바이스 및 장비에 대한 영향 최소화
고객이 서비스를 사용하기 위해 사용하는 디바이스와 장비, 예상 수명 주기, 이러한 구성 요소 교체가 재정 및 지속 가능성에 미치는 영향을 이해합니다. 소프트웨어 패턴 및 아키텍처를 구현하여 고객이 디바이스를 교체하고 장비를 업그레이드해야 하는 필요성을 최소화합니다. 예를 들어, 이전 하드웨어 및 운영 체제 버전과 역호환되는 코드를 사용하여 새로운 기능을 구현하거나 대상 디바이스의 저장 용량을 초과하지 않도록 페이로드 크기를 관리합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 고객이 사용하는 디바이스의 인벤토리를 작성합니다.
+ 대표적인 하드웨어 집합과 함께 중앙 관리형 Device Farm을 사용하여 테스트하여 변경 사항이 미치는 영향을 파악하고 개발을 반복하여 지원되는 디바이스를 최대합니다.
+ 페이로드를 구축할 때 네트워크 대역폭과 대기 시간을 고려하고 애플리케이션이 대기 시간이 긴 저대역폭 링크에서 잘 작동하도록 지원하는 기능을 구현합니다.
+ 데이터 페이로드를 사전 처리하여 로컬 처리 요구 사항을 줄이고 데이터 전송 요구 사항을 제한합니다.
+ 서버 측에서 계산 집약적인 활동(예: 이미지 렌더링)을 수행하거나 애플리케이션 스트리밍을 사용하여 구형 디바이스에서 사용자 경험을 개선합니다.
+ 페이로드를 관리하고 로컬 스토리지 요구 사항을 제한하기 위해 특히 대화형 세션의 경우 출력을 분할하고 페이지 번호를 매깁니다.
## 리소스
**관련 문서:**
+ [AWS Device Farm이란 무엇입니까?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [Amazon Elastic Transcoder 설명서](https://docs.aws.amazon.com/elastic-transcoder/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# SUS03-BP05 데이터 액세스 및 스토리지 패턴을 가장 잘 지원하는 소프트웨어 패턴 및 아키텍처 사용
데이터가 워크로드 내에서 사용되고, 사용자가 소비하고, 전송 및 저장되는 방식을 이해합니다. 데이터 처리 및 스토리지 요구 사항을 최소화하는 기술을 선택합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 데이터 액세스 및 스토리지 패턴을 분석합니다.
+ 분석 실행 시 불필요한 처리 작업을 방지하고 프로비저닝된 총 스토리지를 줄이기 위해 Parquet과 같은 효율적인 파일 형식으로 데이터 파일을 저장합니다.
+ 기본적으로 압축된 데이터와 함께 작동하는 기술을 사용합니다.
+ 가장 많이 나타나는 쿼리 패턴을 가장 효과적으로 지원하는 데이터베이스 엔진을 사용합니다.
+ 인덱스 설계가 효율적인 쿼리 실행을 지원하도록 데이터베이스 인덱스를 관리합니다.
+ 사용되는 네트워크 용량을 줄이는 네트워크 프로토콜을 선택합니다.
## 리소스
**관련 문서:**
+ [Athena 압축 지원 파일 형식](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [Amazon Redshift를 사용한 열 기반 데이터 형식에서 COPY 명령](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [Firehose에서 입력 레코드 형식 변환](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)
+ [AWS Glue에서 ETL 입력 및 출력의 형식 옵션](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [열 형식으로 변환하여 Amazon Athena에서 쿼리 성능 향상](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [Amazon Redshift로 Amazon S3에서 압축 데이터 파일 로딩](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon Aurora의 성능 개선 도우미로 DB 로드 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html)
+ [Amazon RDS의 성능 개선 도우미로 DB 로드 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [AWS IoT FleetWise](https://aws.amazon.com/about-aws/whats-new/2021/11/aws-iot-fleetwise-transferring-vehicle-data-cloud/)
**관련 동영상:**
+ [AWS에서의 지속 가능한 구축](https://www.youtube.com/watch?v=ARAitMSIxc8)
# 데이터 패턴
**Topics**
+ [SUS 4 데이터 액세스 및 사용 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?](w2aac19c15c11b5.md)
# SUS 4 데이터 액세스 및 사용 패턴을 활용하여 지속 가능성 목표를 지원하려면 어떻게 해야 합니까?
데이터 관리 원칙을 구현하여 워크로드를 지원하는 데 필요한 프로비저닝된 스토리지와 이를 사용하는 데 필요한 리소스를 줄입니다. 데이터를 이해하고 데이터의 비즈니스 가치와 데이터 사용 방식을 가장 잘 지원하는 스토리지 기술과 구성을 사용합니다. 요구 사항이 감소하면 데이터를 더 효율적이고 성능이 낮은 스토리지로 수명 주기를 변경하고 더 이상 필요하지 않은 데이터는 삭제합니다.
모범 사례:
# SUS04-BP01 데이터 분류 정책 구현
데이터를 분류하여 비즈니스 성과를 실현하는 데 있어서 중요도를 파악합니다. 이 정보를 사용하여 데이터를 보다 에너지 효율적인 스토리지로 이동하거나 안전하게 삭제할 수 있는 시기를 결정합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 데이터 배포, 보존 및 삭제에 대한 요구 사항을 결정합니다.
+ 볼륨 및 개체에 태깅을 사용하여 데이터 분류를 포함하여 관리 방법을 결정하는 데 사용되는 메타데이터를 기록합니다.
+ 환경에 태그가 지정되지 않은 데이터와 분류되지 않은 데이터가 있는지 주기적으로 감사하고 데이터를 적절하게 분류하고 태그를 지정합니다.
## 리소스
**관련 문서:**
+ [데이터 분류 프로세스](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-process.html)
+ [AWS 클라우드를 활용하여 데이터 분류 지원](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html)
+ [AWS Organizations의 태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
# SUS04-BP02 데이터 액세스 및 스토리지 패턴을 지원하는 기술 사용
데이터 액세스 및 저장 방법을 가장 잘 지원하는 스토리지를 사용하여 워크로드를 지원하면서 프로비저닝된 리소스를 최소화합니다. 예를 들어, 솔리드 스테이트 드라이브(SSD)는 자기 드라이브보다 에너지 집약적이므로 활성 데이터 사용 사례에만 사용해야 합니다. 자주 액세스하지 않는 데이터에는 에너지 효율적인 아카이빙 클래스 스토리지를 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 데이터 액세스 패턴을 모니터링합니다.
+ 액세스 패턴에 따라 데이터를 적절한 기술로 마이그레이션합니다.
+ 아카이빙 데이터를 해당 목적으로 설계된 스토리지로 마이그레이션합니다.
## 리소스
**관련 문서:**
+ [Amazon EBS 볼륨 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+ [Amazon EC2 인스턴스 스토어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [Amazon S3 스토리지 클래스 사용](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon Glacier란 무엇입니까?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**관련 동영상:**
+ [AWS의 데이터 레이크용 아키텍처 패턴](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
# SUS04-BP03 수명 주기 정책을 사용하여 불필요한 데이터 삭제
모든 데이터의 수명 주기를 관리하고 삭제 일정을 자동으로 적용하여 워크로드의 총 스토리지 요구 사항을 최소화합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 모든 데이터 분류 유형에 대한 수명 주기 정책을 정의합니다.
+ 수명 주기 규칙을 적용하는 자동화된 수명 주기 정책을 설정합니다.
+ 사용하지 않는 볼륨 및 스냅샷을 삭제합니다.
+ 수명 주기 규칙에 따라 관련 데이터를 집계합니다.
## 리소스
**관련 문서:**
+ [Amazon ECR 수명 주기 정책](https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html)
+ [Amazon EFS 수명 주기 관리](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [AWS Config 규칙으로 리소스 평가](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ [Amazon S3에서 스토리지 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [AWS Elemental MediaStore의 객체 수명 주기 정책](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle.html)
**관련 동영상:**
+ [Amazon S3 수명 주기](https://www.youtube.com/watch?v=53eHNSpaMJI&ab_channel=AmazonWebServices)
# SUS04-BP04 블록 스토리지에서 과다 프로비저닝 최소화
프로비저닝된 스토리지의 총량을 최소화하려면 워크로드에 적합한 크기가 할당된 블록 스토리지를 생성합니다. 탄력적 볼륨을 사용하면 컴퓨팅 리소스에 연결된 스토리지의 크기를 조정할 필요 없이 데이터가 증가함에 따라 스토리지를 확장할 수 있습니다. 탄력적 볼륨을 정기적으로 검토하고 과다 프로비저닝된 볼륨을 현재 데이터 크기에 맞게 축소합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 데이터 볼륨의 사용률을 모니터링합니다.
+ 탄력적 볼륨 및 관리형 블록 데이터 서비스를 사용하여 영구 데이터의 증가에 따른 추가 스토리지 할당을 자동화합니다.
+ 데이터 볼륨의 목표 사용률 수준을 설정하고 예상 범위를 벗어나는 볼륨 크기를 조정합니다.
+ 데이터에 맞게 읽기 전용 볼륨의 크기를 조정합니다.
+ 블록 스토리지의 고정 볼륨 크기로 초과 용량을 프로비저닝하지 않도록 데이터를 객체 스토어로 마이그레이션합니다.
## 리소스
**관련 문서:**
+ [Amazon EBS 탄력적 볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)
+ [Amazon FSx 설명서](https://docs.aws.amazon.com/fsx/index.html)
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon Elastic File System이란 무엇입니까?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
# SUS04-BP05 불필요하거나 중복된 데이터 제거
필요한 경우에만 데이터를 복제하여 총 스토리지 사용을 최소화합니다. 파일 및 블록 수준에서 데이터를 중복 제거하는 백업 기술을 사용합니다. 서비스 수준 계약(SLA)을 충족하는 데 필요한 경우를 제외하고 Redundant Array of Independent Drives(RAID) 구성의 사용을 제한합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 블록 및 객체 수준에서 데이터 중복을 제거할 수 있는 메커니즘을 사용합니다.
+ 블록, 파일 및 객체 수준에서 증분 백업을 만들고 데이터 중복을 제거할 수 있는 백업 기술을 사용합니다.
+ SLA를 충족하는 데 필요한 경우에만 RAID를 사용합니다.
+ 로그 및 추적 데이터를 중앙 집중화하고, 동일한 로그 항목을 중복 제거하며, 필요에 따라 세부적으로 조정하는 메커니즘을 설정합니다.
+ 적절한 경우에만 캐시를 미리 채웁니다.
+ 캐시 모니터링 및 자동화를 설정하여 그에 따라 캐시 크기를 조정합니다.
+ 새 버전의 워크로드를 푸시할 때 객체 스토어 및 엣지 캐시에서 오래된 배포 및 자산을 제거합니다.
## 리소스
**관련 문서:**
+ [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [CloudWatch Logs에서 로그 데이터 보존 기간 변경](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server에서 데이터 중복 제거](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [데이터 중복 제거를 포함한 Amazon FSx for ONTAP의 기능](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [Amazon CloudFront에서의 파일 무효화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html)
+ [AWS Backup을 사용하여 Amazon EFS 파일 시스템 백업 및 복구](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon CloudWatch Logs란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon RDS의 백업 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**관련 예시:**
+ [실습: Amazon Redshift 데이터 공유를 사용하여 데이터 패턴 최적화](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
# SUS04-BP06 공유 파일 시스템 또는 객체 스토리지를 사용하여 공용 데이터에 액세스
공유 스토리지와 단일 정보 소스를 도입하여 데이터 중복을 방지하고 워크로드의 총 스토리지 요구 사항을 줄입니다. 필요한 경우에만 공유 스토리지에서 데이터를 가져옵니다. 사용하지 않는 볼륨을 분리하여 더 많은 리소스를 이용할 수 있도록 하십시오.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 데이터의 소비자가 다수인 경우 데이터를 공유 스토리지로 마이그레이션합니다.
+ 필요한 경우에만 공유 스토리지에서 데이터를 가져옵니다.
+ 사용 패턴에 맞게 데이터를 삭제하고 유지 시간(TTL) 기능을 구현하여 캐시된 데이터를 관리합니다.
+ 자주 사용하지 않는 클라이언트에서 볼륨을 분리합니다.
## 리소스
**관련 문서:**
+ [Amazon FSx](https://aws.amazon.com/fsx/)
+ [캐싱 전략](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html)
+ [Amazon Elastic File System란 무엇입니까?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon S3란 무엇입니까?](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
# SUS04-BP07 네트워크 간 데이터 이동 최소화
공유 스토리지를 사용하고 리전 데이터 스토어의 데이터에 액세스하여 워크로드의 데이터 이동을 지원하는 데 필요한 총 네트워킹 리소스를 최소화합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 가능한 한 소비자와 가까운 곳에 데이터를 저장합니다.
+ 리전별 사용 서비스를 분할하여 해당 리전별 데이터가 사용되는 리전 내에 저장되도록 합니다.
+ 네트워크를 통해 변경 사항을 복사할 때 파일 또는 객체 수준 복제 대신 블록 수준 복제를 사용합니다.
+ 네트워크를 통해 데이터를 이동하기 전에 데이터를 압축합니다.
## 리소스
**관련 문서:**
+ [지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 네트워킹](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [CloudFront 글로벌 엣지 네트워크를 포함한 Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
+ [Amazon OpenSearch Service의 HTTP 요청 요약](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Amazon EMR을 사용하여 중간 데이터 압축](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [Amazon S3에서 Amazon Redshift로 압축 데이터 파일 로딩](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon CloudFront를 사용하여 압축된 파일 제공](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
# SUS04-BP08 다시 생성하기 어려운 경우에만 데이터 백업
스토리지 소비를 최소화하려면 비즈니스 가치가 있거나 규정 준수 요구 사항을 충족하는 데 필요한 데이터만 백업합니다. 백업 정책을 검토하고 복구 시나리오에서 가치를 제공하지 않는 임시 스토리지는 제외합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 데이터 분류를 사용하여 백업해야 할 데이터를 설정합니다.
+ 쉽게 다시 생성할 수 있는 데이터를 제외합니다.
+ 백업 대상에서 임시 데이터를 제외합니다.
+ 공용 위치에서 데이터를 복원하는 데 필요한 시간이 서비스 수준 계약(SLA)을 초과하지 않는 한, 데이터의 로컬 사본을 제외합니다.
## 리소스
**관련 문서:**
+ [AWS Backup을 사용하여 Amazon EFS 파일 시스템 백업 및 복구](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon Relational Database Service의 백업 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
# 하드웨어 패턴
**Topics**
+ [SUS 5 하드웨어 관리 및 사용 방식이 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까?](w2aac19c15c13b5.md)
# SUS 5 하드웨어 관리 및 사용 방식이 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까?
하드웨어 관리 방식을 변경하여 지속 가능성에 미치는 워크로드의 영향을 줄일 수 있는 기회를 모색합니다. 프로비저닝 및 배포에 필요한 하드웨어의 양을 최소화하고 개별 워크로드에 가장 효율적인 하드웨어를 선택합니다.
모범 사례:
# SUS05-BP01 요구 사항을 충족하는 데 필요한 최소한의 하드웨어 사용
클라우드의 기능을 사용하여 워크로드 구현을 자주 변경할 수 있습니다. 변화하는 요구 사항에 따라 배포된 구성 요소를 업데이트합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 수평적 확장을 활성화하고 자동화를 사용하여 로드가 증가하면 확장하고 로드가 감소하면 축소합니다.
+ 가변 워크로드의 경우 작은 증분 단위로 크기를 조정합니다.
+ 로드가 매일, 매주, 매월 또는 매년 달라지므로 주기적인 활용 패턴(예: 격주 처리 활동이 많은 급여 시스템)에 따라 크기를 조정합니다.
+ 자동화가 대체 리소스를 배포하는 동안 일시적인 용량을 줄일 수 있는 서비스 수준 계약(SLA)을 협상합니다.
## 리소스
**관련 문서:**
+ [AWS Compute Optimizer 설명서](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [Lambda 운영: 성능 최적화](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/)
+ [Auto Scaling 설명서](https://docs.aws.amazon.com/autoscaling/index.html)
# SUS05-BP02 영향이 가장 적은 인스턴스 유형 사용
새로운 인스턴스 유형의 릴리스를 지속적으로 모니터링하고 기계 학습 훈련 및 추론, 비디오 트랜스코딩과 같은 특정 워크로드를 지원하도록 설계된 인스턴스 유형을 포함하여 에너지 효율성 개선의 이점을 활용합니다.
**일반적인 안티 패턴:**
+ 인스턴스 패밀리는 하나만 사용합니다.
+ x86 인스턴스만 사용합니다.
+ Amazon EC2 Auto Scaling 구성에서 인스턴스 유형을 하나만 지정합니다.
+ AWS 인스턴스를 설계되지 않은 방식으로 사용합니다(예: 컴퓨팅에 최적화된 인스턴스를 메모리 집약적 워크로드에 사용).
+ 새 인스턴스 유형을 정기적으로 평가하지 않습니다.
+ AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer)의 권장 사항을 확인하지 않습니다.](https://aws.amazon.com/compute-optimizer/)
**이 모범 사례 확립의 이점:** 적정 크기로 조정된 에너지 효율적인 인스턴스를 사용하면 환경 영향 및 워크로드 비용을 크게 줄일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
+ 워크로드의 환경 영향을 줄일 수 있는 인스턴스 유형을 알아보고 탐색합니다.
+ 최신 [AWS의 새로운 소식](https://aws.amazon.com/new/) 을 구독하여 최신 AWS 기술 및 인스턴스 소식을 파악합니다.
+ 다양한 AWS 인스턴스 유형에 대해 알아봅니다.
+ 다음 동영상을 보고 Amazon EC2에서 와트당 에너지 사용 대비 최고 성능을 제공하는 AWS Graviton 기반 인스턴스에 대해 살펴봅니다. [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances(AWS Graviton2 프로세서 기반 Amazon EC2 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=NLysl0QvqXU) 및 [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances(AWS Graviton3 및 Amazon C7g 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents).
+ 워크로드를 영향이 가장 적은 인스턴스 유형으로 전환하도록 계획합니다.
+ 워크로드를 위한 새로운 기능 또는 인스턴스를 평가하기 위한 프로세스를 정의합니다. 클라우드에서 민첩성을 활용하여 새 인스턴스 유형이 워크로드 환경 지속 가능성을 어떻게 개선할 수 있는지 신속하게 테스트합니다. 프록시 지표를 사용하여 작업 단위를 완료하는 데 필요한 리소스를 측정합니다.
+ 가능한 경우 다양한 CPU 수와 다양한 메모리 용량으로 작동하도록 워크로드를 수정하여 인스턴스 유형 선택의 폭을 극대화합니다.
+ 워크로드의 성능 효율성을 개선하려면 워크로드를 Graviton 기반 인스턴스로 전환할 것을 고려합니다( [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/) 및 [AWS Graviton2 for ISVs](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)). 워크로드를 [AWS Graviton 기반 Amazon Elastic Compute Cloud 인스턴스로 전환할 때 이러한 고려 사항을 염두에 두세요.](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)
+ AWS Graviton 옵션 선택을 [AWS 관리형 서비스 사용에 고려하세요. ](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)
+ 지속 가능성에 미치는 영향이 가장 적고 비즈니스 요구 사항을 충족하는 인스턴스를 제공하는 리전으로 워크로드를 마이그레이션합니다.
+ 기계 학습 워크로드의 경우 다음과 같은 맞춤형 Amazon Machine Learning 칩 기반Amazon EC2 인스턴스를 사용합니다. [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)및 [Amazon EC2 DL1.](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) 를 사용하여 ML 추론 엔드포인트의 크기를 적정하게 조정합니다.
+ 실시간 동영상 트랜스코딩을 사용하는 워크로드의 경우 [Amazon EC2 VT1 인스턴스를 사용합니다.](https://aws.amazon.com/ec2/instance-types/vt1/)
+ 사용량이 급증하는 인스턴스의 경우(추가 용량에 대한 요구 사항이 적은 워크로드) [버스트 가능 성능 인스턴스를 사용합니다.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ 상태 비저장 또는 내결함성 워크로드의 경우 [Amazon EC2 스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 를 사용하여 클라우드의 전반적인 활용률을 높이고 사용하지 않는 리소스가 지속 가능성에 미치는 영향을 줄입니다.
+ 워크로드 인스턴스를 운영 및 최적화합니다.
+ 임시 워크로드의 경우 [인스턴스 Amazon CloudWatch 지표](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) (예: `CPUUtilization` )를 사용하여 인스턴스가 유휴 상태이거나 사용률이 적은지 파악합니다.
+ 안정적인 워크로드의 경우 AWS 적정 크기 조정 도구(예: [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) )를 정기적으로 사용하여 인스턴스를 최적화하고 크기를 적정하게 조정할 기회를 파악합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part I: Compute(지속 가능성을 위한 AWS 인프라 최적화, 파트 I: 컴퓨팅)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton 프로세서](https://aws.amazon.com/ec2/graviton/)
+ [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)
+ [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)
+ [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon EC2 버스트 가능 성능 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [Amazon EC2 용량 예약 플릿](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [Amazon EC2 스팟 플릿](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [Amazon EC2 스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)
+ [Amazon EC2 VT1 인스턴스](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon EC2 인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [함수: Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
**관련 동영상:**
+ [Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances(AWS Graviton2 프로세서 기반 Amazon EC2 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=NLysl0QvqXU)
+ [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances(AWS Graviton3 및 Amazon C7g 인스턴스에 대해 자세히 알아보기)](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
**관련 예시:**
+ [실습: 적정 크기 조정 권장 사항](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [실습: Compute Optimizer(으)로 적정 크기 조정](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [실습: 하드웨어 패턴 최적화 및 지속 가능성 KPI 관찰](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
# SUS05-BP03 관리형 서비스 사용
관리형 서비스는 배포된 하드웨어의 높은 평균 사용률과 지속 가능성 최적화를 유지하는 책임을 AWS로 이전합니다. 관리형 서비스를 사용하여 지속 가능성에 미치는 서비스의 영향을 서비스의 모든 테넌트에 분산하여 개인의 기여도를 낮춥니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 셀프 호스팅 서비스를 관리형 서비스로 마이그레이션합니다. 예를 들어, [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 에서 자체 Amazon RDS 인스턴스를 유지 관리하는 대신 관리형 [Amazon Relational Database Service(Amazon RDS)](https://aws.amazon.com/ec2/)인스턴스를 사용하거나 자체 컨테이너 인프라를 구현하는 대신 [AWS Fargate](https://aws.amazon.com/fargate/)와 같은 관리형 컨테이너 서비스를 사용합니다.
## 리소스
**관련 문서:**
+ [AWS Fargate](https://aws.amazon.com/fargate/)
+ [Amazon DocumentDB](https://aws.amazon.com/documentdb/)
+ [Amazon Elastic Kubernetes Service(EKS)](https://aws.amazon.com/eks/)
+ [Amazon Managed Streaming for Apache Kafka(Amazon MSK)](https://aws.amazon.com/msk/)
+ [Amazon Redshift](https://aws.amazon.com/redshift/)
+ [Amazon Relational Database Service(RDS)](https://aws.amazon.com/rds/)
# SUS05-BP04 GPU 사용 최적화
그래픽 처리 장치(GPU)는 높은 전력 소비의 원인이 될 수 있으며 렌더링, 트랜스코딩, 기계 학습 훈련 및 모델링과 같은 많은 GPU 워크로드는 매우 가변적입니다. 필요한 시간 동안만 GPU 인스턴스를 실행하고 필요하지 않은 경우 자동화를 통해 GPU 인스턴스를 폐기하여 리소스 사용을 최소화합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ CPU 기반 대안보다 효율적인 작업에만 GPU를 사용합니다.
+ 자동화를 사용하여 사용하지 않는 GPU 인스턴스 사용을 해제합니다.
+ 전용 GPU 인스턴스 대신 유연한 그래픽 가속을 사용합니다.
+ 워크로드 전용 맞춤형 하드웨어를 활용합니다.
## 리소스
**관련 문서:**
+ [가속화된 컴퓨팅](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)
+ [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)
+ [EC2 인스턴스의 가속화된 컴퓨팅](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [Amazon EC2 VT1 인스턴스](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon Elastic Graphics](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-graphics.html)
# 개발 및 배포 프로세스
**Topics**
+ [SUS 6 개발 및 배포 프로세스가 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까?](w2aac19c15c15b5.md)
# SUS 6 개발 및 배포 프로세스가 비즈니스의 지속 가능성 목표를 어떻게 지원하고 있습니까?
개발, 테스트 및 배포 방식을 변경하여 지속 가능성에 미치는 영향을 줄일 수 있는 기회를 모색합니다.
모범 사례:
# SUS06-BP01 지속 가능성 개선을 신속하게 도입할 수 있는 방법 도입
잠재적 개선 사항을 프로덕션 환경에 배포하기 전에 테스트하고 검증합니다. 개선 사항으로 실현될 미래의 잠재적 이익을 계산할 때 테스트 비용을 고려합니다. 소규모 개선 사항을 제공할 수 있도록 저비용 테스트 방법을 개발합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 개발 프로세스에 지속 가능성에 대한 요구 사항을 추가합니다.
+ 여러 리소스를 동시에 활용하여 지속 가능성 개선 사항을 개발, 테스트 및 배포할 수 있도록 지원합니다.
+ 지속 가능성에 미치는 잠재적 영향에 대한 개선 사항을 프로덕션 환경에 배포하기 전에 테스트 및 검증합니다.
+ 실제 환경을 잘 반영하는 현실적인 최소 구성 요소를 사용하여 잠재적 개선 사항을 테스트합니다.
+ 테스트된 지속 가능성 개선 사항이 제공되면 프로덕션에 배포합니다.
## 리소스
**관련 문서:**
+ [AWS가 지원하는 지속 가능성 솔루션](https://aws.amazon.com/sustainability/)
**관련 예시:**
+ [실습:](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) 비용 및 사용량 보고서를 효율성 보고서로 변환
# SUS06-BP02 워크로드를 최신 상태로 유지
최신 운영 체제, 라이브러리 및 애플리케이션을 통해 워크로드 효율성을 개선하고 보다 효율적인 기술을 더 쉽게 도입할 수 있습니다. 공급 업체가 자체적인 지속 가능성 목표를 충족할 수 있는 기능을 제공함에 따라, 최신 소프트웨어에는 워크로드의 지속 가능성에 미치는 영향을 보다 정확하게 측정하는 기능이 포함될 수도 있습니다.
**일반적인 안티 패턴:**
+ 시간이 지나면 현재 아키텍처가 정적 아키텍처가 되고 업데이트되지 않는다고 가정합니다.
+ 업데이트된 소프트웨어 및 패키지가 워크로드와 호환되는지 평가하는 시스템 또는 정기적인 주기가 없습니다.
+ 시간이 지나면 타당한 이유 없이 아키텍처 변경을 도입합니다.
**이 모범 사례 확립의 이점:** 워크로드를 최신 상태로 유지하기 위한 프로세스를 확립하면 새로운 기능을 도입하고 문제를 해결하며 워크로드 효율성을 개선할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
+ 워크로드를 위한 새로운 기능 또는 인스턴스를 평가하기 위한 프로세스 및 일정을 정의합니다. 클라우드에서 민첩성을 활용하여 새 기능이 다음 작업을 수행하도록 워크로드를 어떻게 개선할 수 있는지 신속하게 테스트합니다.
+ 지속 가능성 영향 줄이기
+ 성능 효율성을 높이기
+ 계획된 개선 작업의 장애 요인 제거
+ 지속 가능성에 미치는 영향을 측정 및 관리할 수 있는 능력 증진
+ 워크로드 소프트웨어 및 아키텍처를 조사하여 업데이트하는 데 필요한 구성 요소를 식별합니다. [AWS Systems Manager 인벤토리](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) 를 사용하여 Amazon EC2 인스턴스에서 운영 체제(OS), 애플리케이션, 인스턴스 메타데이터를 수집하고 소프트웨어를 실행 중인 인스턴스, 소프트웨어 정책에 필요한 구성, 업데이트해야 할 인스턴스를 신속하게 파악합니다.
+ 워크로드 구성 요소의 업데이트 방법을 파악합니다.
+ [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) for Linux 또는 Windows 서버 이미지에 대한 업데이트를 다음을 사용하여 관리합니다. [EC2 Image Builder](https://aws.amazon.com/image-builder/).
+ 기존 파이프라인과 함께 [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 를 사용하여 [Amazon Elastic Container Service (Amazon ECS) 이미지 관리](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) 및 [Amazon Elastic Kubernetes Service 이미지 관리를 수행해야 합니다.](https://docs.aws.amazon.com/=AmazonECR/latest/userguide/ECR_on_EKS.html)
+ AWS Lambda에는 [버전 관리 기능이 있습니다.](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)
+ 업데이트 프로세스에 자동화를 사용하여 새 기능 배포에 필요한 작업 수준을 줄이고 수동 프로세스로 인한 오류를 제한합니다. [AWS Systems Manager Patch Manager과 같은 도구를 사용하여](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 시스템 업데이트 프로세스를 자동화하고 다음을 사용하여 이 활동을 예약할 수 있습니다. [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html).
## 리소스
**관련 문서:**
+ [AWS 아키텍처 센터](https://aws.amazon.com/architecture)
+ [AWS의 새로운 소식](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS Systems Manager Patch Manager과 같은 도구를 사용하여](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**관련 예시:**
+ [Well-Architected 실습 - 인벤토리 및 패치 관리](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
+ [실습: AWS Systems Manager](https://mng.workshop.aws/ssm.html)
# SUS06-BP03 구축 환경의 사용률 제고
자동화와 코드형 인프라를 사용하여 필요 시 프로덕션 전 환경을 가동하고 사용하지 않을 때는 해당 환경을 종료합니다. 일반적인 패턴은 개발 담당 팀원의 근무 시간과 일치하는 가용 기간을 예약하는 것입니다. 최대 절전 모드는 상태를 유지하고 필요할 때만 인스턴스를 빠르게 온라인으로 전환할 수 있는 유용한 도구입니다. 버스트 용량이 포함된 인스턴스 유형, 스팟 인스턴스, 탄력적 데이터베이스 서비스, 컨테이너 및 기타 기술을 사용하여 사용량에 따라 개발 및 테스트 용량을 조정합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 자동화를 통해 개발 및 테스트 환경의 활용률을 극대화합니다.
+ 자동화를 통해 개발 및 테스트 환경의 수명 주기를 관리합니다.
+ 현실적인 최소한의 재현 환경을 사용하여 잠재적 개선 사항을 개발 및 테스트합니다.
+ 온디맨드 인스턴스를 사용하여 개발자 디바이스를 보완합니다.
+ 자동화를 통해 구축 리소스의 효율성을 극대화합니다.
+ 버스트 용량이 포함된 인스턴스 유형, 스팟 인스턴스 및 기타 기술을 사용하여 사용량에 맞게 구축 용량을 조정합니다.
+ 배스천 호스트 플릿을 배포하는 대신 네이티브 클라우드 서비스를 도입하여 보안 인스턴스 셸에 액세스합니다.
## 리소스
**관련 문서:**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 성능 순간 확장 가능 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# SUS06-BP04 테스트에 관리형 Device Farm 사용
관리형 Device Farm은 하드웨어 제조 및 리소스 사용이 지속 가능성에 미치는 영향을 여러 테넌트에 분산시킵니다. 관리형 Device Farm은 다양한 디바이스 유형을 제공하며, 사용 빈도가 낮은 오래된 하드웨어를 지원하고 불필요한 디바이스 업그레이드로 인한 고객의 지속 가능성에 미치는 영향을 방지할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
대표적인 하드웨어 집합과 함께 중앙 관리형 Device Farm을 사용하여 테스트하여 변경 사항이 미치는 영향을 파악하고 개발을 반복하여 지원되는 디바이스를 최대합니다.
## 리소스
**관련 문서:**
+ [AWS Device Farm이란 무엇입니까?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)