Aurora 스펙별 제한
| 인스턴스 클래스 | vCPU | 메모리(GiB) | 인스턴스 스토리지(GiB) | 최대 EBS 대역폭(Mbps) | 네트워크 대역폭(Gbps) |
| db.r6g.16xlarge | 64 | 512 | EBS 최적화 전용 | 19,000 | 25 |
| db.r6g.12xlarge | 48 | 384 | EBS 최적화 전용 | 13,500 | 20 |
| db.r6g.8xlarge | 32 | 256 | EBS 최적화 전용 | 9,000 | 12 |
| db.r6g.4xlarge | 16 | 128 | EBS 최적화 전용 | 4,750 | 기준 5.0 / 최대 10 |
| db.r6g.2xlarge | 8 | 64 | EBS 최적화 전용 | 기준 2375 / 최대 4,750 | 기준 2.5 (312.5 MB/s) / 최대 10 |
| db.r6g.xlarge | 4 | 32 | EBS 최적화 전용 | 기준 1188 / 최대 4,750 | 기준 1.25 (156.2 MB/s) / 최대 10 |
| db.r6g.large | 2 | 16 | EBS 최적화 전용 | 기준 630 / 최대 4,750 | 기준 0.75 / 최대 10 |
Elasticache 스펙별 제한
| 인스턴스 클래스 | vCPU | 메모리(GiB) | 네트워크 대역폭(Gbps) |
| db.r6g.16xlarge | 64 | 419.09 | 25 |
| db.r6g.12xlarge | 48 | 317.77 | 20 |
| db.r6g.8xlarge | 32 | 209.55 | 12 |
| db.r6g.4xlarge | 16 | 105.81 | 기준 5.0 / 최대 10 |
| db.r6g.2xlarge | 8 | 52.82 | 기준 2.5 (312.5 MB/s) / 최대 10 |
| db.r6g.xlarge | 4 | 25.32 | 기준 1.25 (156.2 MB/s) / 최대 10 |
| db.r6g.large | 2 | 13.07 | 기준 0.75 / 최대 10 |
A. vCPU
가상 CPU의 수입니다.
B. 메모리(GiB)
DB 인스턴스에 할당되는 RAM입니다.
C. 최대 EBS 대역폭(Mbps)
초당 메가비트 단위의 최대 EBS 대역폭입니다. 이 값을 8로 나누면 초당 메가바이트 단위로 예상되는 처리량을 구할 수 있습니다. 이 수치는 DB 인스턴스 내 로컬 스토리지에 대한 I/O 대역폭을 나타냅니다.
Aurora 클러스터 볼륨과의 통신에는 적용되지 않습니다.
D. 네트워크 대역폭
인스턴스 대역폭 사양은 인스턴스의 인바운드 트래픽과 아웃바운드 트래픽에 모두 적용됩니다.
예를 들어 인스턴스가 최대 10Gbps의 대역폭을 지정하는 경우 인바운드 트래픽에 대해 최대 10Gbps의 대역폭 및 이와 동시에 아웃바운드 트래픽에 대해 최대 10Gbps의 대역폭이 있음을 의미합니다
버스트 가능 네트워크 성능을 발휘하는 인스턴스 유형은 네트워크 I/O 크레딧 메커니즘을 사용하여 최선의 노력을 기준으로 기준 대역폭을 초과하여 버스트할 수 있습니다.
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html
운영시 고려해야 할 부분
Aurora와 ElastiCache는 네트워크 대역폭에 대하여 주의할 부분이 있습니다.
- 4xlarge 이하의 인스턴스는 기준 대역폭과 최대 대역폭으로 나누어져 있습니다. 여기서 기준 대역폭은 평상시 사용할 수 있는 대역폭이며 최대 대역폭은 기준 대역폭 이하를 사용할 때 크레딧을 보관해두고 높은 처리량이 왔을 때 해당 크레딧을 소모하여 기준 대역폭 이상의 값을 사용할 수 있는 대역폭입니다. 최대 대역폭은 인스턴스 스펙에 따라 5~60분간 유지가 되나 이를 모니터링할 수 있는 방안은 없으므로 기준 대역폭 내의 사용량으로 운영이 필요합니다.
- Aurora는 클라이언트 대역폭으로 볼 수 있는 NetworkThroughput, 스토리지 대역폭으로 볼 수 있는 StorageNetworkThroughput 으로 나누어져 있습니다. 각 대역폭은 모두 네트워크 대역폭을 사용하여 함께 모니터링이 필요합니다.
- 일반적으로 인스턴스 기반의 Database는 네트워크 대역폭을 IN과 OUT으로 나누어져 관리됩니다. 다만 Aurora는 IN과 OUT을 합친 대역폭으로 관리합니다.
- ElastiCache의 CloudWatch의 대역폭은 분 단위 지표이며 처리량으로 나오기 때문에 다음의 계산이 필요합니다.
Aurora의 경우 네트워크 관련 지표는 초당 바이트입니다.
예) 그래프가 2.5GB 로 확인되고 기준 대역폭이 1.25Gbps인 겨우 네트워크 사용량 : 5GB * 1024 / 60 → 85MB/S
기준 대역폭 : 1.25Gbps → 약 156.25MB/S → 대역폭 내의 사용량 (AWS/ElastiCache 네임스페이스에는 다음과 같이 개별 캐시 노드에 대한 호스트 수준 지표가 포함되어 있습니다. 이러한 지표는 60초 간격으로 각 캐시 노드에 대해 측정되어 게시됩니다.) - Aurora의 경우 Enhanced Monitoring의 수집 주기를 조절하여 좀 더 세분화된 네트워크 트래픽을 확인할 수 있습니다. [Enhanced Monitoring] : Disk I/O-Write Throughput + Disk I/O-Read Throughput + Network-Rx + Network-Tx [Performance Insight] : Network-Rx +Network-Tx + diskIO-auroraStorageBytesRx + diskIO-auroraStorageBytesTx 위 합계를 8로 곱하면 Mbps로 환산이 되고, 이를 1000으로 나누면 Gbps로 확인 가능.
지연이 발생한 케이스
1. PostgreSQL에서 VACUUM 이 동작하는 경우


