# SUS 2 클라우드 리소스를 비즈니스 요구에 어떻게 맞추나요?
사용자 및 애플리케이션이 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 인프라를 지속적으로 확장하여 수요를 충족하고 사용자를 지원하는 데 필요한 최소 리소스만 활용하는지 확인합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자가 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용되지 않는 자산을 제거합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.
**Topics**
+ [SUS02-BP01 워크로드 인프라 동적 규모 조정](sus_sus_user_a2.md)
+ [SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정](sus_sus_user_a3.md)
+ [SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지](sus_sus_user_a4.md)
+ [SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화](sus_sus_user_a5.md)
+ [SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화](sus_sus_user_a6.md)
+ [SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화](sus_sus_user_a7.md)
# SUS02-BP01 워크로드 인프라 동적 규모 조정
클라우드의 탄력성을 활용하고 인프라를 동적으로 조정하여, 클라우드 리소스 공급을 수요에 맞게 조정하고 워크로드의 용량 초과 프로비저닝을 방지할 수 있습니다.
**일반적인 안티 패턴:**
+ 사용자 로드에 따라 인프라 규모를 조정하지 않습니다.
+ 항상 인프라 규모를 수동으로 조정합니다.
+ 조정 이벤트 후에 다시 스케일 다운하는 대신 증가된 용량을 그대로 둡니다.
**이 모범 사례 확립의 이점:** 워크로드 탄력성을 구성하고 테스트하면 클라우드 리소스 공급을 수요에 효율적으로 일치시키고 과도한 프로비저닝을 방지할 수 있습니다. 클라우드의 탄력성을 활용하여 수요가 급증하는 도중과 그 이후에 용량을 자동으로 조정하여 비즈니스 요구 사항을 충족하는 데 필요한 리소스만큼만 사용할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
클라우드는 수요 변화에 맞춰 다양한 메커니즘을 통해 리소스를 동적으로 확장 또는 축소할 수 있는 유연성을 제공합니다. 공급과 수요를 최적으로 일치시키면 워크로드 환경에 미치는 영향이 최소화됩니다.
수요는 고정되거나 가변적일 수 있으므로 관리에 부담이 되지 않도록 측정 기준과 자동화가 필요합니다. 애플리케이션은 인스턴스 크기를 수정하여 수직(위로 또는 아래로)으로 스케일링하거나 인스턴스 수를 수정하여 수평(안 또는 밖으로)으로 스케일링하거나 둘을 모두 조합하여 규모를 조정할 수 있습니다.
다양한 접근 방식을 사용하여 리소스 공급과 수요를 일치시킬 수 있습니다.
+ **타겟 추적 접근 방식**: 규모 조정 지표를 모니터링하고 필요에 따라 용량을 자동으로 늘리거나 줄입니다.
+ **예측 규모 조정:** 일별 및 주별 추세를 고려하여 스케일 인합니다.
+ **일정 기반 접근 방식:** 예측 가능한 로드 변화에 따라 자체 규모 조정 일정을 설정합니다.
+ **서비스 규모 조정:** 기본적으로 설계별로 규모 조정되는 서버리스와 같은 서비스를 선택하거나 Auto Scaling을 기능으로 제공합니다.
활용률이 낮거나 없는 기간을 식별하고 리소스의 크기를 조정하여 초과 용량을 제거하고 효율성을 개선합니다.
## 구현 단계
+ 탄력성은 보유한 리소스의 공급을 해당 리소스의 수요에 맞춥니다. 인스턴스, 컨테이너 및 함수는 자동 규모 조정과 함께 또는 서비스의 기능을 사용하여 탄력성을 지원하는 메커니즘을 제공합니다. AWS는 사용자 로드가 적은 기간에 워크로드를 빠르고 쉽게 스케일 다운할 수 있도록 다양한 Auto Scaling 메커니즘을 제공합니다. 다음은 Auto Scaling 메커니즘 예제입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2024-06-27/framework/sus_sus_user_a2.html)
+ 규모 조정은 대개 Amazon EC2 인스턴스나 AWS Lambda 함수 등의 컴퓨팅 서비스와 관련하여 설명하는 경우가 많습니다. [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 읽기/쓰기 용량 단위나 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 샤드와 같은 컴퓨팅 외의 서비스를 구성할 때는 수요에 일치시키는 것이 좋습니다.
+ 스케일 업 또는 스케일 다운에 대한 지표가 배포 중인 워크로드 유형에 대해 검증되었는지 확인합니다. 동영상 트랜스코딩 애플리케이션을 배포하는 경우 100%의 CPU 활용률이 예상되므로, 기본 지표로 사용해서는 안 됩니다. 필요한 경우 규모 조정 정책에 [사용자 지정 지표](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/)(예: 메모리 사용률)를 사용할 수 있습니다. 올바른 지표를 선택하려면 Amazon EC2에 대한 다음 지침을 고려하세요.
+ 지표는 유효한 사용률 지표여야 하며 인스턴스가 얼마나 많이 사용되는지를 설명해야 합니다.
+ 지표 값은 Auto Scaling 그룹의 인스턴스 수에 비례하여 증가하거나 감소합니다.
+ Auto Scaling 그룹의 경우 [수동 규모 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) 대신 [동적 규모 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)을 사용합니다. 또한 동적 규모 조정에서 [목표 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)을 사용하는 것이 좋습니다.
+ 워크로드 배포에서 스케일 아웃 및 스케일 인 이벤트를 모두 처리할 수 있는지 확인합니다. 스케일 인 이벤트에 대한 테스트 시나리오를 생성하여 워크로드가 예상대로 작동하고 사용자 환경에 영향(예: 스티키 세션 손실)을 미치지 않는지 확인합니다. [활동 내역](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)을 사용하여 Auto Scaling 그룹의 조정 활동을 확인할 수 있습니다.
+ 워크로드의 예측 가능한 패턴을 평가하고 예측 및 계획된 수요 변화에 따라 사전 예방적으로 확장합니다. 예측 규모 조정에서는 용량을 과도하게 프로비저닝할 필요가 없습니다. 자세한 내용은 [Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)을 참조하세요.
## 리소스
**관련 문서:**
+ [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning](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](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)
+ [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](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**관련 비디오:**
+ [AWS re:Invent 2023 - Scaling on AWS for the first 10 million users ](https://www.youtube.com/watch?v=JzuNJ8OUht0)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [AWS re:Invent 2022 - Scaling containers from one user to millions ](https://www.youtube.com/watch?v=hItHqzKoBk0)
+ [AWS re:Invent 2,023 - Scaling FM inference to hundreds of models with Amazon SageMaker AI ](https://www.youtube.com/watch?v=6xENDvgnMCs)
+ [AWS re:Invent 2023 - Harness the power of Karpenter to scale, optimize & upgrade Kubernetes ](https://www.youtube.com/watch?v=lkg_9ETHeks)
**관련 예제:**
+ [ Autoscaling ](https://www.eksworkshop.com/docs/autoscaling/)
# SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정
지속 가능성 목표를 기준으로 서비스 수준에 관한 계약(SLA)을 검토 및 최적화하여 계속해서 비즈니스 필요를 충족하면서 워크로드를 지원하는 데 필요한 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 워크로드 SLA가 알려져 있지 않거나 모호합니다.
+ 가용성 및 성능에 대해서만 SLA를 정의합니다.
+ 모든 워크로드에 대해 동일한 설계 패턴(예: 다중 AZ 아키텍처)을 사용합니다.
**이 모범 사례 확립의 이점:** SLA를 지속 가능성 목표에 맞게 조정하면 비즈니스 요구 사항을 충족하는 동시에 리소스를 최적으로 사용할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
SLA는 클라우드 워크로드에서 예상되는 서비스 수준(예: 응답 시간, 가용성, 데이터 보존 등)을 정의합니다. SLA는 클라우드 워크로드의 아키텍처, 리소스 사용 및 환경 영향에 영향을 미칩니다. 주기적으로 SLA를 검토하여 허용 가능한 수준으로 서비스를 줄여 리소스 사용을 크게 줄이는 절충안을 제시합니다.
### 구현 단계
+ **지속 가능성 목표 이해:** 탄소 배출 감소 또는 리소스 활용 개선과 같은 조직의 지속 가능성 목표를 식별합니다.
+ **SLA 검토:** SLA를 평가하여 SLA가 비즈니스 요구 사항을 지원하는지 평가합니다. SLA를 초과 충족하는 경우 추가 검토를 수행합니다.
+ **장단점 이해:** 워크로드의 복잡성(예: 대량의 동시 사용자), 성능(예: 지연 시간), 지속 가능성에 미치는 영향(예: 필요한 리소스) 전반의 절충점을 이해합니다. 일반적으로 세 번째 요소 대신 첫 두 요소가 우선 고려됩니다.
+ **SLA 조정:** 허용 가능한 수준으로 서비스를 줄여 지속 가능성에 미치는 영향을 크게 줄이는 절충안을 제시합니다.
+ **지속 가능성 및 신뢰성:** 가용성이 높은 워크로드는 리소스를 더 많이 소비하는 경향이 있습니다.
+ **지속 가능성 및 성능:** 성능을 높이기 위해 더 많은 리소스를 사용하면 환경에 더 큰 영향을 미칠 수 있습니다.
+ **지속 가능성 및 보안:** 워크로드 보안이 지나치면 환경에 더 큰 영향을 미칠 수 있습니다.
+ **가능한 경우 지속 가능성 SLA 정의:** 워크로드에 대한 지속 가능성 SLA를 포함합니다. 예를 들어 최소 사용률 수준을 컴퓨팅 인스턴스의 지속 가능성 SLA로 정의합니다.
+ **효율적인 설계 패턴 사용:** 비즈니스에 중요한 기능에 우선순위를 두고 중요하지 않은 기능에 대해 더 낮은 서비스 수준(예: 응답 시간 또는 복구 시간 목표)을 허용하는 AWS의 마이크로 서비스와 같은 설계 패턴을 사용합니다.
+ **의사 소통 및 책임 확립:** 개발팀 및 고객을 포함한 모든 관련 이해관계자와 SLA를 공유합니다. 보고 기능을 사용하여 SLA를 추적하고 모니터링합니다. SLA의 지속 가능성 목표를 달성하기 위한 책임을 할당합니다.
+ **인센티브 및 보상 사용:** 인센티브와 보상을 사용하여 지속 가능성 목표에 맞는 SLA를 달성하거나 초과 달성합니다.
+ **검토 및 반복:** SLA가 진화하는 지속 가능성 및 성능 목표에 부합하는지 정기적으로 검토하고 조정합니다.
## 리소스
**관련 문서:**
+ [ Understand resiliency patterns and trade-offs to architect efficiently in the cloud ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
+ [Importance of Service Level Agreement for SaaS Providers](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**관련 비디오:**
+ [AWS re:Invent 2023 - Capacity, availability, cost efficiency: Pick three ](https://www.youtube.com/watch?v=E0dYLPXrX_w)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지
워크로드에서 미사용 자산을 폐기하여 수요를 지원하는 데 필요한 클라우드 리소스 수를 줄이고 낭비를 최소화합니다.
**일반적인 안티 패턴:**
+ 중복되거나 더 이상 필요하지 않은 자산에 대해 애플리케이션을 분석하지 않습니다.
+ 중복되거나 더 이상 필요하지 않은 자산을 제거하지 않습니다.
**이 모범 사례 확립의 이점:** 미사용 자산을 제거하면 리소스가 절약되고 워크로드의 전반적인 효율성이 향상됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
미사용 자산은 스토리지 공간 및 컴퓨팅 전력과 같은 클라우드 리소스를 소비합니다. 이러한 자산을 식별하고 제거함으로써 리소스를 확보하여 클라우드 아키텍처의 효율성을 높일 수 있습니다. 애플리케이션 자산(예: 사전 컴파일된 보고서, 데이터세트, 정적 이미지 등)과 자산 액세스 패턴을 정기적으로 분석하여 중복된 자산, 활용률이 낮은 자산 및 잠재적 폐기 대상을 식별합니다. 이러한 중복 자산을 제거하여 워크로드의 리소스 낭비를 줄이세요.
### 구현 단계
+ **인벤토리 구성:** 포괄적인 인벤토리를 구성하여 워크로드 내의 모든 자산을 식별합니다.
+ **사용 분석:** 지속적인 모니터링을 사용하여 더 이상 필요하지 않은 정적 자산을 식별합니다.
+ **미사용 자산 제거:** 더 이상 필요하지 않은 자산을 제거할 계획을 세웁니다.
+ 자산을 제거하기 전에 제거로 인해 아키텍처가 받는 영향을 평가합니다.
+ 중복 생성 자산을 통합하여 중복 처리를 제거합니다.
+ 애플리케이션을 업데이트하여 더 이상 필요 없는 자산을 생성하고 저장하지 않습니다.
+ **서드파티와 커뮤니케이션:** 더 이상 필요하지 않은 관리 자산의 생산 및 저장을 중단하도록 서드파티에 지시합니다. 중복 자산 통합을 요청합니다.
+ **수명 주기 정책 사용:** 수명 주기 정책을 사용하여 미사용 자산을 자동으로 삭제합니다.
+ [Amazon S3 수명 주기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)를 사용하여 전체 수명 주기 동안 객체를 관리할 수 있습니다.
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html)를 사용하여 Amazon EBS 지원 AMI 및 Amazon EBS 스냅샷의 생성, 보존 및 삭제를 자동화할 수 있습니다.
+ **검토 및 최적화:** 워크로드를 정기적으로 검토하여 사용되지 않는 자산을 식별하고 제거합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
+ [AWS 계정 계정에서 더 이상 필요하지 않은 활성 리소스를 종료하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**관련 비디오:**
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Preserving and maximizing the value of digital media assets using Amazon S3 ](https://www.youtube.com/watch?v=8OI0Uu-YvD8)
+ [AWS re:Invent 2023 - Optimize costs in your multi-account environments ](https://www.youtube.com/watch?v=ie_Mqb-eC4A)
# SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화
네트워크 트래픽이 이동해야 하는 거리를 단축하고 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄일 수 있는 워크로드의 클라우드 위치 및 서비스를 선택합니다.
** 일반적인 안티 패턴: **
+ 자신의 고유한 위치를 기준으로 워크로드의 리전을 선택합니다.
+ 모든 워크로드 리소스를 하나의 지리적 위치로 통합합니다.
+ 모든 트래픽이 기존 데이터 센터를 통과합니다.
**이 모범 사례 확립의 이점:** 사용자에게 가깝게 워크로드를 배치하면 지연 시간을 최대한 단축할 수 있고 동시에 네트워크 간 데이터 이동을 줄이며 환경에 미치는 영향을 줄일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
AWS 클라우드 인프라는 리전, 가용 영역, 배치 그룹, 엣지 로케이션(예: [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 및 [AWS 로컬 영역](https://aws.amazon.com/about-aws/global-infrastructure/localzones/))과 같은 위치 옵션을 중심으로 구축됩니다. 이러한 위치 옵션은 애플리케이션 구성 요소, 클라우드 서비스, 엣지 네트워크, 온프레미스 데이터 센터 간의 연결을 유지합니다.
워크로드의 네트워크 액세스 패턴을 분석하여 이러한 클라우드 위치 옵션을 사용하는 방법을 식별하고 네트워크 트래픽이 이동해야 하는 거리를 줄입니다.
## 구현 단계
+ 워크로드의 네트워크 액세스 패턴을 분석하여 사용자가 애플리케이션을 사용하는 방법을 식별합니다.
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 및 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)과 같은 모니터링 도구를 사용하여 네트워크 활동에 대한 데이터를 수집합니다.
+ 데이터를 분석하여 네트워크 액세스 패턴을 식별합니다.
+ 다음과 같은 주요 요소를 토대로 하여 워크로드 배포용 리전을 선택합니다.
+ **지속 가능성 목표:** [리전 선택](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html)에서 설명합니다.
+ **데이터 위치:** 데이터를 많이 사용하는 애플리케이션의 경우(예: 빅 데이터 및 기계 학습) 애플리케이션 코드는 최대한 데이터와 가까운 위치에서 실행되어야 합니다.
+ **사용자 위치:** 사용자가 직접 사용하는 애플리케이션의 경우 워크로드의 사용자와 가까운 하나 이상의 리전을 선택합니다.
+ **기타 제약 조건:** [What to Consider when Selecting a Region for your Workloads](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)에 나와 있는 비용 및 규정 준수 등 제약 요건을 고려합니다.
+ 자주 사용하는 자산에 로컬 캐싱 또는 [AWS Caching Solutions](https://aws.amazon.com/caching/aws-caching/)를 사용하여 성능을 개선하고, 데이터 이동을 줄이며, 환경에 미치는 영향을 줄입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2024-06-27/framework/sus_sus_user_a5.html)
+ 워크로드 사용자에게 더 가까운 위치에서 코드를 실행할 수 있는 서비스를 사용합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2024-06-27/framework/sus_sus_user_a5.html)
+ 연결 풀을 사용하여 연결을 재사용하고 필요한 리소스를 줄입니다.
+ 지속적 연결 및 동기식 업데이트에 의존하지 않는 분산 데이터 스토어를 사용하여 리전별 사용자 집단을 일관되게 지원합니다.
+ 사전 프로비저닝된 정적 네트워크 용량을 공유 동적 용량으로 교체하고 네트워크 용량의 지속 가능성에 미치는 영향을 다른 구독자와 공유합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](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)
+ [What is Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
+ [AWS 글로벌 인프라 ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones and AWS Outposts, choosing the right technology for your edge workload ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ 배치 그룹 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [AWS 로컬 영역 ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
**관련 비디오:**
+ [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ Scaling network performance on next-gen Amazon EC2 instances ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
+ [AWS Local Zones Explainer Video ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: Overview and How it Works ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2023 - A migration strategy for edge and on-premises workloads ](https://www.youtube.com/watch?v=4wUXzYNLvTw)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020 - AWS Wavelength: Run apps with ultra-low latency at 5G edge ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Building low-latency websites with Amazon CloudFront ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - Build your global wide area network using AWS](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
**관련 예제:**
+ [AWS Networking 워크숍](https://catalog.workshops.aws/networking/en-US)
+ [ Architecting for sustainability - Minimize data movement across networks ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화
팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 환경 지속 가능성에 미치는 영향을 최소화합니다.
**일반적인 안티 패턴:**
+ 팀원이 사용하는 디바이스가 클라우드 애플리케이션의 전반적인 효율성에 미치는 영향을 무시합니다.
+ 팀원이 사용하는 리소스를 수동으로 관리하고 업데이트합니다.
**이 모범 사례 확립의 이점:** 팀원 리소스를 최적화하면 클라우드 지원 애플리케이션의 전반적인 효율성이 향상됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
팀원이 서비스를 사용하는 데 활용하는 리소스, 예상 수명 주기, 재무 및 지속 가능성에 미치는 영향을 이해합니다. 이러한 리소스를 최적화하기 위한 전략을 구현합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 확장 가능한 인프라에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.
### 구현 단계
+ **에너지 효율적인 워크스테이션 사용:** 팀원에게 에너지 효율이 높은 워크스테이션과 주변 디바이스를 제공합니다. 이러한 디바이스에서 효율적인 전력 관리 기능(예: 저전력 모드)을 사용하여 에너지 사용량을 줄입니다.
+ **가상화 사용:** 가상 데스크톱 및 애플리케이션 스트리밍을 사용하여 업그레이드 및 디바이스 요구 사항을 제한합니다.
+ **원격 협업 장려:** 팀원이 [Amazon Chime](https://aws.amazon.com/chime/) 또는 [AWS Wickr](https://aws.amazon.com/wickr/) 같은 원격 협업 도구를 사용하여 출장의 필요성 및 이와 관련된 탄소 배출량을 줄이도록 장려합니다.
+ **에너지 효율적인 소프트웨어 사용:** 불필요한 기능 및 프로세스를 제거하거나 해제하여 팀원에게 에너지 효율적인 소프트웨어를 제공합니다.
+ **수명 주기 관리:** 디바이스 수명 주기에 대한 프로세스 및 시스템의 영향을 평가하고 비즈니스 요구 사항을 충족하면서 디바이스 교체 요구 사항을 최소화하는 솔루션을 선택합니다. 워크스테이션이나 소프트웨어를 정기적으로 유지 관리하고 업데이트하여 효율성을 유지하고 개선합니다.
+ **원격 디바이스 관리:** 디바이스에 대한 원격 관리를 구현하여 필요한 출장을 줄입니다.
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html)는 AWS 또는 온프레미스에서 실행 중인 노드를 원격으로 관리하는 데 도움이 되는 통합 사용자 인터페이스(UI) 환경입니다.
## 리소스
**관련 문서:**
+ [Amazon WorkSpaces란 무엇인가요?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Cost Optimizer for Amazon WorkSpaces](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**관련 비디오:**
+ [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE)
# SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화
버퍼링 및 제한은 수요 곡선을 완화하고 워크로드에 필요한 프로비저닝 용량을 줄입니다.
**일반적인 안티 패턴:**
+ 클라이언트 요청은 필요하지 않아도 즉시 처리합니다.
+ 클라이언트 요청에 대한 요구 사항을 분석하지 않습니다.
**이 모범 사례 확립의 이점:** 수요 곡선을 단순화하면 워크로드에 필요한 프로비저닝 용량이 줄어듭니다. 프로비저닝 용량을 줄이면 에너지 소비와 환경에 미치는 영향도 줄어듭니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
워크로드 수요 곡선을 완화하면 워크로드에 프로비저닝된 용량을 줄이고 환경에 미치는 영향도 줄일 수 있습니다. 아래 그림에 표시된 수요 곡선을 바탕으로 워크로드를 가정합니다. 이 워크로드에는 2개의 피크가 있으며, 이러한 피크를 처리하기 위해 주황색 선으로 표시된 리소스 용량이 프로비저닝됩니다. 이 워크로드에 사용되는 리소스와 에너지는 수요 곡선 아래의 영역이 아니라 프로비저닝된 용량 선 아래의 영역으로 표시됩니다. 이 2개의 피크를 처리하려면 프로비저닝된 용량이 필요하기 때문입니다.
![\[높은 프로비저닝 용량을 필요로 하는 두 개의 피크가 있는 프로비저닝된 용량 파형.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2024-06-27/framework/images/provisioned-capacity-1.png)
버퍼링 또는 제한을 사용하여 수요 곡선을 수정하고 피크를 완화할 수 있습니다. 이렇게 되면 프로비저닝된 용량과 소비되는 에너지가 줄어듭니다. 클라이언트가 재시도를 수행할 때 제한을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다.
![\[버퍼링 또는 제한을 사용하여 피크를 완화한 워크로드를 표시하는 파형 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2024-06-27/framework/images/provisioned-capacity-2.png)
**구현 단계**
+ 클라이언트 요청을 분석하여 응답 방법을 결정합니다. 고려해야 할 질문은 다음과 같습니다.
+ 이 요청을 비동기식으로 처리할 수 있는가?
+ 클라이언트에 재시도 기능이 있는가?
+ 클라이언트에 재시도 기능이 있는 경우 현재 요청을 처리할 수 없으면 나중에 다시 시도해야 함을 소스에 알려주는 제한 기능을 구현할 수 있습니다.
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)를 사용하여 제한을 구현할 수 있습니다.
+ 재시도를 수행할 수 없는 클라이언트의 경우 수요 곡선을 완화하려면 버퍼를 구현해야 합니다. 버퍼는 서로 다른 속도로 실행되는 애플리케이션이 효과적으로 통신할 수 있도록 요청 처리를 연기합니다. 버퍼 기반 접근 방식은 대기열 또는 스트림을 사용하여 생산자의 메시지를 수락합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/)는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공하는 관리형 서비스입니다.
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)에서는 여러 소비자가 같은 메시지를 읽을 수 있는 스트림을 제공합니다.
+ 전체 수요, 변경률 및 필수 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 적절하게 조정합니다.
## 리소스
**관련 문서:**
+ [ Getting started with Amazon SQS ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Application integration Using Queues and Messages ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Throttling a tiered, multi-tenant REST API at scale using API Gateway ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ Application integration Using Queues and Messages ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
**관련 비디오:**
+ [AWS re:Invent 2022 - Application integration patterns for microservices ](https://www.youtube.com/watch?v=GoBOivyE7PY)
+ [AWS re:Invent 2023 - Smart savings: Amazon EC2 cost-optimization strategies ](https://www.youtube.com/watch?v=_AHPbxzIGV0)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)