AWS Service Quotas로 리소스 한도 확인 및 증가 완벽 가이드

AWS 클라우드에서 각 서비스의 리소스 한도를 확인하고 필요할 때 증가 요청하는 방법을 알아봅니다. 프로덕션 환경에서 갑자기 리소스 생성이 막히는 상황을 예방하는 핵심 지식입니다.

---

목차

1. Service_Quotas의_개념
2. 주요_서비스_한도_확인
3. 한도_증가_요청_프로세스
4. CloudWatch로_한도_임박_알림_설정
5. 계정별_vs_리전별_할당량
6. 프로덕션_출시_전_한도_계획

---

1. Service Quotas의 개념

김개발 씨가 급하게 신규 서버를 10대 더 띄워야 하는 상황이 발생했습니다. EC2 인스턴스 생성 버튼을 눌렀는데, 갑자기 "You have requested more instances than your current instance limit allows" 에러가 떴습니다.

대체 무슨 일이 벌어진 걸까요?

Service Quotas는 AWS에서 각 계정이 사용할 수 있는 리소스의 최대 개수를 관리하는 서비스입니다. 마치 아파트 주차장에 세대당 2대까지만 주차할 수 있다는 규정이 있는 것처럼, AWS도 각 서비스마다 사용 한도를 정해놓고 있습니다.

이 한도를 미리 파악하고 관리하면 갑작스러운 서비스 장애를 예방할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# Service Quotas 클라이언트 생성
client = boto3.client('service-quotas', region_name='ap-northeast-2')

# EC2 서비스의 모든 할당량 조회
response = client.list_service_quotas(
    ServiceCode='ec2'
)

# 각 할당량 정보 출력
for quota in response['Quotas']:
    print(f"할당량 이름: {quota['QuotaName']}")
    print(f"현재 한도: {quota['Value']}")
    print(f"조정 가능 여부: {quota['Adjustable']}")
    print("-" * 50)

김개발 씨는 스타트업에서 일하는 3년 차 백엔드 개발자입니다. 어느 날 마케팅팀에서 긴급 요청이 들어왔습니다.

"내일 대형 프로모션이 있어서 서버를 10대 더 늘려야 해요!" 김개발 씨는 자신만만하게 AWS 콘솔에 접속했습니다. 평소처럼 EC2 인스턴스를 생성하려고 했는데, 갑자기 빨간 에러 메시지가 나타났습니다.

인스턴스 한도를 초과했다는 것이었습니다. 옆자리의 박시니어 씨가 상황을 보더니 말했습니다.

"아, Service Quotas 확인 안 했구나? AWS는 무한정 리소스를 쓸 수 있는 게 아니야." 그렇다면 Service Quotas란 정확히 무엇일까요?

쉽게 비유하자면, Service Quotas는 마치 휴대폰 요금제와 같습니다. 기본 요금제에서는 데이터를 월 10GB까지만 쓸 수 있는 것처럼, AWS도 각 서비스마다 기본 사용량 한도가 정해져 있습니다.

더 필요하면 요금제를 변경하듯이, AWS에서도 한도 증가를 요청해야 합니다. AWS가 이런 한도를 두는 이유는 무엇일까요?

첫째, 시스템 안정성 보호입니다. 한 계정이 갑자기 수천 대의 서버를 띄우면 다른 사용자에게 영향을 줄 수 있습니다.

둘째, 비용 보호입니다. 실수로 과도한 리소스를 생성하는 것을 막아줍니다.

셋째, 보안입니다. 해킹당한 계정이 무한정 리소스를 사용하는 것을 방지합니다.

위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리로 service-quotas 클라이언트를 생성합니다.

서울 리전(ap-northeast-2)을 지정했습니다. 그 다음 list_service_quotas 함수로 EC2 서비스의 모든 할당량을 조회합니다.

반환된 결과에서 QuotaName은 할당량의 이름, Value는 현재 허용된 한도, Adjustable은 이 한도를 증가 요청할 수 있는지 여부를 나타냅니다. 실제로 많은 기업들이 이 Service Quotas를 모니터링 대시보드에 포함시켜 운영합니다.

한도에 가까워지면 미리 알림을 받아 사전에 대응하는 것이 베스트 프랙티스입니다. 김개발 씨는 박시니어 씨의 설명을 듣고 나서야 상황을 이해했습니다.

