[DOP-C01] AWS DevOps Engineer Professional : Part 21

 

 

 

1. EC2에서 기가비트 네트워크 처리량을 달성하려면 무엇이 필요합니까? 향상된 네트워킹이 포함된 클러스터 컴퓨팅, 10GB 인스턴스를 이미 선택했으며 워크로드가 이미 네트워크에 바인딩되어 있지만 10기가비트 속도가 표시되지 않습니다.
   • 서버에서 양방향 네트워킹을 활성화하여 패킷이 양방향으로 차단되지 않고 전환 오버헤드가 없도록 합니다.
   • 한 VPC에서 인터넷 게이트웨이가 포화되지 않도록 인스턴스가 서로 다른 VPC에 있는지 확인하십시오.
   • 드라이브에 대한 PIOPS를 선택하고 여러 개를 마운트하여 충분한 디스크 처리량을 프로비저닝할 수 있습니다.
   • 인스턴스가 동일한 가용 영역에서 물리적으로 서로 가까이 있도록 인스턴스에 대한 배치 그룹을 사용합니다.
   설명:

   배치 그룹 내를 제외하고 10기가비트 성능이 보장되지 않습니다. 배치 그룹은 단일 가용 영역 내 인스턴스의 논리적 그룹입니다. 배치 그룹을 사용하면 애플리케이션이 대기 시간이 짧은 10Gbps 네트워크에 참여할 수 있습니다. 배치 그룹은 낮은 네트워크 대기 시간, 높은 네트워크 처리량 또는 둘 다의 이점을 활용하는 애플리케이션에 권장됩니다.
   
   

2. CloudFormation 스택 상태 업데이트가 지속적 배포 시스템에 가능한 한 실시간에 가깝게 표시되도록 하려면 어떻게 해야 합니까?
   • CloudFormation 스택의 리소스 개체에 대해 긴 폴링을 사용하고 시스템의 UI에 해당 상태 변경 사항을 표시합니다.
   • CloudFormation 스택에 대한 <code>ListStacksAPI</code> 호출에서 긴 폴링을 사용하고 시스템의 UI에 해당 상태 변경 사항을 표시합니다.
   • 이벤트를 게시하도록 CloudFormation 스택에 알리는 SNS 주제에 지속적 전달 시스템을 구독하십시오.
   • 이벤트를 게시하도록 CloudFormation 스택에 지시하는 SQS 대기열에 지속적 전달 시스템을 구독하십시오.
   설명:

   거의 실시간으로 스택 이벤트를 SNS에 푸시하기 위해 CreateStack 호출을 만들 때 NotificationARNs.member.N을 사용하십시오.
   
   

3. 실행 중인 EC2 인스턴스에 연결된 모든 EBS 볼륨에 대해 IOPS가 0이고 비어 있지 않은 I/O 대기열이 있다는 것은 무엇을 의미합니까?
   • I/O 큐는 버퍼 플러시입니다.
   • EBS 디스크 헤드가 마그네틱 스트라이프를 찾고 있습니다.
   • EBS 볼륨을 사용할 수 없습니다.
   • OS에서 EBS 볼륨을 다시 마운트해야 합니다.
   설명:
   이것은 EC2 및 EBS SLA에서 사용할 수 없음의 정의입니다. “사용 불가” 및 “사용 불가”는… Amazon EBS의 경우 연결된 모든 볼륨이 읽기 쓰기 IO를 전혀 수행하지 않고 대기 중인 IO가 대기열에 있는 경우를 의미합니다.
4. 규정 준수 및 보안 관점에서 다음 중 참인 설명은 무엇입니까?
   • AWS IAM 사용자에 대한 액세스 키를 교체할 필요가 없습니다.
   • AWS IAM 역할이나 AWS IAM 사용자에 대한 액세스 키를 교체할 필요가 없습니다.
   • 다른 진술 중 어느 것도 사실이 아닙니다.
   • 다른 진술 중 어느 것도 사실이 아닙니다.
   설명:

   IAM 역할 액세스 키는 AWS에서 사용자를 대신하여 자동으로 회전합니다. 회전할 필요가 없습니다. 응용 프로그램에는 역할과 연결된 보안 자격 증명을 통해 역할에 대해 정의한 작업 및 리소스에 대한 권한이 부여됩니다. 이러한 보안 자격 증명은 일시적이며 자동으로 교체됩니다. 이전 자격 증명이 만료되기 최소 5분 전에 새 자격 증명을 사용할 수 있습니다.
   
   

