레이블이 AWS인 게시물을 표시합니다. 모든 게시물 표시

2025년 3월 6일 목요일

AWS Secrets Manager vs AWS Systems Manager Parameter Store

AWS Secrets Manager와 AWS Systems Manager Parameter Store는 둘 다 애플리케이션의 구성 정보를 안전하게 저장하고 관리할 수 있도록 하는 서비스이지만, 주요 차이점이 있다.

1. 기능 및 사용 목적

항목	AWS Secrets Manager	AWS Systems Manager Parameter Store
주요 목적	데이터베이스 암호, API 키, 인증 정보 같은 민감한 보안 정보를 저장 및 자동 회전	애플리케이션 설정, 구성 값, 비밀번호 등 다양한 키-값 데이터 관리
자동 키 회전	지원 (RDS, DocumentDB, Redshift와 연계 가능)	미지원 (수동으로 변경 필요)
IAM 권한 관리	IAM 정책으로 세밀한 접근 제어 가능	IAM 정책으로 접근 제어 가능하지만 보안 기능이 제한적
암호화	AWS KMS 기본 지원	기본적으로 AWS KMS 사용 가능하지만 선택 사항
버전 관리	여러 버전의 보안 정보를 저장하고 롤백 가능	기본적으로 버전 관리 지원
비용	별도 비용 발생 (사용량 기준 과금)	기본 기능은 무료, 고급 기능(고급 파라미터)은 유료

2. 보안 및 암호화

Secrets Manager는 보안이 중요한 민감한 정보를 저장하고, 자동으로 비밀번호를 회전할 수 있어 보안 관리가 강화된다.
Parameter Store도 KMS를 활용한 암호화 기능을 제공하지만, 기본적으로 보안 비밀번호 회전 기능은 없다.

3. 비용

Secrets Manager는 비밀번호 회전 및 보안 기능을 포함하여 추가 비용이 발생한다.
Parameter Store의 표준 파라미터는 무료이며, 고급 파라미터(암호화된 값 포함) 사용 시 추가 비용이 발생한다.

4. 사용 사례

사용 사례	AWS Secrets Manager	AWS Systems Manager Parameter Store
데이터베이스 암호 관리	✅	⭕ (수동 관리)
API 키 및 인증 정보 저장	✅	✅
애플리케이션 구성 값 저장	⭕ (비효율적)	✅
비밀번호 자동 회전 필요	✅	⭕
운영 환경에서 설정값 관리	⭕	✅

5. 결론

Secrets Manager는 자동 비밀번호 회전 및 보안 강화가 필요한 경우 적합하다. (예: RDS, API 키 등 민감한 정보)
Parameter Store는 일반적인 애플리케이션 설정 값 관리에 유리하며, 비용 절감이 필요한 경우 더 적합하다.

즉, 보안이 중요한 경우 Secrets Manager, 일반적인 설정 관리는 Parameter Store를 사용하는 것이 좋다. 🚀

2024년 8월 13일 화요일

docker-compose : 특정 서비스 최신 이미지 강제로 Pull 한 후 다시 시작

docker-compose 명령을 사용하여 특정 서비스의 최신 이미지를 강제로 pull 한 후 재실행하려면 docker-compose pull 명령과 docker-compose up 명령을 결합하여 사용할 수 있다.

단계별 설명

ECR 로그인

aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

이미지 Pull

docker-compose pull 명령을 사용하여 최신 이미지를 pull 한다. 특정 서비스만 pull 할 수 있다:
```
docker-compose pull app
```
서비스 재실행

docker-compose up 명령을 사용하여 특정 서비스를 재실행:
```
docker-compose up -d app
```

두 명령을 한 번에 실행:

docker-compose pull app && docker-compose up -d app

자동화를 위한 스크립트

위의 명령을 쉘 스크립트로 만들어 사용하면 더 편리하게 사용할 수 있다.

#!/bin/bash

# ECR 로그인
aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

# 최신 이미지 pull
docker-compose pull app

# 서비스 재실행
docker-compose up -d app

2024년 8월 12일 월요일

맥북에서 폴더를 EC2 서버에 업로드 : scp, ssh

로컬 맥북에서 "my-project" 프로젝트 폴더를 EC2 서버에 업로드

SCP를 이용한 파일 업로드

로컬 맥북 터미널을 열고 scp 명령어를 사용하여 프로젝트 폴더를 EC2 서버로 업로드한다.
```
scp -i <your-key-pair.pem> -r /path/my-project ec2-user@your-ec2-instance-public-dns:/home/ec2-user/
```

파일 업로드 후 확인

SSH로 EC2 서버에 접속하여 파일이 정상적으로 업로드되었는지 확인한다.
```
ssh -i <your-key-pair.pem> ec2-user@your-ec2-instance-public-dns
cd /home/ec2-user/
ls
```

