AWS 글로벌 인프라와 계정 기초

글로벌 인프라 — 리전, 가용 영역, 그리고 그 바깥

AWS의 물리 인프라는 세 겹으로 되어 있습니다. 리소스를 실제로 실행하는 리전과 가용 영역, 리전보다 사용자에게 더 가까이 컴퓨팅을 밀어 넣는 로컬 존과 Wavelength 존, 그리고 콘텐츠를 캐시해 응답하는 엣지 네트워크입니다. 시험 문항은 요구사항의 성격으로 이 셋 중 하나를 지목합니다.

리전 — 격리의 기본 단위

리전은 지리적으로 분리된 영역이며, 각 리전은 독립적으로 동작합니다. 기본적으로 리소스는 리전 밖으로 복제되지 않고, API 호출도 리전 엔드포인트로 나뉩니다. 리전 간 복제는 우리가 명시적으로 구성해야 일어납니다 — Amazon S3 교차 리전 복제, Amazon RDS 스냅샷 복사, Amazon DynamoDB 글로벌 테이블이 모두 그런 예입니다.

이 격리는 규정 준수 요구사항을 만족시키는 근거가 됩니다. "데이터가 국경을 넘어서는 안 된다"는 조건이 붙으면, 답은 리전을 고정하고 리전 간 복제를 켜지 않는 설계입니다.

계정 수준에서 리전은 활성화 상태를 가집니다. 오래된 리전은 기본으로 켜져 있지만 (ENABLED_BY_DEFAULT), 나중에 추가된 리전은 계정에서 옵트인해야 사용할 수 있습니다. 쓰지 않는 리전을 꺼 두는 것 자체가 공격 표면을 줄이는 통제입니다.

가용 영역 — 데이터센터 한 동이 아니다 SAA 빈출

가용 영역(Availability Zone, AZ)은 하나 이상의 개별 데이터센터로 구성된 논리 단위입니다. 각 가용 영역은 독립된 전원 · 냉각 · 물리 보안을 갖추고, 같은 리전의 다른 가용 영역과는 저지연 네트워크로 연결됩니다. 즉 가용 영역 하나 안에도 이미 여러 건물이 있고, 가용 영역을 나누는 이유는 건물이 아니라 장애 도메인을 나누는 것입니다.

여기서 실무와 시험 양쪽의 결론이 하나로 모입니다. 같은 가용 영역 안에서 인스턴스를 여러 대 띄우는 것은 고가용성이 아닙니다. 전원이나 네트워크 수준의 사고는 가용 영역 단위로 발생하기 때문입니다. 가용성을 올리려면 서로 다른 가용 영역에 배치해야 합니다.

가용 영역 이름과 가용 영역 ID

us-east-1a 같은 가용 영역 이름은 계정마다 다른 물리 가용 영역에 매핑됩니다. A 계정의 us-east-1a와 B 계정의 us-east-1a가 같은 곳이라는 보장이 없습니다. AWS가 계정별로 이름을 무작위로 배정해 특정 가용 영역에 부하가 몰리는 것을 막기 때문입니다.

반면 use1-az1 형태의 가용 영역 ID는 모든 계정에서 같은 물리 위치를 가리킵니다. EC2 API 문서는 AvailabilityZoneId에 대해 "계정 간에 일관된 식별자를 제공하므로 AvailabilityZone보다 이 옵션이 선호된다"고 명시합니다. 여러 계정이 VPC 서브넷을 공유하거나 계정 간 배치를 맞춰야 할 때는 이름이 아니라 ID로 이야기해야 합니다.

# 리전 코드는 예시입니다. <리전코드> 자리에 실제 값을 넣습니다.
aws ec2 describe-availability-zones \
  --region ap-northeast-2 \
  --query 'AvailabilityZones[].[ZoneName,ZoneId,ZoneType,OptInStatus]' \
  --output table

# 옵트인하지 않은 존까지 포함해 로컬 존을 확인합니다.
aws ec2 describe-availability-zones \
  --region us-west-2 \
  --all-availability-zones \
  --filters Name=zone-type,Values=local-zone \
  --query 'AvailabilityZones[].[ZoneName,OptInStatus,ParentZoneName]' \
  --output table

로컬 존과 Wavelength 존 — 옵트인해야 보인다

EC2 API는 존을 availability-zone, local-zone, wavelength-zone 세 가지 유형으로 구분합니다. 뒤의 두 가지는 부모 리전에 딸린 확장이며, API 호출 같은 제어 평면 작업의 일부를 부모 존이 대신 처리합니다.