"아, 그래서 미리 한도를 확인하고 필요하면 증가 요청을 해야 하는 거군요!"

실전 팁

💡 - Service Quotas 콘솔에서 모든 서비스의 한도를 한눈에 확인할 수 있습니다

• 프로젝트 시작 시 주요 서비스의 기본 한도를 반드시 확인하세요

---

2. 주요 서비스 한도 확인

김개발 씨가 Service Quotas의 개념을 이해한 후, 박시니어 씨에게 물었습니다. "그럼 어떤 서비스들의 한도를 주로 확인해야 하나요?" 박시니어 씨는 노트북을 열며 말했습니다.

"EC2, VPC, ELB 이 세 가지는 반드시 체크해야 해."

AWS의 핵심 인프라 서비스들은 각각 중요한 할당량을 가지고 있습니다. EC2는 인스턴스 개수와 vCPU 수, VPC는 VPC 개수와 서브넷 수, ELB는 로드밸런서 개수 등이 대표적입니다.

이러한 한도는 서비스 운영 중 갑자기 막히면 치명적이므로 미리 파악해두어야 합니다.

다음 코드를 살펴봅시다.

import boto3

client = boto3.client('service-quotas', region_name='ap-northeast-2')

# 주요 서비스별 핵심 할당량 확인
services = {
    'ec2': 'Running On-Demand Standard instances',
    'vpc': 'VPCs per Region',
    'elasticloadbalancing': 'Application Load Balancers per Region'
}

for service_code, quota_name in services.items():
    response = client.list_service_quotas(ServiceCode=service_code)
    for quota in response['Quotas']:
        if quota_name in quota['QuotaName']:
            print(f"[{service_code.upper()}] {quota['QuotaName']}")
            print(f"  현재 한도: {int(quota['Value'])}")
            print(f"  적용 사용량: {quota.get('UsageMetric', '측정 불가')}")

박시니어 씨가 화면을 보여주며 설명을 시작했습니다. "우리 회사에서 가장 자주 한도에 걸리는 서비스가 뭔지 알아?" 김개발 씨는 고개를 갸웃거렸습니다.

"글쎄요, EC2 아닐까요?" "맞아. 그런데 단순히 인스턴스 개수가 아니라 vCPU 수로 제한되는 거야." EC2의 경우, 예전에는 인스턴스 개수로 한도가 정해졌습니다.

하지만 지금은 vCPU 기반 한도로 바뀌었습니다. 예를 들어 On-Demand Standard 인스턴스의 기본 한도가 vCPU 32개라면, 4 vCPU 인스턴스는 8대까지만 띄울 수 있는 것입니다.

VPC는 또 다른 함정이 숨어 있습니다. "VPC는 리전당 기본 5개야.

많아 보이지?" 박시니어 씨가 물었습니다. 김개발 씨는 고개를 끄덕였습니다.

"근데 개발, 스테이징, 프로덕션 환경 분리하고, 파트너사 연동용 VPC 만들다 보면 금방 차." VPC 안에서도 서브넷, 인터넷 게이트웨이, NAT 게이트웨이 등 세부 리소스마다 각각의 한도가 있습니다. 서브넷은 VPC당 200개, 라우팅 테이블은 VPC당 200개가 기본값입니다.

ELB(Elastic Load Balancing)도 놓치기 쉬운 부분입니다. "Application Load Balancer는 리전당 기본 50개야.

마이크로서비스 아키텍처로 가면 서비스마다 ALB 하나씩 붙이잖아. 금방 차더라고." 위 코드에서는 boto3를 사용해 세 가지 핵심 서비스의 대표 할당량을 조회합니다.

list_service_quotas 함수로 해당 서비스의 모든 할당량을 가져온 뒤, 필요한 항목만 필터링하여 출력합니다. 실무에서는 이런 정보를 자동으로 수집해서 Slack이나 이메일로 주간 리포트를 보내는 경우가 많습니다.

한도의 80%에 도달하면 미리 알림을 받아 대응할 수 있도록 설정하는 것이 좋습니다. "아, 그래서 신규 프로젝트 시작할 때마다 인프라팀에서 한도 체크 요청을 하는 거였군요." 김개발 씨가 이해한 표정을 지었습니다.

