복원한 RDS가 available로 표시됩니다. 그런데 서비스에서 조회한 데이터는 여전히 기존 DB의 내용으로 보이는 경우가 간혹 있습니다. 복원 작업 시 진행 상태만 보고 애플리케이션까지 새 DB로 옮겨 갔다고 판단하면, 정작 뭘 확인해야될지 확인해야 할 접속 대상이 빠집니다.복원 완료와 접속 전환의 차이AWS의 스냅샷 복원 문서에 따르면 DB 스냅샷 복원은 기존 인스턴스를 덮어쓰는 방식이 아니라 DB 인스턴스를 새로 만드는 작업입니다. 따라서 기존 주소로 직접 접속하는 애플리케이션은 새 DB를 사용하도록 별도로 config를 변경해줘야 합니다. 여기서는 일반 RDS DB 인스턴스의 직접 연결을 기준으로 설명하며, Aurora나 프록시를 통한 연결은 구성을 따로 확인해야 합니다.먼저 복원 목적을 정합니..

실무를 하다보면 S3에서 파일을 지웠는데 저장 비용이 좀처럼 줄지 않는 상황을 이 글을 읽는 여러분도 종종 겪을 수 있습니다. 객체 목록은 비어 있는데 청구 내역에는 금액이 있다면, 먼저 삭제가 어떤 상태를 만들었는지 살펴볼 차례입니다. 이 글은 버전 관리가 활성화된 일반 목적 버킷을 기준으로 현재 버전·이전 버전·삭제 마커를 구분합니다.목록에서 사라진 파일과 남아 있는 버전버전 관리는 같은 객체 키에 여러 버전을 보관하는 기능입니다. 버전 ID를 지정하지 않고 삭제하면 S3는 삭제 마커를 현재 버전으로 추가하고, 삭제 직전의 데이터는 이전 버전으로 남깁니다. 일반 목록에서 파일이 사라졌다는 사실만으로 저장 데이터까지 없어졌다고 판단하기 어려운 이유입니다.가령 같은 키에 100MB 파일을 두 번 올린 뒤..

거래처에 S3 다운로드 링크를 보냈는데 다음 날 열리지 않는다면, 유효기간을 짧게 잡았다고만 보기는 어렵습니다. 링크에 넣은 시간보다 서명에 사용한 임시 자격 증명이 먼저 만료됐을 수도 있습니다. 반대로 문의를 줄이려고 기간을 늘리면 링크가 재전달되어 사용될 수 있는 시간도 길어집니다.설정한 유효기간과 실제 사용 가능 시간S3 사전 서명 URL은 특정 객체를 내려받을 권한을 일정 시간 제공하는 주소입니다. 수신자가 AWS 계정을 따로 보유할 필요는 없지만, 주소를 가진 다른 사람도 같은 조건에서 사용할 수 있습니다. 한 번 내려받았다고 자동 소멸하는 일회용 링크도 아닙니다. 공유 방식을 정할 때 이 성격부터 확인해야 합니다.일반적인 S3 객체 공유에서 콘솔은 최대 12시간, CLI·SDK의 SigV4 방..

Teamviewwe는 전세계적으로 널리 사용되고 있는 원격 데스크톱 연결 프로그램이다. 이 프로그램에서 취약점이 발견되었는데 과연 원격 지원을 받는 직원 PC만 최신 버전이면 안심해도 될까. 이번 취약점은 오히려 원격 화면을 보는 쪽의 프로그램을 먼저 살펴야 한다. IT 담당자가 외부 업체 장비나 직원 PC에 접속할 때 사용하는 관리용 PC도 점검 대상이다.2026년 10월 27일 TeamViewer가 공개한 보안 권고에는 세 가지 취약점이 포함됐다. 이 글에서는 그중 CVE-2026-111585에 초점을 맞춘다. 아래 버전과 설명은 2026년 11월 3일 확인한 권고를 기준으로 한다. TeamViewer 보안 권고 원격 화면을 보는 프로그램에서 발생하는 문제이 취약점은 원격제어 화면을 처리하는 클라이..

대상 그룹은 정상인데 사용자는 로그인에 실패합니다. 이때 정상 표시가 틀렸다고 보기보다, 헬스 체크가 확인한 범위와 로그인 요청이 실제로 지나가는 경로를 나눠 보는 편이 빠릅니다. 이 글은 ALB와 애플리케이션을 운영하는 담당자가 두 경로의 차이를 좁혀 가는 기준을 정리합니다. 정상 표시가 보장하는 범위ALB는 대상 그룹에 설정된 경로와 포트로 주기적으로 헬스 체크를 보냅니다. 응답이 설정된 성공 코드와 횟수 등의 조건을 충족하면 해당 대상을 정상으로 판단합니다. 이 결과는 확인 시점의 지정된 요청에 대한 판정이며, 모든 업무 기능이 정상이라는 뜻은 아닙니다.예를 들어 /health가 프로세스의 응답만 확인한다면 DB나 외부 인증 서비스 연결이 끊겨도 정상 응답을 줄 수 있습니다. 반대로 해당 엔드포인..