EC2 서버 Docker 및 Docker Compose 설치, 삭제 후 재설치

Amazon Linux 2023 EC2 서버에 도커를 설치하고 자동 재실행 설정하는 절차는 다음과 같다.

1. Amazon Linux 2023 EC2 서버에 도커 설치 및 서비스로 자동 재실행 설정

도커 설치

EC2 인스턴스에 SSH 접속한다.

ssh -i <your-key-pair.pem> ec2-user@your-ec2-instance-public-dns

도커를 설치한다.

sudo yum update -y
sudo yum install docker -y

도커 서비스를 시작하고 부팅 시 자동으로 시작되도록 설정한다.
```
sudo systemctl start docker
sudo systemctl enable docker
```
도커가 정상적으로 설치되었는지 확인한다.
```
docker --version
```

도커 자동 재실행 설정

도커 서비스가 재부팅 시 자동으로 재실행되도록 설정한다.
```
sudo systemctl enable docker
```
컨테이너가 재부팅 시 자동 재시작되도록 Dockerfile 또는 docker run 명령어에 --restart 옵션을 추가한다.
```
docker run -d --restart unless-stopped <image-name>
```

2. Docker Compose 설치

Docker Comopose 설치

Docker Compose 바이너리를 다운로드한다.

sudo curl -SL "<https://github.com/docker/compose/releases/latest/download/docker-compose-linux-$>(uname -m)" -o /usr/local/bin/docker-compose

바이너리에 실행 권한을 부여한다.
```
sudo chmod +x /usr/local/bin/docker-compose
```
심볼릭 링크를 생성하여 Docker Compose 명령어를 사용할 수 있도록 한다.
```
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
```
Docker Compose가 정상적으로 설치되었는지 확인한다.
```
docker-compose --version
```

Docker Compose 서비스 자동 재시작 설정

docker-compose.yml 파일에 restart 정책을 추가하여 컨테이너가 자동으로 재시작되도록 설정한다. 설정 샘플:
```
version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    restart: unless-stopped
```
Docker-compose 실행
```
docker-compose up -d
```

3. Docker 재설치

docker.service가 의존하는 다른 서비스가 실패하거나 알 수 없는 이유로 Docker 서비스를 시작할 수 없는 경우, Docker를 제거하고 다시 설치하는 것도 하나의 방법이다.

Docker 제거

sudo yum remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine

위의 도커 설치 참고하여 재설치

<aside> 💡 의존성 확인 및 문제 해결

docker.service의 의존성을 확인하여 관련된 서비스들이 모두 제대로 작동하는지 확인한다.

sudo systemctl list-dependencies docker.service

원인 확인

journalctl -xe 명령어를 사용하여 자세한 오류 메시지를 확인한다.

sudo journalctl -xe

이 명령어는 최근 시스템 로그를 표시하여 Docker 서비스가 왜 실패했는지에 대한 더 구체적인 정보를 제공한다.

Docker 서비스의 상태를 확인한다.

sudo systemctl status docker

Docker가 의존하는 서비스 중 주로 containerd 서비스가 문제일 수 있다.

containerd 서비스 상태 확인 및 재시작

sudo systemctl status containerd
sudo systemctl restart containerd

이후 Docker 서비스를 다시 시작해본다.

sudo systemctl start docker

</aside>

4. Docker Compose 삭제

현재 설치된 방식에 따라 삭제 방법이 다를 수 있으니, 해당하는 방법을 따라 진행하면 된다.

Docker Compose 바이너리 삭제 (직접 다운로드한 경우)

만약 Docker Compose를 직접 바이너리 파일로 설치했다면, 아래 명령어를 통해 파일을 삭제할 수 있다.
```
sudo rm /usr/local/bin/docker-compose
```
또는 Docker Compose가 다른 경로에 설치되어 있는 경우, 설치된 경로에서 파일을 삭제하면 된다.
```
sudo rm /usr/bin/docker-compose
```
패키지 관리자를 통한 삭제 (패키지 관리자로 설치한 경우)

만약 Docker Compose를 패키지 관리자를 통해 설치한 경우, 해당 패키지를 제거하면 된다.

예를 들어, pip을 사용해 설치한 경우:
```
pip uninstall docker-compose
```
설치된 위치 확인

설치된 위치를 모르는 경우, 다음 명령어로 Docker Compose의 설치 경로를 확인한 후 해당 파일을 삭제한다.
```
which docker-compose
```
출력된 경로를 확인하고 해당 파일을 삭제하면 된다.
```
sudo rm /경로/도커-compose
```

요약

