About

AWS 기반 운영/기술지원에 강점이 있습니다. IaC(재현성), CI/CD(속도), Observability+RCA(안정성)를 중심으로 “변경은 작게, 기록은 정확히” 원칙으로 재발을 줄이는 운영을 지향합니다.

Skill Map

• Cloud: AWS VPC, EC2/Auto Scaling, ALB, RDS, S3, CloudFront, Route 53, ACM, ECR, EKS, WAF
• IaC/CI/CD: Terraform(모듈화), Jenkins, Argo CD, Git
• Observability: CloudWatch, Prometheus, Grafana(대시보드·알람)
• Ops/Sec: 최소권한 SG, 프라이빗 서브넷, HTTPS 강제, 캐시/Invalidation, 변경관리

Highlights

• 반복 가능한 인프라: CloudFront→ALB(HTTPS)→EC2(ASG)→RDS 아키텍처를 Terraform으로 모듈화
• 자동 배포: Jenkins(빌드)→Argo CD(배포)로 릴리스 절차 표준화
• 관측성 기반 운영: Grafana/Prometheus 대시보드 + 로그 분석으로 이상 조기 탐지
• 대표 성과: 배포 리드타임 수시간 → 수십 분, Webhook 중복 빌드 0건, RCA 정례화로 재발 건수 감소

Projects

TPB — WordPress HTTPS 인프라 (개인, 2025.06–2025.08)

역할: 전체 설계·구현, Terraform 모듈화, 운영 가이드
아키텍처

TLS/ACM 구조

핵심 기여

• VPC/ALB/EC2/ASG/RDS/CloudFront/Route 53/ACM/Bastion 모듈화로 동일 환경 반복 배포
• UserData 자동 설치(Nginx·PHP-FPM·WordPress), HTTP→HTTPS 강제
• 헬스체크·캐시 정책·DNS A(ALIAS) 정합성 확보

운영(선별 스크린)

• VPC & Subnets
• ALB 리스너
• CloudFront 배포/헤더

Troubleshooting (RCA)

• HTTPS 리다이렉션 루프
  원인: 프록시 헤더(X-Forwarded-Proto) 미처리 + 중복 리다이렉션
  조치: Nginx·wp-config 보완, ALB/CloudFront 정책 정리
  재발방지: 배포 체크리스트 항목화(HTTPS 강제/헤더 확인)
• CloudFront 캐시 지연
  원인: TTL 과다·Invalidation 누락
  조치: TTL 합리화 + Invalidation 절차화

결과

• 배포 리드타임 수시간→수십 분, HTTPS 기본화로 안정성·보안 강화
• terraform apply로 리소스 일괄 생성(39 added)

Weasel — AI 문제 해설 서비스 인프라 (팀, 2025.04–2025.07)

역할: Jenkins 전체 관리, 관측성 구축, Terraform 일부 코드화
구성: ECR→EKS, ALB/CloudFront, Jenkins(빌드)→Argo CD(배포), Prometheus/Grafana, CloudWatch

아키텍처

CI/CD 흐름

핵심 기여

• Generic Webhook + 브랜치 필터링으로 main 단일 파이프라인 유지(중복 빌드 제거)
• Grafana 대시보드로 CPU/메모리/지연/에러율 상시 모니터링, Slack 알림 연동

운영 스크린샷

Webhook/필터링 설정(증빙)

Troubleshooting (RCA)

• Jenkins Webhook 다중 실행
  원인: 모든 브랜치 트리거 → 설정에 브랜치 필터링 부재
  조치: JSONPath($.ref) 변수 추출 + 정규식 refs/heads/main으로 main만 빌드
  결과: 불필요 빌드 0건

결과

• 코드 푸시→배포 자동화로 릴리스 속도 및 안정성 개선
• 대시보드/알람 기반 운영으로 탐지→원인 파악 시간 단축

QA & QC 요약

Contact

Email: csb19989@gmail.com

AWS Organizations를 이용해 다중 계정을 중앙에서 관리하기 위해서는 기존에 사용하던 계정 또는 Organizations를 이용해 새로 만든 계정이 필요하다. 이번 포스팅에서는 AWS Organizations에서 계정 생성 후 실수로 잘못 만든 계정을 삭제하려다 발생한 문제와 해결 과정을 정리했다.

📚 참고자료

• AWS 공식 문서: Closing a member account in an organization with AWS Organizations

• AWS 공식 문서 : Enable trusted access for AWS Account Management

배경: 왜 계정 삭제가 필요했는가?

Organizations로 생성한 멤버 계정의 이름을 목표한 조직의 구조와 맞지 않아 편집하려고 했는데 찾기가 어려워 삭제 후 계정 재생성을 하려고 했다.

문제 해결 시도

문제 해결 시도 #1 : 멤버 계정에서 조직 탈퇴 시도 (실패)

• 방금 생성한 계정에 들어가 조직 탈퇴를 눌러봤지만 결제 방법 등록 및 주소 등록 등의 복잡한 절차를 요구해서 1차 실패, 후에 모든 요소 등록 후 재시도 해봤지만 AWS Organizations로 계정 생성 시 AWS는 보안 상의 이유로 일정 기간 동안 조직 탈퇴를 제한해서 실패했다. 조직을 탈퇴하려면 독립적인 계정으로 인정받아야 한다. (standalone)

문제 해결 시도 #2 : 관리 계정에서 Close Account 이용해 삭제 시도

• 관리 계정 AWS Organizations 콘솔에서 삭제할 계정 선택 ➡️ 계정 닫기(Close Account) 클릭

• Close Account 를 하려면 멤버 계정이 결제 및 주소 등록을 마친 상태

  ⚠️ 예상과 다른 결과: 계정은 여전히 존재 계정 상태 : Suspended(중지) 상태로 변경

계정 닫기(Close Account) 기능의 의미

• 계정 닫기는 즉시 삭제가 아닌 90일간 유예 기간을 두고 계정을 비활성화하는 상태

• 이 기간 동안 계정은 비활성화 상태로 유지되고, 필요 시 복구 가능하다. AWS의 과금, 보안, 법적 문제 대비 정책

  ⛔ 즉시 삭제되지 않는 이유 : 청구 및 보안 문제로 인해 계정을 즉시 삭제하지 않음

• 🛠️ 복구

  • 90일 내 AWS Support를 통해 계정 복구 가능

• 90일이 지난 후 계정 삭제

계정 문의 방법

• AWS Organizations의 관리 계정으로 AWS Support에 접속해 문의하면 복구 시켜줌

💡 주의 : Root 계정으로 문의해야 한다.

문제 해결

멤버 계정 이름을 조직 구조에 맞게 변경 시키고 계정을 Suspend 상태에서 복구 요청했다.

계정 이름 변경 방법

관리 계정 ➡️ AWS Organizations ➡️ AWS 계정 ➡️ 멤버 계정 클릭

• 아래쪽에 AWS Account Management의 신뢰할 수 있는 액세스가 활성화되지 않았다는 문구가 뜬다.

AWS Account Management란?

• AWS Organizations 내에서 계정 관리 기능을 확장하기 위해 사용되는 기능

  기능	설명
  계정 이름 변경	멤버 계정의 이름(Name)을 콘솔에서 직접 수정 가능
  이메일 주소 변경	계정의 이메일 주소도 변경 가능 (조건 있음)
  계정 보안 설정 조회	MFA 활성 여부, 루트 계정 로그인 여부 등 확인
  계정 태그 관리	계정에 태그를 달아 분류 및 검색 가능

  • 활성화 하는 법 : AWS Organization ➡️ 서비스 탭에서 AWS Account Management 찾고 클릭 ➡️ 신뢰할 수 있는 액세스 활성화

• 다시 멤버계정에 돌아가보면 아까와 다르게 계정 이름을 업데이트 할 수 있는 작업 버튼이 생겼다.

💡 정리

• Close Account 기능은 계정 삭제를 시키긴 하지만, 90일의 소요 시간이 걸린다.

• 실수 방지를 위한 계정 네이밍 및 메모 전략 또는 네이밍을 잘못했다고 리소스를 지우고 다시 생성하는 습관을 버리자..

이전 글에서는 Assume Role을 이용해 다중 계정 간 리소스를 안전하게 공유하고 권한을 위임하는 방법을 정리했다. 하지만 계정 수가 많아지고 팀/조직 단위로 운영이 복잡해질수록, 단순한 역할 위임만으로는 통합적인 관리가 어려워진다. 이번 시간에는 AWS Organizations라는 계정 중앙 관리 시스템을 이용해 효율적인 계정 통합과 정책 관리를 어떻게 하는지에 대해 정리해보았다.

🔗 관련링크

AWS 계정의 기초 관리

AWS 다중 계정 구조에서 Assume Role로 권한 위임해보기

TroubleShooting-AWS Organizations로 잘못 만든 계정 Closeaccount로 삭제하기

AWS Organizations 개념

AWS Organizations란?

• 여러 개의 AWS 계정을 중앙에서 통합 관리할 수 있는 서비스

• 계정 생성 및 관리, 정책 적용, 액세스 제어 등을 중앙에서 수행 가능

• 하나의 Organization은 하나의 관리 계정과 0개 이상의 멤버 계정으로 구성됨 AWS계정은 단 하나의 Organization 소속만 가능하다.

• Organizations로 생성된 계정은 계정 닫기를 통해 비활성화 후 제거할 수 있다.

계정 닫기(Close Account)란?

AWS Organizations 환경에서 계정 닫기(Close Account)는 다중 계정 운영 시 불필요해진 계정을 안전하게 종료하고 관리 비용을 줄이기 위한 절차

📕 써야 하는 이유

• OU 단위 조직 관리
  계정을 조직 단위(OU)로 그룹화해서 정책을 적용하고 제어 가능

• 비용 통합 관리
  모든 계정의 리소스 사용 비용을 하나의 관리 계정으로 통합 청구

• 보안 정책 일괄 적용
  모든 계정에 대해 SCP(서비스 제어 정책)을 일괄 적용 가능

• 계정 생성 자동화 및 초대
  새 계정을 Organizations에서 간편하게 생성할 수 있고, 새 계정은 OU에 자동 분류가 가능한 서비스가 있다. 기존 계정도 OU에 배치 가능

• 실수 방지 프로덕션 과 개발 계정을 분리하여 실수로 리소스를 삭제하는 사고 예방 가능

조직에서의 팀 단위 계정 설계 예시

• Infra Team, Dev Team , Prod Team으로 분리해서 관리

• Team 별 역할 :

  • Infra Team: 공통 인프라 리소스를 별도 계정에서 관리하여, 운영 환경과의 권한 분리를 실현

  • Dev Team: 개발 전용 계정에서 자유롭게 테스트 및 개발을 수행하면서 운영 계정과 격리

  • Prod Team: 운영 서비스가 배포되는 계정으로, 보안 및 안정성이 중요한 리소스만 존재

AWS Organizations 사용해보기

🧾 준비

AWS Organizations를 쓰려면 계정이 두 개 이상 필요하다. 이때, Gmail의 +기능을 써서 하나의 Gmail 주소로 여러 AWS 계정을 만들어서 이용하는 게 가능하다.

예시 : test@gmail.com ➡️ test+dev@gmail.com 또는 test+prod@gmail.com

AWS는 이걸 각각 다른 이메일로 보고 계정을 만드는게 인정이 된다. 메일은 전부 원래 Gmail 계정으로 온다.

🧪 구성 목표

⚠️ 관리 계정 + 인프라 OU 및 하위 계정 생성

1. AWS Organizations에서 관리 계정(Management Account)을 기준으로 조직을 구성한다.

2. OU(조직 단위, Organizational Unit)를 생성하여 팀 또는 기능 단위로 계정을 분리한다.

3. 인프라 OU를 생성하고, 여기에 로그 관리 전용 계정을 하나 생성하여 소속시킨다.

4. 큰 단위의 인프라팀 OU 와 로그 확인 용도의 계정에 각각 SCP(Service Control Policy)를 적용하여, 어떻게 동작되는지 확인한다.

구성하기

1. 관리 계정 접속 ➡️ AWS 콘솔 ➡️ AWS Organizations ➡️ 조직 생성

2. OU 생성

Root 체크 ➡️ 작업 클릭 ➡️ 새로 생성

• OU 이름 : OU-Infra

3. 계정 추가

• 상단에 있는 AWS 계정 추가 클릭

• AWS 계정 생성에서 정보 입력 기존 계정이 있으면 기존 AWS 계정 초대에서 초대할 수 있다.

Gmail의 Alias 기능을 이용해 자신계정+infra@gmail.com 이런식으로 계정을 생성할 수 있다. 이메일 인증은 자신의 원래 계정으로 오게 된다.

4. 정책 생성

AWS Organizations ➡️ 정책 ➡️ 서비스 제어 정책 ➡️ 서비스 제어 정책 활성화 ➡️ 정책 생성

