페페 더 엔지니어

[57] 프로젝트 개설 : #0

페페 더 엔지니어 — Sun, 15 Mar 2026 12:41:16 +0900

개요

지금까지 했던 AWS 서비스를 묶어 하나의 아키텍쳐 안에 녹이기

+ 로깅 / 모니터링을 새로 추가해서 엮어보기

+ 이제껏 main.tf 하나에 다 담았는데, 모듈화하기

1 : VSCODE로 작업하기 위해 AWS CLI 작업환경 구축

2 : 모듈 / 환경별 작업공간 분리하기

2 : tier-3 작성

4 : 무너뜨리고 완전히 새로

5 : github actions : ansible로 똑같이

6 : 모듈레이션

7 : EKS

-----------------------------------------------------

Terraform (IaC)
Ansible (config management)

CI/CD
GitHub Actions

Monitoring
Prometheus
Grafana

Logging
Loki
Promtail

aws-devops-platform
│
├ terraform
│   ├ modules
│   │    ├ vpc
│   │    ├ eks
│   │    ├ rds
│   │    └ s3
│   │
│   ├ environments
│   │    ├ dev
│   │    └ prod
│   │
│   ├ backend.tf
│   ├ provider.tf
│   └ variables.tf
│
├ ansible
│   ├ inventory
│   ├ roles
│   │   ├ docker
│   │   ├ kubectl
│   │   └ helm
│   └ setup.yml
│
├ kubernetes
│   ├ namespace.yaml
│   ├ deployment.yaml
│   ├ service.yaml
│   └ ingress.yaml
│
├ monitoring
│   ├ prometheus
│   └ grafana
│
├ logging
│   └ loki
│
└ cicd
    └ github-actions.yml

[56] Github Actions

페페 더 엔지니어 — Sun, 8 Mar 2026 08:52:49 +0900

Workflow runs · riptae/aws-ansible

---------------------개요---------------------------------------------

이전에는 내 Windows PC 에서

local -> local 코드 -> terraform apply -> Aws API -> 리소스 생성

local (wsl) -> ansible inventory + playbook -> EC2 Public IP -> 설정(nginx)

-------------------------Github Actions------------------------------

지금은 아예 github에 Push -> Github runner 임시 서버에서

- github 코드로 terraform apply

- inventory 자동생성

- wsl -> ansible 설치 -> inventory + playbook -> EC2 public IP

로 리소스 생성 + 관리 자동화

--------------------------------------------------------------------------------------

새롭게 추가되는 것

./github/workflows

ㄴ deploy.yml

-> 체크아웃

-> AWS credentials

-> 여기서 테라폼 cmd

-> ansible설치

-> SSH key 생성

-> inventory 생성

-> playbook

/scripts/

ㄴ gen_inventory.sh

-> public ip output 받아서 자동생성

github secrets에 SSH private key 넣어두고

ansible에서 사용할 수 있게 키 생성 (deploy)

기존 내 windows Local이 아닌, github actions에서 AWS 리소스 생성할 수 있도록 AWS 크레덴셜 작업

--------------------------------------------------------------------------------------------------------------------------------

OIDC

1 : arn 생성

IAM -> ACCESS mgmt -> Identity Providers -> OpenID connect

arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com

2 : IAM Role 생성

Github Actions가 AssumeRole로 사용할 예정

Create Role -> Web Identity -> Identity Provider 삽입 -> Githup REpo를 조건으로 넣는다

---------------------------------------------------------------------------------------------------------------

주로 SSH키 생성에서 오류 발생

QUICK ACCESS

페페 더 엔지니어 — Sat, 7 Mar 2026 23:04:03 +0900

1. AWS configure

[1]

[6] WSL 에서 읽는 ssh key경로

페페 더 엔지니어 — Sat, 7 Mar 2026 23:03:36 +0900

C:/terraform/aws-ansible/

여기에 main.tf, ssh key 가 있었고

C:/terraform/aws-ansible/ansible/

에 inventory.ini / playbook.yml이 있었는데

ansible 명령어는 WSL 안에서 때리는 거여서

chmod 400을 해도 권한이 여전히 오픈되어 있었다

그래서 ansible home dir에 키를 카피

이후 chmod가 정상 동작했다

문제는 inventory.ini 안의 key 경로 옵션인데