직접 설치한 경우: sudo rm /usr/local/bin/docker-compose 또는 해당 경로에서 파일 삭제
패키지 관리자로 설치한 경우: pip uninstall docker-compose
설치된 위치를 모르는 경우: which docker-compose로 경로 확인 후 삭제

2024년 6월 28일 금요일

AWS Freetier 프리티어 사용 및 과금 발생 확인: 퍼블릭 IPv4

1. 서비스 구성

프런트엔드 Front-end

React NextJS SSR
S3 + CloudFront

백엔드 Back-end

Python
Docker + uvicorn
ALB + Auto Scaling + EC2 + S3

실 운영환경으로 구성하기 위하여 백엔드 서비스에 ALB와 오토스케일링 그룹까지 생성하였다.

처음 생각한 백엔드 서비스 구성은 ALB + Fargate + ECS + ECR 이었지만 프리티어를 사용해야 하기 때문에 Fargate는 포기함.

NextJS로 구현한 프런트 사이트도 정상적으로 동작하였고 프런트에서 백엔드 API도 정상적으로 호출되어 서비스는 문제없이 구축되었다.

2. 과금 정보 및 비용 관리

AWS 루트 계정의 과금 정보 및 비용 관리 홈으로 이동 후 프리 티어를 확인하였다.

사용 중인 프리 티어 목록을 확인할 수 있다.

청구 예정 금액은 청구서로 이동하여 확인 가능하다.

3. 청구서 과금 발생 !!

며칠 서비스 운영 후 청구서를 확인해 보니 과금이 발생하고 있었다.

위 청구서 캡쳐 참조

Virtual Private Cloud (VPC)

정확히는 VPC에서 사용되는 Public IPv4 Addresses 에 대하여 과금이 발생하였다.

프리 티어로 사용되는 시간만큼 합산하여 무료가 될 것으로 생각하였으나 과금 체계는 다른 것으로 보인다.

$0.00 per In-use public IPv4 address per hour for EC2 Free Tier
$0.005 per In-use public IPv4 address per hour

2번으로 과금되는 서비스가 무엇일까?

4. 과금 원인 파악

EC2 > 네트워크 및 보안 > 네트워크 인터페이스 로 이동하여 목록을 확인해 보니 퍼블릭 IPv4 주소가 3개가 생성되어 있었다.

EC2 인스턴스에서 1개, ALB에 연결된 VPC의 서브넷 2개에서 각각 1개 생성하여 총 3개의 퍼블릭 IP가 생성됨.

EC2의 파이썬 도커에서 외부 공공 API를 호출해야 하기 때문에 EC2에서는 퍼블릭 IP가 필요하였다.

결국 ALB를 삭제하고 프런트 엔드에서 호출하는 백엔드 API의 도메인은 ALB 대신 EC2의 도메인으로 변경하여 다시 배포하였다.

ALB 대신 NLB 사용하여 서브넷을 하나만 사용하도록 하여 LB용 퍼블릭 IP를 1개만 생성하도록 하면 EC2 1개 NLB 1개 사용으로 2개 모두 프리 티어 대상이 될 수도 있을 듯 하다. (구성 후 확인은 하지 않았다)

AWS Support 답변

안녕하세요, AWS 고객지원팀입니다.

프리 티어 사용 중 발생한 VPC 요금과 관련하여 문의해 주신 것으로 이해하였습니다.
답변에 앞서, 2024년 2월 1일자로 서비스 연결 여부에 관계없이 모든 퍼블릭 IPv4 주소에 대해 시간당 IP당 0.005 USD의 요금이 부과되는 점 참고해 주시기 바랍니다. IPv4 주소 요금과 관련한 자세한 내용은 다음 링크에서 확인할 수 있습니다:

https://aws.amazon.com/ko/blogs/korea/new-aws-public-ipv4-address-charge-public-ip-insights/
Elastic Compute Cloud 인스턴스와 연결된 IPv4 주소의 경우, 1년간의 프리 티어 사용량에 해당하여 비용이 발생하고 있지 않습니다. 다만, EC2 외 서비스의 퍼블릭 IPv4 주소에 대해서는 프리 티어 사용량에 해당하지 않아 비용이 발생하고 있습니다.
문의하신 VPC 요금을 중단하기 위해서는 VPC에서 요청자 관리형 네트워크 인터페이스를 생성한 모든 리소스를 종료하거나 삭제해야 합니다. 예를 들어 퍼블릭 IPv4를 사용하는 Application Load Balancer(ALB)를 종료하고 NAT 게이트웨이, 전송 게이트웨이 VPC 연결 및 인터페이스 VPC 엔드포인트를 삭제해야 하는 점 참고해 주시기 바랍니다.

AubE Log : 오브 로그