Introduction to the AWS Management Console

AWS에 로그인할 때는 계정의 AWS 루트 사용자에 대한 주요 특성으로 인해 개인이 아닌 그룹이 엑세스할 수 있는 이메일 주소를 사용하는 것이 좋다. 여기서의 주요 특성이란, 루트 사용자가 AWS 계정 내에서 절대적인, 무소불위의 권한을 가진다는 점을 말한다. 이는 IAM 정책이나 경계로도 제한할 수 없다. 이처럼 루트 사용자 계정이 너무나 강력하기 때문에, 이를 개인에게 종속시키지 않고 그룹 이메일로 관리해야 보안 및 운영상의 이점을 얻는다. 

 

① 담당자가 퇴사하거나 부서를 이동해도, 해당 이메일은 계속 존재하며, 팀 전체가 계정 복구 및 긴급 접근을 할 수 있다.

② 이메일 접근 권한을 소수의 신뢰받는 관리자 그룹에게만 부여하여, 루트 계정 자격 증명에 대한 접근을 엄격히 통제할 수 있다.

③ 루트 계정이 잠기거나 암호 재설정이 필요할 때, 팀 멤버 누구라도 해당 이메일로 접근하여 신속하게 문제를 해결할 수 있다.

 

즉, AWS 루트 사용자는 계정의 핵심 마스터 키와 같으므로, 개인이 아닌 조직의 통제 하에 안전하게 보관하고 공유된 책임으로 관리하기 위해 그룹 이메일을 사용해야 한다는 것이다. 루트 사용자로는 일상적인 작업을 수행하지 않고, 일상 업무는 최소 권한의 IAM 사용자를 만들어 사용해야 한다.

 

③을 부연설명하면, AWS 계정과 연결된 이메일 주소에 대한 엑세스 권한을 상실하면, 암호를 분실한 경우 계정에 대한 엑세스 권한을 복구할 수 없다. AWS로부터 오는 암호 재설정 링크를 수신 및 확인할 수 있는 방법이 완전히 사라지게 되는 것이다. 이 경우, 관리자나 그룹의 IAM 사용자는 정상적으로 접근할 수 있지만, 계정 폐쇄나 지원 플랜 변경 등 루트 사용자만이 할 수 있는 핵심 관리 작업을 영구적으로 수행할 수 없게 되는 심각한 문제가 발생하는 것이다.

콘솔에 로그인하면 Add Widgets을 통해 원하는 위젯을 추가할 수 있으며, 제거하고 싶으면  ︙를 클릭하여 Remove 할 수 있다. 위젯을 재정렬하고 싶으면 클릭하여 옮기면 되고, 사이즈는 ︙에서 Change size를 통해 조절할 수 있다. 여기서 Explore AWS와 같은 일부 위젯은 크기 변경을 지원하지 않는다. 최초로 들어가려면 위 사진의 Reset을 클릭하면 된다.

 

AWS 콘솔에는 개별 서비스 콘솔로 이동하는 여러가지 방법이 있다.

 

검색창에 입력하는 방법

최근 사용 명단에서 클릭하는 방법

All services를 클릭하여 확인하는 방법

탐색 모음에서 Services를 클릭하여 전체 서비스 목록을 여는 방법 등이 있다.

 

물론 자주 사용하는 서비스는 최근 사용 목록에 뜨겠지만, Favorite에 저장하는 것도 방법이다. Favorite은 브라우저 쿠키에 저장되어 있고, 콘솔 세션 사이에 쿠키를 삭제하면 Favorite 목록이 지워진다. 일반적으로 브라우저에서 AWS 콘솔에 로그인한 후 로그아웃해도, 브라우저가 이 쿠키를 유지하고 있기 때문에 다음에 다시 로그인하면 이전에 설정했던 Favorite 목록이 그대로 보인다. 즉, 동일한 브라우저에서 AWS 계정 A에 로그인했다가 로그아웃하고 계정 B에 로그인해, Favorite 목록은 동일하게 보인다. 이는 해당 목록이 AWS 계정 자체가 아니라 브라우저에 저장된 정보이기 때문이다. 바꿔 말하면, 같은 계정을 쓰더라도 Favorite은 각각 다르다. 이 Favorite을 보기 위해서는 위젯에서 추가해야 한다. 그럼 제일 하단에 위치해 있을 것이다. 그럼 끌어올려 편한 위치에 두면 된다.

 

Favorite에 서비스를 추가하기 위해서는 탐색 목록에서 서비스 왼쪽에 커서를 대고 별표를 활성화한다. 주황색 별이 된다면 Favorite에 포함된 것이다.

 

AWS 콘솔에서 서비스를 선택할 때는 AWS 리전의 영향을 이해하는 것이 중요하다. 이 '리전'은 AWS 데이터 센터에서 클라우드 인프라 구축에 사용되는 하드웨어가 들어 있는 격리된 지리적 영역이다.  

 