실전 팁

💡 - EC2 vCPU 한도는 인스턴스 패밀리(Standard, Compute, Memory 등)별로 따로 적용됩니다

• AWS 콘솔의 Service Quotas 대시보드에서 사용량 대비 한도를 시각적으로 확인할 수 있습니다

---

3. 한도 증가 요청 프로세스

김개발 씨가 현재 EC2 한도를 확인해보니 vCPU 32개가 한도였고, 이미 28개를 사용 중이었습니다. 내일 프로모션을 위해 서버 10대가 더 필요한 상황.

박시니어 씨가 말했습니다. "지금 바로 한도 증가 요청 넣어야 해.

방법 알려줄게."

한도 증가 요청은 Service Quotas 콘솔이나 API를 통해 진행할 수 있습니다. 대부분의 요청은 자동으로 승인되지만, 큰 폭의 증가는 AWS 지원팀의 검토가 필요합니다.

요청 후 승인까지 몇 분에서 며칠이 걸릴 수 있으므로 여유를 두고 신청해야 합니다.

다음 코드를 살펴봅시다.

import boto3

client = boto3.client('service-quotas', region_name='ap-northeast-2')

# 한도 증가 요청 생성
response = client.request_service_quota_increase(
    ServiceCode='ec2',
    QuotaCode='L-1216C47A',  # Running On-Demand Standard instances
    DesiredValue=64.0  # 원하는 새 한도값
)

# 요청 결과 확인
request_id = response['RequestedQuota']['Id']
status = response['RequestedQuota']['Status']
print(f"요청 ID: {request_id}")
print(f"상태: {status}")

# 요청 이력 조회
history = client.list_requested_service_quota_change_history(
    ServiceCode='ec2'
)
for req in history['RequestedQuotas']:
    print(f"요청일: {req['Created']}, 상태: {req['Status']}")

박시니어 씨가 AWS 콘솔을 열며 말했습니다. "한도 증가 요청은 두 가지 방법이 있어.

콘솔에서 클릭 몇 번으로 하거나, API로 자동화하거나." 콘솔 방법은 간단합니다. Service Quotas 서비스로 들어가서 원하는 서비스를 선택하고, 증가하고 싶은 할당량 옆의 "Request quota increase" 버튼을 클릭하면 됩니다.

하지만 박시니어 씨는 코드로 하는 방법을 권했습니다. "인프라를 코드로 관리하는 IaC(Infrastructure as Code) 시대잖아.

한도 요청도 코드로 남겨두면 이력 관리가 편해." 위 코드에서 핵심은 request_service_quota_increase 함수입니다. 이 함수를 호출할 때 세 가지 정보가 필요합니다.

첫째, ServiceCode는 서비스 식별자입니다. EC2는 'ec2', VPC는 'vpc'입니다.

둘째, QuotaCode는 각 할당량의 고유 코드입니다. 이 코드는 콘솔에서 확인하거나 list_service_quotas API로 조회할 수 있습니다.

셋째, DesiredValue는 원하는 새 한도값입니다. "근데 시니어님, 요청하면 바로 되나요?" 김개발 씨가 조급하게 물었습니다.

박시니어 씨가 고개를 저었습니다. "상황에 따라 달라.

소폭 증가는 보통 자동 승인돼서 몇 분이면 끝나. 근데 큰 폭으로 늘리면 AWS 팀이 직접 검토해서 며칠 걸릴 수도 있어." 요청 상태는 다음과 같은 값을 가집니다.

PENDING은 검토 대기 중, CASE_OPENED는 AWS 지원 티켓이 생성됨, APPROVED는 승인됨, DENIED는 거절됨을 의미합니다. 실무에서 중요한 팁이 있습니다.

거절당했을 때 당황하지 마세요. AWS Support Center에서 해당 케이스를 열어 추가 설명을 제공하면 재검토받을 수 있습니다.

"왜 이 한도가 필요한지, 어떤 비즈니스 요구사항이 있는지" 구체적으로 설명하면 승인 확률이 높아집니다. "다음부터는 미리미리 요청해놔야겠네요." 김개발 씨가 한숨을 쉬었습니다.

실전 팁

💡 - 대규모 이벤트 2-3주 전에 미리 한도 증가를 요청하세요

