반응형 전체 글7 SES 프로덕션 전환 신청부터 하세요 — 코드로 안 되는 것들 Terraform을 쓰면 전부 코드로 될 것 같지만, 승인과 대기가 필요한 것들이 있다. 그리고 이것들이 일정을 잡아먹는다.인프라를 다 만들어 놓고 서비스를 못 여는 상황이 여기서 나온다. 문자 발신번호와 SES 프로덕션 전환이 리드타임이 가장 길다.인프라 코드를 쓰기 전에 신청부터 넣는 게 맞다.먼저 신청해야 하는 것들항목왜 걸리나문자 발신번호·Sender ID계정에 종속. 새 계정이면 재취득·재등록이고 리드타임이 가장 길다메일(SES) 프로덕션 액세스기본이 샌드박스. 도메인·DKIM 인증 + 별도 신청 + 승인 대기버킷 이름전역 유일. 다른 계정에서 쓰던 이름을 그대로 못 쓴다DNS 네임서버zone을 만들면 NS가 바뀐다. 등록기관에서 바꿔야 전환된다CDN용 인증서반드시 us-east-1. DNS 검.. 2026. 9. 3. S3 프리티어 초과 청구 — 5GB보다 2,000 PUT이 먼저 터진다 S3 프리티어에서 먼저 터지는 건 용량이 아니라 요청 수다. 저장 5GB에 비해 쓰기 요청 2,000건은 훨씬 빨리 소진된다.100GB 파일 하나를 멀티파트로 올리면 API 호출이 1,002번 나간다. 그 한 번으로 월 한도의 절반이 사라진다.그리고 2025년 7월 15일부터 신규 계정은 프리티어 구조 자체가 달라졌다. 내 계정이 어느 쪽인지부터 확인해야 한다.먼저 — 내 계정은 어느 프리티어인가2025년 7월 15일을 기준으로 두 가지가 공존한다. 검색해서 나오는 글 대부분은 왼쪽 기준이라, 신규 계정이면 그 설명이 안 맞는다.2025-07-15 이전 생성2025-07-15 이후 생성형태서비스별 무료 사용량크레딧S3 몫5GB 저장 / GET 20,000 / PUT 2,000 / 전송 100GB서비스 공.. 2026. 9. 3. 930일 동안 이중화가 0이었다 — mod_jk에서 ALB 블루그린으로 이중화된 줄 알았던 구간이 사고로 한 대만 남은 채 930일을 돌고 있었다. 에러가 안 났고, 그래서 아무도 몰랐다.아파치 mod_jk 뒤에 Tomcat 여러 대를 두는 구성을 ALB 블루그린으로 옮기면서 알게 된 것들이다."무중단으로 보이지만 실은 이중화 0"인 상태가 가능하고, 그 상태는 평상시에 아무 신호도 내지 않는다."무중단인 줄 알았는데"기존 구조는 아파치 mod_jk 뒤에 Tomcat 여러 대였다. 오래된 자바 웹 서비스에서 흔한 구성이고, 몇 년 동안 별 탈 없이 돌았다.원인은 mod_jk의 sticky_session_force 설정이다. 이게 없으면 죽은 워커로 핀 된 세션이 조용히 다른 워커로 넘어간다. 사용자는 로그인이 풀리거나 장바구니가 비는 정도를 겪지만, 그건 "가끔 그러네"로 .. 2026. 9. 2. SSM Session Manager로 베스천 없이 EC2에 접속하기 퍼블릭 IP를 단 베스천을 만들지 않고 SSM Session Manager로 전부 대신했다. 인바운드 포트를 하나도 열지 않고, 접속 주체가 IAM으로 식별되고 기록된다.편해진 만큼 새로 생긴 위험도 있었다. AWS가 주는 관리형 포트포워딩 문서는 목적지를 호출자가 정하기 때문에, 그걸 그냥 허용하면 경유 박스에서 닿는 내부망 전체로 터널을 열 권한을 주는 셈이 된다.권한을 "무엇을 할 수 있는가"가 아니라 "어디까지 닿는가"로 읽어야 보이는 문제였다.새 리전은 3일 만에 올라갔다1편에서 모듈을 갈라 놓은 덕에, 새 리전은 값만 채워서 세웠다.7/3 network + EC2 3대(admin / web / api) 그린필드 구성7/3 Aurora MySQL 클러스터(writer 1대) + 삭제 보호7/.. 2026. 9. 1. Terraform import로 콘솔에서 만든 AWS 계정 코드화하기 몇 년째 콘솔에서 손으로 만들어 온 AWS 계정을 Terraform으로 끌어왔다. 두 달, 커밋 139개짜리 작업의 첫 주 기록이다.terraform plan의 create는 "AWS에 없다"는 뜻이 아니다. state 기준이라 콘솔에서 만든 실물이 멀쩡히 있어도 create로 나오고, apply는 그걸 통째로 덮어쓴다.import가 끝났다는 판정 기준은 하나다. 첫 plan이 "No changes"인 것.왜 갑자기 코드로그 계정만 있었다면 굳이 바꿀 이유가 없었다. 계기는 다른 리전에 계정을 하나 더 세워야 한다는 것이었다.콘솔로 또 만들면 두 계정은 반드시 달라진다. 그리고 그 차이는 문제가 터진 다음에, "어? 저쪽은 왜 되지" 하는 형태로 드러난다. 그래서 새로 만드는 쪽을 코드로 세우기로 했고,.. 2026. 8. 31. CloudWatch Logs 요금이 계속 오르는 이유와 보관 기간 점검 CloudWatch Logs 요금은 수집과 보관 두 갈래로 나오는데, 보관 기간의 기본값이 "만료 안 함"이라 손대지 않으면 로그가 영원히 쌓인다.청구서에서 CloudWatch 항목이 커졌다면 보관 기간이 없는 로그 그룹부터 찾는 게 순서다. 대부분 Lambda나 ECS가 자동으로 만든 그룹이다.보관 기간을 설정하면 만료된 로그는 즉시 과금 대상에서 빠진다. 실제 삭제는 최대 72시간 뒤지만 요금은 먼저 멈춘다.요금은 수집과 보관 두 갈래로 나온다두 항목이 따로 계산된다.수집 요금 — 로그를 CloudWatch Logs로 보낼 때 GB당. 한 번만 낸다.보관 요금 — 저장된 로그에 대해 GB당 월 단위. 지우기 전까지 매달 낸다.보관 요금은 압축된 크기 기준이다. AWS 요금 예시도 원본 로그가 압축된 .. 2026. 8. 30. 이전 1 2 다음 반응형