SCP-OU-Infra

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowBasicInfraServices",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "iam:Get*",
        "iam:List*",
        "logs:*",
        "cloudwatch:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "rds:*",
        "sns:*",
        "sqs:*",
        "cloudtrail:*",
        "kms:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyHighRiskDeleteActions",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUser",
        "iam:DeleteRole",
        "iam:DeletePolicy",
        "s3:DeleteBucket",
        "s3:DeleteObject"
      ],
      "Resource": "*"
    }
  ]
}

SCP-Log-Account

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyLoggingAndAnalysis",
      "Effect": "Allow",
      "Action": [
        "cloudtrail:*",
        "s3:*",
        "glue:*",
        "athena:*",
        "logs:*",
        "config:*",
        "guardduty:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyAllOtherServices",
      "Effect": "Deny",
      "NotAction": [
        "cloudtrail:*",
        "s3:*",
        "glue:*",
        "athena:*",
        "logs:*",
        "config:*",
        "guardduty:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyS3DeleteActions",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

5. 정책연결

만들어진 SCP 정책 또는 OU나 계정에서 정책 연결을 하면된다.

6. 정책 작동 확인

OU-Infra에 속해있는 로그 관리 계정에 접속해 ec2 생성을 하려고 했지만, OU-Infra에는 ec2*(ec2에 관한 모든 행위 허용) SCP가 있어도 로그 관리 계정의 ec2 생성 및 보기 권한이 차단되어있어 접근할 수 없는 것을 확인할 수 있다.

💡 계정에 FullAWSAccess와 사용자 정의 SCP가 모두 연결되어 있더라도, 두 정책의 교집합만 허용되기 때문에 FullAccess 정책의 모든 권한을 사용할 수는 없다.

📓 정리

• AWS Organizations는 여러 AWS 계정을 중앙에서 통합 관리할 수 있게 해주는 서비스로, 대규모 팀 운영에 필수적이다.

• OU(Organizational Unit)를 사용하면 팀, 기능 또는 목적에 따라 계정을 그룹화하고, 각 그룹별로 다른 정책(SCP)을 적용할 수 있다.

• SCP(Service Control Policy)를 통해 각 계정의 권한을 루트 레벨에서 제어할 수 있다. (IAM보다 상위 개념)

• 계정에 두 개 이상의 정책이 모두 연결되어 있더라도, 두 정책의 교집합만 허용되기 때문에 그 중 하나가 FullAccess 정책이라도 모든 권한을 사용할 수는 없다.

• Gmail의 +Alias 기능을 이용하면 하나의 메일 주소로 여러 AWS 계정을 만들어 테스트할 수 있어 비용 없이 학습과 실습이 가능하다.

• 조직 내 각 팀(Infrastructure, Dev, Prod)은 역할과 책임을 분리해 실수 방지와 보안 강화를 도모할 수 있다.

지난 시간에는 IAM User를 통해 관리자 권한을 가진 계정을 만들었다. 이 방식은 소규모 환경에서는 효율적이지만, 팀 단위나 프로젝트 단위로 운영하는 업무 환경에서 하나의 계정으로 모든 리소스를 관리하는 것이 제한적이다. 이번 시간에는 AWS에서 다계정을 운영할 때, 어떻게 리소스를 관리하고 계정 간 권한을 연동하는지에 대해 정리했다.

🔗 관련링크

AWS 계정 생성 후 초기 설정 https://velog.io/@go_sbchi/account-management

환경 구축 - AWS 계정 관리(IAM을 이용해 관리자 계정 만들기) https://velog.io/@go_sbchi/env-aws-iam

다중 계정을 사용하는 이유

각 목적별, 용도별로 팀단위로 묶어서 관리하기 위해서이다.

• 보안과 안정성 하나의 계정으로 모든 것을 관리하게 되면 보안에 취약해지고, 계정을 사용하는 여러 개의 팀중에 하나의 팀만 문제가 생겨도, 전체 시스템에 문제가 생길 수 있기 때문에 분리하여 안정성과 보안을 높인다.

• 비용 관리 비용 청구가 계정 각각에 발생하기 때문에 계정을 사용하는 팀은 다른 팀의 비용청구 내용을 알 필요가 없어서 관리하기 좋다.

• 관리 효율성 각각의 계정별로 리소스나 권한 등을 관리하기 때문에 관리가 편하다.

계정 간 리소스 접근을 하는 방법

팀 단위로 계정을 분리하더라도, 계정 간에 리소스를 공유하거나 접근해야 하는 상황이 발생한다. 이때 사용하는 기능이 Assume Role이다.

Assume Role이란?

다른 계정의 역할을 임시로 해당 계정의 권한을 사용하는 기능

내 계정의 사용자가 다른 계정의 권한을 일시적으로 빌려서 그 계정의 리소스를 사용할 수 있도록 해주는 기능

👉 운영 계정에 로그인한 내가, 개발 계정의 S3 버킷을 잠깐 보고 싶을 때 , 개발 계정에서 운영 계정에서 사용할 수 있게 역할을 설정해 놓으면 운영 계정에서 나는 개발 계정의 역할을 잠깐 빌려와서 S3를 볼 수 있다.

• 이후 원래 계정의 사용자는 다른 계정의 역할이 허용한 범위 내에서 권한 행사

• AWS 콘솔 UI에서 스위칭 가능 AWS 서비스 중 하나인 멀티 세션을 이용하면 세션 만료없이 두개 이상의 계정을 관리할 수 있다.

🧪 구성 흐름

1. A계정에서 로그인 후 역할 생성

2. 멀티 세션을 이용해 A,B 계정 세션 만료 없이 사용

3. 역할 전환으로 B계정으로 A계정 접근

4. B계정으로 접속중인 상태로 A계정에 S3 버킷 생성해보기

📕 Assume Role 활용해보기

💡 계정 구분

A계정 ID : 05**********

B계정 ID : 00**********

1. A계정 접속

• 계정 접속 ➡️ IAM 콘솔에 접속 ➡️ 역할 탭 클릭 ➡️ 역할 생성 ➡️ 다음 클릭

2. 세부 정보 구성하기(역할 생성)

• 엔터티 유형 : AWS 계정
• 아래에 AWS 계정에서 다른 AWS 계정 클릭 : B계정의 계정 ID를 복사 붙여넣기한다. ➡️ 다음 클릭

3. 권한 부여

• 테스트이기 때문에 모든 접근이 가능한 AdministratorAccess를 권한으로 부여했다.

4. 역할 이름 주기 후 완료 클릭

• 역할 이름: aws-multi-account-management

이제 B계정에 만들어진 역할만 넘겨주면 A계정에 접근해 동작시킬 수 있다.

5. 멀티 세션 키기

• 멀티 세션 지원 켜기 클릭 ➡️ 세션 추가 클릭

서로 다른 세션이 켜진게 확인된다.

💡 멀티 세션이란?

• 동시에 여러 개의 세션에 접속 유지 시켜주는 AWS 기능

• 켜져 있지 않으면 브라우저창을 두 개 띄워놓고 각각 다른 계정으로 로그인 해도, 제일 최근에 로그인한 계정으로 두 개다 바뀐다.

6. 역할 전환

• B계정에서 아래쪽에 새 역할 클릭

7. 구성하기(역할 전환)

• Account ID : A계정 ID

• IAM role name : aws-multi-account-management

• Display name - optional : login-beom-account ➡️ 선택사항(별명)

• Display color - optional : Blue ➡️ 선택사항(역할이 무슨 색으로 표시될 것인가)

• 완료되면 Switch Role 클릭

B계정으로 A계정에 접속이 된게 확인된다.

8. S3 생성해보기

A 계정에 접근했으니, 아까 주어진 AdministratorAccess 권한을 활용해 S3 버킷이 A계정에 만들어지는지 확인해보자

• Region : ap-northeast-2 , Seoul로 변경

• 간단한 S3버킷 생성

• 이름 : test-bucket-beom

A계정에 돌아가 확인해 봐도 잘 만들어진게 확인된다.

🧾 정리

• 계정을 분리하면 보안과 비용 관리를 강화되고, Assume Role로 계정 간 권한을 임시 위임해 리소스를 안전하고 효율적으로 공유할 수 있다.

모든 사용자에게 제한 없이 리소스 접근을 허용하면 보안상 큰 문제가 생길 수 있기 때문에, AWS 환경에서는 사용자마다 권한을 명확히 구분하는 것이 매우 중요하다.

이번 실습에서는 하나의 AWS 계정 내에서 IAM 을 이용해 관리자에 해당하는 유저를 만들고 , 필요한 권한을 넣어서 관리자의 권한을 수행하게 했다.

🔗 관련 링크

AWS 계정의 기초 관리

인증과 인가 - IAM의 AWS에서의 역할

🧪 구성 목표

IAM 사용자 생성으로 루트 계정을 대신할 관리자 계정 구성해보기

🛠️ 실습 흐름

1. Root 계정으로 접속 후 IAM 사용자(관리자) 개별 구성

2. IAM Group을 이용해 관리자의 권한을 가지지 않은 계정에 관리자 권한 부여

👤 IAM 권한 부여는 크게 두 가지 방식이 있다.

1️⃣ 개별 사용자에게 직접 권한 부여

1. IAM 사용자 생성하기

• 검색에 IAM 검색 ➡️ 사용자 탭에서 사용자 생성

2. 세부 정보 쓰기

• 사용자 이름: admin

• AWS Management Console에 대한 사용자 액세스 권한 제공 체크

• IAM 사용자 생성 클릭

⚙️ 콘솔 암호의 경우 사용자 지정 암호 설정 시 - 사용자는 다음 로그인 시 새 암호를 생성해야 합니다 체크 해제 선택돼있으면 다음 로그인 때 무조건 다른 비밀번호로 변경해야한다.

• 완료 후 다음 클릭

3. 정책 연결

• 직접 정책 연결 체크 후 권한 정책은 복잡하게 하지 않고, AdministratorAccess를 넣었다.

    * AdministratorAccess란?  : 
  
    모든 서비스(*)의 모든 작업(*)을 모든 리소스(*)에 허용
  
    {
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
    }

4. 관리자 권한의 IAM 계정 생성

• 콘솔 로그인 URL을 통해 로그인을 할 수 있다.

5. 계정 생성 완료

• 🔐 Root 계정에 이어서 추가로 관리자 계정은 보안 강화를 위해 반드시 MFA를 설정한다.

* 특징 

- 사용자 수가 적거나 임시, 테스트용 계정일 때 사용  

- 빠르고 간단하게 권한 부여 가능  

- 사용자가 많아지면 관리가 어려워지고, 권한 변경 시 일일이 수정해야 함

2️⃣ 그룹에 권한 부여 후 사용자 할당

1. 그룹 생성하기

• IAM ➡️ 사용자 그룹 ➡️ 그룹 생성

2. 세부 정보 입력

• 그룹이름 : admin-group

• 그룹 권한 AdministratorAccess

• 클릭 후 생성

(기존에 만들었던 admin IAM 계정은 이미 관리자 권한이 있기때문에 제외하고 그룹만 생성)

3. 새로운 IAM User 하나 생성

• 이름 : no-role-user

기존과 같이 IAM 사용자 생성 클릭 후 다음

4. 그룹에 추가하지 않음

• 권한을 부여하지 않으면 어떤식으로 동작하는지 보기위해 그룹에 넣지않음

아무것도 하지 않고 다음 클릭

5. 사용자 생성

6. 로그인

☁️ ec2를 만드려 했으나 권한이 없으므로 아무 것도 사용할 수가 없다 다시 admin 계정으로 접속 후 그룹에 연결해보자

7. admin으로 접속 후 사용자 그룹에서 사용자 추가 클릭

8. admin group에 no-role-user을 넣어보자

9. no-role-user의 작동 확인

ec2가 정상적으로 만들어지는게 확인된다.

- 여러 사용자나 역할별 권한 관리가 필요할 때 사용  

- 그룹 권한 변경 시 해당 그룹 모든 사용자에게 자동 적용  

- 신규 사용자 추가가 편리하며 관리 효율성이 높음  

- 초기 그룹 설정과 관리가 필요하고, 그룹이 많아지면 복잡해질 수 있음

정리

소수 사용자나 빠른 설정은 개별 권한 부여,

다수의 사용자나 조직 관리는 그룹 기반 권한 관리가 적합하다.

🔍 Intro

AWS 서비스의 가장 큰 장점은 다른 서비스들과의 유기적인 연결이다. 이번 시간에는 ASG와 ELB를 활용해 트래픽 증가에 대응하고, 서비스 안정성을 높이는 방법을 정리했다.

*Auto Scaling 이란? *

Auto Scaling : 서버의 부하에 따라 컴퓨팅 자원을 자동으로 늘리거나 줄이는 기능

• 서버를 사용하려는 사용자가 평소보다 많을 때

  서버에 부하가 발생할 경우, 서버 인스턴스를 자동으로 추가해 서버에 트래픽을 분산시켜서 서비스가 끊기지 않게 한다.

• 서버를 사용하려는 사용자가 평소보다 적을 때

  서비스를 이용하려는 고객이 줄어들어, 부하가 줄면 불필요한 서버를 줄여 비용을 절감한다.

💡 Auto Scaling : 트래픽 변화에 유연하게 대응해 서비스 안정성과 비용 효율성을 동시에 확보하는 기술

• 고가용성 보장 및 장애 대비와 안정적인 서비스 운영

📌

Auto Scaling: 원리

ASG : Auto Scaling 이라는 원리를 AWS에서 실제로 실행하는 도구

💡 AWS 서비스에서 Auto Scaling을 구현하기 위한 기능

1. Launch Template

2. Auto Scaling Group

3. Scaling Policy

AWS에서의 Auto Scaling

1. Launch Template의 기능

• EC2 인스턴스 생성 시 사용할 값들을 미리 정의해 놓고, Auto Scaling으로 인스턴스가 증감할 때에, 템플릿을 기반으로 인스턴스가 생성되게 하는 것

Launch Template 구성 예시

# UserData 작성

#!/bin/bash
yum update -y
amazon-linux-extras install nginx1 -y
systemctl start nginx
systemctl enable nginx

목적에 따른 EC2 인스턴스 선택

🔒 보안 그룹 설정

🎯 Launch Template이 Auto Scaling에서 하는 역할

Auto Scaling Group은 인스턴스를 자동으로 만들고 없애야 하는데, EC2가

무슨 OS를 써야 하고 , 무슨 사양으로 만들어야 하는지를 알아야 되기 때문에,

이걸 미리 정리해둔 Launch Template의 역할이 되게 중요하다.

2. Auto Scaling Group(ASG)란?

• AWS에서 실제로 Auto Scaling을 구현하는 리소스

• 주요 기능

  • 📌 1. EC2 인스턴스를 자동으로 늘리고 줄이며, 원하는 수의 인스턴스를 사용하게 조정

      `CloudWatch 지표를 기반으로 자동 확장도 가능`

  • 📌 2. EC2 자체 헬스 체크 , ELB 헬스 체크로 인스턴스 상태 확인(인스턴스가 죽으면, 종료 후 새로 생성)

  • 📌 3. ASG에 여러 가용영역을 지정하면, 인스턴스를 자동으로 분산 배치해서, 장애 대비

  • 📌 4. 원하는 시간대(Traffic 포화, 비포화 시간)에 미리 맞춰서 인스턴수 수를 변경 가능

3. Scaling Policy란?

• 클라우드 컴퓨팅 환경에서 리소스를 자동으로 조정하는 규칙을 정의하는 정책 ASG가 언제 인스턴스 숫자를 늘리고 줄이지를 정하는 자동화 규칙

• Scaling Policy의 보편적인 3가지 방법

  - Target Tracking : CPU 사용률의 목표치를 정하고 목표치에 근사하게 자동으로 늘리고 줄임

  - Step Tracking : CPU 사용률 올라갈 시 인스턴스를 더 많이 늘림

  - Scheduled Scaling : 정해진 시간에 자동으로 인스턴스 수 조정

• Scaling Policy의 특징

  1. 사용자가 갑자기 많아져도 대응 가능

  2. 트래픽이 적을 땐 자동으로 인스턴스를 줄여 비용 절감

  3. 서버의 증감을 자동으로 해주기 때문에 사람이 직접 서버 수를 늘리거나 줄일 필요없다.

  4. 부하에 대한 대응이 가능하기 때문에 고가용성 확보

Load Balancer란?

Load Balancer : 여러 개의 서버에 들어오는 트래픽을 분산시켜주는 서비스

1. 서버에 들어오는 접속자 수가 갑자기 많아짐

2. 적은 수의 서버로 갑자기 들어오는 트래픽 처리가 어려워짐

3. 서버를 몇개 더 띄워서 트래픽 처리 예정

4. 트래픽 분산을 Load Balancer라는 것을 통해 처리

🔥 Auto Scaling을 통해 인스턴스 수를 자동으로 늘리거나 줄이고, 

여러 대의 인스턴스에 사용자의 요청을 효율적으로 분산시키지 않으면,

트래픽이 특정 인스턴스에 몰려 서버가 과부하가 걸리거나 서비스 장애가 발생할 수 있다.

또한, 인스턴스가 늘고 줄어들 때마다 직접 IP나 주소를 관리하기 위해, Auto Scaling과 함께 ELB를 사용한다.

ELB (Elastic Load Balancer) 란?

• AWS에서 제공하는 로드 밸런서

• 사용자의 요청을 여러 대의 EC2 서버에 분산

• Target Group을 통한 트래픽 분산 : 죽은 서버를 확인하고, 살아있는 서버에만 트래픽 전달

• Auto Scaling과 연결되어 EC2가 늘어나도 자동으로 연결

• 하나의 도메인 주소로 여러 서버 관리 가능

• SSL 인증서를 붙여서 보안 접속 가능 (HTTPS)

👉 보통 사용하는 ELB는 ALB(Application Load Balancer) : 웹 트래픽을 URL, 도메인 기준으로 나눠주는 로드밸런서

ASG와 ELB의 동작 흐름

1. 사용자가 도메인 접속 → 요청은 ELB로 진입

2. Target Group을 참고해서 트래픽을 보낼 대상을 결정

3. Target Group 내부의 헬스 체크 결과를 보고, 이상 없는 대상에게만 트래픽 분산

4. Auto Scaling이 트래픽이나 CPU에 따라 EC2를 자동으로 증가/축소

5. ELB는 새 EC2에 자동 연결, 종료된 인스턴스는 자동 제외

🔗 정리

1. Auto Scaling

서버의 부하에 따라 EC2 인스턴스를 자동으로 늘리거나 줄이는 기능

이를 통해 트래픽 변화에 유연하게 대응하고 비용을 절감한다.

2. Load Balancer

Elastic Load Balancer(ELB)는 여러 서버에 들어오는 트래픽을 분산시켜주는 서비스 사용자 요청을 효율적으로 처리하여 Traffic Jam을 막는다.

3. ASG와 ELB의 사용

ASG와 ELB를 함께 사용하면, ASG가 인스턴스를 자동으로 조정하고, ELB가 트래픽을 이상없는 EC2 인스턴스에 분산시켜 서비스 안정성을 높인다.

4. 헬스 체크와 트래픽 분산

헬스 체크 기능을 통해 비정상 인스턴스를 신속히 감지하고, 문제가 있는 인스턴스를 ASG를 통해 자동으로 교체하거나 트래픽에서 제외하여 안정적인 서비스를 제공한다.

컴퓨터에 네트워크 인터페이스 카드(NIC)가 있어 네트워크에 연결되듯, AWS의 EC2 인스턴스에도 가상 네트워크 인터페이스인 ENI가 부착되는데, 이번 포스팅에서는 ENI의 구성 요소와 역할을 정리하고, 그 과정에서 Elastic IP(EIP)가 어떤 역할을 하며 ENI와 어떻게 연결되는지 정리했다.

🌐 ENI란?

• 물리 서버의 NIC 역할을 하는 EC2의 가상 NIC

    `-> EC2 인스턴스가 VPC 네트워크와 통신하기 위해 사용되는 가상 네트워크 인터페이스`

• 하나의 ENI에는 다음이 포함됨:

  1. MAC 주소
  
  2. 프라이빗 IP 주소
  
  3. 하나 이상의 보안 그룹
  
  4. 탄력적 IP 주소 (선택)

• 하나의 EC2 인스턴스에 여러 개의 ENI 부착 가능

    `하나의 인스턴스가 한 개 이상의 IP 주소를 보유 가능`

• ENI는 다른 인스턴스로 이동 가능

    `1.인스턴스 장애 발생 시 빠른 복구`
    `2.ENI에 고정된 IP, MAC 주소를 그대로 가져가서 새 인스턴스에 붙이면 문제 없이 동작`

• ENI는 인스턴스 종료 시에도 사라지지 않고 독립적으로 존재 가능

ENI 연결 순서

🌐 EIP란?

Elastic IP는 AWS에서 제공하는 고정 IP 주소로, EC2 인스턴스에 연결할 수 있는 서비스다.

✨ ENI에 할당되어 인스턴스가 재부팅되거나 장애가 발생해도 동일한 IP 주소를 유지할 수 있도록 지원한다.

  💡 EC2 인스턴스의 Public IP는 인스턴스를 중지 후 다시 시작할 때마다 퍼블릭 IP가 새로 할당되어 바뀐다. 

       도메인을 Route53같은 서비스로 IP에 부착할때 IP가 유동적이면 연결 시,

       중지가 되면 제대로 도메인에 연결이 안되기 때문에 고정 IP인 EIP를 사용하여 해결할 수 있다.

EIP의 기능

1. 고정 IP 주소

EIP를 사용하면 인스턴스의 IP 주소가 변경되지 않아, DNS 설정이나 외부 시스템과의 연결이 안정적이다.

클라이언트가 특정 IP 주소를 통해 서비스에 접근해야 하는 경우에 유용

2. 장애 조치

인스턴스에 문제가 발생했을 때, EIP를 다른 인스턴스에 쉽게 재할당하여 빠른 복구가 가능하다.

EX :

주 인스턴스에 장애가 발생하면 EIP를 대체 인스턴스에 할당하여 서비스 중단 없이 운영

EIP의 요금

💡 정리

Elastic IP는 ENI와 함께 사용하여 EC2 인스턴스의 외부 접근성(도메인 연결)을 향상시키고, 장애 조치 및 고가용성을 위한 중요한 역할을 한다. EIP를 활용하면 IP 주소의 변동 없이 안정적인 서비스를 제공하고, 인스턴스 장애 시에도 빠르게 복구할 수 있는 유연성을 제공한다.

ENI와 EIP

EIP 요금

AWS에서 가장 기본적이면서도 핵심적인 서비스 중 하나인 EC2에 대해 정리해봤다.

기본적이고 많이 쓰이는 서비스인 만큼, 내가 제대로 이해하고 있는지 다시 한번 점검하는 의미에서 내용을 정리했다.

EC2 란?

안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스

개발자가 더 쉽게 웹 규모의 클라우드 컴퓨팅 작업을 할 수 있도록 설계됐다.

클라우드는 IT 자원을 인터넷을 통해 빌려 쓰는 개념이고,

클라우드 컴퓨팅은 그중에서도 서버, 저장공간, 네트워크 같은 컴퓨팅 자원을 빌려 쓰는 것.

EC2는 그중 '서버(가상 컴퓨터)'를 빌려 쓸 수 있게 해주는 AWS의 서비스다.

📘 EC2의 장점

초 단위 온디맨드 가격 모델

• 온디맨드모델에서는 가격이 초 단위로 결정

• 서비스 요금을 미리 약정하거나 선입금이 필요 없음

빠른 구축 속도와 확장성

• 몇분이면 전 세계에 인스턴스 수백여대를 구축 가능

다양한 구성방법 지원

• 머신러닝, 웹서버, 게임서버, 이미지처리 등 다양한 용도에 최적화된 서버 구성 가능

• 다양한 과금 모델 사용 가능

여러 AWS 서비스와 연동

• 오토스케일링, ELB, CloudWatch 등등 다양한 서비스와 연동가능하다.

EC2 인프라 아키텍처

• 사용자는 AWS 관리 콘솔, CLI 또는 SDK를 통해 AWS에 액세스

• 인스턴스 타입, AMI, 네트워크 설정, 보안 구성 등 모든 필요한 설정을 완료한 후 최종적으로 실행 중인 EC2 인스턴스를 생성한다.

  - AWS 콘솔/CLI: 사용자가 AWS 관리 콘솔 또는 CLI를 통해 EC2 인스턴스 생성을 시작 

  - EC2 인스턴스 설정: 인스턴스 유형, AMI(운영 체제 이미지), 스토리지, 키 페어 등의 옵션 구성

  - 네트워크 및 보안: VPC, 서브넷, 보안 그룹, IAM 역할 등 네트워크와 보안 관련 설정

  - 고급 설정: 사용자 데이터, 테넌시, 메타데이터, 스팟 인스턴스 등 추가적인 구성 옵션을 설정

  - EC2 인스턴스: 구성된 EC2 인스턴스를 실행 중 상태로 배포한다.

  (인스턴스 ID, 퍼블릭/프라이빗 IP 주소 등의 정보를 확인 가능)

인스턴스란?

EC2 서비스를 통해 사용자가 생성하여 실행된 하나의 가상 서버

• 실제 서버처럼 작동

• 물리적으로는 AWS의 데이터 센터 어딘가에 존재

• 사용자는 이 인스턴스를 통해 리눅스/윈도우 서버 운영, 웹 애플리케이션 호스팅, 데이터 처리 등 다양한 작업을 수행

인스턴스 구성 요소

💡 가용영역(AZ)과 인스턴스 위치

• 하나의 EC2 인스턴스는 항상 하나의 가용영역(AZ) 에 생성한다.

• 여러 AZ에 인스턴스를 배포하고 싶다면, 여러 인스턴스를 각각 다른 AZ에 생성해야 하는데, 고가용성(HA)이나 장애 대비 목적이라면, 오토스케일링 그룹과 함께 여러 AZ를 사용하는 구성이 일반적이다.

📌 정리

EC2(Elastic Compute Cloud)

• AWS에서 제공하는 가상 서버를 생성하고 운영할 수 있는 서비스

• 클라우드 컴퓨팅 환경에서 서버를 직접 구축하지 않고도 몇 분 만에 전 세계에 수백 대의 서버 인프라를 구성할 수 있다.

• 온디맨드 과금, 빠른 확장성, 다양한 인스턴스 구성, 다른 AWS 서비스와의 연동이 장점

인스턴스

• EC2를 통해 생성된 하나의 가상 서버로, 사용자는 이 인스턴스를 통해 다양한 애플리케이션을 운영 가능

• 인스턴스는 AMI, 인스턴스 타입, 스토리지, 네트워크, 키 페어 등의 설정으로 구성된다.

• 하나의 인스턴스는 항상 하나의 가용영역(AZ) 에 생성되며, 여러 AZ에 인스턴스를 배포하려면 각 AZ에 별도로 생성해야 한다

• 고가용성 확보와 장애 대비를 위해서는 오토스케일링 그룹(ASG)을 활용해 여러 AZ에 인스턴스를 자동으로 분산 배포하는 구성이 일반적이다.

예) 🏢EC2는 식당
🪑인스턴스는 식당 안의 테이블 하나다.

식당이라는 공간 안에 여러 테이블이 있고, EC2 안에 여러 인스턴스가 생성되어 각자 독립적으로 작동하는 느낌이다..

AWS 계정을 만든 직후 기본 보안, 사용자 관리, 비용 설정을 제대로 하지 않으면 보안 사고나 예상치 못한 과금이 발생할 수 있다.

이 글에서는 AWS 계정을 만든 직후 해야 할 초기 설정을 정리했다.

1. Root 사용자 보안 강화

AWS 계정 생성 시 자동으로 만들어지는 최고 권한 사용자이다.

Root 계정은 모든 AWS 리소스를 삭제하거나 변경할 수 있는 강력한 권한을 갖고 있다.
해킹 시 피해가 크기 때문에 바로 보안 설정을 강화해야 한다.

필수 설정

• ✅ MFA (Multi-Factor Authentication) 설정

MFA는 Google Authenticator, Authy 등의 앱으로 설정 가능

실습

1. AWS 콘솔에 로그인

2. 우측 상단에서 보안 자격 증명(Security credentials) 클릭

3. MFA 활성화 > 가상 MFA 디바이스 설정 선택

2. IAM 사용자 생성 및 권한 분리

Root 계정은 비상시에만 사용하고, 실사용은 IAM 사용자로 진행한다.

IAM은 AWS 리소스를 안전하게 제어하기 위한 사용자 및 권한 관리 시스템이다.

IAM 사용자를 생성해 역할에 맞는 권한을 나누는 것이 필수다.

📌 예시

 💡 IAM 그룹을 활용하면 여러 사용자에게 
    동일한 권한을 제공하는 것을 한 번에 설정할 수 있다.

3. 비용 통제 설정 (프리티어 + 예산 설정)

초기에는 AWS 프리티어로 대부분의 리소스를 무료로 사용할 수 있다.
하지만 잘못 설정하면 금방 요금이 발생하므로 비용 감시 도구 설정은 필수다.

AWS 프리티어란?

• 12개월 무료: EC2, RDS, S3 등 일부 서비스는 가입 후 12개월간 무료

• 항상 무료: Lambda, SNS 등 일부 서비스는 무제한 무료 사용 가능

• ⚠️ 초과 시 과금: 무료 사용량을 초과하면 바로 요금 부과

💡 설정 방법

• AWS Budgets
  예산을 초과하면 이메일로 알림을 받을 수 있음
  Billing > Budgets > Create Budget에서 설정 가능

• Cost Explorer
  서비스별 비용을 시각적으로 분석할 수 있는 도구

1. 콘솔에서 결제 및 비용 관리 검색

2. 좌측 메뉴 → 예산(Budgets) > 예산 생성 Create Budget 클릭

3. 예산 이름: My Zero-Spend Budget, 금액: $1

4. 알림 이메일 설정

5. 저장 후 알림 수신 테스트

**Cost Explorer**에서 서비스별 요금 시각화가능

4. 리전(Region) 확인 및 설정

AWS는 리전(Region) 단위로 리소스를 관리한다.

선택한 리전에 따라 가격, 성능, 서비스 종류가 달라지기 때문에 신중히 선택해야 한다.

AWS 콘솔 우측 상단에서 리전 변경 가능

1. AWS 콘솔 오른쪽 상단에서 ap-northeast-2 (Seoul) 선택

2. EC2 또는 S3를 생성할 때, 현재 선택된 리전이 반영되는지 확인

5. 조직이 커지면? AWS Organizations

여러 계정을 관리해야 할 경우 AWS Organizations를 활용해 중앙에서 통제할 수 있다.

주요 기능 요약

예시 구성

규모가 커질수록 AWS Organizations 구조가 유용해진다.

1. 관리 계정으로 로그인

2. AWS Organizations 검색 > 조직 생성

3. OU (예: dev, prod) 생성

4. 새 계정 추가 또는 기존 계정 초대

5. 각 OU에 계정을 할당하고 SCP 정책 설정

📌 정리

1. Root 계정 MFA 설정 – 해킹 방지를 위해 다중 인증(MFA)을 설정해야 한다

2. IAM 사용자 생성 및 권한 분리 – Root 계정은 잠그고, 역할별 사용자로 안전하게 관리

3. 예산 알림 및 비용 모니터링 설정 – 예상치 못한 과금 방지를 위해 예산 알림을 설정

4. 리전(Region) 확인 및 설정 – 리전을 잘못 설정하면 리소스 위치와 과금에 영향이 있음

5. AWS Organizations 구성 – 여러 계정을 효율적으로 통제하고 관리하기 위한 구조화

블로그 포스팅 초기에 다뤘던 클라우드 컴퓨팅의 대표 서비스인 AWS에 대해 다뤄볼 것이다. 이번 시간에는, AWS의 기본 구조 및 가상화가 무엇인지에 대해 정리해보았다.

가상화란?

하나의 물리적인 컴퓨터 자원을 여러 개의 독립된 가상 환경(가상 머신)으로 분할하여 사용할 수 있게 해주는 기술.

각 가상 머신은 자체 운영체제와 애플리케이션을 실행할 수 있으며, 실제 컴퓨터처럼 동작한다.

장점 : 자원을 효율적으로 활용하고, 시스템 운영의 유연성과 확장성을 높일 수 있다.

☁️ 클라우드 서비스(AWS)는 이 가상화 기술을 바탕으로, 

한 물리 서버에서 여러 사용자가 자원을 나눠 쓰도록 만든다.

가상화를 통해 서버를 효율적으로 운영하고, 필요한 만큼 자원을 빠르게 제공하는 것이 가능해진다.

AWS 구조 이해하기

AWS는 전 세계 어디에서나 안정적으로 서비스를 제공하기 위해 계층적인 인프라 구조를 가지고 있다.

각각의 역할이 뭔지 알아보자

🧾 1. AWS 계정 (Account) : AWS 리소스를 생성하고 관리하기 위한 기본 단위

이 계정을 이용해 사용자는 AWS의 다양한 서비스를 사용할 수 있다. 예를 들어, 과금은 계정 *기준으로 발생, IAM 사용자나 역할 같은 권한 설정도 *계정 내부에서 가능하다.

🌍 2. 리전 : AWS서비스가 제공되는 서버의 물리적인 위치

특징

1. 전 세계에 걸쳐 여러 대륙에 분산되어있다.

2. 리전 간은 서로 독립적이라 장애가 전파되지 않는다.

3. 각 리전은 여러 개의 가용 영역(Availability Zone)으로 구성한다.

4. 리전별로 가능한 서비스가 다르다.

5. 사용자는 원하는 리전을 직접 선택해서 리소스를 배포 가능하다.

⚠️ 리전 선택시 고려할 점

• 지연속도 사용자가 있는 위치에서 가까운 리전을 선택하면 응답 속도가 빨라지고 서비스 체감 품질이 좋아진다.

• 법률

  각 나라별로 데이터 저장과 처리에 관한 법률이 다르기 때문에, 법적 요구사항을 충족하려면 해당 리전에 필요한 AWS 서비스가 제공되는지 반드시 확인해야 한다.

🏢 3. 가용 영역 (Availability Zone, AZ) : 리전 내에 속한 하위 단위로, 하나의 리전은 보통 3개 이상의 가용 영역으로 구성된다.

가용영역의 구성

• 하나 이상의 독립된 데이터 센터로 이루어져 있다.

• 가용 영역 간에는 초고속 전용 네트워크로 연결되어 있다.

• 물리적으로 어느 정도 떨어져 있다. (100km 이내의 거리에 위치)

  여러 재해에 대한 대비 및 보안

이런 구조 덕분에 여러 재해에 대비할 수 있고, 보안성도 강화된다.

가용영역의 위치

안정성을 높이기 위해, 인프라는 반드시 하나 이상의 가용 영역(AZ)에 분산(provision)해야 한다.

각 AWS 계정별로 AZ 코드(예: us-east-1a)가 실제 물리적 위치와 1:1로 일치하지 않는다.

예시그림

UserA가 사용하는 AZ-A와 UserB가 사용하는 AZ-A는 서로 다른 물리적 데이터 센터일 수 있다. AWS에서는 AZ 이름이 계정마다 다르게 매핑되기 때문에, 동일한 AZ 이름이라도 서로 다른 실제 위치일 수 있다.

AWS가 리전 내 AZ 분산을 균형 있게 유지하고, 특정 AZ에 너무 많은 트래픽이 몰리지 않도록 하기 위한 설계다.

리전 안에서의 리소스 배치와 VPC 역할

AWS 계정 아래에는 여러 리전이 있고, 각 리전은 여러 가용 영역으로 구성된다. 가용 영역 내에서는 VPC라는 논리적 네트워크를 통해 리소스(예: EC2, RDS 등)가 운영된다.

엣지 로케이션 (Edge Location)

AWS의 CDN등의 여러 서비스들을 가장 빠른 속도로 제공(캐싱)하기 위한 거점

즉, Global Accelerator와 유저를 연결하는 거점이고, 전세계 여러 장소에 흩어져 있다.

* CDN (Content Delivery Network) : 사용자와 가까운 서버에 웹 콘텐츠를 캐시해, 빠르고 안정적으로 전달하는 서비스

* AWS Global Accelerator: 전 세계에 분산된 AWS 네트워크 인프라를 활용해, 사용자와 애플리케이션 간의 트래픽을 가장 빠르고 안정적인 경로로 최적화하는 서비스

👉 AWS는 엣지 로케이션, 리전, 가용 영역 등 다양한 인프라 구성 요소를 통해 글로벌하게 서비스를 제공한다.

하지만 , 어떤 서비스는 전 세계 어디서나 동일하게 제공되고, 어떤 서비스는 특정 리전에서만 사용할 수 있다. 그래서 AWS는 서비스의 제공 범위에 따라 크게 두 가지로 구분한다.

AWS 서비스 : 글로벌 서비스와 리전 서비스

AWS 서비스에는 서비스가 제공되는 지역의 기반에 따라 글로벌 서비스와 리전 서비스로 분류한다.

글로벌 서비스

데이터 및 서비스를 전 세계의 모든 인프라가 공유

** 예: IAM, Route 53, WAF (웹 방화벽)**

WAF : HTTP 요청을 필터링하는 역할을 한다.

지역 서비스

특정 리전을 기반으로 데이터와 서비스를 제공한다.

대부분의 서비스는 리전 내 여러 가용 영역에서 운영되거나, 하나의 가용 영역에서만 제공된다.

예 : EC2, RDS, S3 등등

ARN

AWS의 리소스에 부여되는 고유 식별자

전 세계 AWS에서 특정 리소스를 정확히 식별할 수 있게 해준다

💡정리

AWS의 구성

• AWS는 여러 리전과 리전 안의 3개 이상의 가용영역, 엣지 로케이션으로 구성

• 리전: AWS서비스가 제공되는 서버의 물리적인 위치

• 가용영역 : 리전 내에 속한 하위 단위로, 하나의 리전은 보통 3개 이상의 가용 영역으로 구성

• 엣지 로케이션 : AWS의 여러 서비스를 빠르게 제공하기 위한(캐싱) 거점

• AWS 서비스는 글로벌 서비스와 리전서비스로 구분

• AWS의 모든 리소스는 ARN(AWS의 리소스에 부여되는 고유 식별자)이 부여

AWS를 본격적으로 다루기 전에, 클라우드 환경에서 보안 관리의 중요성을 먼저 짚고 넘어가야 한다. 이 글에서는 인증(Authentication)과 인가(Authorization)의 개념, 그리고 IAM이 클라우드 보안에서 어떤 역할을 하는지 정리했다.

📚 관련 문서

• What is LDAP? (Lightweight Directory Access Protocol)

• 관리형 정책과 인라인 정책 - AWS 공식 문서

인증과 인가란?

클라우드 보안을 이야기할 때 빠질 수 없는 두 가지 개념이 있다: 인증(Authentication) 과 인가(Authorization) 이다.

• 인증: 시스템에 접근하려는 사용자가 누구인지 확인하는 절차이다. 보통 ID/PW, OTP, 인증서 등을 통해 사용자의 신원을 검증한다.
• 인가: 인증이 완료된 사용자에게 어떤 리소스에 어떤 작업을 허용할지를 결정하는 절차이다. 역할(role), 정책(policy), 권한(permission)을 기반으로 설정된다.

💡 AWS에서는 다음과 같이 구분된다:

• 인증: IAM 사용자가 AWS Management Console에 로그인할 때 ID와 비밀번호 또는 MFA를 입력하는 행위

• 인가: 로그인 후, 사용자가 EC2 인스턴스를 시작할 수 있는지, S3 버킷을 열람할 수 있는지를 IAM 정책(Policy)을 통해 판단한다.

IAM이란?

• IAM(Identity and Access Management)은 AWS에서 인증과 권한을 부여하기 위한 핵심 서비스

• 사용자, 그룹, 역할, 정책을 기반으로 AWS 리소스에 대한 접근 제어를 수행한다.

🔑 주요 개념

• Root 계정: AWS 서비스에 대한 전체 권한을 가진 내장된 계정이다.

  • Root 계정은 사용을 최소화하고, IAM 계정을 만들어 필요한 권한만 부여해 사용하는 것이 보안상 바람직하다.

• 보안 주체(Security Principal): AWS 리소스에 대한 작업을 요청하는 주체로, IAM 사용자, AWS 서비스, 페더레이션 사용자 등을 포함한다.

LDAP, AD, IdP와의 관계

• LDAP: 디렉터리 정보를 검색 및 관리하기 위한 프로토콜이다.
• Active Directory (AD): Microsoft가 개발한 디렉터리 서비스로 LDAP 기반으로 작동한다.
• IdP (Identity Provider): 사용자 인증 및 권한 부여를 제공하는 시스템이다. LDAP을 이용해 사용자 정보를 저장하고 검색할 수 있다.

이들은 서로 포함 관계가 아니라, 인증 구조를 구성하는 서로 다른 역할의 기술들이다.

IAM의 구성 요소

👤 IAM 사용자

• AWS 계정 내 개별 사용자이다.
• 기본적으로 아무런 권한도 없으며, 정책을 통해 명시적으로 권한을 부여해야 한다.

👥 IAM 사용자 그룹

• 여러 사용자를 하나의 그룹으로 묶고, 그룹 단위로 권한을 부여할 수 있다.
• 하나의 사용자는 여러 그룹에 속할 수 있으며, 그룹별 권한을 모두 적용받는다.

🎭 IAM 역할(Role)

• 일시적인 권한을 부여하는 메커니즘이다.

• 사용자는 직접 권한을 갖는 대신, 필요할 때 역할을 수임(AssumeRole) 하여 해당 역할의 권한으로 작업을 수행할 수 있다.

• 역할 수임은 IAM 사용자뿐 아니라 EC2, Lambda 같은 AWS 서비스도 가능하며, 이때 STS(Security Token Service)가 임시 자격 증명을 발급한다.

🌀 역할 수임(AssumeRole) 흐름 예시

1. EC2 인스턴스 또는 IAM 사용자가 역할을 요청

2. AWS STS가 임시 자격 증명을 발급

3. 해당 자격으로 S3 버킷 등 리소스에 접근

IAM 정책

IAM 정책은 어떤 작업을 어떤 리소스에 대해 허용할지를 정의하는 JSON 형식의 문서이다. IAM 정책은 여러 범주로 나뉜다:

자격 증명 기반 정책 (Identity-based Policies)

• 역할 기반 접근 제어(RBAC) 구조를 따른다.
• 관리형 정책: 여러 사용자나 그룹에서 재사용할 수 있도록 AWS 또는 사용자가 생성한 정책이다.
• 인라인 정책: 특정 사용자 또는 역할에 직접 연결되는 1:1 정책이다.

리소스 기반 정책

• S3 버킷, SQS 큐 등 리소스에 직접 연결되어 해당 리소스에 대한 접근 권한을 정의한다.

서비스 제어 정책 (SCP)

• AWS Organizations에서 조직 단위(OU) 또는 계정 단위로 적용되는 정책이다.
• 조직의 최대 권한을 제한하여 보안 수준을 제어한다.

권한 경계 (Permissions Boundary)

• IAM 사용자 또는 역할이 가질 수 있는 최대 권한을 제한한다.
• 개발자에게 자율성을 부여하되, 허용된 범위를 초과하지 않도록 하는 데 유용하다.

🔁 SCP vs 권한 경계

• SCP는 조직 전체 또는 계정 단위로 적용된다.
• 권한 경계는 개별 IAM 사용자나 역할에 적용된다.

🔐 심층 방어 전략 (Defense in Depth)

보안을 하나의 계층이 아닌, 여러 겹으로 구성하는 전략이다. 하나의 계층이 뚫려도 전체가 뚫리지 않도록 방어한다.

• KMS (Key Management Service): 키 페어를 기반으로 데이터 암호화 및 복호화를 수행한다.
• IAM 역할 변경 주의: EC2 인스턴스 등에서 IAM 역할을 실시간으로 삭제/변경하면 곧바로 반영되어 시스템에 영향을 줄 수 있으므로 주의해야 한다.

정리

• 인증은 "이 사용자가 누구인지"를 확인하는 절차이다.
• 인가는 "무엇을 할 수 있는가"를 결정하는 절차이다.
• IAM은 AWS의 핵심 보안 서비스로, 사용자/역할/그룹/정책을 통해 인증과 인가를 관리한다.
• IAM 정책은 자격 증명 기반, 리소스 기반, 서비스 제어 정책, 권한 경계로 나뉘며 각각의 보안 목적에 따라 활용된다.
• IAM은 클라우드 보안을 구성하는 핵심 축이며, KMS, STS와 함께 사용할 때 더욱 강력한 보안 체계를 제공한다.

웹사이트나 애플리케이션을 빠르게 작동시키려면 데이터를 빠르게 불러오는 게 중요하다. 

이때 캐싱이라는 기술이 큰 역할을 한다.

캐싱은 자주 사용하는 데이터를 임시로 저장해두어, 필요할 때 빠르게 꺼내 쓰도록 도와준다.

이번 글에서는 캐싱이 무엇인지, 왜 필요한지에 대해 정리했다.

캐싱

데이터의 복제본 혹은 연산 결과를 임시로 저장해서, 자주 사용되는 복잡한 연산, 자주 찾는 데이터의 결과를 효율적으로 전달하는 것을 목적으로 두는 기술

장점

1. 요청에 따라 빠르게 데이터 전달

2. 복잡한 연산 리소스 / 부하를 줄임

*단점 *

1. 일관성 유지 어려움

2. 아키텍처의 복잡도 증가 (일관성 유지 위함)

3. 비용 증가

캐싱을 사용하지 않는 방식

조회 서버에서 데이버베이스에 대한 작업을 한 후 클라이언트에 정보를 넘기는 시스템

📊 매 조회마다 데이터 수집, 데이터 가공, 데이터 통계, 데이터 리턴이라는 순서를 가지고 조회를 해야함

** 캐시 서버 이용**

조회서버에서 한번 조회한 데이터베이스의 기록을 가공 후 저장해놓은 다음, 클라이언트에서 요청이 일어날때 캐시서버에 저장후 다른 곳에서 요청이 일어나면 캐시서버의 내용을 바로 가져다 씀

💡 장점 : 연산의 부하, 요청의 부하, 네트워크 트래픽 해결

캐싱 주요 개념

*원본 *

- 캐싱할 데이터 혹은 연산 결과를 제공하는 주체

Cache Hit

- 요청에 따라 캐시에 저장된 데이터로 응답할 수 있는 상황

- 캐싱에서 지향할 상황이며 원본에 요청 없이 응답 가능

Cache Miss

- 요청에 따른 데이터를 캐시에서 찾을 수 없는 상황

- 별도로 원본에 요청 혹은 다른 방식으로 응답 필요 

캐시 만료

- 캐시를 삭제하는 행위

- TTL : 캐시가 얼마만큼 살아있는지를 나타내는 시간 단위 ( TTL 10초 : 10초 동안 캐시가 살아잇음)

캐싱 방식

개념

캐시에 원본 데이터를 채우는 다양한 정책

1. Lazy Loading

작동 방식

첫요청이 있으면 조회 서버에서 통계를 만들고, 캐시 서버에 가공 후 저장한다. 그 이후 캐시서버에서 가져와서 사용한다.

💾 단점 : 첫번째 요청에서 엄청난 시간이 걸림

2. Eager Loading

작동 방식

 조회 요청이 없어도 미리 데이터를 조회하고,

 캐시서버에 저장 후 클라이언트 조회 요청에 캐시 서버 조회     

💾 단점 : 요청이 다양한 기간, 분야 등등 다방면에서 오면 효율적일 수 있으나,

특정 기간에 있는 특정 데이터를 가져오는 작업을 할 때에는 효율적이지 않을 수 있다.

3. Write Through

작동 방식

클라이언트에서 이미지 업데이트나 자료 업데이트할 때,

캐시서버와 저장 서버 동시에 자료를 저장할 때 사용

💾 단점: 데이터의 일관성이 항상 보장되지만 쓰기 과정이 복잡해지고 느려질 수 있음

조회를 하기 위한 아키텍처(Write Back)

작동방식

데이터를 캐시에 먼저 쓰고 후에 원본에 업데이트

💾 단점: 쓰기가 빠르고 간단하지만 원본에 업데이트 전에 유실될 가능성이 있다.

💡 결론

1. Lazy Loading : 요청이 있을 때만 캐시에 원본데이터를 채움

   • 불필요한 요청이 줄어들지만 최초 데이터 로딩 필요

2. Eager Loading : 미리 캐시에 데이터를 채워두고 요청을 기다리는 정책

   • 데이터가 항상 준비되어 있지만, 모든 데이터를 채우려면 불필요한 캐시 용량이 낭비되고 처음에 모든 데이터를 채울 때, 매우 큰 리소스가 필요

3. Write Through : 데이터가 변경되거나 저장되는 시점에 원본과 캐시에 동시에 저장

   • 데이터의 일관성이 항상 보장되지만 쓰기 과정이 복잡해지고 느려질 수 있음

4. Write Back : 데이터를 캐시에 먼저 쓰고 후에 원본에 업데이트

   • 쓰기가 빠르고 간단하지만 원본에 업데이트 전에 유실될 가능성이 있음

캐시 만료 방식

1. TTL : 일정 시간이 지나면 만료

• 항상 일정 시간 후 데이터가 만료되고 갱신할 수 있으나 모든 데이터를 항상 갱신 필요

2. Least Recently Used : 가장 사용시점이 먼 캐싱 데이터부터 만료

• 사용이 발생한 데이터들을 계속 보관할 수 있으나 상황에 따라 비효율적일 수 있다.

3. Least Frequently Used : 가장 덜 사용된 데이터부터 만료

• 자주 사용된 데이터를 남겨둘 수 있으나 현재 시점에 자주 사용되지 않는 데이터도 같이 남겨둘 수 있다.

4. First in First Out : 먼저 들어온 데이터부터 만료

• 간단하지만 패턴을 고려하지 않아 비효율적이다.

*캐싱 사용 사례 *

💻 CDN, ElastiCache,웹 브라우저,RAM,DNS 등 연산이나 기록에 대한 저장을 몇일 동안 캐시에 저장해놓는다. (거의 대부분의 경우 TTL의 방식을 사용)

인터넷에서 데이터를 주고받을 때는 정보가 노출되거나 변조될 위험이 있다. 

그걸 방지하기 위해 암호화 기술이 필수적이며, 웹 보안에선 SSL/TLS 프로토콜이 주로 사용된다.

AWS에서도 이런 보안 기능을 지원해 안전한 통신 환경을 제공하는데,

이번 글에서는 AWS에 들어가기 전, 암호화와 SSL/TLS의 기본 개념을 정리했다.

암호화 및 SSL/TLS

암호화

수학적인 과정으로 어떤 정보를 읽을 수 없는 데이터로 변환하는 행위

용어

1. 평문

암호화 하기 전의 데이터

2. 암호문

평문을 암호 키와 알고리즘을 사용해 암호화 한 데이터

3. 암호화

평문에 암호화 알고리즘, 키를 적용하여 소유한 주체가 아니면 알아볼 수 없는 암호문으로 만드는 과정

4. 복호화

암호문에 키와 복호화 알고리즘을 적용하여 평문으로 되돌리는 과정

5. 키

평문을 암호화하거나 암호문을 평문으로 돌리기 위한 비밀번호(값)

6. 암호 알고리즘

암호화/복호화를 위한 알고리즘 (AES/DES)

💡AES/DES?

🔐 DES (Data Encryption Standard) 1. 옛날 방식의 암호화 기술 (1970년)

2. 64비트 블록 단위로 데이터를 암호화

3. Key가 지금 기준으로는 너무 짧아서 쉽게 뚫림

4. 과거에 많이 썼지만, 보안이 약해서 지금은 거의 안 씀

🔐 AES (Advanced Encryption Standard)

1. DES를 대체한 현대적인 암호화 방식

2. AES에 비해 길고 훨씬 안전함

3. 128비트 블록으로 데이터 처리

4. 속도도 빠르고, 스마트폰, 인터넷, 군사 통신 등에서 표준으로 널리 사용

저장된 데이터의 보호

유저가 어플리케이션에 파일을 업로드하면 디스크에 암호화 상태로 저장하고, 복호화시 키가 필요한 기술

💡디스크를 도난당햇을 때 암호화가 되있기 때문에 쉽게 데이터를 열어볼 수 없다.

1. 하나의 물리적인 기기에 보안을 적용하기 위해 사용 2. 키파일 혹은 암호를 사용하여 암호화/복호화

전송 중 데이터 보호

데이터의 전송 중 암호화를 적용하여 데이터가 탈취 되지 않도록 보호

💡주로 여러 시스템/기기 간에 보안을 적용하기 위해 사용

SSL/TLS,HTTPS 등

대칭키 암호화

하나의 키를 암호화, 복호화 하는 알고리즘

• 연산이 빠름
• 키를 전달하는 방법에 대한 고민이 필요함

가정

Bob : 전송자

Alice : 수신자

Chuck : 도청자

Bob과 Alice가 정보를 주고받을 때, Chuck이 중간에 데이터를 빼내면 키만 가지고 있으면 데이터를 복호화 할 수 있는 문제가 있다.

비대칭키 암호화

한 쌍의 키를 활용한 암호화

• 하나의 키는 암호화만 가능하고, 다른 하나는 복호화만 가능

가정

Bob : 전송자

Alice : 수신자

Chuck : 도청자

Bob이 공개키를 통해 자신의 비밀키를 Alice에게 전달하고 Alice는 자신의 키를 통해 복호화를 진행한다. 이 과정에서 Chuck이 공개키를 가지고 있더라도 복호화를 할 수 있는 비밀키가 없기 때문에 복호화를 할 수 없다.

단점

매우 느리다. 그래서 키를 교환하거나 특별한 정보를 교환할 때말고는 대칭키를 사용한다.

암호화 서명

키를 사용해서 데이터의 생성자가 데이터를 생성했음을 보장하는 방법

Private 키를 사용하여 Public 키로 검증 가능한 데이터의 서명을 생성

• Alice가 비밀키를 통해 데이터를 암호화 하고, 복호화 할 수 있는 공개키를 가진 사람(Bob)은 검증을 통해 데이터가 원본인지 아닌지 확인할 수 있다.

AWS 활용

Presigned URL

• 어플리케이션이 가지고 있는 키로 서명(Presigned URL)을 하면 이것을 토대로 S3나 AWS application에 파일을 달라고 검증을 할 수 있다.

SSL/TLS

클라이언트와 서버간에 데이터의 무결성과 기밀성을 보장하는 프로토콜

상호간의 통신 암호화 후 전달되며 중간에서 탈취당해도 안전함

HTTPS등 다양한 프로토콜에 활용

• HTTPS : HTTP + SSL

SSL/TLS 3단계 과정

1. Cipher Suites 교환

* Cipher Suites : TLS에서 활용하는 보안 알고리즘

*클라이언트와 서버가 만나면 정보를 교환함 * 클라이언트 -> 서버

1. SSL/TLS 버전

2. 지원하는 Cipher Suites 목록

3. 기타정보

서버 -> 클라이언트

1. SSL/TLS 버전

2. 지원하는 Cipher Suites 목록

3. 기타정보

4. 인증서

*인증서 : 믿을 수 있는 인증 기관(CA)에서 배포하는 서버 신원에 대한 검증 확인

💡 클라이언트가 서버에 접속할 때 신뢰할 수 있는 서버인지 판단해야 한다. 어떤식으로 인증이 진행되고 있을까?

2. 인증

인증 과정

1. 공신력있는 기관 CA에서 클라이언트와 서버에 CA공개키를 제공

2. 서버에서 공개 키와 비밀키를 만든다.

3. 서버는 서버에 대한 정보와 서버의 공개키를 묶어서 CA에 인증서를 만들어 달라 요청

4. CA에서는 정보에 대한 검증을 끝내고 CA비밀키를 통해 그 정보를 암호화해서 인증서를 발급해줌

5. 서버는 정보를 요청한 클라이언트에 받은 인증서를 건네줌

6. 클라이언트는 암호화 된 정보를 CA 공개키를 사용하여 복호화함

3. 키교환

클라이언트는 서버의 공개키를 사용하여 서버와 통신하고 CA비밀키를 사용해서 RSA를 만들고 서버에서는 공개키와 대응하는 비밀키를 통해 키를 만들고 만들어진 키를 기반으로 통신

 웹사이트에 접속할 때 도메인 주소를 입력하면, 실제 서버의 IP 주소로 연결되는데, 

 도메인과 IP를 연결해주는 역할을 하는 것이 DNS다.

 AWS에서는 이런 DNS 기능을 제공하는 서비스도 운영하고 있고,

 이번 글에서는 AWS에 대해 제대로 공부하기 전, DNS의 기본 개념들과 구조를 간단히 정리해보자

DNS ?

사람이 읽을 수 있는 도메인 이름을 머신이 읽을 수 있는 IP주소로 변환하는 시스템

DNS 주요 개념

    - 도메인 : 대상의 IP 주소등의 정보와 맵핑되는, 사람이 알아볼 수 있는 문자열

        - 서브도메인 : 도메인 중 스트링 앞에 추가 문자열이 붙은 도메인 ex) a.example.com -> (a)

        - APEX도메인(Zone Apex, Root Domain...) : 도메인 중 앞에 추가 문자열이 없는 순수한 최상위 도메인 
        ex) example.com -> (example)

        - 레코드  (DNS Record) : 도메인이 어떤 방식으로 데이터와 매칭되는지 정의하는 기록  ( 주소록의 역할 )

            1. A 레코드
            설명: 도메인 이름을 IPv4 주소에 매핑
            ex)
            example.com → 192.0.2.1

            2. AAAA 레코드
            설명: 도메인 이름을 IPv6 주소에 매핑
            ex)
            example.com → 2001:0db8:85a3:0000:0000:8a2e:0370:7334

            3. CNAME 레코드
            설명: 도메인 이름을 다른 도메인 이름에 매핑
            ex)
            www.example.com → example.com

            4. MX 레코드
            설명: 이메일 서버를 정의
            ex)
             example.com → mail.example.com

        - Domain Zone : 도메인 정보를 담은 레코드 모음

        - Zone File : Domain Zone 정보를 저장한 텍스트 파일

        - DNS Query : 주어진 도메인에 해당하는 정보를 요청하는 쿼리
        ex) example.com이 어떤 IP주소를 가지고 있니? 요청하는 행동

          Name Server : DNS Query를 Zone File을 기반으로 응답할 수 있는 서버
          Authoritative Server : DNS 정보의 원본을 가지고 있는 가장 최상위 NS 서버
          None-Authoritative Server : Authoritative NS Server를 조회하여 
                                      정보를 보관하고 있거나 응답하는 서버

          DNS Resolver : 사용자와 NS 서버 사이에 위치한 서버로 
                           실제 유저의 요청에 따라 IP주소등의 정보를 확보하는 서버                                      