처음 착각은 inventory와 playbook이 일반 Window C경로에 있으니 /mnt/c 나 ~ (리눅스 홈 dir) 를 쓰면 안 되는줄 알았는데

어차피 wsl이 실행하는 기준이니까 상관없다

참고

[5 rocky vs rhel vs ubuntu 기본 접속포트 활성화

페페 더 엔지니어 — Sat, 7 Mar 2026 14:33:19 +0900

케이스1 :

안산 공공기관A 보안취약점 작업 사전연습을 위해

RHEL 8.8을 oracle virtualbox vm에 설치

포트포워딩 설정 : 127.0.0.1:2222 -> RHEL 8.8 22

내 노트북으로 붙어서 conf적용 실습

rocky 9.6은 동일 방식으로 바로 성공

RHEL 8.8은 불가해서

- 포워딩 설정 제대로 되어 있는지

- 다른 포트로 빠져나가는 것 없는지

- 포트 리슨 정상

- sshd 상태 정상

- /etc/ssh/sshd_config 로그인 / auth 정상설정 확인

계속 안되서 헤매다가

ip a를 치니 커넥션 자체가 기본으로 활성화되지 않았음을 확인

connection up 후 정상접속 확인됨

--------------------------------------------------

케이스2: pem key

al2023을 주로 사용하다가

ubuntu로 ssh pem key 접속 테스트를 사용했지만 바로 접속 가능

직렬 콘솔로 들어가서 확인해보니, 아예 pubkeyauthentication 주석처리 되어있어도 기본값은 yes 이고

여긴 기본 ip가 살아있었다

버전이나 종류에 따라

- ssh가 활성화 되어있는지

- authentication 허용 여부

- connection / ip 활성화 되어있는지

- id / pw는 정확한지

안되면 전부 다 순회하는 방향으로 해야 제일 깔끔할 것 같다

[55] EC2 public ip OVERRIDE

페페 더 엔지니어 — Mon, 2 Mar 2026 11:09:49 +0900

subnet 에서

map_public_ip_on_launch = true 해도 OVERRIDE

[1]

그런데 기존 작성된 "EC2 -> RDS" 구조에서

EC2가 mysql client를 다운받아졌다

[2]

RDS용 NATGW (EIP)가 Private subnet과 라우팅되긴 하지만

NATGW은 public subnet 에 되니까 그것때문인가 생각했지만

애초에 EC2도 private subnet과 라우팅을 해버렸다

[3]

public subnet으로 교체 확인

[4]

pending 확인

-----------------------------------------------------------------------------------------------------------------------

여기서 associate_public_ip_address = false는

map_public_ip_on_launch = true

를 오버라이드해서 인터넷이 막히는 게 확실하며

만약 이런식으로 구성해서 서비스가 돌아가고 있을 때

1 - EC2의 subnet 바꾸기 : EC2를 끄거나 밀어버리고 작업해야 함

2 - EIP 할당

두가지 옵션이 있는데, 당연히 2번을 해야 한다.

EIP할당 후 다운 완료

RDS 접속 완료

IP 매핑 해제

릴리스

리소스 삭제

SAA

페페 더 엔지니어 — Wed, 18 Feb 2026 11:56:29 +0900

[1] S3

Global Accelerator :

TCP,UDP

CloudFront :

HTTP 프로토콜

S3 버킷 :

Amazon S3에 저장된 객체에 대한 컨테이너, 버킷에 저장할 수 있는 객체 수에는 제한이 없음. ACL, 버킷정책 또는 둘다를 통해 버킷 및 객체에 퍼블릭 액세스 권한이 부여

S3 버전관리, 버킷에 버전관리, MFA Delete

S3 Transfer Acceleration :

클라이언트와 S3 버킷 간의 장거리 파일 전송을 파일을 빠르고 쉽고 안전하게 전송할 수 있는 버킷 기능. 전 세계에서 S3 버킷으로 전송 속도를 최적화. Amazon CloudFront에서 전 세계에 분산된 엣지 로케이션을 활용

S3 File Gateway

• 하이브리드 클라우드 스토리지 솔루션인 AWS Storage Gateway의 한 유형

온프레미스 환경 <-> AWS 클라우드 스토리지 연결
온프레미스 애플리케이션이나 파일 서버가 S3 버킷을 마치 로컬 파일 공유처럼 사용할 수 있도록 연결

<aside> ✅

캐싱 구조

로컬 캐시: 자주 액세스되는 데이터는 온프레미스 게이트웨이의 로컬 디스크에 캐시되어 짧은 대기 시간으로 제공됨
클라우드 스토리지: 모든 데이터는 S3 객체로 저장되어 무한한 확장성과 높은 내구성을 확보 </aside>

수명 주기 통합:

S3에 저장된 데이터이므로, S3 수명 주기 정책을 통해 자동으로 Glacier 등으로 데이터를 이동시켜 비용을 최적화할 수 있음

게이트웨이 VPC 엔드포인트 :

PC용 인터넷 게이트웨이 또는 NAT 디바이스가 없어도 Amazon S3 및 DynamoDB에 안정적인 연결을 제공

Gateway API : 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스, HTTP 기반, 상태비저장, 표준 HTTP 메서드를 구현

S3 Standard :

기본 스토리지 클래스, 객체를 업로드 할때 스토리지 클래스를 지정하지 않으면 S3가 해당 클래스를 할당

S3 Glacier Deep Archive

거의 액세스 할 필요가 없는 데이터를 보관할 때 사용. 클래스에 저장된 데이터의 최소 스토리지 기간은 180일이고 기본 검색 시간은 12시간, 가장 저렴한 스토리지 옵션

S3 Intelligent-Tiering

3개의 액세스 계층에 자동으로 저장

한 계층 : 빈도 높은 액세스
하나의 저렴한 계층 : 빈도 낮은 액세스
또 다른 매우 저렴한 계층 : 거의 액세스하지 않은 데이터에 최적화

저렴한 월별 객체 모니터링 및 자동화 요금으로 액세스 패턴을 모니터링하고 연속 30일동안 액세스하지 않은 객체를 Infrequent Access 계층으로 자동 이동

90일동안 액세스X, 성능 영향이나 운영 오버헤드 없이 → Archive Instant Access

사용

S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Flexible Retrieval로 이동,
Amazon Athena를 사용하여 Amazon S3에 있는 파일을 쿼리하고검색, S3 Glacier Select를 사용하여 S3 Glacier에 있는 파일을 쿼리하고 검색
Amazon S3 Intelligent-Tiering 에 개별 파일을 저장.

S3 Glacier Flexible Retrieval

분 단위로 데이터 일부를 검색해야 하는 아카이브에 사용. 해당 클래스에 저장된 데이터는 최소 스토리지 기간이 90일이며, 신속 검색을 사용하여 최소 1~5분 이내에 액세스 함. 검색 시간은 유연하며 최대 5~12시간 내에 무료 대량 검색을 요청

S3 Glacier Instant Retrieval :

거의 액세스하지 않고 밀리초 단위로 검색해야 하는 데이터를 아카이브하는데 사용. 저장된 데이터는 S3 Stand-IA 스토리지 클래스와 동일한 대기 시간 및 처리량 성능으로 S3 Standard-IA 스토리지 클래스보다 비용을 절감

S3수명 주기 정책 :

일정 시간이 지났을 때 사용되지 않는 파일들을 삭제하거나 다른 곳에 백업하여 S3 저장 공간을 절약할 수 있는 비용 효율적인 방법.

S3 객체 잠금 모드 비교: Governance Compliance

**Amazon S3 객체 잠금(Object Lock)**은 데이터를 특정 기간 동안 또는 무기한으로 수정하거나 삭제할 수 없게 만드는 기능으로, 이 두 가지 모드를 제공합니다.

1. 거버넌스 모드 (Governance Mode)

거버넌스 모드는 보호 잠금 이라고 생각할 수 있습니다.

보호 수준: 높은 수준의 보호를 제공하지만, 특정 권한을 가진 사용자에게는 유연성을 남겨둡니다.

우회 가능성: s3:BypassGovernance 권한을 가진 IAM 사용자나 역할은 보존 기간이 설정된 객체라도 잠금을 우회하고 삭제하거나 설정 변경이 가능합니다.

2. 규정 준수 모드 (Compliance Mode)

규정 준수 모드는 영구적인 잠금 이라고 생각할 수 있습니다.

보호 수준: **최고 수준의 보안(불변성)**을 제공합니다.

우회 가능성: 객체가 보존 기간 내에 있는 한, AWS 루트 계정 사용자조차도 잠금 설정을 변경하거나 객체를 삭제할 수 없습니다. 즉, 어떤 사용자나 프로세스도 데이터를 수정/삭제할 수 없도록 강제합니다.

Reduced Redundancy :

RRS 스토리지 클래스는 S3 Standard 스토리지 클래스보다 더 적은 중복성으로 저장될 수 있는 데이터 중에서도 중요하지 않고 재현 가능한 데이터를 목적으로 설계, 내구성 측면에서 객체 손실이 발생하므로 사용하지 않는 것이 좋음

[2] Organizations

AWS Organizations :

여러 AWS 계정을 생성하고 중앙에서 관리하는 조직으로 통합할 수 있는 계정 서비스, 조직의 계층적 구조를 구성하는 루트 및 OU, 조직의 멤버, 조직 내 다음 개체에 연결하는 정책, 조직 상태를 변경할 때 사용하는 핸드세이크에 대해 액세스 제어

• aws:PrincipalOrgID :

리소스 기반 정책의 Principal 요소 지정을 간소화.

전역 키는 조직 내 모든 AWS 계정의 계정 ID를 전부 나열하는 대안을 제공.

조직의 멤버인 모든 계정을 나열하는 대신 Condition 요소에 조직 ID를 지정.

서비스 제어 정책 (SCP)

IAM 정책과 유사하지만, 최대 권한을 정의함
여기서 허용되지 않은 작업은 절대 수행할 수 없음

SCP는 계정의 모든 IAM 엔티티에 대한 중앙 액세스를 제공. 이를 사용하여 비즈니스의 모든 사람이 따르기를 원하는 권한을 적용.

[54] aws s3 ls 시 (환경변수 / credentials / IMDS slot)

페페 더 엔지니어 — Wed, 18 Feb 2026 11:22:12 +0900

[0]

aws s3 ls 검색시

AWS SDK / CLI 는

1. 환경변수
2. ~/.aws/credentials
3. IMDS (Instance Role)

로 크레덴셜을 탐색하기 시작한다

[1]

Environment Variables

-> 하드코딩 키

보통

IAM User Access Key

STS 임시 키

CI/CD 파이프라인 키

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN   # (옵션, STS일 경우)


EX)
export AWS_ACCESS_KEY_ID=AKIA....
export AWS_SECRET_ACCESS_KEY=abcd....

