<aside>
CloudWave · W05 · 1/5 · 예상 읽기 7분
</aside>
처음 AWS 권한을 배울 때 가장 헷갈린 질문은 “로그인하면 무엇이든 할 수 있는가?”였다. 답은 주체가 누구인지와 어떤 정책이 적용되는지에 달려 있었다. 네트워크도 마찬가지였다. VPC를 만들었다고 연결이 자동으로 열리는 것이 아니라, 경로와 허용 규칙이 함께 맞아야 했다.
루트 사용자는 계정의 시작점이지만 일상 작업의 주체로 삼지 않는 편이 안전하다. IAM user를 무조건 늘리는 대신 역할과 임시 자격 증명을 우선하면 자격 증명이 오래 남는 위험을 줄일 수 있다. 역할은 필요한 주체가 승인된 시간 동안 맡는 권한 묶음이며, AWS 서비스나 외부 인증 흐름에서도 활용된다.
정책은 누가 무엇을 어떤 리소스에 할 수 있는지 표현한다. Allow가 있다고 항상 허용되는 것은 아니며 명시적 Deny, 조직의 제어 정책, 권한 경계가 함께 평가될 수 있다. 공개 글에서는 실제 계정이나 ARN을 쓰지 않고 example-app과 demo-bucket 같은 가상 이름으로 흐름만 설명해야 한다.
VPC 안에서도 서브넷은 배치 범위를 나누고 라우팅 테이블은 목적지에 따른 다음 경로를 정한다. 인터넷 게이트웨이, NAT, VPN 같은 대상이 달라지면 같은 기본 경로도 의미가 달라진다. 보안 그룹과 네트워크 ACL은 경로 자체가 아니라 트래픽을 허용하거나 제한하는 별도 층이다. 그래서 접속 실패를 보면 주소만 확인하지 말고 경로와 규칙을 함께 본다.
Local은 개인의 빠른 확인, Dev는 통합, QA는 품질 검증, Staging은 운영과 가까운 최종 리허설, Production은 실제 사용자 제공이라는 역할 차이가 있다. 환경마다 역할과 데이터 접근을 분리하면 실수의 범위를 줄일 수 있다. 실습 구성은 개념 확인용이고 운영에서는 감사 로그, 승인, 복구와 고가용성을 추가로 설계해야 한다.
배포 파이프라인은 사람의 장기 자격 증명보다 역할을 통해 필요한 작업만 수행하게 만드는 편이 낫다. 네트워크도 애플리케이션이 필요한 방향만 열고, 운영 환경에는 더 엄격한 조건과 검토를 둔다. 권한 정책은 처음부터 넓게 주고 나중에 줄이는 방식보다 실제 호출을 관찰하며 필요한 동작만 남기는 방식이 검토하기 쉽다.
VPC는 방화벽 하나가 아니며 IAM은 네트워크 접근 제어가 아니다. 또 IAM user보다 role이 항상 자동으로 안전한 것도 아니다. 신뢰 정책, 세션 수명, 로그와 회수 절차가 함께 있어야 한다.
AWS의 첫 설계는 서비스를 고르는 일이 아니라 권한과 네트워크의 경계를 정하는 일이다.