시험에서는 표현이 갈림길이 됩니다. "특정 도시의 사용자에게 매우 낮은 지연"이면 로컬 존, "5G 이동통신 단말"이면 Wavelength, "온프레미스 데이터센터 안에서 AWS API를 그대로"면 Outposts입니다 (Outposts는 4장 VPC 연결과 하이브리드에서 다룹니다).

엣지 로케이션과 리전 엣지 캐시

엣지 로케이션은 리전 바깥에 훨씬 촘촘하게 배치된 지점으로, Amazon CloudFront가 콘텐츠를 캐시하고 Amazon Route 53이 DNS 질의에 응답하는 곳입니다. 엣지에서 캐시 미스가 나면 곧바로 오리진으로 가지 않고 리전 엣지 캐시를 한 번 더 거칠 수 있습니다. CloudFront 문서는 Origin Shield를 끄면 "여러 엣지 로케이션이나 리전 엣지 캐시에서 오리진으로 직접 요청이 갈 수 있다"고 설명합니다. 이 중간 계층이 오리진 부하를 줄여 줍니다.

리전 선택의 네 가지 기준

"가까운 곳을 고른다"는 답이 아닙니다. 실제로는 네 가지를 함께 저울질합니다.

네 기준이 충돌할 때의 우선순위는 문제문이 정해 줍니다. 규정 준수 제약이 명시되면 그것이 다른 세 가지를 이깁니다 — 명시된 제약을 위반하는 선택지는 아무리 싸고 빨라도 오답이기 때문입니다.

책임 공유 모델 — 선이 어디에 그어지는가

AWS는 보안 책임을 둘로 나눕니다. 클라우드 자체의 보안(security of the cloud)은 AWS가, 클라우드 안의 보안(security in the cloud)은 고객이 맡습니다. AWS는 하드웨어 · 물리 시설 · 리전과 가용 영역을 잇는 네트워크 · 하이퍼바이저를 책임지고, 고객은 그 위에 올린 데이터 · 자격 증명 · 권한 · 네트워크 구성 · 암호화 선택을 책임집니다.

서비스 유형에 따라 경계가 움직인다

모델을 외우기만 하면 문항을 놓칩니다. 핵심은 경계선이 고정되어 있지 않다는 점입니다. 관리형 서비스일수록 AWS가 가져가는 몫이 커지고, 고객의 몫은 위쪽으로 좁아집니다.

표의 마지막 두 줄이 핵심입니다. 데이터와 권한은 어떤 서비스를 쓰든 항상 고객 책임입니다. Amazon RDS처럼 중간에 있는 서비스도 마찬가지여서, 데이터베이스 엔진과 운영체제 패치는 AWS가 수행하지만 스키마 · 데이터베이스 사용자 · 네트워크 배치 · 암호화 여부는 고객이 정합니다.

Well-Architected Framework — 6개 기둥과 시험 도메인

AWS Well-Architected Framework는 설계를 평가하는 여섯 가지 관점입니다. SAA는 이 프레임워크를 직접 묻지는 않지만, 문항의 한정어가 곧 기둥의 이름이라 기둥을 알면 무엇이 우선인지 빨리 판단할 수 있습니다.

기둥과 SAA 도메인의 대응

SAA의 4개 도메인은 기둥 2번부터 5번까지에 그대로 대응합니다. 운영 우수성과 지속 가능성은 개념 이해용으로만 다루면 충분합니다 — 이 사이트가 두 기둥에 지면을 적게 쓰는 이유도 여기에 있습니다.

계정, 루트 사용자, 그리고 AWS Organizations

AWS 계정은 청구의 단위이자 격리의 단위입니다. 계정이 다르면 리소스 이름이 겹쳐도 상관없고, 한 계정에서 권한을 잘못 준 실수가 다른 계정으로 번지지 않습니다. 이 성질이 다중 계정 전략의 출발점입니다.

루트 사용자를 쓰지 않는 이유

루트 사용자는 계정을 만들 때 생기는 이메일 주소로 로그인하는 최상위 자격 증명이며, 계정 안의 모든 리소스에 대해 제한 없는 권한을 가집니다. IAM 정책으로 루트의 권한을 줄일 수 없고, 서비스 제어 정책(SCP)만이 조직 멤버 계정의 루트에 상한을 걸 수 있습니다.

문제는 이 권한이 회수도 추적도 어렵다는 점입니다. 루트 자격 증명이 유출되면 계정 전체가 넘어가고, 누가 무엇을 했는지 구분할 수도 없습니다. 그래서 실무 표준은 다음과 같습니다.