서비스를 선택할 때는 서비스를 사용할 수 있는 리전과 고객에게 가장 가까운 리전을 선택하는 것이 제일 좋다. 고객과 가까워야 지연 시간을 줄이는 데 도움이 되기 때문이다. 선택하는 리전이 사용 가능한 서비스, 서비스 비용 및 사용자에 대한 지연 시간에 영향을 미친다는 점을 이해해야 한다. 그러나 리전은 데이터 보안, 데이터 엑세스, 저장 가능한 데이터 양에는 영향을 미치지 않는다. 또한, 리전 데이터 규정 준수는 법적 이유로 특정 데이터를 특정 리전에 유지할 것을 의무화한다. 

 

그러나 이것은 어디까지나 '기본적인 관점'에서 해석했을 때의 의미다. 실질적으로 따르면 리전은 데이터 보안, 데이터 엑세스, 저장 가능한 데이터 양에는 영향을 미친다고 할 수 있다.

① 데이터 보안: 컴플라이언스는 보안의 필수 요소이며, 리전이 데이터 주권 법규를 결정하므로, 법적/규제적 보안 측면에서는 리전이 결정적인 영향을 미친다. 

② 데이터 엑세스: 지연 시간은 데이터에 접근하는 실질적인 품질이며, 고객 경험 측면에서 매우 중요하다. 느린 액세스는 곧 불량한 액세스와 같다고 할 수 있다.

③ 저장 가능한 데이터 양: AWS는 서비스별로 리전당 할당량을 설정한다. 특정 리전에 배포할 수 있는 EC2 인스턴스, 볼륨, 또는 특정 서비스 자원의 양에는 상한선이 있다. 따라서 실제 운영 규모 측면에서는 리전이 용량에 영향을 미친다.

일부 서비스는 특정 리전에서 제공되지 않는다. 위 사진의 좌측은 모든 서비스가 이용 가능한 경우고, 우측에서는 회색 부분은 서비스가 제공이 되지 않는 것이다. 일부 AWS 서비스가 특정 리전에서 제공되지 않는 주된 이유는 시장 수요, 규제 준수, 그리고 물리적 인프라 요구 사항 및 비용 효율성 등의 사유 때문이다.

 

 

AWS 리전은 가용 영역(AZ)으로 알려진 격리된 위치 2곳 이상으로 구성된다. 가용 영역은 지연 시간과 중복성이 매우 낮은 건물(데이터 센터)의 소규모 캠퍼스로 구성된다. 이 모든 것은 서로, 그리고 인터넷과 연결되어 있기 때문에 지진과 같이 모두가 공유하는 상황이나 발전기 등 일반적 장애 지점에 따라 동시에 영향을 받지 않는다. 

 

AWS 리전은 서비스의 고가용성과 재해 복구 능력을 보장하기 위해 설계된 지리적 단위이다. AZ 간에는 충분한 거리를 두어(수 킬로미터), 지진, 홍수, 화재 등 지역적인 자연재해가 발생하더라도 모든 AZ가 동시에 영향을 받지 않도록 하고, 각 AZ는 자체적으로 독립된 전력, 냉각 시스템, 네트워크 연결을 갖는다. AZ들은 서로를, 그리고 인터넷을 초고속의 전용 사설 네트워크 링크로 연결하고, 이는 지연 시간이 매우 낮아(밀리초 미만) 고객이 여러 AZ에 걸쳐 애플리케이션을 배포해도 하나의 통합된 데이터 센터처럼 작동할 수 있게 한다. 고객은 이 독립된 AZ들을 활용하여 웹 서버, 데이터베이스 등을 최소 2개 이상의 AZ에 분산 배치한다. 이를 Redundancy라 하며, 만약 한 AZ가 완전히 다운되더라도 나머지 AZ가 트래픽을 인수하여 서비스의 지속적인 가용성을 유지한다.

AWS는 종량제로 결제한다. 장기 계약이나 복잡한 라이선스 없이 사용 기간 동안 필요한 개별 서비스에 대해서만 요금을 지불한다는 것이다. 종량제 모델에서는 예측이 아닌 수요에 따라 비즈니스를 조정하기 때문에 용량을 과도하게 프로비저닝하거나 누락하는 위험을 줄일 수 있다.

 

정액제를 통한 비용 절감은 AWS 사용 요금을 크게 절감할 수 있는 유연한 요금제로, Saving Plans 가입 기간은 1년 또는 3년이며, AWS Cost Explorer에서 권장사항, 성능 보고, 예산 알림 등을 통해 요금제를 관리할 수 있다. 2년 이상 지속되는 프로젝트에 인스턴스를 사용하는 경우, 이를 위해서는 2년 동안 일정한 사용량을 약정해야 할 것이다.

 