저장 위치 : OS 환경변수

수명 : 키 만료까지 (회전x)

보안 x

우선순위 1순위

[2]

로컬 자격증명 파일

~/.aws/credentials

[default]
aws_access_key_id = AKIA....
aws_secret_access_key = abcd....

[dev]
aws_access_key_id = AKIA....
aws_secret_access_key = efgh....

저장 위치 : 파일

키 종류 : IAM User Key

Profile : 여러 개 가능

CLI 사용 : aws configure

우선순위 : 2순위

---------------------------------------------

환경변수와 credentials 파일에는

"IAM User Access Key or STS 임시 키가 들어 있다

둘 다 Role 기반 키 아님.

[3]

EC2 Role (IMDS)와 차이

	환경변수 / Credentials	IMDS
키 발급 주체	IAM User or STS	STS (Role 기반)
저장 위치	OS / 파일	Metadata API
자동 회전	❌	⭕
권장 여부	낮음	높음
EC2 표준	❌	⭕

[4]

실무 보안 관점

환경변수 x

credentials x

IMDS o

이것만 남겨둔다

[6]

cli / aws configure의 경우

-> STS token이 아닌

-> IAM User의 Long-term Credentials

그러면 저장되는 파일

~/.aws/credentials
~/.aws/config

##ex####
[default]
aws_access_key_id = AKIA....
aws_secret_access_key = abcd....