5. 이러한 구성 또는 배포 방법 중 RDS에 대한 보안 위험은 무엇입니까?
   • SQL 함수 코드를 일반 텍스트로 저장
   • 비 다중 AZ RDS 인스턴스
   • RDS 및 EC2 인스턴스가 동일한 서브넷에 있음
   • 퍼블릭 서브넷의 RDS
   설명:
   퍼블릭 서브넷의 퍼블릭 인터넷에서 RDS에 액세스할 수 있도록 하면 데이터베이스를 직접 주소 지정 및 스팸 가능하게 만들어 보안 위험이 있습니다. VPC 내에 배포된 DB 인스턴스는 인터넷 또는 VPC 외부의 EC2 인스턴스에서 액세스할 수 있도록 구성할 수 있습니다. VPC 보안 그룹이 TCP 포트 22와 같은 포트 액세스를 지정하면 DB 인스턴스의 방화벽이 인스턴스가 구성원인 DB 보안 그룹에서 지정한 IP 주소를 통해서만 액세스를 제공하기 때문에 DB 인스턴스에 액세스할 수 없습니다. of 및 DB 인스턴스가 생성될 때 정의된 포트.
   
   
6. 다음 중 다중 AZ RDS 인스턴스가 장애 조치되는 이유가 아닌 것은 무엇입니까?
   • 가용 영역 중단
   • 장애 조치와 함께 재부팅을 사용하여 DB 인스턴스의 수동 장애 조치가 시작되었습니다.
   • 더 높은 인스턴스 클래스로 자동 확장하려면
   • 기본 DB 인스턴스 실패
   설명:

   다음 조건 중 하나가 발생하면 기본 DB 인스턴스가 대기 복제본으로 자동 전환됩니다. 가용 영역 중단, 기본 DB 인스턴스 장애, DB 인스턴스의 서버 유형 변경, DB 인스턴스의 운영 체제 소프트웨어 진행 중 패치, 장애 조치와 함께 재부팅을 사용하여 DB 인스턴스의 수동 장애 조치가 시작되었습니다.
   
   

7. 고객 뱅킹 데이터에 대한 모든 변경 사항에 대한 감사 로그를 생성해야 합니다. DynamoDB를 사용하여 이 고객 뱅킹 데이터를 저장합니다. 서버 장애로 인해 정보가 손실되지 않도록 하는 것이 중요합니다.
   
   이것을 달성하는 우아한 방법은 무엇입니까?
   
   • DynamoDB StreamSpecification을 사용하고 모든 변경 사항을 AWS Lambda로 스트리밍합니다. AWS CloudWatch Logs에 대한 변경 사항을 기록하고 기록하기 전에 중요한 정보를 제거합니다.
   • DynamoDB에 쓰기 전에 애플리케이션 서버의 디스크에 미리 쓰기 승인을 수행하여 로깅하기 전에 중요한 정보를 제거합니다. 주기적으로 이러한 로그 파일을 S3로 교체합니다.
   • DynamoDB StreamSpecification을 사용하고 주기적으로 EC2 인스턴스 스토어로 플러시하여 객체를 넣기 전에 중요한 정보를 제거합니다. 주기적으로 이러한 배치를 S3로 플러시합니다.
   • DynamoDB에 쓰기 전에 애플리케이션 서버의 디스크에 미리 쓰기 승인을 수행하여 로깅하기 전에 중요한 정보를 제거합니다. 주기적으로 이러한 파일을 CloudWatch Logs로 파이프합니다.
   설명:
   제안된 모든 주기적 옵션은 주기적 플러시 중 또는 주기적 플러시 사이의 서버 오류에 민감합니다. Lambda로 스트리밍한 다음 CloudWatch Logs에 로깅하면 시스템이 인스턴스 및 가용 영역 장애에 대한 복원력을 갖게 됩니다.
   
   
