2025/05 20

Amazon MQ란? SNS, SQS와의 차이와 선택 기준 정리

Amazon MQ란 무엇인가?Amazon MQ는 AWS에서 제공하는 표준 메시지 브로커 서비스로, 기존에 온프레미스에서 사용하던 ActiveMQ 또는 RabbitMQ 기반 시스템을 AWS로 마이그레이션할 때 유용하게 사용된다. MQ의 존재 이유Amazon MQ는 새로운 시스템 개발보다는 기존 메시징 시스템의 클라우드 이전을 돕기 위한 목적이 크다. JMS(Java Message Service), AMQP, STOMP, MQTT 등 업계 표준 메시징 프로토콜을 그대로 지원하기 때문에, 기존 메시징 코드를 거의 수정하지 않고도 AWS 환경에서 그대로 사용할 수 있다.즉, "코드를 거의 안 고치고 AWS로 옮기고 싶을 때" 사용하는 실용적 서비스다. SNS/SQS vs Amazon MQ 비교 Amazon SN..

AWS 2025.05.24

AWS KMS와 CloudHSM의 차이와 선택 기준

AWS에서는 데이터 암호화를 위한 다양한 키 관리 옵션을 제공한다. 그 중에서도 대표적인 서비스가 KMS (Key Management Service)와 CloudHSM이다. 이 두 서비스는 모두 하드웨어 보안 모듈(HSM, Hardware Security Module)을 기반으로 하며, 보안 수준은 높지만 운영 방식과 사용 목적이 크게 다르다. 1. KMS란?KMS는 AWS가 제공하는 완전관리형 키 관리 서비스이다. 사용자는 AWS 콘솔이나 API를 통해 손쉽게 키를 생성하고, 해당 키를 이용해 데이터를 암호화하거나 복호화할 수 있다. 내부적으로는 HSM을 사용해 키를 안전하게 저장하고 있지만, 고객은 해당 HSM이나 키 저장 위치에 직접 접근할 수 없다. KMS는 S3, RDS, EBS, Lambda ..

AWS 2025.05.23

VPC 내부 EC2 인스턴스 간 통신 구조와 보안 설정 이해하기