VACUUM 동작시 많은 양의 스토리지 네트워크 대역폭을 사용합니다. 이로 인하여 클라이언트와의 네트워크에서 지연이 발생하였습니다. 이를 개선하기 위해 VACUUM 관련 COST LIMIT과 DELAY 지표를 조정하여 단일 VACUUM 동작당 처리하는 양을 조절하였고 스토리지 네트워크 사용량 지표가 낮아지는 것을 황긴하였습니다.
2. 네트워크 대역폭이 초과하였으나 확인이 어려운 경우
오로라의 네트워크는 EC2에의 오로라 프로세스에서 처리된 네트워크에 대해서만 확인이되고 EC2와 스토리지, 클라이언트 사이의 네트워크는 정확하게 확인이 어렵다. 즉 스토리지에서 인스턴스에 대량의 데이터가 올라올 때 EC2에서는 이를 다 수용하지 못하고 일부 프로세스에서만 처리하는 경우 지표에서는 낮은 수준으로 확인이 될 수 있다.
3. ElastiCache에서 큰 사이즈의 지속적으로 데이터를 조회하는 경우
NetworkBandwidthOutAllowanceExceeded
엘라스틱캐시에는 NetworkBandwidth 같은 지표가 존재하여 네트워크가 대역폭을 초과하였는지를 좀 더 자세하게 모니터링이 가능하다.

'공부 > DATABASE' 카테고리의 다른 글
| [Aurora PostgreSQL] 성능 개선 도우미(PI), pg_stat_statements 지표 (0) | 2025.10.08 |
|---|---|
| [Aurora PostgreSQL] 입력 지연 장애 복기 (0) | 2025.10.08 |
| [Aurora PostgreSQL] Toast 테이블과 VACUUM (0) | 2025.10.08 |
| [ElastiCache] 실시간 알람을 위한 PUB/SUB (0) | 2025.10.08 |
| [Aurora PostgreSQL] 파티션 테이블 전환 (0) | 2025.10.08 |