[번외편] AWS NAS 구축 삽질기

 

안녕하세요! AWS NAS 구축 시리즈를 진행하며 예상치 못한 여러 문제에 부딪혔습니다. 이번 포스팅에서는 그 문제들을 어떻게 진단하고 해결했는지, 그 '삽질'의 과정을 기록해보려 합니다.

---

문제 1: User Data 스크립트가 실행되지 않음 (/var/www/html 디렉터리 없음)

 

가장 먼저 부딪힌 큰 문제는, 5편에서 User Data 스크립트를 추가하고 서버를 교체했음에도 불구하고 /var/www/html 디렉터리가 생성되지 않는 현상이었습니다. User Data가 아예 실행되지 않았거나 중간에 실패했다는 신호였죠.

1. 원인 추적 1 (로그 확인): /var/log/cloud-init-output.log 파일을 확인해보니, yum install 같은 스크립트 실행 기록 자체가 없었습니다. User Data가 아예 시작조차 못 한 것으로 판단했습니다.
2. 진단 1: Auto Scaling Group이 User Data가 추가된 최신 버전의 시작 템플릿을 사용하지 않고, 이전 버전을 계속 사용하고 있다는 가설을 세웠습니다.
3. 해결 1: EC2 콘솔의 '시작 템플릿' 메뉴에서 최신 버전을 '기본 버전'으로 명확히 설정하고, 서버를 다시 교체했습니다.

---

문제 2: EFS ID 조회 실패 (AccessDeniedException)

첫 번째 문제를 해결하고 다시 로그를 확인하니, 이번에는 스크립트 실행 중 아래와 같은 권한 오류가 발생했습니다.

An error occurred (AccessDeniedException) when calling the DescribeFileSystems operation...

1. 원인 추적 2: 오류 메시지를 통해 EC2 인스턴스에 연결된 IAM 역할(EC2-EFS-ReadOnly-Role)에 elasticfilesystem:DescribeFileSystems 권한이 없다는 것을 파악했습니다.
2. 진단 2: IAM 역할을 만들 때 실수로 잘못된 권한 정책(ClientReadOnly가 포함된 이름)을 연결했다는 것을 확인했습니다.
3. 해결 2: IAM 콘솔에서 해당 역할을 찾아, 올바른 권한 정책인 AmazonElasticFileSystemReadOnlyAccess로 교체하고 서버를 다시 교체했습니다.

---

문제 3: EFS 마운트 실패 (Failed to resolve...)

IAM 권한 문제까지 해결했지만, 여전히 /var/www/html/nas_storage 디렉터리가 생성되지 않았습니다. 다시 로그를 확인하니 이번에는 EFS 주소를 찾지 못한다는 오류가 보였습니다.

Failed to resolve "fs-xxxx.efs.ap-northeast-2.amazonaws.com"...

1. 원인 추적 3: 이 오류는 VPC 내부에서 DNS 주소 조회가 실패했다는 의미였습니다.
2. 진단 3: VPC 설정 자체에 DNS 확인 기능이 비활성화되어 있다는 것을 문제의 원인으로 특정했습니다.
3. 해결 3: VPC 콘솔에서 nas-vpc의 설정을 편집하여 'DNS 호스트 이름 활성화'와 'DNS 확인 활성화' 옵션을 모두 켜고 서버를 다시 교체했습니다.

DNS 주소 조회를 위해 DNS 활성화

---

문제 4: sudo echo ... > ... 권한 거부

EFS 마운트 성공했지만 Permission denied 오류 발생

EFS 마운트까지 성공한 후, 공유 스토리지 테스트를 위해 파일을 생성하려 했지만 sudo를 사용했음에도 Permission denied 오류가 발생했습니다.

1. 원인 분석: 리눅스의 리디렉션(>) 작동 방식 때문임을 알게 되었습니다. > 기호는 sudo가 권한을 높이기 전에 현재 사용자(ec2-user) 권한으로 파일을 열려고 시도하기 때문에 오류가 발생한 것이었습니다.
2. 해결: 파일 쓰기 작업까지 root 권한으로 실행하기 위해 echo "..." | sudo tee /path/to/file.txt 와 같이 tee 명령어를 사용하는 방식으로 변경하여 문제를 해결했습니다.

---

문제 5: SSH 접속 실패 (Permissions are too open 또는 Permission denied)

Bastion Host나 Private EC2 인스턴스에 SSH로 접속하려 할 때, 키 파일(.pem)의 권한 문제로 접속이 거부되는 경우가 있었습니다. SSH는 보안을 위해 키 파일이 다른 사용자에게 노출되지 않도록 엄격하게 권한이 설정되어 있을 때만 접속을 허용합니다.

• 원인 분석: 다운로드한 .pem 키 파일에 현재 사용자 외에 다른 사용자(예: Administrators 그룹)의 접근 권한이 남아있어서 SSH가 안전하지 않다고 판단했습니다.
• 해결 (Windows 기준):
  1. 파일 탐색기에서 .pem 파일 우클릭 → 속성 → 보안 탭 → 고급 버튼 클릭.
  2. '상속 사용 안 함' 버튼 클릭 → "상속된 사용 권한을 이 개체에 대한 명시적 사용 권한으로 변환합니다." 선택.
  3. 권한 항목 목록에서 현재 로그인한 본인 계정만 남기고 나머지 모든 항목(SYSTEM, Administrators 등) 선택 후 '제거' 버튼 클릭.
  4. 마지막으로 남은 본인 계정을 선택하고 '편집' → '모든 권한' 체크 확인 후 '적용', '확인'.

•  

---

기타 자잘한 삽질들

• 지역(Region) 착각: EFS 생성 시 서울 리전 서브넷이 보이지 않아 당황했는데, 알고 보니 AWS 콘솔 지역이 시드니로 잘못 설정되어 있었습니다. (AWS 작업 전 리전 확인 필수)
• NAT 게이트웨이 생성 순서: IGW를 VPC에 연결하기 전에 NAT 게이트웨이를 만들려고 해서 오류가 발생했습니다. (IGW 연결 → NAT 생성 순서 중요!)

---

배우고 느낀 점

이번 프로젝트를 통해 단순히 AWS 서비스를 사용하는 것을 넘어, 각 서비스가 어떻게 상호작용하고 어떤 권한과 설정이 필요한지 깊이 있게 이해할 수 있었습니다. 특히, 문제가 발생했을 때 로그 파일을 분석하고 원인을 추적하여 해결하는 과정은 정말 값진 경험이었습니다.

클라우드 인프라 구축은 예상치 못한 변수가 많지만, 차분하게 원인을 분석하고 해결해나가는 과정 자체가 엔지니어로서 성장하는 길이라는 것을 깨달았습니다.