• 루트 사용자에 MFA를 활성화하고 자격 증명을 잠가 둡니다.
• 루트 액세스 키를 만들지 않습니다. 이미 있다면 삭제합니다.
• 일상 작업은 IAM 역할이나 AWS IAM Identity Center로 발급받은 임시 자격 증명으로 합니다.
• 계정 이메일 변경, 계정 해지처럼 루트만 할 수 있는 작업일 때만 로그인합니다.

aws configure set aws_access_key_id "$ROOT_KEY" --profile prod
aws configure set aws_secret_access_key "$ROOT_SECRET" --profile prod
aws s3 sync ./build s3://example-app-assets --profile prod

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/DeployRole \
  --role-session-name ci-deploy
aws s3 sync ./build s3://example-app-assets

AWS Organizations — 조직, OU, SCP

AWS Organizations는 여러 계정을 하나의 조직으로 묶습니다. 조직을 만든 계정이 관리 계정이 되고, 나머지는 멤버 계정입니다. 계정은 조직 단위(Organizational Unit, OU)로 묶어 계층을 만들며, 정책은 조직 루트 · OU · 개별 계정 중 어디에나 붙일 수 있습니다.

조직을 만들 때 기능 집합을 고릅니다. 전체 기능(ALL)으로 만들면 조직 루트에 서비스 제어 정책이 자동으로 활성화됩니다. 통합 결제 전용(CONSOLIDATED_BILLING)으로 만들면 어떤 정책 유형도 활성화되지 않고 조직 정책을 쓸 수 없습니다. 시나리오에 "여러 계정에 일괄적으로 가드레일을 걸어야 한다"가 나오면 전체 기능이 전제입니다.

서비스 제어 정책(Service Control Policy, SCP)의 성질은 두 문장으로 요약됩니다.

• SCP는 권한을 부여하지 않습니다. 최대 권한의 상한(guardrail)만 정합니다. 실제 허용은 여전히 IAM 정책이 해야 합니다.
• SCP는 멤버 계정의 루트 사용자에게도 적용됩니다. IAM 정책으로는 막을 수 없는 루트를 통제하는 유일한 수단입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "cloudfront:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

리전 개념이 없는 글로벌 서비스는 NotAction으로 빼 둡니다. 빼지 않으면 IAM 사용자 생성이나 Route 53 레코드 수정까지 함께 막혀 조직이 마비됩니다. SCP 평가가 IAM 정책과 어떻게 결합하는지는 2장 IAM과 자격 증명에서 자세히 다룹니다.

다중 계정 전략을 쓰는 이유

조직을 표준 구성으로 한 번에 세우는 도구가 AWS Control Tower이고, 운영과 계정 관리 전반은 17장 모니터링·운영·계정 관리에서 다룹니다.

요금 모델 — 세 가지 원칙과 데이터 전송의 방향성

요금 3원칙

여기에 하나를 더하면 사용하지 않는 것을 끄는 것이 가장 확실한 절감입니다. 예를 들어 EC2 API 문서는 인스턴스를 중지한 동안에는 인스턴스 사용 요금과 데이터 전송 요금이 부과되지 않지만 볼륨 요금은 계속 부과된다고 명시합니다. "인스턴스를 껐는데 왜 요금이 나오나"라는 질문의 답이 여기 있습니다.

데이터 전송 요금의 방향성 SAA 빈출

데이터 전송은 양이 아니라 방향으로 요금이 정해집니다. 이 비대칭을 모르면 비용 문항에서 계속 헷갈립니다.

시험 범위 — 무엇을 공부하고 무엇을 버릴 것인가

AWS는 SAA-C03 시험 가이드에서 범위 안 서비스와 범위 밖 서비스를 각각 목록으로 공개합니다. 범위 밖 목록을 먼저 읽는 편이 시간을 아낍니다. 여기 있는 서비스는 문항에 정답으로 등장하지 않습니다.

범위 안 — 이 사이트가 다루는 영역

컴퓨팅(EC2 · Lambda · ECS · EKS), 스토리지(S3 · EBS · EFS · FSx), 데이터베이스(RDS · Aurora · DynamoDB · ElastiCache), 네트워킹(VPC · Route 53 · CloudFront · ELB), 보안(IAM · KMS · WAF · Shield · GuardDuty), 통합(SQS · SNS · EventBridge · Step Functions), 관리(CloudWatch · CloudTrail · Config · Systems Manager · CloudFormation). 18장 커리큘럼은 이 범위를 도메인 가중치에 맞춰 배분한 것입니다.