DNS의 구성

DNS는 계층 구조?

    - 최상위 도메인부터 차례대로 계층구조로 구성되어 있음

    - 실제 레코드는 가장 마지막 계층에서 관리(보관 및 처리)

도메인은 . 단위로 상위 레벨로 올라간다는 의미

즉 계층구조로 상위 계층에 하나씩 올라가면서 마지막에 내가 원하는 도메인의 NS서버에 도달해야지만 원하는 정보를 얻을 수 있는 구조이다.

DNS의 계층 구조

1. DNS Root

    - DNS 계층 구조의 최상위 레벨 (DNS Query 수행 시 최초로 조회하는 거점)

    - 다음 단계인 TLDs(Top Level Domain)의 Zone file을 가진 NS서버의 주소 정보 보유

    - Root Hints File

          - DNS Root의 주소를 담은 파일

          - 각 DNS Resolver에 하드코딩되있다.

도메인 조회 과정

도메인 조회는 탑레벨 도메인부터 실제 IP까지 점점 구체적인 정보로 내려가는 계층적 구조를 따른다.

도메인은 어떻게 생겼을까?

예시) www.example.com

com: 탑레벨 도메인 (TLD)

example: 세컨드 레벨 도메인 (SLD)

www: 서브도메인

🔍 도메인 조회