• AWS Support 플랜이 높을수록(Business, Enterprise) 처리 속도가 빠릅니다

---

4. CloudWatch로 한도 임박 알림 설정

한도 증가 요청을 마친 김개발 씨에게 박시니어 씨가 물었습니다. "근데 매번 이렇게 급하게 대응할 거야?

한도에 가까워지면 미리 알림 받는 게 낫지 않아?" 김개발 씨의 눈이 반짝였습니다. "그게 가능해요?"

CloudWatch와 Service Quotas를 연동하면 리소스 사용량이 한도에 가까워질 때 자동으로 알림을 받을 수 있습니다. 사용량이 80%에 도달하면 이메일이나 Slack으로 알림을 보내도록 설정하면, 긴급 상황 없이 여유 있게 대응할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2')
sns = boto3.client('sns', region_name='ap-northeast-2')

# SNS 토픽 생성 (알림 수신용)
topic = sns.create_topic(Name='quota-alerts')
topic_arn = topic['TopicArn']

# CloudWatch 알람 생성 - 한도 80% 도달 시 알림
cloudwatch.put_metric_alarm(
    AlarmName='EC2-vCPU-Quota-Warning',
    MetricName='ResourceCount',
    Namespace='AWS/Usage',
    Dimensions=[
        {'Name': 'Service', 'Value': 'EC2'},
        {'Name': 'Resource', 'Value': 'vCPU'},
        {'Name': 'Type', 'Value': 'Resource'},
        {'Name': 'Class', 'Value': 'Standard/OnDemand'}
    ],
    Statistic='Maximum',
    Period=300,
    EvaluationPeriods=1,
    Threshold=80,  # 퍼센트 기준
    ComparisonOperator='GreaterThanThreshold',
    AlarmActions=[topic_arn]
)

박시니어 씨가 화면을 공유하며 설명을 시작했습니다. "CloudWatch와 Service Quotas를 연동하면 사용량 기반 알람을 만들 수 있어." 어떻게 동작하는지 살펴봅시다.

Service Quotas는 일부 서비스에 대해 AWS/Usage 네임스페이스로 사용량 지표를 CloudWatch에 자동으로 보냅니다. 이 지표를 활용해서 알람을 설정하는 것입니다.

"모든 할당량이 다 지원되나요?" 김개발 씨가 물었습니다. "아니, 일부만 지원돼.

Service Quotas 콘솔에서 각 할당량 옆에 CloudWatch 아이콘이 있는 것만 사용량 모니터링이 가능해." 위 코드를 단계별로 살펴보겠습니다. 먼저 SNS 토픽을 생성합니다.

이 토픽은 알람이 발생했을 때 알림을 보내는 채널 역할을 합니다. 이 토픽에 이메일을 구독시키면 이메일로, Lambda를 연결하면 Slack으로 알림을 보낼 수 있습니다.

다음으로 put_metric_alarm 함수로 CloudWatch 알람을 생성합니다. Dimensions가 중요한데, 여기서 어떤 서비스의 어떤 리소스를 모니터링할지 지정합니다.

Threshold를 80으로 설정했는데, 이는 사용량이 한도의 80%를 넘으면 알람이 발생한다는 의미입니다. Period는 300초(5분)마다 체크한다는 뜻입니다.

실무에서는 여러 단계의 알람을 설정하는 것이 좋습니다. "우리 팀은 70%에서 주의 알림, 85%에서 경고 알림, 95%에서 긴급 알림을 보내도록 설정해놨어." 박시니어 씨가 설명했습니다.

"70%면 여유 있게 한도 증가 요청하고, 95%면 당장 대응해야 하니까." Slack으로 알림을 보내고 싶다면 SNS와 AWS Chatbot을 연동하거나, Lambda 함수를 만들어서 Slack Webhook으로 메시지를 보내면 됩니다. "이거 한번 세팅해놓으면 마음이 편하겠네요." 김개발 씨가 감탄했습니다.

실전 팁

💡 - 알람 임계값은 70%, 85%, 95% 세 단계로 설정하면 단계별 대응이 가능합니다

• AWS Chatbot을 사용하면 SNS 알림을 Slack 채널로 쉽게 연동할 수 있습니다

---

5. 계정별 vs 리전별 할당량