범위 밖 — 공부하지 않습니다

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 하나씩 섞여 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 2장 · IAM과 자격 증명 이 장에서 예고한 정책 평가 로직과 SCP 결합 규칙을 정면으로 다룹니다. 가중치가 가장 큰 도메인의 중심입니다. 기본개념 · SAA 최우선
• 3장 · VPC 네트워킹 기초 서브넷이 가용 영역에 묶인다는 사실에서 다중 가용 영역 설계가 시작됩니다. 보안 그룹과 네트워크 ACL의 차이도 여기서. 기본개념 · SAA 최우선
• SAA 시험 개요와 8주 플랜 도메인 가중치, 과제 진술 14개, 도메인과 챕터의 매핑, 그리고 8주 학습 순서를 한 페이지에 모았습니다. 시험 대비
• 한정어 키워드 사전 MOST cost-effective, LEAST operational overhead 같은 한정어가 어떤 답을 가리키는지 정리했습니다. 시험 대비 · 최우선
• 서비스 빠른참조 시험 범위 서비스의 한 줄 정의와 선택 기준. 범위 밖 목록도 함께 있어 학습 범위를 좁히는 데 씁니다. 빠른참조
• 진단 테스트 40문항 4개 도메인의 취약점을 먼저 재고, 가중치와 부족분을 곱해 개인별 학습 순서를 자동으로 만들어 줍니다. 문제 풀이

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• Amazon EC2 사용 설명서 — 리전과 가용 영역 — 리전이 독립적으로 동작한다는 점, 가용 영역이 하나 이상의 데이터센터로 구성된다는 정의
• Amazon EC2 API 레퍼런스 — DescribeAvailabilityZones — 존 유형 세 가지(availability-zone / local-zone / wavelength-zone), 가용 영역의 OptInStatus가 항상 opt-in-not-required라는 사실, ParentZoneName의 의미
• Amazon EC2 API 레퍼런스 — CreateSubnet — AvailabilityZoneId가 계정 간에 일관된 식별자이므로 AvailabilityZone보다 선호된다는 서술
• AWS 계정 관리 참조 — 리전 활성화와 비활성화 — 계정 수준 리전 옵트인과 기본 활성 리전의 구분
• AWS Local Zones 사용 설명서 — 로컬 존의 동작 — 로컬 존이 부모 리전의 확장이며 사용 전에 활성화가 필요하다는 점
• AWS Wavelength 개발자 안내서 — Wavelength의 동작 — 통신 사업자 네트워크 안의 존이라는 성격과 캐리어 게이트웨이
• Amazon CloudFront 개발자 안내서 — CloudFront란 — 엣지 로케이션의 역할과 배포 상태가 Deployed일 때 전 엣지에 전파되었다는 의미
• Amazon CloudFront 개발자 안내서 — Origin Shield — 엣지 로케이션과 리전 엣지 캐시가 별도의 계층으로 존재한다는 서술
• AWS Well-Architected Tool 사용 설명서 — 소개 — 프레임워크와 기둥의 개념
• AWS Well-Architected Framework (한국어) — 6개 기둥의 정의와 한국어 표기
• IAM 사용 설명서 — AWS 계정 루트 사용자 — 루트 사용자의 권한 범위와 루트만 수행할 수 있는 작업
• IAM 사용 설명서 — 보안 모범 사례 — 루트 자격 증명을 잠가 두고 임시 자격 증명을 쓰라는 권고
• AWS Organizations 사용 설명서 — 소개 — 관리 계정 · 조직 루트 · OU · 멤버 계정의 관계
• AWS Organizations 사용 설명서 — 용어와 개념 — 전체 기능과 통합 결제 전용 기능 집합의 차이
• AWS Organizations 사용 설명서 — SCP 전략 — SCP가 권한을 부여하지 않고 상한만 정한다는 점, 허용 목록과 거부 목록 전략
• Amazon S3 사용 설명서 — 요청자 지불 버킷 — 기본적으로 버킷 소유자가 내려받기 요금을 부담한다는 서술
• Amazon S3 API 레퍼런스 — CopyObject — 복사 원본이 다른 리전이면 데이터 전송이 원본 계정에 청구된다는 서술
• Amazon EC2 API 레퍼런스 — StopInstances — 중지된 인스턴스에는 사용 요금과 데이터 전송 요금이 부과되지 않지만 볼륨 요금은 계속된다는 서술
• AWS Certified Solutions Architect – Associate 시험 가이드 (SAA-C03) — 문항 수 65, 시간 130분, 합격 점수 720, 보상형 채점, 도메인 가중치 30/26/24/20
• SAA-C03 시험 가이드 — 범위 안 서비스 — 이 사이트가 다루는 서비스 목록의 근거
• SAA-C03 시험 가이드 — 범위 밖 서비스 — CDK를 포함한 범위 밖 목록의 근거