AWS에서 VPC(Virtual Private Cloud)는 가상의 격리된 네트워크 공간을 제공한다. 이 VPC 내에는 여러 개의 서브넷을 만들 수 있고, 각 서브넷에는 EC2 인스턴스를 배치할 수 있다. 이번 글에서 서로 다른 서브넷에 있는 EC2 인스턴스들이 정상적으로 통신하기 위해 확인해야 할 요소들을 정리해보려 한다. 1. 기본 전제: 서브넷이 달라도 VPC 내부라면 통신은 가능하다같은 VPC에 속한 서브넷이라면 기본적으로 라우팅 테이블이 자동으로 설정되어 있기 때문에, 특별한 제한이 없다면 서로 통신이 가능하다. 그러나 보안 설정에 따라 통신이 차단될 수 있으므로 다음과 같은 항목을 반드시 확인해야 한다. 2. 서브넷 수준: 네트워크 ACL(NACL) 설정 확인네트워크 ACL(Network A..

AWS 2025.05.22

AWS KMS와 S3 서버 측 암호화 방식 정리

1. KMS(Key Management Service)란?AWS Key Management Service(KMS)는 암호화 키의 생성부터 저장, 회전, 삭제까지 전체 수명주기를 관리하고, 실제 암호화 및 복호화 요청도 처리해주는 서비스다. 이 키들은 AWS가 제공하는 FIPS 140-2 인증 하드웨어 보안 모듈(HSM) 내부에서 안전하게 관리되며, 사용자나 AWS 운영자조차 키 내용을 직접 볼 수 없다. 사용자는 키를 보는 것이 아니라, 암호화 또는 복호화를 요청만 하고, 결과만 응답받는 방식이다.KMS 키는 AWS 콘솔 또는 API를 통해 생성할 수 있고, 각 키에 대한 IAM 권한 설정이나 키 사용 기록 추적도 가능하다. CloudTrail을 통해 어떤 서비스나 사용자가 해당 키를 사용했는지 로그로 ..

AWS 2025.05.21

S3 객체 소유권과 액세스 제어

Amazon S3에서는 객체를 업로드한 사용자 또는 계정이 그 객체의 소유자(owner)가 된다. 즉, 외부 계정이 내 버킷에 객체를 업로드하면, 그 객체는 기본적으로 외부 계정의 소유가 된다. 이때 버킷 소유자는 그 객체에 대해 자동으로 접근 권한을 갖지 않는다. IAM 정책 만으로는 객체에 접근할 수 없다. 그 이유는, IAM 정책은 주체(사용자나 역할)에게 권한을 부여하는데, 하지만 객체에 대한 최종 접근 권한은 다음과 같이 결정된다:최종 권한 = IAM 정책 + 버킷 정책 + 객체 ACL + 소유권 구조​ 즉, IAM 정책에서 s3:GetObject 권한이 있더라도, 객체가 다른 계정의 소유이거나, ACL에서 허용되지 않았거나, 버킷 정책에서 막았다면➡️ 객체에 접근할 수 없다. 이 문제를 해결하..

AWS 2025.05.20

DMS 흐름으로 본 계층 보안의 이유

웹에서 어떤 요청이 들어온다는 건 단순한 일이 아니다. 이 요청이 누구로부터 왔는지, 정상적인 경로를 통해 왔는지, 그 안에 담긴 내용이 안전한지를 모두 확인해야 하기 때문이다. 이번에 하나의 요청이 서버로 도달하기까지 거치는 보안 계층들을 살펴보고, AWS의 Database Migration Service(DMS) 사례를 통해 왜 네트워크 보안만으로는 충분하지 않으며, SSL과 같은 상위 계층 보안이 필수적인지를 정리해보려 한다. 여러 층으로 나뉘어져 있는 보안요청이 네트워크를 통해 시스템에 도달할 때, 보안은 하나의 레이어가 아닌 여러 단계로 분산되어 작동한다. 1. 네트워크 보안 (IP, 포트 기반 접근 제어)방화벽, 보안 그룹, 네트워크 ACL은 IP 주소나 포트를 기준으로 누가 접근할 수 있는지..

AWS 2025.05.19

AWS WAF를 활용한 국가 기반 요청 차단 및 예외 IP 허용

회사에서 ALB(Application Load Balancer) 뒤의 Amazon ECS 클러스터에서 애플리케이션을 운영하고 있다고 가정하자. 이때, 특정 국가의 요청은 차단하면서도, 그 국가 내 일부 IP는 예외적으로 허용해야 하는 보안 요구사항이 생길 수 있다. 이러한 정교한 요청 필터링은 어디에서 어떻게 구현해야 할까? WAF로 요청 필터링"누가 들어올 수 있는가?"를 판단하는 보안 계층은 AWS WAF(Web Application Firewall)에서 담당한다. 요청 자체를 허용하거나 차단하는 역할을 하며, 통과된 요청은 ALB에서 어떤 인스턴스나 서비스로 보낼지를 결정하게 된다. AWS WAF는 다음과 같은 요청 필터링 기능을 제공한다:IP 기반 필터링IP set이라는 객체를 정의하여 특정 I..

AWS 2025.05.18

SQS를 이용한 사용자 우선순위 처리 아키텍처 설계

서비스에서 유료 회원(프리미엄 사용자)의 요청을 무료 회원보다 우선 처리해야 하는 상황에서, AWS SQS를 활용해 어떤 방식으로 아키텍처를 구성할 수 있을지에 대해 학습하고 정리해본다. 1. 문제 상황 가정웹사이트에서 프리미엄 사용자와 무료 사용자 모두 사진을 업로드하고, 이를 비디오로 변환해 다운로드하는 기능을 제공한다고 가정한다. 모든 요청은 SQS 대기열을 통해 EC2 인스턴스에서 처리된다. 이때 프리미엄 사용자의 요청을 무료 사용자보다 먼저 처리해야 하는 요구사항이 존재한다. 2. 단일 SQS의 한계프리미엄 사용자와 무료 사용자의 요청이 단일 SQS 대기열에 저장되고, EC2 인스턴스가 이를 처리하는 구조같은 경우 SQS가 메시지의 우선순위를 자체적으로 지원하지 않기 때문에, 프리미엄 요청을 먼..

AWS 2025.05.17

장애 복구 전략을 세우기 전에 꼭 알아야 할 개념: RTO vs RPO

서버나 시스템에 장애가 발생했을 때, 얼마나 빨리 복구해야 할까? 또 어느 시점까지의 데이터를 복구할 수 있으면 괜찮을까? 장애 복구(Disaster Recovery)를 설계할 때 꼭 알아야 하는 두 가지 핵심 지표가 바로 RTO와 RPO이다. RTO (Recovery Time Objective): 복구 시간 목표"장애 발생 후, 시스템이 몇 분(또는 몇 시간) 이내에 다시 동작해야 하는가?"초점: 시간예시: 장애 발생 후 10분 내에 시스템이 작동 상태로 돌아와야 한다면,→ RTO = 10분RTO가 짧을수록, 복구 환경이 빠르게 준비되어 있어야 함 RPO (Recovery Point Objective): 복구 지점 목표"장애 발생 시점 기준, 얼마나 이전의 데이터까지 복구할 수 있으면 괜찮은가?"초점:..

AWS 2025.05.16

Auto Scaling 최적화 - 안정성과 비용 효율을 동시에 잡는 법

AWS의 Auto Scaling 기능은 애플리케이션의 가용성을 유지하면서도 리소스를 효율적으로 관리할 수 있는 중요한 도구이다. 하지만 설정을 어떻게 하느냐에 따라 불필요한 인스턴스 생성, 불안정한 성능, 예상치 못한 비용 증가가 발생할 수 있다. Auto Scaling이 너무 자주 작동한다면?Auto Scaling 그룹이 너무 자주 스케일 아웃(인스턴스 증가)과 스케일 인(인스턴스 감소)을 반복하면 다음과 같은 문제가 발생할 수 있다:비용 증가: 인스턴스가 짧은 시간이라도 실행되면 비용이 발생불안정한 서비스: 인스턴스가 충분히 안정화되기도 전에 종료됨의미 없는 반응: 사소한 트래픽 변화에도 과도하게 반응 최적화를 위한 두 가지 핵심 조정 포인트1. 휴지 기간(Cooldown Period) 늘리기역할: ..

AWS 2025.05.15