2026년 1월 8일 목요일

EBS 볼륨 확장 정리: 수동 확장부터 자동 확장, 모니터링까지 (Linux 기준)

Amazon Web Services에서 EC2 인스턴스를 운영하다 보면 EBS 볼륨 용량을 늘려야 하는 상황은 자주 발생합니다.

하지만 EBS 볼륨 크기를 늘렸다고 해서 파일 시스템이 자동으로 확장되지는 않습니다.
볼륨 확장 이후에는 파일 시스템 크기 조정 작업을 반드시 추가로 수행해야 실제로 디스크 용량을 사용할 수 있습니다.

이 글은 EBS 볼륨 확장 이후 Linux 인스턴스에서 파일 시스템을 확장하는 전체 흐름을
실무 기준으로 정리한 메모입니다.

먼저 알아두어야 할 점 (중요)

EBS 볼륨이 optimizing 상태가 되자마자 파일 시스템 확장은 바로 시작 가능
중요한 데이터가 있는 볼륨이라면 사전에 스냅샷 생성 권장
Linux AMI가 MBR 파티션 테이블을 사용하는 경우
- 부팅 볼륨 최대 크기: 2TiB 제한
파티션이 있는 경우
- 볼륨 크기 증가 ≠ 파티션 크기 증가

Linux 파일 시스템 확장 전체 흐름

Linux에서 EBS 볼륨 확장은 항상 다음 순서를 따릅니다.

EBS 볼륨 크기 증가 (AWS 콘솔 또는 CLI)
파티션이 있는지 확인
(필요 시) 파티션 크기 확장
파일 시스템 확장

사전 확인: 파일 시스템과 디바이스 구조

파일 시스템 확인


df -hT

블록 디바이스 및 파티션 구조 확인


lsblk

이 두 명령으로 다음을 확인합니다.

파일 시스템 종류 (xfs / ext4 등)
파티션 존재 여부
볼륨 크기와 파티션 크기 차이

예제 1: NVMe EBS 볼륨 (Nitro 기반 인스턴스)

예: M5, C5, T3 등 Nitro 시스템

Root 볼륨: 8GB → 16GB

추가 볼륨: 8GB → 30GB

1️⃣ 현재 파일 시스템 확인


df -hT

예시 출력:


Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  xfs   8.0G  1.6G  6.5G  20% /
/dev/nvme1n1    xfs   8.0G   33M  8.0G   1% /data

2️⃣ 파티션 존재 여부 확인


lsblk


nvme0n1       16G disk
└─nvme0n1p1    8G part /
nvme1n1       30G disk /data

해석:

/dev/nvme0n1 (루트 볼륨)
- 파티션 있음 → 파티션 확장 필요
/dev/nvme1n1 (추가 볼륨)
- 파티션 없음 → 바로 파일 시스템 확장 가능

3️⃣ 파티션 확장 (파티션이 있는 경우만)


sudo growpart /dev/nvme0n1 1

⚠️ 디바이스 이름과 파티션 번호 사이에 공백 필요

확인:


lsblk

4️⃣ 파일 시스템 확장

XFS 파일 시스템


sudo xfs_growfs -d /
sudo xfs_growfs -d /data

XFS는 마운트 상태에서도 확장 가능

필요 시 도구 설치:


sudo yum install -y xfsprogs

ext4 파일 시스템


sudo resize2fs /dev/nvme0n1p1
sudo resize2fs /dev/nvme1n1

5️⃣ 확장 결과 확인


df -h


/dev/nvme0n1p1   16G   15G /
/dev/nvme1n1     30G   30G /data

예제 2: 기존 Xen 기반 인스턴스 (xvd 디바이스)

예: T2 인스턴스

Root 볼륨: 8GB → 16GB

추가 볼륨: 8GB → 30GB

1️⃣ 디바이스 구조 확인


lsblk


xvda    16G disk
└─xvda1  8G part /
xvdf    30G disk
└─xvdf1  8G part /data

→ 두 볼륨 모두 파티션 확장 필요

2️⃣ 파티션 확장


sudo growpart /dev/xvda 1
sudo growpart /dev/xvdf 1

3️⃣ 파일 시스템 확장

XFS