신규 AWS 고객의 경우, 클라우드 시작을 지원하기 위해 최대 1년 간 무료 사용 등급(AWS 프리 티어)를 제공받을 수 있다. 서비스가 프로덕션, 비프로덕션에 사용되는지 여부는 프리 티어 제공에 영향을 미치지 않는다.

프리티어는 위의 3가지 종류가 있는데, 물론 전자가 제일 많다. 상시 무료 제공의 경우, 기본 구성 및 할당량을 기반으로 하는 경우가 많다. 프리 티어 12개월 제공의 경우, 당연하게도 고성능 컴퓨팅 인스턴스는 제외된다.

 

유료로 넘어가게 되면, 선택하는 사항, 서비스가 청구에 어떤 영향을 미치는지 알아야 한다. 예시로, EC2 인스턴스를 중지하면, 볼륨 리소스에 대해 계속 요금이 부과되지만, 컴퓨팅 리소스는 비용이 부과되지 않는다. AWS Cost Explorer를 통해 그러한 AWS 비용 및 사용량을 확인하고 분석해야 한다.

그리고 비용은 리전에 따라서도 다르다. 애플리케이션이 미국과 아일랜드에서 AWS lambda를 사용하면 요금은 동일하다. 그야 미국의 lambda 비용과 아일랜드의 lambda 비용이 동일하기 때문이다. 

 

하지만 애플리케이션이 홍콩에서 AWS lambda를 사용하면 요금이 더 높은 것을 볼 수 있다. 마찬가지로, Kinesis Data Stream의 경우 프랑크푸르트에서 사용하는 것이 미국에서 사용하는 것보다 저렴하다. 따라서 모든 서비스와 리전을 고려하여 AWS 서비스의 실제 총 비용을 결정하는 것이 매우 중요하다.

 

서비스마다 글로벌 옵션이 있는 게 있고 아닌 게 있다. 모든 서비스가 글로벌 서비스인 것은 아니기 때문이다. 글로벌 서비스인 경우 몇 개의 리전에 몇 개의 인스턴스가 있는지 확인 가능하다. 이걸 확인하면 다음의 이점이 생긴다.

 

① 비용 및 리소스 관리 효율성 향상: 어느 리전에 인스턴스가 몰려 있는지 파악하면 불필요한 리전 사용이나 중복 리소스를 제거할 수 있다. 예를 들어, 테스트 서버가 여러 리전에 중복 생성돼 있다면, 그걸 한 리전으로 통합해 비용 절감이 가능하다.

② 보안 거버넌스 및 컴플라이언스 점검: 일부 규제(개인정보보호, 금융 관련 규제 등)는 데이터가 특정 리전 내에만 존재해야 함을 요구한다.리전별 인스턴스 현황을 확인하면, 데이터 주권 위반 여부를 빠르게 점검할 수 있다. 또한, 사용하지 않는 리전에 노출된 자원을 찾아 공격표면을 줄일 수도 있다. 

③ 장애 대응(BCP, DR) 설계 검증: 리전별로 인스턴스가 얼마나 분산돼 있는지를 알면, 이중화 구조(High Availability) 또는 재해복구(Disaster Recovery) 설계가 제대로 되어 있는지 검증할 수 있다. 예를 들어, 서울 리전 장애 시 도쿄 리전에서 서비스 가능한가?를 실제 인스턴스 분포로 확인 가능하다는 것이다.

④ 운영 가시성 확보 및 자동화 근거 확보: 글로벌 규모의 계정이나 조직에서는 자원이 수 백~수 천 개로 늘어난다. 각 리전의 인스턴스 수를 주기적으로 모니터링하면, 자동 스케일링 정책을 검증하고, 비정상 리전 사용 감지 등에 활용할 수 있다.

⑤ 비용 이상 징후 탐지: 갑자기 특정 리전의 인스턴스 수가 증가하면, 그건 곧 해킹이나 설정 오류로 인한 비정상 인스턴스 생성을 의미하는 것일 수 있다. 즉, 리전별 리소스 현황은 CloudTrail, Cost Explorer와 함께 보안 모니터링 지표로도 쓸 수 있다는 것이다.

 

글로벌 서비스가 아닌 리전 서비스의 경우, 직접 한 번에 인스턴스 개수 확인이 불가하므로, 각 리전별로 따로 관리해야 한다. AWS의 구조상 대부분 서비스(EC2, RDS, S3 등)는 리전 단위로 완전히 분리된 인프라로 설계되어 있다. 그러니까 서울 리전(ap-northeast-2)의 EC2 인스턴스는 버지니아 리전(us-east-1)과 완전히 별개라는 것이다. 심지어 내부 DB, API 엔드포인트, IAM 역할 매핑도 리전별로 다르게 관리된다.