발급 주체 : IAM User

수명 : 만료 없음

발급 : IAM

token : 없음

STS개입 : 없음

즉 CLI CRUD가 가능한 이유는

IAM User 자체 권한으로 직접 AWS API 호출하는 것

STS 토큰과 차이

STS 사용시 credential 형태

AccessKeyId
SecretAccessKey
SessionToken   ← 이게 핵심
Expiration

하지만 aws configure 기본 키에는

SessionToken 없음

Expriation 없음

-> 그래서 장기 키

chain

AWS CLI
   ↓
Access Key 서명
   ↓
AWS API 직접 호출

[7]

token을 사용하는 경우 3가지

A : MFA 세션 토큰

(aws sts get-session-token)

web 로그인시 authenticator

B : AWS SSO 로그인

CLI v2 특징

aws configure sso
aws sso login

##########동작#################
SSO 인증
   ↓
STS Token 발급
   ↓
CLI 저장

C :

Assume Role Profile

[default]
aws_access_key_id=AKIA...
aws_secret_access_key=abcd...

[prod]
role_arn = arn:aws:iam::123:role/Admin
source_profile = default

##############################################

aws s3 ls --profile prod

############# 동작 ###################3
default 키 사용
   ↓
sts:AssumeRole
   ↓
Temp Credential 발급
   ↓