sudo xfs_growfs -d /
sudo xfs_growfs -d /data

ext4


sudo resize2fs /dev/xvda1
sudo resize2fs /dev/xvdf1

4️⃣ 최종 확인


df -h

자주 헷갈리는 포인트 정리

볼륨 크기만 늘리고 끝내면 안 됨
파티션이 있으면 growpart 먼저
XFS vs ext4 명령 다름
optimizing 상태에서도 파일 시스템 확장 가능
운영 환경에서는 스냅샷 먼저

마무리

EBS 볼륨 확장은 자주 하는 작업이지만,
파일 시스템 확장 단계를 빼먹으면 실제 용량은 늘어나지 않습니다.

(추가) EBS 볼륨 자동 확장 방법 정리

AWS에서는 별도의 중단 없이 EBS 볼륨 크기를 조정할 수 있는
Elastic Volumes 기능을 제공합니다.

이를 활용하면 운영 중에도 볼륨 크기 확장이 가능하며,
여기에 간단한 자동화와 모니터링을 조합하면 사실상 자동 확장 구조를 만들 수 있습니다.

Elastic Volumes 개요

인스턴스 중지 없이 EBS 볼륨 크기 변경 가능
optimizing 상태에서도 I/O 가능
대부분의 최신 인스턴스 타입에서 기본 지원

📌 단, 파일 시스템 확장은 여전히 OS 레벨에서 수행해야 합니다.

자동 확장 설계 패턴 (실무 기준)

패턴 1: CloudWatch + Lambda 기반 자동 확장 (가장 일반적)

구성 흐름

CloudWatch에서 디스크 사용률 모니터링
임계치 초과 시 Lambda 트리거
Lambda가 EBS 볼륨 크기 확장
인스턴스 내부에서 파일 시스템 확장 수행


CloudWatch → Alarm → Lambda → ModifyVolume(EBS)
                              ↓
                      OS 파일 시스템 확장

CloudWatch 모니터링 설정

EBS는 기본적으로 볼륨 사용률(filesystem usage) 을 직접 제공하지 않습니다.
따라서 인스턴스 내부 지표를 CloudWatch로 올려야 합니다.

1️⃣ CloudWatch Agent 설치 (Linux)


sudo yum install -y amazon-cloudwatch-agent

2️⃣ 디스크 사용률 수집 설정 예시


{
  "metrics": {
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "disk": {
        "measurement": [
          "used_percent"
        ],
        "resources": [
          "/",
          "/data"
        ]
      }
    }
  }
}

적용:


sudo amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
  -s

3️⃣ CloudWatch Alarm 설정

예시:

Metric: disk_used_percent
Threshold: 80%
Period: 5분
Action: Lambda 트리거

Lambda를 이용한 EBS 볼륨 자동 확장

Lambda 로직 개념

현재 볼륨 크기 조회
일정 비율(예: +20%)로 확장
최대 크기 제한 적용 (예: 500GB)

의사 코드 예시


new_size = int(current_size * 1.2)

if new_size <= MAX_SIZE:
    modify_volume(volume_id, new_size)

📌 중요

Lambda는 EBS 크기만 늘림
파일 시스템 확장은 별도 처리 필요

파일 시스템 자동 확장 방법

방법 1: cron + growpart + filesystem 명령 (가장 단순)

예시 스크립트:


#!/bin/bash

growpart /dev/nvme0n1 1
xfs_growfs -d /

cron 등록:


*/5 * * * * root /usr/local/bin/fs-grow.sh

볼륨이 확장되면 다음 주기에 자동 반영됨

방법 2: systemd 서비스 + udev (조금 더 깔끔)

볼륨 크기 변경 이벤트 감지
systemd unit으로 growfs 실행
cron보다 중복 실행 리스크 적음

(이건 환경에 따라 복잡도가 올라가서 필요할 때만 추천)

운영 시 주의사항 (자동 확장)

❌ 자동 축소는 불가
❌ 무한 확장 방지 필요 (상한선 필수)
✅ 사전 스냅샷 또는 정기 백업 권장
✅ 알람은 “확장 성공/실패”도 함께 설정

모니터링 요약 정리