1. 브라우저 → 로컬 DNS 캐시 확인

컴퓨터가 내 컴퓨터, 공유기 안의 캐시에 도메인 정보가 있는지 확인하고,

있으면 IP 주소 반환, 없으면 다음 단계로 넘어간다.

2. 로컬 DNS 서버(보통 ISP)로 요청 인터넷 제공업체(ISP)의 DNS 서버에 example.com이 뭔지 물어보고, 여기도 정보가 없으면, DNS 서버가 직접 루트 네임서버로 요청

3. 루트 네임서버 → TLD 네임서버 안내 루트 네임서버는 요청을 받고,.com을 관리하는 서버에게 물어보고, .com TLD 네임서버의 주소를 알려준다.

4. TLD 네임서버 → SLD 네임서버 안내 .com TLD 네임서버는 example.com을 담당하는 네임서버(NS) 정보를 알려준다.

ex) ns1.exampledns.com ns2.exampledns.com

5. 권한 네임서버(NS) → 실제 IP 주소 반환

브라우저는 이제 ns1.exampledns.com에 접속해서 www.example.com의 IP 주소를 묻는다.

권한 있는 네임서버는 최종적으로 IP 주소를 반환

www.example.com = 192.0.2.10

💡 결론

[브라우저] ↓ 요청 (예: www.example.com) [운영체제의 DNS 캐시] ↓ (없으면) [로컬 DNS 서버 (ISP나 회사의 DNS)] ↓ (없으면 재귀 질의 시작) [루트 네임서버] → .com 어디 있는지 알려줌 ↓ [TLD 네임서버 (.com)] ↓ [권한 네임서버 (예: ns1.exampledns.com)] ↓ [최종 IP 응답: 93.184.216.34]