API 호출

[8]

내 환경이 STS인지 확인하는 경우

1 : ~/.aws/credentials -> Session Token 있으면 STS

2: cli로 aws get-caller-identity

User ARN -> IAM User 키

Assumed-role ARN -> STS

[53] AWS APP mesh

페페 더 엔지니어 — Tue, 17 Feb 2026 20:15:22 +0900

k8s 에코시스템으로 제공되는 OSS

------------------------

서비스 메시

MSA 아키텍쳐로 구성된 앱에서 분산된 서비스 간 통신 처리를 지원하는 기술

--------------------------

MSA에서는

- HTTP 통신에서는 안정된 통신 보증x

- 접근 지연, 연결 에러 발생

- 신뢰할 수 없는 네트워크 공간에서는 요청의 안정성 및 정당성 검증

통신이 발생하는 MS간

- 재시도 처리, 인증 허가

- 원인 특정을 위한 로깅

- 추적

필요

-> 프록시 라는 컴포넌트(container)를 준비하고 서비스에서 통신이 발생할 때마다 이 컨테이너를 경유해서 통신

-> 컨테이너와 프로세스는 하나씩만 매핑되므로, 여기에 사이드카로 이걸 넣는다

이 사이드카로 구성된 프록시가 OSS인 Envoy

Envoy에서는 다음과 같은 기능을 프록시 안에서 ㅅ실행 가능

- logging

- 서킷 브레이커

- 서비스 디스커버리

- 헬스 체크

- LB

- HTTP2/gRPC 지원

- 암호화

--------------

APP Mesh는 이 컨테이너 배치를 구현하기 위해

컨트롤 플레인이 되는 관리형 서비스

트래픽 소스와 타깃으로 ECS / EKS 사용 가능

Fargate 환경 지원 가능

무료 사용

단 배포된 Proxy container에서는 ECS / EKS 컨테이너와 동등하게 과금

[52] "EC2 Launch Type" vs "ECS Fargate"

페페 더 엔지니어 — Tue, 17 Feb 2026 19:50:36 +0900

[0]

	EC2 Launch Type	Fargate
실행 호스트	EC2 직접 운영	AWS가 운영
노드 관리	사용자	AWS가 함
OS 접근	가능	불가
비용 구조	인스턴스 기준	Task 기준
Kubernetes 비유	Self-managed nodes	Serverless nodes

[1]

[2]

스케쥴링 흐름

[3]

런치타입은 인프라 레벨 제어 가능

- SSH 접속

- 로그 파일 확인

- docker ps

- tcpdump

- sysctl 튜닝

FARGATE는 컨테이너만 존재하는 공중부양 실행 환경

[4]

네트워크

ECS Launch Type

bridge / host / awsvpc : ENI 공유 / 분리 선택

FARGATE

awsvpc only

TASK = ENI 1개 / 그래서 Pod처럼 동작

[5]

리소스 할당

[6]

과금 기준

인스턴스 시간 / TASK기준 (Task vCPU + 메모리 + 실헹 시간)

[7]

보안 격리 수준

docker namespace : host 공유 <--------------> MicroVM

거의 VM수준 격리로 멀티테넌시 안전

[8]
Fargate 쓰는 경우

운영 단순화 / 짧은 배치 / 이벤트성 작업 / 소규모 서비스 / Dev and test

Launch Type 쓰는 경우

GPU 필요 / Daemon 필요 / 커널 튜닝 / 고성능 네트워크 / 비용 최적화 (장기실행용)

*EC2 내부 ECS Agent -> docker api에게 task전달 -> Img pull form ECR

Fargate도 동일 흐름이긴 함 / 가시성만 없음