항목	방법
디스크 사용률	CloudWatch Agent
확장 트리거	CloudWatch Alarm
볼륨 확장	Lambda (ModifyVolume)
파일 시스템	cron / systemd
알림	SNS 연계

정리

EBS는 Elastic Volumes 덕분에 온라인 확장이 가능
파일 시스템 확장은 여전히 OS 레벨 작업
CloudWatch + Lambda + 간단한 스크립트로
운영 부담 없는 자동 확장 구조 구성 가능
“완전 자동”보다는
모니터링 + 제한된 자동화가 가장 안전한 패턴

참고 자료 (AWS 공식 문서)

이 글에서 정리한 내용은 실제 운영 경험을 바탕으로 작성했으며,
아래 Amazon Web Services 공식 문서를 함께 참고하면
각 환경별 세부 사항을 더 정확하게 확인할 수 있습니다.

EBS 볼륨 확장 및 파일 시스템 관련

Amazon EBS 볼륨 크기 조정
- https://docs.aws.amazon.com/ko_kr/ebs/latest/userguide/ebs-modify-volume.html
- EBS Elastic Volumes 개념 및 온라인 확장 가능 여부 설명
Linux 인스턴스에서 EBS 볼륨 파일 시스템 확장
- https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
- 파티션 여부 확인, growpart, 파일 시스템 확장 절차
NVMe 기반 EBS 볼륨 설명
- https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html
- Nitro 인스턴스에서 NVMe 디바이스 명명 규칙

자동 확장 및 모니터링 관련

EC2 인스턴스 스토리지 옵션
- https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/Storage.html
- 인스턴스 중지 없이 볼륨 확장 가능
CloudWatch Agent 설치 및 설정
- https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
- 디스크 사용률 수집 설정
CloudWatch 지표 및 알람 구성
- https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
- Alarm + SNS 연계
EBS ModifyVolume API
- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html
- Lambda를 이용한 볼륨 크기 확장 시 사용

스냅샷 및 백업

Amazon EBS 스냅샷 생성
- https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
- 확장 작업 전 롤백 대비용 스냅샷

AWS Client VPN + Keycloak SSO 구축 (NameID 이메일, Redirect URI 포함)

Keycloak과 AWS Client VPN SAML 연동 구성 가이드 (실무 기준)

8년 만에 다시 기술 블로그 포스팅을 시작해보려고 합니다.

그동안 협업 프로젝트를 진행하면서 여러 인프라와 인증 구성을 직접 만들었지만,
정리하지 못한 채 넘어간 경우가 많았습니다.
이번에는 제가 실제로 구성하고, 삽질하고, 운영까지 고려했던 내용들을 정리하는 목적으로 다시 기록을 남기려 합니다.

첫 번째 주제는 AWS Client VPN입니다.

왜 AWS Client VPN + Keycloak인가?

AWS Client VPN은 기본적으로 다음 두 가지 인증 방식만 제공합니다.

인증서 기반 인증
IAM 기반 인증

하지만 실제 기업 환경에서는 보안팀에서 다음과 같은 요구사항을 제시하는 경우가 많습니다.

MFA 필수
중앙 인증 체계(IdP) 연동
사용자 / 그룹 기반 접근 제어
계정 수명 및 정책 통합 관리

AWS Client VPN 자체 기능만으로는 이를 만족시키기 어렵습니다.
그래서 선택한 방식이 Keycloak을 IdP로 사용한 SAML 연동이었습니다.

검색해보면 관련 자료가 많지 않고,
GPT나 Gemini를 활용해도 처음에는 구조가 잘 와닿지 않았습니다.
이 글은 그런 시행착오를 줄이기 위한 실무 기준 정리입니다.

이 글에서 다루는 내용

Keycloak ↔ AWS Client VPN SAML 연동 구성
이메일 기반 NameID 인증 방식
실제 사용자 접속 흐름
AWS Client VPN의 제약 사항
운영 관점의 장단점 및 확장 포인트

전체 아키텍처 개요

인증 및 접속 흐름

사용자가 AWS Client VPN 애플리케이션 실행
VPN 연결 시 브라우저가 자동으로 열리며 SAML 인증 요청
Keycloak에서 사용자 인증 (ID / Password / MFA)
AWS Client VPN Endpoint가 SAML Assertion 검증
인증 성공 시 VPC 내부 리소스 접근