이전에 OSI 1~4계층에서는 물리적인 연결부터 데이터가 안전하게 전달되기까지의 과정이었다.

OSI 5~7 계층은 사용자와 가장 가까운 영역으로, 

실제 우리가 애플리케이션을 통해 데이터를 주고받는 데 중요한 역할이다.

각각의 계층이 무슨 역할을 하는지 간단하게 살펴보자.

세션 계층

세션계층의 역할 ?

통신 세션의 설정,유지,종료 관리

• 사용자 A와 서버 B가 통신을 시작함

• 중간에 일시적인 장애가 있어도 다시 연결해서 이어가는 방식

• 파일 전송 중에 중단되면 이어서 전송하는 기능 (checkpointing)

세션 : 두 장치 간의 논리적인 연결

HTTP에서 세션레이어의 역할

1. 클라이언트가 서버에 인증요청을 함

2. 서버에서는 클라이언트의 사용자 정보를 쿠키로 만들어서 등록함

3. 컨텐츠 요청을 하면 서버에서는 사용자 정보를 기반으로 인증을 끝내놨기 때문에 IP가 바껴도 인증을 추가로 받지 않음

FTP에서는 세션을 유지하는 세션계층을 구현해놓지 않기 때문에 사용자의 IP상태가 변경되면 검증을 다시 해야한다.