EC2의 EBS 볼륨을 늘렸는데 서버에서는 여전히 기존 용량만 보이는 경우가 있습니다. 비용을 더 투자해서 스토리지를 늘렸는데 안보이니 우선 파일시스템이 의심갑니다. AWS에서 확보한 저장 공간이 곧바로 파일시스템의 사용 가능 공간이 되는 것은 아니기 때문입니다. Linux 서버에서 볼륨, 파티션, 파일시스템을 어떤 순서로 확인할지 살펴보겠습니다. 확장된 볼륨과 실제 사용 공간의 차이EBS 볼륨은 서버에 연결된 저장 장치이고, 파티션은 그 장치를 나눈 영역입니다. 파일시스템은 그 위에서 파일을 저장하고 관리합니다. 구성에 따라 파티션 없이 볼륨 전체에 파일시스템을 만들거나, 중간에 LVM 논리 볼륨을 둘 수도 있습니다.예를 들어 디스크 볼륨을 50G에서 100G로 늘렸더라도 파티션과 파일시스템이 이전 ..

점검을 마친 EC2 인스턴스가 실행 중인데도 외부 시스템에서 접속하지 못한다면 공인 IP부터 확인해 볼 만합니다. 작업자가 말한 “서버 재시작”이 EC2의 재부팅인지, 인스턴스를 중지한 뒤 다시 시작한 것인지에 따라 외부에서 접근 가능한 주소의 처리 방식이 달라집니다. 이 글은 Elastic IP를 사용하지 않고 DHCP IPv4로 직접 통신하는 EC2를 중심으로 설명합니다. 재부팅과 중지 후 시작의 주소 차이 EC2 콘솔 자체의 재부팅(Reboot)은 운영체제 재시작에 해당하며 기존 공인 IPv4 주소를 유지합니다. AWS는 프라이빗 IPv4와 인스턴스 스토어 데이터도 재부팅 시 유지된다고 설명합니다. AWS — EC2 인스턴스 재부팅반면 중지(Stop)하면 자동 할당된 공인 IPv4가 해제됩니다...

SSH 키를 바꾼 뒤 터미널에서는 접속되는데 자동 배포만 실패할 수 있습니다. 이때 수동 접속 성공은 배포 작업도 새 키를 사용한다는 증거가 아닙니다. 두 작업이 같은 서버에 접속하더라도 실행하는 계정과 읽는 파일, 인증 정보를 전달받는 환경이 다를 수 있기 때문입니다. 접속 계정과 실행 계정부터 분리가령 관리자는 노트북에서 접속하고 배포는 별도 Linux 실행기에서 수행하는 상황을 가정하겠습니다. 노트북의 키만 교체했다면 실행기에 남은 키는 그대로일 수 있습니다. 같은 서버에서 실행하더라도 관리자 계정과 배포 서비스 계정은 서로 다른 설정을 읽을 수 있습니다.먼저 작업을 실행하는 로컬 계정과 원격 서버에 로그인하는 계정을 나눠 기록합니다. 아래 명령은 배포 작업 안에서 실행하는 예시입니다. deplo..

서버에서 애플리케이션이 갑자기 사라졌는데 재시작 후에는 정상으로 보일 때가 있다. 이때 현재 메모리 사용량만 보면 종료 당시의 상황을 놓칠 수 있다. 커널의 OOM(Out of Memory) 기록을 확인하면 종료 시각과 대상 프로세스를 찾고, 서버 전체의 메모리 압박인지 특정 서비스의 제한인지 조사 범위를 좁힐 수 있다. OOM 기록이 알려주는 것과 알려주지 않는 것 커널은 메모리 확보에 실패한 상황에서 OOM killer를 호출해 프로세스를 종료할 수 있다. 다만 메모리 할당 실패가 모두 OOM killer의 실행으로 이어지는 것은 아니다. 커널 로그에 남은 종료 대상은 그 시점에 선택된 프로세스이지, 메모리 부족을 처음 일으킨 유일한 원인이라는 뜻은 아니다.서버 전체에 여유가 없어 발생하는..

같은 Docker 이미지를 운영 환경과 테스트 환경에 배포했는데 설정값을 바꾸려면 이미지를 다시 만들어야 할까요? 답은 설정이 저장된 위치와 애플리케이션이 값을 읽는 시점에 따라 달라집니다. 이미지 안에 포함된 파일과 컨테이너 생성 시 외부에서 전달한 설정을 구분하면 변경 범위와 확인 순서를 정하기 쉽습니다.이미지에 복사한 설정은 이미지 버전의 일부입니다Dockerfile의 COPY로 설정 파일을 넣으면 빌드 당시 파일이 이미지에 포함됩니다. 이후 원본 파일을 수정해도 이미 만들어진 이미지나 실행 중인 컨테이너가 자동으로 바뀌지는 않습니다. 변경된 파일을 이미지에 반영하려면 이미지를 다시 빌드하고, 새 이미지로 컨테이너를 교체해야 합니다.이 방식은 애플리케이션과 기본 설정을 함께 버전 관리하기 쉽습니다...