구성 요소 요약

구성 요소	역할
Keycloak	SAML Identity Provider (IdP)
AWS IAM	SAML Provider 및 Role 관리
AWS Client VPN	VPN Endpoint 및 인증 처리
AWS Client VPN App	사용자 접속 전용 클라이언트

1. Keycloak 설정

1.1 Realm 생성

Realm Name: aws-clientvpn

VPN 인증 전용 Realm을 분리하면 다음과 같은 장점이 있습니다.

인증 정책 분리
MFA 정책 관리 용이
사용자 / 그룹 관리 단순화

1.2 SAML Client 생성

항목	값
Client ID	`urn:amazon:webservices:clientvpn`
Client Protocol	`saml`
Access Type	`public`
Enabled	`On`

⚠️ Client ID는 변경할 수 없습니다.
AWS Client VPN은 해당 URN 값을 고정으로 사용합니다.

1.3 Client Settings

항목	값
Root URL	비워둠
Valid Redirect URIs	`*`
Master SAML Processing URL	비워둠
IDP-Initiated SSO URL Name	선택 사항

Redirect URI에 `*`가 필요한 이유

AWS Client VPN 인증 과정에서는 로컬 콜백 주소를 사용합니다.


http://127.0.0.1:35001

이 주소는 사전에 고정 등록이 불가능하기 때문에
Valid Redirect URIs에 와일드카드(*) 설정이 필수입니다.

1.4 NameID Mapper 설정 (중요)

AWS Client VPN은 NameID 값을 기준으로 사용자를 식별합니다.