🔍 왜 FTP는 별도로 세션 계층을 구현하지 않았나?

FTP는 TCP 기반이고, 클라이언트가 로그인부터 파일 업로드/다운로드까지 지속적인 제어 연결을 자체적으로 유지

HTTP는 한 번 요청하고 끝나는 구조이기 때문에 세션을 유지하려면 별도의 장치 (예: 쿠키, 세션, 토큰)가 필요

표현 계층

역할 : 받은 데이터를 어떻게 해석할것인가?

• 파싱 , 압축 해제, 복호화 등등 애플리케이션 계층에서 사용할 수 있는 형식으로 변환

응용 계층

역할 : 실제 받은 데이터를 처리하는 방법을 정의 데이터를 가지고 무엇을 어떻게 처리할 것인지?

Ex) HTTP의 경우

• Method(Get/Post/Put 등등...)

• Status Code(2xx,3xx,4xx,5xx)

• Header

  • Host,User-Agent,Authorizations,Accept-Encoding,Content-Type

    이런식으로 데이터를 마지막으로 처리하는 계층이다.

    이전에 살펴본 네트워크 계층은 한 번에 하나의 통신만 처리할 수 있었고, 

    패킷의 순서를 보장하거나 유실에 대응하는 기능이 부족했다.

    이제 이러한 한계를 보완하는 전송 계층에 대해 알아보자.

