🔥 Synthetics, 엔드포인트 가용성 모니터링
강의 목차
외부 모니터링 대시보드에는 99.99%가 찍혀 있었다. 그런데 같은 시각, 우리 사용자는 로그인 버튼을 눌러도 다음 화면으로 못 넘어가고 있었다. 두 사실이 동시에 참이라는 게 처음 봤을 때는 이상하게 들렸는데, 그날 새벽에 천천히 풀어 보니 이상한 일이 아니었다. 외부 도구가 우리 서비스를 보고 있던 곳과, 사용자가 우리 서비스를 만나고 있던 곳이 서로 다른 지점이었기 때문이다.
이 한 가지 차이가 CloudWatch Synthetics가 존재하는 이유다. 지난 편까지 본 CloudWatch의 네 축(Metric / Log / Alarm / Event) 위에 합성 트래픽을 한 줄 더 얹어, AWS 인프라 안쪽에서 우리 엔드포인트로 진짜 사용자처럼 요청을 보내는 도구가 Synthetics다. 그래서 외부 ping이 못 보는 곳, 내부 의존 서비스가 느려졌거나, Cognito 토큰 발급이 막혔거나, 결제 API 응답이 30초 넘게 걸리는, 까지 같이 잡는다.
대신 청구서가 한 줄이 아니라 여섯 줄로 나뉜다. 이 글은 어떻게 동작하는지보다 내가 카나리 한 줄을 켤 때 무엇을 같이 켜게 되는지를 더 자세히 본다. Synthetics 한 줄을 켜는 일은 거의 항상 Lambda, S3, CloudWatch Logs, IAM 역할, custom metrics, 그리고 (선택) VPC ENI를 같이 켜는 일이라, 그 다섯 동반자의 가격·권한·동작을 함께 짚어 두는 편이 운영에서 덜 새는 길이다.
외부에서 본 우리, 안쪽에서 본 우리, 두 시점이 다른 답을 낼 때
UptimeRobot이나 Pingdom 같은 외부 모니터링 도구는 인터넷 곳곳의 위치에서 우리 서비스의 공개 엔드포인트를 정한 주기로 한 번씩 호출한다. 받는 응답이 200이면 OK, 4xx/5xx면 ALARM. 단순하고 빠르고 싸다. 인터넷 자체가 끊어졌거나 DNS가 깨졌거나 ALB가 죽은 상황은 외부 도구가 가장 먼저 잡는다. 이 카테고리가 전체 장애의 가장 큰 비중이라 외부 ping을 완전히 끄는 운영은 드물다.
그런데 외부에서 보는 우리 서비스는 공개 표면만 드러난다. 사용자의 실제 여정, 로그인 → 메인 → 장바구니 → 결제 → 영수증, 가운데 어떤 한 단계가 깨져 있어도 맨 앞 페이지 GET이 200을 잘 돌려보내면 외부 도구는 100%로 뜬다. 내가 처음 이 갭에 부딪힌 건 Cognito 토큰 발급이 5초 넘게 걸리던 새벽이었다. 외부 도구는 정상이었고, 사용자는 로그인 직후 무한 로딩 화면에 머물러 있었다. 두 사실 모두 그 시점에는 참이었다.
Synthetics는 시점을 안쪽으로 가져간다. 카나리(Canary)라고 부르는 작은 스크립트를 AWS 인프라 안쪽에 두고, 그 스크립트가 직접 헤드리스 브라우저를 띄워 우리 엔드포인트를 호출한다. 단순 GET이 아니라 우리가 짠 시나리오를 그대로 돈다. 예를 들어 로그인 폼에 테스트 계정 이메일을 넣고, 비밀번호를 넣고, 로그인 버튼을 누르고, 다음 페이지의 특정 텍스트가 보이는지를 확인한다. 한 단계라도 실패하면 그 단계의 스크린샷·HAR·로그가 S3에 저장되고, Failed 메트릭이 1로 올라간다.
같은 서비스, 같은 사용자 여정인데 외부 도구는 바깥에서 한 점을 찍고, Synthetics는 안쪽에서 시나리오를 돈다. 두 도구가 서로 다른 답을 낼 때가 종종 있고, 그 차이가 사용자가 직접 부딪히는 곳이다. 그래서 운영에서는 외부 ping과 Synthetics를 둘 다 켜 두는 게 가장 흔한 구조다. 외부 도구는 인터넷·DNS·ALB 죽음을 빨리 잡고, Synthetics는 안쪽 의존성·인증·UI 회귀를 잡는다.
Canary 한 줄의 형태, Lambda 함수 + 스케줄 + Blueprint 일곱 가지
콘솔에서 'Create canary' 버튼을 누르면 그 뒤에서 만들어지는 자원이 정확히 세 개다. 첫째, 우리 모니터링 스크립트를 담은 Lambda 함수 한 개. 둘째, 그 함수의 실행 스케줄(rate() 또는 cron() expression). 셋째, 함수가 S3·CloudWatch Logs·CloudWatch Metrics·(옵션) VPC ENI에 접근할 수 있게 해 주는 IAM 역할 한 개. 카나리는 사실상 스케줄 + Lambda + IAM 역할의 묶음 이름이라고 보면 가장 가깝다.
스케줄은 rate() 표현식 기준 최소 1분, 최대 1시간이 한도다. 그보다 긴 주기가 필요하면, 한 번/하루, 한 번/주, 매주 화요일 새벽 3시 같은, cron() 표현식으로 잡는다. 1분보다 더 자주는 못 돈다는 한 줄짜리 한도가 있어서, 진짜 초 단위 가용성이 필요한 워크로드(증권 거래소 매매 게이트웨이 같은)는 Synthetics가 잘 맞지 않는다. 그쪽은 외부 합성 모니터링과 자체 health-check를 같이 돌리는 편이다.
스크립트 자체는 처음부터 다 짜는 경우가 드물다. AWS가 흔한 시나리오를 Blueprint라는 템플릿으로 미리 마련해 두어서, 콘솔에서 하나를 골라 URL이나 API 엔드포인트만 채우면 동작하는 카나리가 생긴다. Blueprint는 일곱 가지다.
- Heartbeat monitor, 가장 기본 형태. URL 한 개를 로딩하고 HTTP archive(HAR), 로그, 페이지 스크린샷을 S3에 저장한다. 엔드포인트가 살아 있는지, 페이지 로딩 시간이 얼마나 걸리는지를 보는 가장 단순한 길이다.
- API canary, REST API 엔드포인트를 호출하는 카나리. 한 카나리 안에서 여러 호출을 순서대로 보내고, 응답 헤더와 본문에 특정 문자열이 있는지 확인한다. 예를 들어 로그인 API → 토큰 → 토큰으로 다음 API 호출 같은 연계 시나리오가 자연스럽게 들어간다.
- Broken link checker, 한 페이지에서 출발해 그 페이지 안의 모든 링크를 따라가며 깨진 링크(404, 5xx, 타임아웃)를 모아 보고한다. 페이지를 다 갈아엎은 다음 외부 백링크가 살아 있는지 확인할 때 가장 자주 쓴다.
- Visual monitoring, Heartbeat과 비슷한데, 첫 성공 실행의 스크린샷을 기준선(baseline)으로 저장해 두고 다음 실행마다 화면을 비교한다. CSS가 어긋나서 UI가 틀어졌는데 기능은 정상인 회귀, 즉 화면만 깨진 회귀를 잡는 길이다.
- Canary recorder, Chrome 확장 위에서 사용자 행동(클릭, 입력, 스크롤)을 녹화하면 Synthetics가 그대로 Puppeteer 스크립트로 변환한다. 코드를 한 줄도 쓰지 않고 다단계 시나리오를 만드는 가장 빠른 길이다.
- GUI workflow builder, 콘솔 안에서 step(Click / Verify text / Wait 등)을 골라 클릭으로 워크플로를 짠다. recorder가 외부 녹화라면 builder는 콘솔 안 클릭이라 두 갈래로 다르다.
- Multi-check blueprint, 2025년 10월 22일 GA된 가장 새로운 한 가지. 한 카나리 안에 HTTP / DNS / TCP 포트 / SSL 인증서 만료일 같은 다른 종류의 점검을 최대 10단계까지 한 JSON으로 묶어 정의한다. 이전에는 점검 종류마다 카나리를 따로 만들어야 해서 카나리 개수가 곱하기로 자랐는데, 이걸 묶으면 카나리 개수와 청구서의 Canary 실행 라인이 같이 줄어든다.
런타임은 Node.js + Puppeteer / Node.js + Playwright / Python + Selenium / Java 네 갈래다. 가장 흔한 선택은 syn-nodejs-puppeteer-15.0 라인. Heartbeat이나 Visual 같은 브라우저 시나리오는 Puppeteer가 잘 맞고, 순수 REST API 검사는 가벼운 HTTP 클라이언트로 충분해서 Python/Selenium보다 Node.js + Puppeteer 쪽을 더 자주 고른다. 한 가지 작은 함정이 있는데, syn-nodejs-puppeteer-13.1 이후로 require 모듈 namespace가 바뀌었다는 점이다. 옛 sample을 그대로 옮기면 동작이 어긋난다.
// Heartbeat Blueprint가 만들어 주는 Puppeteer 스크립트의 한 부분
const synthetics = require('@aws/synthetics-puppeteer'); // ← v13.1 이전: 'Synthetics'
const log = require('@aws/synthetics-logger'); // ← v13.1 이전: 'SyntheticsLogger'
const pageLoad = async function () {
const url = 'https://www.codingmax.com/';
const page = await synthetics.getPage();
const response = await page.goto(url, {
waitUntil: 'domcontentloaded',
timeout: 30000,
});
if (response.status() < 200 || response.status() > 299) {
throw new Error(`Failed to load page: status ${response.status()}`);
}
await synthetics.takeScreenshot('loaded', 'page');
};
exports.handler = async () => {
return await pageLoad();
};// Heartbeat Blueprint가 만들어 주는 Puppeteer 스크립트의 한 부분
const synthetics = require('@aws/synthetics-puppeteer'); // ← v13.1 이전: 'Synthetics'
const log = require('@aws/synthetics-logger'); // ← v13.1 이전: 'SyntheticsLogger'
const pageLoad = async function () {
const url = 'https://www.codingmax.com/';
const page = await synthetics.getPage();
const response = await page.goto(url, {
waitUntil: 'domcontentloaded',
timeout: 30000,
});
if (response.status() < 200 || response.status() > 299) {
throw new Error(`Failed to load page: status ${response.status()}`);
}
await synthetics.takeScreenshot('loaded', 'page');
};
exports.handler = async () => {
return await pageLoad();
};스크립트가 throw 하면 그 실행은 실패로 기록되고, 던져진 에러 메시지·스크린샷·HAR이 S3에 함께 저장한다. 디버깅할 때는 콘솔의 카나리 상세 화면에서 그 자료를 그대로 본다. 이 자료가 자동으로 모이는 것이 외부 도구와 가장 크게 갈리는 차이고, 운영자가 새벽에 폰을 들고 일어나야 할 일이 줄어드는 단계다.
메트릭과 알람, 알람 편에서 본 그 형태 그대로
카나리가 한 번 실행될 때마다 세 가지 메트릭이 CloudWatchSynthetics namespace에 publish된다. SuccessPercent(성공한 실행의 비율), Duration(실행 시간 ms), Failed(실패한 실행 수). 이 세 가지만 알아도 알람을 거는 데는 충분하다.
가장 자주 거는 알람은 SuccessPercent다. 1분 주기 카나리가 5분 동안 5번 모두 성공했다면 100, 5번 중 1번이 실패하면 80. 90 미만이 5분 평가 윈도에서 잡히면 ALARM 상태로 바뀌도록 잡아 둔다. 이때 알람을 어떻게 거는지는 Alarm: 임계값을 걸고 알림을 받는 법에서 자세히 풀어 둔 곳이다. 임계값 비교 4종(Greater/Less/Equal), M-of-N 윈도(period × evaluation periods × datapoints to alarm), TreatMissingData 4모드(missing/notBreaching/breaching/ignore), 그리고 Composite Alarm까지, 모두 그 글에서 본 형태가라 여기서는 다시 풀지 않는다.
한 줄만 짚자면, Synthetics 메트릭은 기존 CloudWatch 알람과 한 결이라는 점이다. 새 알람 모델을 배울 일이 없다는 뜻이다. SNS Topic으로 알림을 보내는 단계도, Amazon Q Developer in chat applications(2025-02-26 AWS Chatbot 리브랜드, endpoint·IAM·API·Region 가용성은 그대로)로 Slack에 떨구는 단계도, EventBridge Rule로 Lambda 자동 복구를 트리거하는 단계도, 이미 깔린 인프라를 그대로 재사용한다.
이 재사용이 외부 도구와 갈리는 가장 큰 차이다. 가령 UptimeRobot이나 Pingdom을 쓰면 알림 라우팅과 자동 복구를 별도 시스템에서 다시 짜야 한다. 이쪽도 PagerDuty 통합이 있고 webhook도 잘 지원하지만, AWS 안의 다른 자원과 한 파이프라인으로 묶기에는 한 단계가 더 들어가게 된다. Synthetics는 그 한 단계가 없는 것이다. 운영 6개월쯤 누적되면 이 차이가 코드 200줄 + 추가 SaaS 한 개 + 운영 수첩 한 페이지 만큼의 차이로 자라곤 한다.
진짜 청구서, 1분 주기 카나리 하나에 청구되는 여섯 가지
여기까지가 카나리 한 줄을 켜는 기능 이야기다. 이제 같은 한 줄을 켜는 비용 이야기가 남는다. Synthetics는 '관리형 서비스가 감추는 비용'이라는 키스레드가 가장 또렷하게 드러나는 대목이다. 콘솔에서 한 번의 클릭으로 만들어진 자원이 청구서에서는 여섯 항목으로 나뉘는데, 그래서 카나리 비용을 단순히 '$0.0012/run'으로만 보고 있다가 월말에 깜짝 놀라는 일이 종종 있다.
운영팀이 가장 자주 켜는 시나리오, 우리 가장 비싼 엔드포인트 한 개를 1분 주기로 한 달 모니터링한다, 를 그대로 계산한다. 가격은 US East (N. Virginia) 기준 2026년 4월, 다른 region도 비슷한 비율이다.
먼저 기본 산수부터. 1분 주기로 한 달은 60회/시간 × 24시간 × 30일 = 43,200회. 이 숫자가 모든 비용 라인의 입력이 된다.
1. Canary 실행 비용, 매월 첫 100회는 무료, 이후 한 번에 $0.0012. 무료 100회를 빼면 청구 대상 43,100회 × $0.0012 = $51.72.
2. Lambda 실행 비용, 카나리는 Lambda 함수다. 한 실행이 평균 10초 걸리고 메모리 1024 MB(= 1 GB)를 쓴다고 가정하면, 요청 비용 43,200 × $0.20/M = $0.0086, 실행 시간 비용 43,200 × 10s × 1 GB × $0.0000166667/GB-s = $7.20. 합쳐 $7.21. (Lambda 프리 티어는 다른 워크로드에 이미 다 썼다고 가정하고 빼지 않았다.)
3. S3 저장 비용, 카나리는 매 실행마다 로그, HAR, 스크린샷을 S3 버킷에 적재한다. 한 실행 평균 1 MB 아티팩트라고 잡으면 한 달 누적 43,200 MB ≈ 43.2 GB. PUT 요청 비용 43,200 × $0.005/1,000 = $0.22, 저장 비용 43.2 GB × $0.023/GB(Standard) = $0.99. 합쳐 $1.21. 라이프사이클 정책 없이 1년을 쌓으면 이 항목이 GB 단위로 누적되니, 한 줄짜리 라이프사이클 룰(30일 이상 객체는 자동 삭제)을 같이 거는 것이 운영 표준이다.
4. CloudWatch Logs ingestion, Lambda가 stdout/stderr로 찍는 로그가 자동으로 CloudWatch Logs로 이동한다. 카나리 로그는 의외로 두꺼워서 한 실행 1 MB가 흔하다. 43.2 GB × $0.50/GB = $21.60. 청구서에서 가장 자주 깜짝 놀라는 곳이 이 항목인데, Lambda 실행 비용($7.21)보다 Logs ingestion이 3배 큰 게 정상이다.
5. CloudWatch Logs storage, 한 번 들어온 로그는 retention 정책 없이 두면 영구히 남는다. 43.2 GB × $0.03/GB = $1.30. retention을 7일이나 30일로 잡아 두지 않으면 매달 누적되어 1년 후엔 같은 카나리가 매달 $15+를 storage로만 쓰게 된다. retention_in_days = 7 한 줄을 처음에 같이 잡는 것이 운영에서 가장 자주 새지 않는 길이다.
6. CloudWatch custom metrics, 카나리는 SuccessPercent·Duration·Failed 세 가지 custom metric을 publish한다. 표준 해상도 메트릭 한 개당 $0.30/월(US East 기준)이라 3 × $0.30 = $0.90. 메트릭 자체는 작아 보이지만, 카나리가 100개로 늘면 이 항목만 $90/월로 자라기 때문에 카나리 fleet이 큰 운영에서는 Metric: 숫자 하나가 찍히는 과정에서 본 dimension 폭발과 같은 형식으로 가장 빨리 자라는 단계가 된다.
여섯 항목을 다 더하면 약 $83.94 ($51.72 + $7.21 + $1.21 + $21.60 + $1.30 + $0.90). Synthetics 라인($51.72)만 보고 있었다면 실제 청구서의 62%만 본 셈이고, 나머지 38%는 Lambda·S3·Logs·Metrics에 흩어져 있는 것이다. 그리고 위 계산에는 Logs Insights 쿼리 비용과 NAT Gateway 데이터 처리 비용을 일부러 뺐다. 둘 다 켜는 환경에 따라 다시 추가한다. (Logs Insights 비용 형태은 Logs Insights: 로그에 쿼리를 발행하는 법에서 자세히 풀었다.)
이 청구서 형태을 한 번 보고 나면 카나리 주기 결정이 다른 형태로 보이게 된다. 1분 주기를 5분 주기로 늦추기만 해도 청구 대상 실행 횟수가 1/5로 줄어 Canary·Lambda·Logs·S3 항목이 모두 같이 줄어든다. 운영에서 가장 자주 새지 않는 패턴은 가장 비싼 엔드포인트만 1분, 그 외는 5분~10분으로 쪼개는 구조다.
VPC 안 사설 엔드포인트는?, Lambda VPC 모드의 두 갈래
카나리가 모니터링해야 할 대상이 VPC 안쪽 사설 API라면, 가령 사내 어드민 도구, 내부 마이크로서비스, RDS Proxy 뒤의 DB 헬스 엔드포인트 같은, 카나리도 그 VPC 안에서 돌아야 닿는다. 인터넷에서 못 보는 곳이니까 그렇다. Synthetics는 이걸 VPC 모드로 지원한다.
VPC 모드 카나리를 만들 때 콘솔에서 추가로 채우는 칸이 세 곳이다. VPC ID, 서브넷 두세 개(AZ 분산), 보안 그룹. 이 셋이 Lambda 함수의 VPC 설정으로 그대로 들어간다. 첫 실행 직전에 카나리 Lambda가 그 서브넷 안에 ENI(Elastic Network Interface)를 자동으로 만들고, 그 ENI를 통해 사설 IP로 사내 API에 닿는다. 한 가지 같이 잡혀야 하는 것이 있는데, 카나리 IAM 역할에 AWSLambdaVPCAccessExecutionRole 관리 정책(또는 같은 권한을 담은 inline 정책)이 붙어 있어야 한다는 점이다. 이 정책이 ENI 생성·관리 권한(ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, ec2:DeleteNetworkInterface)을 준다. 빠뜨리면 카나리가 첫 실행에서 ENI 생성에 실패하고 INSUFFICIENT_DATA 상태로 멈추는데, 처음 설정할 때 가장 자주 막히는 대목이다.
VPC 모드 카나리가 AWS 서비스 자신(S3로 아티팩트 저장, CloudWatch Logs로 로그 보내기)에 닿는 길은 두 갈래로 다르다. 첫 갈래는 NAT Gateway를 통해 인터넷을 거쳐 나가는 길. 라우팅 테이블에 0.0.0.0/0 → NAT GW 한 줄이 깔려 있어야 한다. 두 번째 갈래는 VPC Endpoint, S3·DynamoDB에 나가지 않고 접근하기에서 본 길로, S3 Gateway Endpoint와 CloudWatch Logs Interface Endpoint를 사설 네트워크 안에 두고 인터넷을 거치지 않게 하는 구조다. 인터넷 연결 자체가 막힌 폐쇄 VPC 환경(금융·보안 워크로드)이라면 두 번째 갈래가 강제다.
두 갈래의 비용 갭이 의외로 크다. NAT Gateway는 시간당 $0.045 + GB당 $0.045(US East), VPC Endpoint(S3 Gateway)는 무료, CloudWatch Logs Interface Endpoint는 AZ당 시간당 $0.01 + GB당 $0.01. 카나리 트래픽 자체는 가볍지만, 같은 VPC에 다른 워크로드가 NAT를 같이 쓰고 있다면 NAT 청구서가 카나리 청구서를 압도하는 경우가 종종 있다. 이미 깔린 인프라 위에 카나리를 얹는 추가 비용 결정이라, 카나리 단독으로 NAT를 새로 깔 일은 드물다.
언제 이걸 쓰지 말아야 하는가, 외부 도구와 갈리는 세 가지 상황
매 글 끝마다 한 번씩 묻는 질문, 언제 이 서비스를 쓰지 말아야 하는가. Synthetics에 답을 잡아 보면 세 가지 상황이 있다.
첫째, 단순 uptime 모니터링이 전부인 경우. 가령 공개 API 한두 개의 200 응답만 보면 충분한 운영이라면 UptimeRobot의 무료 티어(50개 모니터, 5분 주기)가 가장 빠르고 싸다. 청구서 여섯 항목을 켤 이유가 없다. 외부 vantage가 진짜 외부라는 보너스도 따라온다.
둘째, AWS 외부의 진짜 외부 시점이 필요한 경우. 전 세계 여러 위치에서 동시에 응답 시간을 측정하거나, 실제 ISP·CDN 라우팅에 따라 사용자가 보는 latency가 어떻게 갈리는지를 보고 싶은 운영. 이쪽은 Pingdom이나 Datadog Synthetics 같은 SaaS가 더 잘 받친다. Synthetics 카나리는 결국 AWS region 안에서 도는 것이라, region 자체가 우리 사용자의 인터넷 경로와 다르다면 진짜 외부로 보기 어렵다.
셋째, 초 단위 가용성이 비즈니스 의미를 갖는 경우. 카나리 최단 주기는 1분이라 30초 안에 내려갔다 올라오는 마이크로 장애는 그냥 못 본다. 결제·주문·매매 시스템처럼 30초가 사용자 경험에 의미가 있는 워크로드는 자체 health-check + 외부 모니터링을 같이 두는 편이 낫다.
내 결론을 한 줄로 적자면, Synthetics를 선택하는 가장 또렷한 이유는 AWS 알람·SNS·EventBridge·Lambda와 한 파이프라인으로 묶고 싶을 때다. 카나리 실패가 SNS Topic으로 이동하고, Lambda 함수가 자동 복구를 시도하고, 실패하면 EventBridge Rule이 SSM Run Command로 다음 단계를 트리거하는, 이런 자동화 사슬을 처음부터 새로 짤 일이 없다는 게 가장 큰 가치다. 반대로 그런 사슬 없이 단순 알림만 받으면 되는 운영이라면 외부 도구가 더 가볍다. 어느 쪽이 어울리는지는 우리가 알람을 받은 다음에 무엇을 할 것인지에 따라 갈리는 것이다.
다음 편 예고
다음 편은 X-Ray, 분산 트레이싱의 출발점이다. Synthetics가 겉에서 사용자 시나리오의 성공/실패를 본다면, X-Ray는 안에서 한 요청이 여러 마이크로서비스를 거쳐 가는 여정을 한 줄씩 짚는다. 두 도구가 답하는 질문이 다르고, 사용자가 들어왔는가 / 들어온 요청이 어디에서 느려졌는가, 그래서 운영에서는 둘을 같이 켜 두는 게 자연스럽다.
1분 주기 카나리 다섯 개를 한꺼번에 띄울 작정이라면, 매달 청구서에 들어올 여섯 항목(Canary 실행 + Lambda + S3 + Logs ingest + Logs storage + Metrics)을 모두 합산한 다음에 결정한다. 그 합산이 AWS 네이티브 알림·자동화 사슬의 값보다 크다면 외부 도구가 더 잘 맞는다.
참고 자료
- CloudWatch Synthetics Canaries 공식 문서, 카나리 개념과 동작 형태
- Canary Blueprints reference, 일곱 가지 Blueprint 목록과 사용 예
- Synthetics 메트릭 reference,
CloudWatchSyntheticsnamespace의 메트릭 목록 - Node.js + Puppeteer 런타임 버전,
syn-nodejs-puppeteer-15.0등 최신 런타임과 deprecated 정책 - VPC 카나리 troubleshoot, VPC 모드 설정에서 가장 자주 막히는 대목
- What's New: Multi-check canaries (2025-10-22 GA), 한 카나리 안에 10단계 묶기
- What's New: Safe canary updates + automatic retries (2025-05-19 GA), 업데이트 안전 모드와 자동 재시도
- CloudWatch pricing, Canary 실행, Logs, custom metrics 가격 항목별 정리
YouTube 영상