항목	값
Mapper Type	User Property
Property	email
SAML NameID Format	`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
SAML Attribute Statement	Off

📌 이메일 기반 NameID가 아니면 인증 실패 가능성이 매우 높습니다.
Keycloak 사용자 계정에 반드시 email 값이 존재해야 합니다.

2. AWS 설정

2.1 IAM SAML Identity Provider 생성

Provider Name: keycloak-clientvpn
Metadata: Keycloak Client의 SAML Metadata XML

경로:


Keycloak → Client → SAML Metadata

2.2 IAM Role 생성 (SAML Federation)

Trusted Entity

SAML 2.0 federation
Provider: keycloak-clientvpn

Condition


{
  "StringEquals": {
    "SAML:aud": "urn:amazon:webservices:clientvpn"
  }
}

권한

VPN 사용에 필요한 VPC 접근 최소 권한 정책 적용

2.3 Client VPN Endpoint 생성

항목	값
Authentication	SAML-based authentication
SAML Provider	keycloak-clientvpn
IAM Role	위에서 생성한 Role

3. Client 접속 방식 (중요)

AWS Client VPN App 필수

⚠️ AWS Client VPN은 일반 OpenVPN 클라이언트로 정상 동작하지 않습니다.

반드시 AWS 공식 Client VPN Desktop Application을 사용해야 합니다.

지원 OS
- Windows
- macOS

사용자 접속 흐름

AWS Client VPN App 실행
.ovpn 파일 로드
Connect 클릭
브라우저 자동 실행
Keycloak 로그인 (MFA 포함 가능)
인증 완료 후 VPN 연결

4. 단점 및 제약 사항

❌ 모바일 환경 미지원

Android / iOS용 AWS Client VPN 앱 없음
모바일 기기에서 VPN 접속 불가
BYOD, 모바일 중심 업무 환경에는 부적합

❌ 클라이언트 의존성

AWS Client VPN 전용 애플리케이션 필수
OpenVPN, Tunnelblick 등 서드파티 클라이언트 사용 불가

5. 트러블슈팅

오류: `수신된 자격 증명이 잘못되었습니다`

확인해야 할 항목:

Valid Redirect URIs가 *로 설정되어 있는지
NameID Mapper가 email 기반인지
Client ID가 urn:amazon:webservices:clientvpn인지
IAM Role의 SAML:aud 조건이 정확한지
Keycloak 사용자 계정에 email 값이 존재하는지

6. 운영 시 확장 포인트

Keycloak 그룹 기반 접근 제어

그룹별 IAM Role 분리
부서 또는 권한 단위 VPN 접근 제어 가능

MFA 연동

OTP, WebAuthn 등 Keycloak MFA 정책 적용
VPN 접속 시 추가 인증 단계 제공

로그 중앙화

Keycloak Audit Log
AWS CloudWatch Logs 연계

마무리

Keycloak과 AWS Client VPN을 SAML 방식으로 연동하면
IAM User 없이도 중앙 인증 기반 VPN 접근 제어가 가능합니다.

보안성과 운영 편의성 측면에서는 매우 강력한 구성입니다.
다만 모바일 미지원과 AWS 전용 클라이언트 의존성은
도입 전에 반드시 고려해야 할 요소입니다.

2026년 1월 8일 목요일

EBS 볼륨 확장 정리: 수동 확장부터 자동 확장, 모니터링까지 (Linux 기준)

먼저 알아두어야 할 점 (중요)

Linux 파일 시스템 확장 전체 흐름

사전 확인: 파일 시스템과 디바이스 구조

파일 시스템 확인

블록 디바이스 및 파티션 구조 확인

예제 1: NVMe EBS 볼륨 (Nitro 기반 인스턴스)

1️⃣ 현재 파일 시스템 확인

2️⃣ 파티션 존재 여부 확인

3️⃣ 파티션 확장 (파티션이 있는 경우만)

4️⃣ 파일 시스템 확장

XFS 파일 시스템

ext4 파일 시스템

5️⃣ 확장 결과 확인

예제 2: 기존 Xen 기반 인스턴스 (xvd 디바이스)

1️⃣ 디바이스 구조 확인

2️⃣ 파티션 확장

3️⃣ 파일 시스템 확장

XFS

ext4

4️⃣ 최종 확인

자주 헷갈리는 포인트 정리

마무리

(추가) EBS 볼륨 자동 확장 방법 정리

Elastic Volumes 개요

자동 확장 설계 패턴 (실무 기준)

패턴 1: CloudWatch + Lambda 기반 자동 확장 (가장 일반적)

구성 흐름

CloudWatch 모니터링 설정

1️⃣ CloudWatch Agent 설치 (Linux)

2️⃣ 디스크 사용률 수집 설정 예시

3️⃣ CloudWatch Alarm 설정

Lambda를 이용한 EBS 볼륨 자동 확장

Lambda 로직 개념

의사 코드 예시

파일 시스템 자동 확장 방법

방법 1: cron + growpart + filesystem 명령 (가장 단순)

방법 2: systemd 서비스 + udev (조금 더 깔끔)

운영 시 주의사항 (자동 확장)

모니터링 요약 정리

정리

참고 자료 (AWS 공식 문서)

EBS 볼륨 확장 및 파일 시스템 관련

자동 확장 및 모니터링 관련

스냅샷 및 백업

AWS Client VPN + Keycloak SSO 구축 (NameID 이메일, Redirect URI 포함)

Keycloak과 AWS Client VPN SAML 연동 구성 가이드 (실무 기준)

왜 AWS Client VPN + Keycloak인가?

이 글에서 다루는 내용

전체 아키텍처 개요

인증 및 접속 흐름

구성 요소 요약

1. Keycloak 설정

1.1 Realm 생성

1.2 SAML Client 생성

1.3 Client Settings

Redirect URI에 *가 필요한 이유

1.4 NameID Mapper 설정 (중요)

2. AWS 설정

2.1 IAM SAML Identity Provider 생성

2.2 IAM Role 생성 (SAML Federation)

2.3 Client VPN Endpoint 생성

3. Client 접속 방식 (중요)

AWS Client VPN App 필수

사용자 접속 흐름

4. 단점 및 제약 사항

❌ 모바일 환경 미지원

❌ 클라이언트 의존성

5. 트러블슈팅

오류: 수신된 자격 증명이 잘못되었습니다

6. 운영 시 확장 포인트

Keycloak 그룹 기반 접근 제어

MFA 연동

로그 중앙화

마무리

EBS 볼륨 확장 정리: 수동 확장부터 자동 확장, 모니터링까지 (Linux 기준)

Redirect URI에 `*`가 필요한 이유

오류: `수신된 자격 증명이 잘못되었습니다`