전송 계층

주요 단위 : 세그먼트

주요 구성요소 : TCP/UDP

🔍 주요 특징 

    1. 여러 애플리케이션 간의 동시 통신 지원

    2. 패킷의 순서 및 신뢰성 보장

     3. 오류 검출 및 재전송 기능 제공

TCP란?

• 패킷의 전달 과정에서 순서를 보장하고 유실되지 않도록 하는 통신 규약 패킷 안에 세그먼트를 담아서, 주고 받으며 로직 처리

  • 지속적으로 무결성 확인

  • 사용사례 : 웹 페이지(HTTP/HTTPS) , 이메일, 파일 전송, SSH 등등...

세그먼트란?

🌟 TCP/UDP의 데이터 전달 단위

주요 구성

- Port : 소스/목적

- Sequence / Acknowledgement Number : 통신 주체끼리 데이터 주고 받았는지 확인하는 용도

- Flags : 세그먼트의 목적 등을 정의(ACK,SYN,FIN) 

- Window Size : 세그먼트를 만든 주체가 얼마만큼의 데이터를 받을지 전달

- Urgent Pointer : 세그먼트의 중요도 설정 (먼저 처리해야 하는 세그먼트는 무엇인가 등등)

- 기타 (checksum 등등)

- 실제 데이터

💻 port ~ CheckSum 까지를 TCP 헤더라고 부른다.

🧑‍ 세그먼트는 그 밑 계층에 있는 3계층의 패킷에 담기게 된다.

🧑‍ 패킷은 프레임에 담기게 된다.

TCP 세그먼트 동작방식

🎯 클라이언트와 서버 간에 세션을 먼저 설정한 뒤, 데이터를 주고받는다. 클라이언트는 여러 연결을 처리하기 위해 동적으로 할당되는 임시 포트 번호를 사용하고 , 서버는 고정된 서비스 포트 번호를 사용한다. 연결 설정 과정은 3-Way Handshake로 구성한다.

3-Way Handshake

1. SYN

   클라이언트가 서버에 연결 요청을 보낼 때, 자신의 초기 시퀀스 번호(CS)를 포함한 SYN 패킷을 전송한다.

   [클라이언트] → [서버]

   (CS = 13)

2. SYN-ACK

   서버는 클라이언트의 SYN에 응답하면서, 자신의 초기 시퀀스 번호(SS)를 포함한 SYN과 클라이언트의 시퀀스 번호 + 1 을 ACK로 포함한 SYN-ACK 패킷을 보낸다.

   [서버] → [클라이언트]

   (SS = 4431, ACK = 14)

3. ACK

   클라이언트는 서버의 시퀀스 번호(SS)에 +1 (4431 + 1 = 4432) 한 값을 ACK로 설정하여 ACK 패킷을 전송한다.

   클라이언트 → 서버

   (CS = 14, ACK = 4432)

UDP란?

- 빠르고 간단하게 데이터를 주고 받음

- Connectionless

    > 데이터의 무결성,순서,전달여부 체크
    > 패킷이 순서대로 오지 않거나, 중복되거나, 아예 전달되지 않을 수 있음
    > 대신에 빠르고 간단함

- 주요 사용 사례

    > 스트리밍
    > 보이스톡
    > 온라인게임

    패킷 하나 정도 유실해도 상관없고, 빠른 처리를 요구할 때 주로 쓰인다.

UDP의 세그먼트는 TCP에 비해 훨씬 간단한게 보인다.

TCP/UDP의 통신 구조

데이터링크 계층에서는 로컬 네트워크 간의 접속만 가능했는데, 

외부 네트워크에 접속하기 위해서는 어떻게 해야할까?

이럴 때 필요한게 3번째인 네트워크 계층이다. 

네트워크 계층

• 여러 노드의 경로를 찾고 올바르게 전달 될 수 있는 기능과 수단을 정의
• 주요 단위 : 패킷
• 주요 구성 요소
  • Router, IP ,ARP
• 주요 특징
  • 서로 떨어진 Local Network간의 통신 지원
    • 중간중간 Node들을 거쳐 목적지까지 도달하는 형식이다.

전세계에 로컬 네트워크가 분포해있고, 모두 인터넷망으로 연결해있다. 그럼 통신 주체를 식별하기 위한 요소인 IP Address가 필요하다.

• IP Address : Internet Protocol상에서 통신 주체를 식별하기 위한 아이디

• IPv4 : 32Bits

• IPv6 : 128Bits IPv4의 경우 아이피를 최대한 활용하기 위해 사설과 공인 IP로 분류하지만, IPv6의 경우 IP의 개수가 너무 많기 때문에 사설 IP의 개념이 불필요하다.

• 특징 : MAC Address와 다르게 수시로 IP는 변동이 가능하다.

  IPv4를 표시하기 위한 방법 중 하나로 CIDR를 사용한다.

• IP는 주소의 영역을 여러 네트워크 영역으로 나누기 위해 IP를 묶는 방식

• 여러 개의 사설망을 구축하기 위해 망을 나누는 방법

CIDR Notation

- 다양한 IP주소들을 통틀어서 표현하기 위함
- 네트워크 주소와 호스트 주소로 구성
- 각 호스트 주소 숫자 만큼의 아이피를 가진 네트워크 망 형성 가능

✅ ex) 192.168.2.0/24

CIDR notation: /24 → 앞 24비트는 네트워크, 뒤 8비트는 호스트

IP 개수: 2⁸ = 256개

범위(CIDR Block): 192.168.2.0 ~ 192.168.2.255

네트워크 비트와 호스트 비트를 분류하는 방법은 CIDR도 있지만 서브넷 마스크라는 것도 활용할 수 있다.

Subnet Mask

- AND 연산을 활용해 네트워크 주소를 필터링한다.
- 네트워크 비트 수만큼 1을 보유한 마스크를 IP에 적용하면 네트워크 비트만 추출

📌 이러한 방식으로 서브넷 마스크를 활용해 네트워크 주소를 추출하면, 네트워크 간의 패킷을 주고 받는다. 이 과정은 라우터라는 장치가 3계층에서 작동하게 된다.

라우터

• 내부와 외부 네트워크 간 IP 변환(NAT) 처리

• 네트워크 간에 데이터를 전달하며, 패킷의 목적지 IP를 기준으로 경로를 결정해 최적의 다음 홉으로 패킷을 전달

  ✅ Route Table을 통해 어떤 경로의 노드를 경우해야 가장 효율적으로 대상에 도착하는지 알고 있다

패킷 전달

1. 라우터가 패킷을 받는다.

• 목적지 IP 192.168.1.10

2. 목적지 IP가 어느 네트워크에 속하는지 라우팅 테이블에서 확인

3. IP가 192.168.1.0/24 대역에 포함되면 로컬 네트워크로 간주

4. 같은 네트워크일 시 로컬 네트워크로 직접 전달

🌐 외부 네트워크인 경우

• 라우터는 패킷을 Frame에 넣어서, 라우팅 테이블에 설정된 다음 홉 라우터(203.0.113.1)로 전달
• 이때, 각 라우터는 다음 홉으로 향하는 최적 경로에 맞게 Frame을 전달하며, 목적지까지 계속 경로를 탐색

📌 Frame에 보내기 위해선 Mac Address를 알아야 되는데 어떻게 알 수 있을까?

라우터는 목적지 IP Address를 알고 있지만, 실제로 패킷을 전송하려면 MAC Address가 필요하다. ARP를 사용해 IP 주소에 대응하는 MAC Address를 찾아낼 수 있다.

ARP?

• IP로 Mac Address를 찾는 프로토콜

⚡ 동작 순서

1. 패킷 전달을 위한 IP 확인

2. 라우터가 네트워크 내의 모든 장치에게 ARP 요청을 브로드캐스트 방식으로 전송

   내용:이 IP 주소에 해당하는 MAC 주소는 무엇인가요?

3. 해당 IP 주소를 가진 장치는 자신의 MAC Address를 포함한 ARP 응답을 라우터에게 보낸다.

   응답: 요청을 보낸 라우터에게만 전달 (유니캐스트 방식)

4. 라우터는 ARP 응답을 받아 해당 IP 주소에 대응하는 MAC 주소를 ARP 캐시에 저장

    이후 동일한 IP 주소에 대해 반복적으로 ARP 요청을 하지 않고, 캐시된 MAC 주소를 사용하여 패킷을 전달

AWS를 깊게 파고들수록 네트워크 지식이 필요하기 때문에 공부내용을 정리했다.

네트워크에서 기본적으로 알고있어야 하는 OSI 7계층에 대해 먼저 정리해보았다.

OSI 7 계층이란?

• 컴퓨터 네트워크 및 통신을 7개의 계층으로 표현한 모델
• 각 계층은 하위 계층의 기능을 활용해 역할을 수행하고 상위 계층으로 처리 결과를 전달
• 낮은 계층 부터 높은 계층 순서로 전달

1계층인 물리 계층에 대해 알아보자

물리 계층이란?

• 장치를 연결하기 위한 매체의 물리적인 사항을 정의

• 주요 단위 : Bits

• 대표 구성 요소 : 케이블/안테나/RF등 전송 매체,허브,리피터

  

주체가 많을수록 네트워크가 복잡해지기 때문에 중앙으로 모아서 연결해주는 장치가 필요하다. 그래서 그 역할을 하는 것이 물리계층에서는 Hub다.

1계층의 네트워크 연결 방식?

Hub란?

물리 계층단위에서 다수의 기기들을 연결해주는 장치

📌 특징

1. 에러/충돌/디바이스 별 제어 기능 없음

2. 받은 신호를 그대로 전달하기 때문에 Broadcast의 형식이다 (확성기의 역할)

Hub의 단점

1. Client가 동시에 얘기를 할 때 충돌을 막을 수 있는 방법이 없다.

2. Client가 다른 대상을 직접 지정해서 연결을 할 수 없다. (Broadcast의 형식이기 때문에)

✅ 이러한 문제를 해결하기 위해서는 데이터링크 계층을 이용해야 한다.

데이터링크 계층이란?

• 물리적인 통신을 제어하여 디바이스간의 통신 및 전송을 안정화 하기 위한 프로토콜

• 주요 단위 : Frame

• 주요 구성 요소 : Mac Address, Switch

• 주요 특징

  • CSMA/CD 방식을 활용해서 각 디바이스간의 통신을 원활하게 연결

  • 대상을 구별하여 디바이스간의 통신을 지원한다(Unicast가 가능하고 Broadcast도 지원)

    💡 CSMA/CD : 신호가 없을 때 데이터를 보내는 방식, 만약 충돌이 일어날 거 같으면 Jamming Signal을 보내 데이터 통신을 대기 시키는 시간을 서로 다르게 줘서 충돌을 피한다.

❗ 데이터 링크 계층에서는 어떻게 주체를 구별할까?

MAC Address
- 네트워크 인터페이스에 부여된 고유의 주소
- 데이터가 지정한 대상에게 잘 전달되게 대상 식별에 사용
예시) 00:1A:2B:3C:4D:5E
첫 3개의 bytes(00:1A:2B) : 제조사에 부여된 고유 식별자
나머지 bytes(3C:4D:5E) : 네트워크 인터페이스 별 고유 번호

네트워크 인터페이스의 MAC Address는 고유의 값이며 변하지 않는다.

2계층의 통신단위 및 통신방식

Frame이란?

- 프레임은 2계층에서 사용하는 일종의 통신단위이다.
- 대상 MAC과 소스 MAC의 정보를 가지고 Payload에 데이터의 내용을 집어넣어 통신을 하는 방식

Switch란?

- 2계층 스위치는 MAC 주소를 기준으로 프레임을 전달하는 장치 
- 같은 네트워크(같은 VLAN) 안에서 장비들끼리 데이터를 주고받게 해주는 역할    

