직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 AWS29 CloudWatch 데이터 부족 경보: missing·ignore·breaching 선택 기준 CloudWatch의 데이터 부족을 정상값 0으로 단정하지 마세요. 계속 보내야 하는 지표인지, 오류가 있을 때만 보내는 지표인지부터 구분하고 누락 데이터 처리와 경보 이력을 확인합니다.적용 환경: AWS CloudWatch 일반 지표 경보, 공식 문서 2026-10-23 확인. 문서 기반 가이드이며 실제 서비스 설정 변경·시험 결과가 아닙니다.1. 원인: 값이 없는 것과 정상값은 다릅니다수집 장애로 지표가 끊길 수도 있고, 이벤트가 있을 때만 값을 내보내는 설계일 수도 있습니다. 먼저 계정·리전·네임스페이스·차원이 실제 자원과 맞는지 확인합니다. 지표를 잘못 선택한 문제를 누락 처리 설정으로 덮지 않습니다.2. 해결 순서: 지표의 의미에 맞춰 선택합니다값누락값을 평가할 때의 의미notBreaching임.. 2026. 10. 24. CloudFront 캐시 정책과 오리진 요청 정책: 캐시 키와 추가 전달값 구분 응답을 구분하는 값은 캐시 키 설계에서, 오리진에만 추가로 필요한 값은 오리진 요청 정책에서 검토하세요. 오리진으로 전달했다는 이유만으로 캐시가 나뉘지는 않습니다. 개인화·인증 응답에는 이 구분을 기계적으로 적용하지 말고 별도의 캐시 안전성을 확인해야 합니다.원인: 전달하는 값과 응답을 구분하는 값을 같은 것으로 본다캐시 정책은 헤더·쿠키·쿼리 문자열 등 캐시 키에 포함할 값과 TTL을 다룹니다. 오리진 요청 정책은 캐시 키에 없는 추가 정보를 오리진 요청에 포함하는 용도로 사용할 수 있습니다. 캐시 키에 포함한 값은 오리진 요청에도 포함됩니다. 캐시 적중 때마다 오리진 요청이 발생하는 것으로 이해하면 검증이 어긋납니다.질문검토 대상확인할 결과이 값에 따라 응답이 다른가캐시 키 또는 캐시 금지 설계서로 .. 2026. 10. 23. CloudTrail Event history와 Trail 선택: 조회 기간·이벤트 유형·보존 책임 구분 최근 관리 이벤트를 계정·리전 단위로 확인할 때는 Event history에서 시작하고, 지속적인 보관이나 데이터 이벤트 수집이 필요하면 Trail의 범위·저장·조회 설계를 따로 검토하세요. “CloudTrail을 쓴다”는 한 문장만으로 모든 활동이 보관됐다고 판단할 수 없습니다.원인: 현재 조회되는 기록과 지속 수집 설정을 혼동한다Event history는 최근 90일의 리전별 관리 이벤트를 보여 주며 Trail이나 이벤트 데이터 스토어와 별개입니다. 기본 조회 화면에 나타난다는 사실과 조직 전체·장기 보관 요구를 만족한다는 판단은 다릅니다. 애플리케이션 오류 로그나 사용자 행동 분석도 이 범위와 구분해야 합니다.확인할 요구먼저 볼 곳놓치기 쉬운 조건최근 관리 작업 확인Event history계정·리전.. 2026. 10. 23. AWS 관리형 키와 고객 관리형 KMS 키 선택: 정책·수명주기·복호화 확인 서비스가 지원하는 키 종류를 먼저 확인한 뒤, 정책과 키 수명주기를 직접 통제해야 하는지로 선택하세요. 고객 관리형 키는 통제 범위가 넓어지는 만큼 비용과 운영 책임도 생깁니다. 암호화를 켰다는 사실만으로 복구 가능한지까지 확인된 것은 아닙니다.원인: 키의 소유와 운영 책임을 구분하지 않는다AWS 문서는 고객 관리형, AWS 관리형, AWS 소유 키를 구분합니다. 고객 관리형은 계정에서 만들고 관리하는 키입니다. AWS 관리형은 연동 서비스가 계정에서 생성·관리하며, AWS 소유 키는 계정의 키 목록에서 직접 관리하는 유형이 아닙니다. 선택 가능한 조합은 사용하는 서비스에서 다시 확인해야 합니다.검토 질문관리형부터 검토고객 관리형 검토서비스 기본 운영으로 충분한가지원 옵션 확인추가 통제 필요성 확인키 정.. 2026. 10. 22. SNS와 EventBridge 선택: 구독 알림과 이벤트 라우팅을 구분하는 순서 같은 메시지를 여러 구독자에게 알리는 것이 중심이면 SNS를, 여러 이벤트의 내용과 출처에 따라 처리 대상을 나누는 것이 중심이면 EventBridge를 먼저 검토하세요. 단, SNS도 본문 필터를 지원하므로 “본문을 검사하면 무조건 EventBridge”라는 기준은 맞지 않습니다.원인: 알림 대상과 처리 규칙을 한 질문으로 섞는다“메시지를 전달한다”만으로 제품을 정하면 수신 방식과 운영 책임을 놓칩니다. SNS는 토픽을 구독한 엔드포인트에 알림을 전달하는 모델이고, EventBridge는 이벤트를 받아 조건에 맞는 대상으로 연결하는 이벤트 버스 모델입니다. 기존 큐의 Standard/FIFO 선택과는 다른 설계 단계입니다.먼저 적을 요구검토 출발점추가 확인여러 구독자로 알림 전달SNS구독 프로토콜·실패.. 2026. 10. 22. CloudFront Functions와 Lambda@Edge 선택: 네트워크·본문·실행 시점 확인 짧은 URL 변경이나 헤더 정리는 CloudFront Functions부터 검토합니다. 외부 네트워크 조회, 요청 본문 접근, 원본 요청·응답 이벤트가 필요하면 Lambda@Edge의 지원 범위를 확인하세요. 요청마다 실행할 코드와 캐시를 놓쳤을 때 실행할 코드를 먼저 구분해야 합니다.혼동의 원인: 엣지에서 실행한다는 말만 보고 고른다두 기능 모두 CloudFront 요청 흐름에 코드를 연결하지만 같은 실행 환경은 아닙니다. URL 하나를 바꾸는 작업과 외부 권한 서버의 응답을 기다리는 작업은 필요한 자원이 다릅니다. 먼저 입력 정보, 호출 대상, 실행 시점을 한 줄씩 적어 보세요.필요 동작검토 후보주의짧은 URL·헤더 변경Functions런타임 제한외부 네트워크 조회Lambda@Edge지연·실패 처리요.. 2026. 10. 21. 이전 1 2 3 4 5 다음