8. 전체 리전 AWS 장애 중에 온라인 상태를 유지하려면 DynamoDB에서 지원하는 API가 필요합니다. 대규모 오류 이벤트 동안 몇 분의 지연 또는 속도 저하를 허용할 수 있지만 시스템은 몇 분 후에 정상 작동으로 복구되어야 합니다.
   
   좋은 접근 방식이란 무엇입니까?
   
   • 다른 리전에 단일 대기가 있는 마스터-대기 구성에서 DynamoDB 교차 리전 복제를 설정합니다. DynamoDB가 실행 중인 각 리전에서 ELB 뒤에 Auto Scaling 그룹을 생성합니다. 두 리전의 ELB를 리소스 레코드로 사용하여 DNS 장애 조치가 포함된 Route53 지연 시간 DNS 레코드를 추가합니다.
   • DynamoDB 다중 리전 테이블을 설정합니다. DynamoDB가 실행 중인 각 리전에서 ELB 뒤에 Auto Scaling 그룹을 생성합니다. 두 리전의 ELB를 리소스 레코드로 사용하여 DNS 장애 조치가 포함된 Route53 지연 시간 DNS 레코드를 추가합니다.
   • DynamoDB 다중 리전 테이블을 설정합니다. 지역 간 Auto Scaling 그룹을 가리키는 지역 간 ELB를 생성하고 DNS 장애 조치가 포함된 Route53 지연 시간 DNS 레코드를 지역 간 ELB로 보냅니다.
   • 다른 리전에 단일 대기가 있는 마스터-대기 구성에서 DynamoDB 교차 리전 복제를 설정합니다. 지역 간 Auto Scaling 그룹을 가리키는 지역 간 ELB를 생성하고 DNS 장애 조치가 포함된 Route53 지연 시간 DNS 레코드를 지역 간 ELB로 보냅니다.
   설명:

   교차 지역 ELB, 교차 지역 Auto Scaling Group, DynamoDB Multi-Region Table 같은 것은 없습니다. 이치에 맞는 유일한 옵션은 Route53 Failover 및 Latency DNS가 포함된 2개의 ELB 및 ASG가 포함된 교차 지역 복제 버전입니다.

9. Auto Scaling 그룹과 SQS 대기열을 사용하는 비동기식 처리 애플리케이션이 있습니다. Auto Scaling Group은 작업 대기열의 깊이에 따라 확장됩니다. 작업 완료 속도가 떨어지고 Auto Scaling 그룹 크기가 최대가 되었지만 인바운드 작업 속도는 증가하지 않았습니다.
   
   가능한 문제는 무엇입니까?
   
   • 들어오는 새 작업 중 일부는 형식이 잘못되어 처리할 수 없습니다.
   • 라우팅 테이블이 변경되었고 어떤 작업자도 더 이상 이벤트를 처리할 수 없습니다.
   • 누군가 작업자 그룹의 인스턴스에 대한 IAM 역할 정책을 변경하고 대기열에 액세스할 수 있는 권한을 위반했습니다.
   • 스케일링 지표가 올바르게 작동하지 않습니다.
   설명:
   IAM 역할이 손상되지 않은 것처럼 양호해야 합니다. 시스템이 대기열 메시지를 가져올 수 없기 때문에 작업이 처리되지 않습니다. 동일한 추론이 라우팅 테이블 변경에 적용됩니다. 나가는 메시지보다 들어오는 메시지가 많아 대기열 깊이가 증가하면 인스턴스 수가 증가하므로 조정 지표는 양호합니다. 따라서 유일하게 합리적인 옵션은 최근 메시지 중 일부가 잘못되어 처리할 수 없는 메시지여야 한다는 것입니다.
10. 회사는 회사의 프로덕션 AWS 계정에서 비용이 발생하는 위치를 이해하려고 합니다. 주어진 시간에 실행되는 많은 응용 프로그램과 서비스가 있습니다. 초기 개발 시간을 너무 많이 들이지 않고 한 달 운영 비용이 가장 많이 드는 애플리케이션을 비즈니스에 가장 잘 이해할 수 있는 방법은 무엇입니까?
    • 청구서에 대한 자세한 월별 정보를 요청하는 AWS Support 티켓을 주기적으로 생성하는 자동화 스크립트를 생성합니다.
    • 시스템에서 사용자 지정 CloudWatch 지표를 사용하고 비용이 발생할 때마다 지표 데이터 포인트를 입력하십시오.
    • 이를 지원하는 모든 리소스에 대해 AWS Cost Allocation Tagging을 사용합니다. Cost Explorer를 사용하여 한 달 내내 비용을 분석하십시오.
    • AWS Price API와 지속적으로 실행되는 리소스 인벤토리 스크립트를 사용하여 시간이 지남에 따라 소비된 리소스의 곱을 기반으로 총 가격을 계산합니다.
    설명:

    비용 할당 태그 지정은 AWS의 기본 제공 기능이며 비용 탐색기와 결합하면 비용을 추적하는 간단하고 강력한 방법을 제공합니다. 비용 탐색기에서 태그를 사용하여 보기를 필터링할 수도 있습니다. 비용 탐색기에서 태그별로 보기를 필터링하려면 먼저 다음 섹션에 설명된 대로 리소스에 태그를 적용하고 활성화해야 합니다. 비용 탐색기에 대한 자세한 내용은 비용 탐색기로 비용 분석 단원을 참조하십시오.
    
    