🧠 Switch 안에는 테이블이 있고 각각의 포트별로 MAC Address를 가지고 있고, 프레임을 저장할 수 있는 공간이 있다. 프레임 스토리지에 Frame을 저장해놓고 아무도 통신하지 않을때 전송하는 방식으로 사용 (CSMA/CD)

이 포트폴리오는 인프라/클라우드 엔지니어링 프로젝트별로 목표 → 설계 → 구현 → 결과 중심으로 정리했습니다. 모든 사례는 실제 AWS 환경에서 설계·구축·자동화·운영까지 직접 수행한 결과물입니다.

📑 목차

1. 프로젝트 일정 및 개요
2. 프로젝트별 링크
3. TPB | AWS·Terraform 기반 WordPress HTTPS 인프라
4. Weasel | AI 기반 문제풀이 서비스
5. 연락처

📅 프로젝트 개요

TPB

• 목표: WordPress 운영 인프라를 IaC로 표준화하고 HTTPS/도메인을 포함해 일관된 재현이 가능하도록 구축
• 역할: 인프라 설계·구현·문서화
• 기술: Terraform, AWS (VPC/ALB/EC2/ASG/RDS/CloudFront/Route 53/ACM)

Weasel

• 목표: 문제 이미지 업로드 → AI(Claude 3.5 Sonnet) 해설 제공 서비스의 클라우드 인프라·CI/CD·모니터링 구축
• 역할: 인프라 설계·구현
• 기술: AWS, Terraform, EKS/ECR, Jenkins, ArgoCD, Prometheus, Grafana

🔗 프로젝트별 링크

TPB | AWS·Terraform 기반 WordPress HTTPS 인프라

• GitHub: https://github.com/ChoiSeungBeom/tpb-project
• Velog: https://velog.io/@go_sbchi/tpb-project

Weasel | 문제 이미지 기반 AI 정답·해설 서비스

• GitHub(Org): https://github.com/Team-S5T1
• Velog: https://velog.io/@go_sbchi/weasel-project

QA & QC

TPB | AWS·Terraform 기반 WordPress HTTPS 인프라

개요

AWS에서 CloudFront → ALB(HTTPS) → EC2(ASG) → RDS(MySQL) 아키텍처를 Terraform으로 모듈화해 apply 한 번으로 재현 가능한 WordPress 환경을 구축했습니다. 도메인(Route 53)과 인증서(ACM) 를 포함하여 HTTPS 강제 및 운영 필수 설정을 반영했습니다.

설계 포인트

• 모듈화: VPC, ALB, EC2(Launch Template/ASG/UserData), RDS, CloudFront, Route 53, ACM, Bastion 분리
• 보안: RDS Private Subnet 격리, SG 최소 권한(EC2 SG 참조), Public Access 비활성화
• TLS: CloudFront(us-east-1 ACM) ↔ ALB(ap-northeast-2 ACM) 종단 분리, HTTPS 강제
• DNS: Route 53 A(ALIAs) 로 root/www → CloudFront, origin → ALB

구현

• UserData 로 Nginx·PHP-FPM·WordPress 자동 설치 및 wp-config.php 프록시 인지(X-Forwarded-Proto) 적용
• 헬스체크: Target Group 200–399, /wp-login.php
• 캐시 운용: 기본 캐시 정책 + Invalidation 워크플로우로 변경 반영
• 문서화: 스크린샷/구성도/트러블슈팅 수록

결과

• IaC 표준화로 환경 간 일관성 확보, 휴먼 에러 감소
• 배포 효율 향상(반복 구축 자동화)
• HTTPS 전환/보안 강화 로 운영 안정성 제고

Weasel | 문제 이미지 기반 AI 정답·해설 서비스

개요

사용자가 업로드한 문제 이미지를 AWS Bedrock(Claude 3.5 Sonnet) 으로 분석해 정답·해설·오답 사유를 제공하는 서비스입니다. 인프라 자동화, EKS 배포, CI/CD, 모니터링까지 구축했습니다.

설계 포인트

• IaC 분리: 변동성 기준으로 Terraform 스택을 persistent/dynamic 으로 분리
• 컨테이너 오케스트레이션: ECR → EKS 배포
• CI/CD: Jenkins(빌드) → ArgoCD(배포) 파이프라인
• 관측성: Prometheus/Grafana 대시보드, ALB/CloudFront 로그 쿼리링

결과

• 코드 푸시 → 운영 배포 자동화로 릴리스 리드타임 단축
• 관측성 강화로 장애 감지 및 대응 시간 단축
• 서비스 안정성/확장성 확보

📬 연락처

• Email: csb19989@gmail.com

Weasel 프로젝트는 AWS Bedrock Claude Sonnet 3.5 모델을 활용한 문제풀이 서비스입니다.
사용자가 문제 이미지를 업로드하면 AI가 정답과 해설을 제공합니다. 총 6명 (Frontend 2명, Backend 2명, Infra 2명)이 참여했고, 저는 인프라 팀의 일원으로 프로젝트를 성공적으로 마무리했습니다.

📝 프로젝트 개요

• 목표: 문제 이미지 업로드 → AI 정답·해설 제공 + CI/CD + 모니터링 환경 구성
• 주요 스택:
  • Backend: Spring Boot
  • Frontend: React
  • IaC(인프라 코드화): Terraform
  • 배포 환경: Amazon EKS, S3, Route53, CloudFront
  • AWS 서비스: VPC, ECR, Secrets Manager, WAF
  • CI/CD: Jenkins, ArgoCD
  • GenAI 모델: AWS Bedrock (Claude Sonnet 3.5)
  • 모니터링: Prometheus, Grafana

🔗 GitHub Link

• Weasel - Github

🏗 아키텍처

• AI 처리 흐름: 문제 이미지를 업로드하면 API가 AWS Bedrock(Claude Sonnet 3.5)과 연동되어, 빠르고 정확한 정답·해설을 반환하도록 구성
• CI/CD 자동화: 코드 변경 시 Jenkins가 자동 빌드를 수행하고, ArgoCD로 EKS에 배포하여 배포 속도와 안정성을 높임
• 모니터링: Prometheus와 Grafana로 CPU·메모리 사용량, API 응답 속도, 에러율을 실시간 확인해 장애를 조기 발견
• 보안 및 HTTPS 적용: CloudFront와 WAF를 활용해 전 구간 HTTPS 통신과 웹 공격 방어를 구현
• 인프라 코드화: Terraform으로 인프라를 코드로 관리해, 환경 재현성과 재사용성을 확보

⚙️ CI/CD 아키텍처

백엔드 배포 파이프라인 (Spring Boot → EKS)

1. GitHub에 코드를 올리면 Jenkins가 자동으로 빌드를 시작합니다.
2. 애플리케이션을 빌드하고, Docker 이미지를 만들어 ECR에 저장합니다.
3. ArgoCD가 매니페스트(Helm/Kustomize) 변경 사항을 감지합니다.
4. 변경된 내용을 EKS에 반영하며, 롤링 업데이트 또는 Blue/Green 방식으로 배포합니다.

프론트엔드 배포 파이프라인 (React → S3·CloudFront)

1. GitHub에 코드를 올리면 Jenkins가 프론트엔드 빌드를 실행합니다.
2. 빌드된 정적 파일(build/)을 S3 버킷에 업로드합니다.
3. 배포 시 CloudFront 캐시를 자동 무효화로 최신 파일을 받을 수 있게 구성했습니다.

Jenkins 빌드 파이프라인 실행 화면

📢 배포 알림 자동화

• Jenkins 빌드 완료 후 Slack Webhook을 통해 성공/실패 여부 실시간 알림
• 백엔드·프론트엔드 각각 별도 파이프라인으로 빌드 상태 확인 가능
• 알림 메시지에 Jenkins Job URL을 포함해 즉시 로그·상태 확인 가능

Jenkins 빌드 성공 시 Slack 채널에 실시간 알림

💻 서비스 화면

문제 이미지를 업로드할 수 있는 입력 UI 및 채팅 내용 저장

업로드한 문제 이미지에 대해 AI가 정답과 해설을 반환하는 화면

📊 모니터링

Grafana 대시보드

Prometheus와 Grafana를 활용해 CPU·메모리 사용량, API 응답 속도, 에러율 등을 실시간으로 모니터링했습니다. 이를 통해 성능 저하나 장애 징후를 조기에 발견하고 신속히 대응할 수 있었습니다.

⚠️ 트러블슈팅 : Node.js Dockerfile 최적화

문제

• Dockerfile이 개발 환경과 프로덕션 환경 구분 없이 작성되어 최종 이미지에 불필요한 개발 도구와 의존성이 포함됨
• 빌드 과정 없이 바로 실행해 최적화가 전혀 이루어지지 않음
• 실행 명령어(npm run dev)가 개발 환경 기준으로 설정되어 프로덕션에 적합하지 않음

원인

1. 베이스 이미지
   • node:20.14.0 이미지는 개발 도구가 포함되어 최종 이미지 크기가 커짐
2. 빌드 과정 누락
   • 최적화된 빌드 산출물이 아닌 원본 소스 코드로 실행
3. 실행 명령어 부적절
   • npm run dev → 개발 의존성(devDependencies)까지 포함 설치
   • 프로덕션에서는 npm start 사용이 적합

해결

• 이미지 최적화: 빌드 단계와 배포 단계를 분리 (multi-stage build)
• 슬림 이미지 사용: 프로덕션 단계에서 node:<버전>-slim 사용
• 빌드 명령어 추가: RUN yarn build로 프로덕션 빌드 생성
• 실행 명령어 변경: CMD ["npm", "start"]로 프로덕션 실행

변경 전/후 비교

변경 전

FROM node:20.14.0

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
RUN yarn install

COPY . .

EXPOSE 3000
CMD ["npm", "run", "dev"]

변경 후 (Multi-stage build)

# 빌드 단계
FROM node:20.14.0 AS builder
WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

# 프로덕션 단계
FROM node:20.14.0-slim
WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --production --frozen-lockfile
COPY --from=builder /usr/src/app/dist ./dist

EXPOSE 3000
CMD ["npm", "start"]

효과

• 이미지 크기 감소: 불필요한 개발 도구/의존성 제거
• 실행 효율 향상: 최적화된 빌드 결과물만 배포
• 환경 분리: 개발/배포 환경 명확하게 구분

⚠️ 트러블슈팅 : Jenkins 파이프라인 브랜치 필터링

문제

• 메인 브랜치에 병합하기 전에 생성된 브랜치에서 push 시에도 Jenkins 파이프라인이 실행됨
• main 브랜치 변경 시에만 파이프라인이 동작하도록 제어 필요

원인

• 기존 설정(GitHub hook trigger for GITScm polling)은 모든 브랜치 변경 시 파이프라인이 실행됨
• 브랜치 조건 필터링 로직이 없어 main 외 브랜치에서도 빌드가 수행됨

해결

1. Plugin 변경

• GitHub hook trigger for GITScm polling → Generic Webhook Trigger

2. Build Triggers 설정

• 기존: GitHub hook trigger for GITScm polling
• 변경: Generic Webhook Trigger

3. Post Content Parameters

1. genericVariables
   • key: 'ref', value: '$.ref' 설정
   • JSONPath($.ref)로 웹훅 페이로드에서 브랜치 정보 추출 후 변수 ref에 저장
2. regexpFilterText
   • $ref로 설정 → 추출된 브랜치 정보(ref)를 필터 텍스트로 사용
3. regexpFilterExpression
   • 'refs/heads/main' 지정 → main 브랜치일 때만 빌드 실행

4. Optional filter

• Text: ref 변수 값
• Expression: refs/heads/main

웹훅 설정

• Payload URL

  http://<도메인 또는 IP>/generic-webhook-trigger/invoke?token=<토큰>
  
  

• Content type: application/json

변경 전/후 비교

💡 마무리

Weasel 프로젝트를 통해 팀원 간 소통과 협력의 중요성을 깊이 느꼈습니다. 첫 팀 프로젝트였던 만큼 부족한 점도 많았지만, 개인 프로젝트에서는 드러나지 않았던 보안 관리, 운영 안정성, 배포 효율성의 한계를 체감했습니다. 이를 해결하기 위해 CI/CD 파이프라인을 최적화해 배포 속도를 개선하고, Grafana·Prometheus 기반 모니터링 환경을 구축해 장애 발생 시 신속하게 대응할 수 있는 체계를 마련하는 등 많은 것을 배웠습니다.

부족하다 느낀점

향후에는 비용 효율성을 위해 Jenkins Fleet을 도입해, 빌드 시에만 에이전트를 동적으로 생성하고 사용 후 자동 종료하는 방식으로 EC2 비용을 절감하는 방안도 고려하고 있습니다. 앞으로도 IaC 기반 클라우드 아키텍처 설계 역량을 확장해, 대규모 트래픽 환경에서도 안정적이고 효율적인 서비스를 운영할 수 있는 체계를 구축하는 것을 목표로 하겠습니다.