김개발 씨가 서울 리전에서 한도 증가를 받고 안심하던 중, 미국 동부 리전에서 배포하려다 또 한도에 걸렸습니다. "어?

분명 증가시켰는데요?" 박시니어 씨가 웃으며 말했습니다. "한도에는 두 종류가 있어.

계정 단위와 리전 단위."

AWS 할당량은 크게 **계정별(Account-level)**과 **리전별(Region-level)**로 나뉩니다. 계정별 할당량은 전체 AWS 계정에 적용되고, 리전별 할당량은 각 리전마다 따로 적용됩니다.

이 차이를 이해하지 못하면 멀티 리전 운영 시 예상치 못한 한도 초과에 직면할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

regions = ['ap-northeast-2', 'us-east-1', 'eu-west-1']

for region in regions:
    client = boto3.client('service-quotas', region_name=region)

    # 리전별 EC2 vCPU 한도 확인
    response = client.get_service_quota(
        ServiceCode='ec2',
        QuotaCode='L-1216C47A'
    )
    print(f"[{region}] On-Demand vCPU 한도: {int(response['Quota']['Value'])}")

# 글로벌 서비스(IAM) 할당량은 us-east-1에서 조회
iam_client = boto3.client('service-quotas', region_name='us-east-1')
iam_quota = iam_client.get_service_quota(
    ServiceCode='iam',
    QuotaCode='L-F55AF5E4'  # IAM users per account
)
print(f"[Global] IAM 사용자 한도: {int(iam_quota['Quota']['Value'])}")

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "AWS 할당량은 두 가지 범위가 있어." 첫 번째는 리전별(Region-level) 할당량입니다.

대부분의 서비스 할당량이 여기에 해당합니다. EC2 인스턴스 수, VPC 개수, RDS 인스턴스 수 등이 대표적입니다.

서울 리전에서 한도를 늘려도 도쿄 리전에는 영향이 없습니다. 각 리전마다 별도로 한도 증가를 요청해야 합니다.

"그래서 글로벌 서비스 런칭할 때 각 리전마다 한도 체크하고 증가 요청하느라 정신없었구나." 김개발 씨가 이해했습니다. 두 번째는 계정별(Account-level) 할당량입니다.

IAM이 대표적인 예입니다. IAM 사용자, 역할, 정책 등은 전체 계정에서 공유됩니다.

IAM 사용자 한도가 1000명이면, 모든 리전을 통틀어 1000명까지만 생성할 수 있습니다. Route 53, CloudFront, S3 같은 글로벌 서비스도 마찬가지입니다.

이런 서비스의 할당량은 us-east-1 리전에서 관리됩니다. 위 코드를 보면, 리전별 할당량은 각 리전의 클라이언트를 만들어서 따로 조회합니다.

반면 IAM 같은 글로벌 서비스는 us-east-1 리전에서 조회해야 올바른 값을 얻을 수 있습니다. 실무에서 흔히 겪는 실수가 있습니다.

"DR(재해복구) 사이트를 다른 리전에 구축했는데, 정작 재해 발생 시 한도 때문에 서버를 못 띄우는 경우가 있어." 박시니어 씨가 경고했습니다. "DR 리전도 미리 동일한 한도로 증가시켜놔야 해." 멀티 리전 아키텍처를 운영한다면, 모든 활성 리전의 할당량을 동일하게 맞춰두는 것이 안전합니다.

자동화 스크립트로 주기적으로 리전 간 할당량을 비교하는 것도 좋은 방법입니다.

실전 팁

💡 - 글로벌 서비스(IAM, Route 53, CloudFront)의 할당량은 us-east-1에서 확인하세요

• DR 리전의 할당량도 프로덕션 리전과 동일하게 유지하세요

---

6. 프로덕션 출시 전 한도 계획

프로모션을 무사히 마친 김개발 씨에게 다음 미션이 주어졌습니다. 신규 서비스 런칭 프로젝트의 인프라 담당이 된 것입니다.

박시니어 씨가 조언했습니다. "이번엔 미리미리 한도 계획을 세워.

런칭 당일에 한도 때문에 고생하면 안 되니까."

프로덕션 출시 전에는 예상 트래픽과 리소스 사용량을 기반으로 **한도 계획(Capacity Planning)**을 수립해야 합니다. 최대 부하 상황을 가정하고, 필요한 리소스 수량을 산정한 뒤, 현재 한도와 비교하여 부족한 부분을 미리 증가 요청해야 합니다.