11. AWS에서 매우 심각한 중단이 발생했습니다. EC2는 영향을 받지 않지만 중단이 발생한 지역에서 EC2 인스턴스 배포 스크립트가 작동을 멈췄습니다.
    
    무엇이 문제일까요?
    
    • AWS 콘솔이 다운되어 CLI 명령이 작동하지 않습니다.
    • S3를 사용할 수 없으므로 새 볼륨을 배포하는 데 사용하는 스냅샷에서 EBS 볼륨을 생성할 수 없습니다.
    • AWS는 시스템 플러드로부터 보호하기 위해 대규모 중단이 있을 때 <code>DeployCode</code> API 호출을 끕니다.
    • 다른 답변은 의미가 없습니다. EC2가 영향을 받지 않는다면 다른 문제일 것입니다.
    설명:
    S3는 모든 스냅샷을 저장합니다. S3를 사용할 수 없으면 스냅샷을 사용할 수 없습니다. Amazon EC2는 또한 Amazon S3를 사용하여 데이터 볼륨의 스냅샷(백업 복사본)을 저장합니다. 응용 프로그램 또는 시스템 오류가 발생한 경우 데이터를 빠르고 안정적으로 복구하기 위해 스냅샷을 사용할 수 있습니다. 또한 스냅샷을 기준으로 사용하여 여러 개의 새 데이터 볼륨을 생성하거나, 기존 데이터 볼륨의 크기를 확장하거나, 여러 가용 영역 간에 데이터 볼륨을 이동함으로써 데이터 사용량의 확장성을 높일 수 있습니다. 데이터 볼륨 및 스냅샷 사용에 대한 자세한 내용은 Amazon Elastic Block Store를 참조하십시오.
    
    
12. 다음 중 스택 모니터링을 위해 AWS OpsWorks를 직접 지원하지 않는 도구는 무엇입니까?
    • AWS 구성
    • Amazon CloudWatch 지표
    • AWS CloudTrail
    • Amazon CloudWatch 로그
    설명:
    다음과 같은 방법으로 스택을 모니터링할 수 있습니다. AWS OpsWorks는 Amazon CloudWatch를 사용하여 스택의 각 인스턴스에 대한 자세한 모니터링과 함께 13개의 사용자 지정 지표를 제공합니다. AWS OpsWorks는 AWS CloudTrail과 통합되어 모든 AWS OpsWorks API 호출을 기록하고 데이터를 Amazon S3 버킷에 저장합니다. Amazon CloudWatch Logs를 사용하여 스택의 시스템, 애플리케이션 및 사용자 지정 로그를 모니터링할 수 있습니다.
    
    
13. AWS CloudFormation의 순환 종속성은 무엇입니까?
    • 템플릿이 자신의 이전 버전을 참조하는 경우.
    • 중첩 스택이 서로 의존하는 경우.
    • 리소스가 DependOn 루프를 형성하는 경우.
    • 템플릿이 원래 템플릿을 참조하는 영역을 참조하는 경우.
    설명:

    종속성 오류를 해결하려면 템플릿의 다른 리소스에 의존하는 리소스에 DependsOn 특성을 추가합니다. 어떤 경우에는 AWS CloudFormation이 올바른 순서로 리소스를 생성하거나 삭제할 수 있도록 종속성을 명시적으로 선언해야 합니다. 예를 들어 탄력적 IP와 동일한 스택에 인터넷 게이트웨이가 있는 VPC를 생성하는 경우 탄력적 IP는 인터넷 게이트웨이 연결에 의존해야 합니다. 추가 정보는 DependsOn 속성을 참조하십시오.
    
    

14. 매우 큰 배치 데이터 처리 작업을 하루에 한 번 실행해야 합니다. 소스 데이터는 전적으로 S3에 존재하며 처리 작업의 출력도 완료되면 S3에 기록되어야 합니다. 이 처리 작업과 시스템의 모든 설정 및 해제 논리를 버전 제어해야 하는 경우 어떤 접근 방식을 사용해야 합니까?
    • AWS Elastic Beanstalk에서 AWS EMR 작업을 모델링합니다.
    • AWS CloudFormation에서 AWS EMR 작업을 모델링합니다.
    • AWS OpsWorks에서 AWS EMR 작업을 모델링합니다.
    • AWS CLI Composer에서 AWS EMR 작업을 모델링합니다.
    설명:
    선언적으로 클러스터의 빌드 및 제거를 모델링하려면 AWS CloudFormation을 사용해야 합니다. OpsWorks 및 Elastic Beanstalk는 EMR 클러스터를 직접 모델링할 수 없습니다. CLI는 선언적이지 않으며 CLI Composer가 존재하지 않습니다.
    
    
    
15. EBS에서 암호화가 작동하는 방식에 대한 설명으로 옳은 것은 무엇입니까?
    • 암호화된 볼륨을 스냅샷하면 암호화된 스냅샷이 생성됩니다. 암호화된 스냅샷을 복원하면 지정/요청 시 암호화된 볼륨이 생성됩니다.
    • 암호화된 볼륨의 스냅샷은 지정/요청 시 암호화된 스냅샷을 생성합니다. 암호화된 스냅샷을 복원하면 지정/요청 시 암호화된 볼륨이 생성됩니다.
    • 암호화된 볼륨을 스냅샷하면 암호화된 스냅샷이 생성됩니다. 암호화된 스냅샷을 복원하면 항상 암호화된 볼륨이 생성됩니다.
    • 암호화된 볼륨의 스냅샷은 지정/요청 시 암호화된 스냅샷을 생성합니다. 암호화된 스냅샷을 복원하면 항상 암호화된 볼륨이 생성됩니다.
    설명:

    암호화된 볼륨에서 가져온 스냅샷은 자동으로 암호화됩니다. 암호화된 스냅샷에서 생성된 볼륨도 자동으로 암호화됩니다. 암호화된 볼륨 및 모든 관련 스냅샷은 항상 보호된 상태로 유지됩니다. 자세한 내용은 Amazon EBS 암호화를 참조하십시오.
    
    

16. 다음 중 AWS OpsWorks에 대해 생각할 때 참인 것은 무엇입니까?
    • 스택에는 많은 레이어가 있고 레이어에는 많은 인스턴스가 있습니다.
    • 인스턴스에는 많은 스택이 있고 스택에는 많은 레이어가 있습니다.
    • 레이어에는 많은 스택이 있고 스택에는 많은 인스턴스가 있습니다.
    • 레이어에는 많은 인스턴스가 있고 인스턴스에는 많은 스택이 있습니다.
    설명:

    스택은 핵심 AWS OpsWorks 구성 요소입니다. 기본적으로 Amazon EC2 인스턴스, Amazon RDS 데이터베이스 인스턴스 등 공통 목적을 갖고 논리적으로 함께 관리해야 하는 AWS 리소스를 위한 컨테이너입니다. 하나 이상의 레이어를 추가하여 스택의 구성 요소를 정의합니다. 계층은 애플리케이션 제공 또는 데이터베이스 서버 호스팅과 같은 특정 용도를 제공하는 Amazon EC2 인스턴스 집합을 나타냅니다. 인스턴스는 Amazon EC2 인스턴스와 같은 단일 컴퓨팅 리소스를 나타냅니다.
    
    

17. AWS Elastic Beanstalk에 대해 생각할 때 올바른 설명은 무엇입니까?
    • 작업자 계층은 SNS에서 작업을 가져옵니다.
    • 작업자 계층은 SNS에서 작업을 가져옵니다.
    • 작업자 계층은 JSON에서 작업을 가져옵니다.
    • 작업자 계층은 SQS에서 작업을 가져옵니다.
    설명:
    Elastic Beanstalk는 작업자 환경에서 Amazon SQS 메시지를 처리하기 위해 Auto Scaling 그룹의 각 Amazon EC2 인스턴스에 데몬을 설치합니다. 데몬은 Amazon SQS 대기열에서 데이터를 가져와 HTTP POST 요청의 메시지 본문에 삽입하고 로컬 호스트에서 사용자가 구성할 수 있는 URL 경로로 보냅니다. HTTP POST 요청 내 메시지 본문의 콘텐츠 유형은 기본적으로 application/json입니다.
    
    
    