이 과정은 런칭 최소 2-3주 전에 완료하는 것이 안전합니다.

다음 코드를 살펴봅시다.

import boto3
import json

def generate_quota_plan(service_requirements):
    """프로덕션 런칭을 위한 한도 계획 생성"""
    client = boto3.client('service-quotas', region_name='ap-northeast-2')
    plan = []

    for service, requirements in service_requirements.items():
        quotas = client.list_service_quotas(ServiceCode=service)
        for quota in quotas['Quotas']:
            quota_name = quota['QuotaName']
            current_limit = quota['Value']
            required = requirements.get(quota_name, 0)

            if required > current_limit * 0.7:  # 70% 이상 사용 예상시
                plan.append({
                    'service': service,
                    'quota_name': quota_name,
                    'current_limit': current_limit,
                    'required': required,
                    'recommended_limit': required * 1.5,
                    'action': 'INCREASE_NEEDED'
                })
    return plan

# 예상 리소스 요구사항 정의
requirements = {
    'ec2': {'Running On-Demand Standard instances': 100},
    'vpc': {'VPCs per Region': 8},
    'elasticloadbalancing': {'Application Load Balancers per Region': 30}
}

quota_plan = generate_quota_plan(requirements)
print(json.dumps(quota_plan, indent=2, ensure_ascii=False))

박시니어 씨가 프로젝트 킥오프 미팅에서 강조했습니다. "한도 계획은 인프라 설계의 핵심이야.

런칭 전에 반드시 체크리스트를 만들어서 확인해야 해." 김개발 씨는 체크리스트를 정리하기 시작했습니다. 첫 번째 단계는 예상 트래픽 산정입니다.

마케팅팀, 비즈니스팀과 협의하여 런칭 후 예상되는 최대 동시 사용자 수, 일일 요청 수 등을 파악합니다. 이 숫자는 보수적으로 잡는 것이 좋습니다.

예상보다 흥행하면 좋은 문제이지만, 한도 때문에 서비스가 멈추면 큰일이니까요. 두 번째 단계는 리소스 요구량 계산입니다.

예상 트래픽을 기반으로 필요한 EC2 인스턴스 수, RDS 크기, ELB 수 등을 산정합니다. 오토스케일링을 사용한다면 최대 스케일아웃 상황을 기준으로 계산해야 합니다.

세 번째 단계는 현재 한도와 비교입니다. 위 코드처럼 각 서비스의 현재 한도를 조회하고, 필요량과 비교합니다.

필요량이 현재 한도의 70% 이상이면 증가를 고려해야 합니다. "왜 70%가 기준이에요?" 김개발 씨가 물었습니다.

"버퍼가 필요하기 때문이야." 박시니어 씨가 설명했습니다. "갑자기 트래픽이 폭증할 수도 있고, 장애 대응으로 긴급히 서버를 늘려야 할 수도 있잖아.

최소 30%의 여유는 두는 게 좋아." 네 번째 단계는 한도 증가 요청입니다. 필요한 한도를 예상 사용량의 1.5배 이상으로 요청합니다.

런칭 후 성장을 고려해서 넉넉하게 잡는 것이 좋습니다. 요청은 런칭 최소 2-3주 전에 완료해야 합니다.

다섯 번째 단계는 문서화입니다. 어떤 한도를 왜 증가시켰는지 기록해둡니다.

다음 프로젝트에서 참고할 수 있고, 비용 검토 시에도 근거가 됩니다. 김개발 씨가 정리했습니다.

"정리하면, 예상 트래픽 파악 -> 리소스 계산 -> 한도 비교 -> 증가 요청 -> 문서화. 이 순서네요." 박시니어 씨가 고개를 끄덕였습니다.

"그리고 런칭 후에도 모니터링은 계속해야 해. 성장하면서 한도도 같이 늘려나가야 하니까."

실전 팁

💡 - 예상 리소스 사용량의 최소 1.5배, 가능하면 2배 한도를 확보하세요

• 한도 증가 요청 내역과 사유를 문서화해두면 추후 비용 검토에 유용합니다
• 런칭 후 첫 주는 CloudWatch 대시보드를 집중 모니터링하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!