18. 귀사는 대규모 클라우드 배포의 3계층을 자동화해야 합니다. 시간 경과에 따라 변경되는 이 배포의 진화를 추적하고 모든 변경 사항을 신중하게 제어할 수 있기를 원합니다. 이러한 요구 사항을 충족하기 위해 스택을 자동화하는 좋은 방법은 무엇입니까?
    • 세 개의 레이어가 있는 OpsWorks Stacks를 사용하여 스택의 레이어링을 모델링합니다.
    • 3개의 하위 스택이 있는 CloudFormation 중첩 스택 템플릿을 사용하여 클라우드의 3개 논리적 계층을 나타냅니다.
    • AWS Config를 사용하여 AWS가 클라우드로 롤아웃해야 하는 구성 집합을 선언합니다.
    • Elastic Beanstalk 연결된 애플리케이션을 사용하여 메타데이터 인터페이스를 사용하여 레이어 간에 중요한 DNS 전체를 전달합니다.
    설명:

    CloudFormation만이 소스 제어 선언적 템플릿을 스택 자동화의 기반으로 허용합니다. 중첩 스택은 레이어를 깔끔하게 분리하는 동시에 필요할 때 모든 레이어를 한 번에 제어할 수 있는 방법을 제공합니다.
    
    

19. 애플리케이션의 Auto Scaling 그룹이 너무 빨리, 너무 많이 확장되고 트래픽이 감소해도 확장된 상태를 유지합니다.
    
    이 문제를 해결하려면 어떻게 해야 합니까?
    
    • 시스템이 목표 용량 초과를 중지하도록 그룹에 더 긴 휴지 기간을 설정합니다. 문제는 확장 시스템이 총 로드를 다시 측정하기 전에 새 인스턴스가 요청 서비스를 시작할 수 있는 충분한 시간을 허용하지 않는다는 것입니다.
    • 컴퓨팅 계층에서 병목 현상 또는 제약 조건을 계산한 다음 이를 새 지표로 선택하고 지표 임계값을 응답 대기 시간에 영향을 미치기 시작하는 경계 값으로 설정합니다.
    • Auto Scaling 그룹과 연결된 CloudWatch 경보 임계값을 높여 조정이 시작되기 전에 수요 증가를 더 많이 차지하도록 합니다.
    • 여러 개의 작은 인스턴스 대신 큰 인스턴스를 사용하면 OS가 더 작은 인스턴스에서 더 높은 비율의 리소스를 사용하기 때문에 그룹이 너무 많은 확장 및 OS 수준으로 리소스 낭비를 중지합니다.
    설명:

    먼저 소진되고 먼저 제한되는 메트릭을 선택하지 않는 한 시스템은 항상 확장됩니다. 또한 대기 시간이 변경의 영향을 받는지 여부에 따라 메트릭의 임계값을 설정하여 비용을 낭비하는 대신 용량을 추가하는 것이 타당함을 입증해야 합니다.
    
    

20. 클러스터 컴퓨팅 애플리케이션을 위해서는 절대적으로 가능한 최고의 네트워크 성능이 필요합니다. 이미 10기가비트 향상된 네트워킹을 지원하는 동종 인스턴스 유형을 선택했고, 워크로드가 네트워크에 바인딩되었는지 확인하고 인스턴스를 배치 그룹에 넣었습니다. 마지막으로 수행할 수 있는 최적화는 무엇입니까?
    • 점보 프레임에 대해 1500 대신 9001 MTU를 사용하여 패킷 본문 대 패킷 오버헤드 비율을 높입니다.
    • 인스턴스를 모두 배치 그룹에 유지하면서 서로 다른 피어링된 VPC로 분리하여 각각 고유한 인터넷 게이트웨이를 갖도록 합니다.
    • 인스턴스에 대한 AMI를 굽고 다시 실행하여 인스턴스가 배치 그룹에서 새로워지고 시끄러운 이웃이 없도록 합니다.
    • TCP 스택에서 SYN/ACK를 끄거나 더 높은 처리량을 위해 UDP를 사용하십시오.
    설명:

    배치 그룹 내에 배치된 인스턴스의 경우 점보 프레임은 가능한 최대 네트워크 처리량을 달성하는 데 도움이 되며 이 경우 권장됩니다. 자세한 내용은 배치 그룹을 참조하십시오.