AWS(Amazon Web Services)는 서버, 네트워크, 데이터베이스, 스토리지, 보안, 모니터링 등 애플리케이션 운영에 필요한 인프라를 제공하는 클라우드 플랫폼이다.
게임 서버를 운영할 때는 단순히 서버 인스턴스를 생성하는 것만으로 충분하지 않다. 외부 트래픽을 안전하게 수용하고, 데이터를 영속적으로 저장하며, 여러 서버 간에 상태를 공유하고, 장애를 감지할 수 있는 전체 인프라 구조를 설계해야 한다.
AWS의 핵심 서비스는 이러한 역할에 따라 구분할 수 있다.
- 컴퓨팅: EC2
- 네트워크: VPC, Subnet, Security Group
- 접근 제어: IAM
- 데이터 저장: RDS, ElastiCache, S3
- 도메인 및 DNS: Route 53
- 모니터링: CloudWatch
각 서비스의 역할과 관계를 이해하면 게임 서버뿐 아니라 웹 서비스, API 서버, 실시간 멀티플레이 플랫폼의 인프라를 설계하는 데에도 활용할 수 있다.
EC2: 가상 서버 운영
EC2(Elastic Compute Cloud)는 AWS에서 가상 서버를 생성하고 실행할 수 있는 컴퓨팅 서비스다.
개발자는 운영체제, CPU, 메모리, 네트워크 성능 등을 선택해 서버를 구성하고, 그 위에 Node.js, Express, WebSocket 등의 애플리케이션을 배포할 수 있다.
주요 개념
인스턴스(Instance)
실제로 실행되는 가상 서버다. 선택한 인스턴스 유형에 따라 CPU, 메모리, 네트워크 성능 등이 달라진다.
AMI(Amazon Machine Image)
인스턴스를 생성할 때 사용하는 이미지다. 운영체제와 사전 구성된 소프트웨어 환경 등을 기반으로 서버를 생성할 수 있다.
EBS(Elastic Block Store)
EC2에 연결하는 블록 스토리지다. 운영체제 디스크나 애플리케이션 데이터 저장소로 사용할 수 있다. 인스턴스와 별도로 유지할 수 있는 볼륨도 제공한다.
Auto Scaling
설정한 조건에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄이는 기능이다. 트래픽 변화에 대응하고 불필요한 컴퓨팅 비용을 줄이는 데 활용한다.
게임 서버에서의 활용
EC2에 게임 서버를 배포하면 클라이언트의 요청을 처리하고, 매칭 서버와 게임 서버를 운영하며, 데이터베이스나 캐시와 통신할 수 있다.
실시간 게임 서버라면 CPU 사용량뿐 아니라 네트워크 처리량, 메모리 사용량, 연결 유지 비용 등을 함께 고려해야 한다.
특히 WebSocket 서버는 연결이 유지되는 동안 클라이언트 상태를 관리하므로, 인스턴스 수를 늘리는 것만으로 부하 분산이 완성되지는 않는다. 세션 관리, 서버 간 통신, 연결 재분배 전략도 함께 설계해야 한다.
운영 시 고려 사항
- 서버에 필요한 CPU와 메모리를 기준으로 인스턴스 유형을 선택한다.
- SSH 접속 포트를 인터넷 전체에 무분별하게 공개하지 않는다.
- 애플리케이션 로그와 데이터를 인스턴스 내부에만 의존하지 않는다.
- 장애 복구와 배포 자동화를 고려해 서버 구성을 코드로 관리한다.
- 실제 부하 테스트를 통해 인스턴스의 적정 사양을 검증한다.
VPC와 Subnet: 네트워크 환경 구성
VPC(Virtual Private Cloud)는 AWS에서 논리적으로 격리된 가상 네트워크를 구성하는 서비스다.
VPC 내부에 IP 주소 범위를 설정하고, Subnet을 분리하며, 라우팅과 네트워크 접근 정책을 구성할 수 있다.
VPC
VPC는 AWS 리소스가 통신하는 네트워크의 기본 경계다.
예를 들어 게임 플랫폼을 운영한다면 EC2, RDS, ElastiCache 등의 리소스를 동일한 VPC 안에 배치하고, 각 리소스의 접근 범위를 제한할 수 있다.
VPC를 설계할 때는 IP 주소 범위가 다른 네트워크와 충돌하지 않도록 고려해야 한다. 향후 개발 환경과 운영 환경을 분리하거나, 외부 네트워크와 연결할 가능성도 함께 검토하는 것이 좋다.
Subnet
Subnet은 VPC의 IP 주소 범위를 더 작은 네트워크로 나눈 것이다. 일반적으로 가용 영역(Availability Zone) 단위로 생성한다.
Subnet은 라우팅 설정과 연결 방식에 따라 공개 인터넷과 통신하는 용도 또는 내부 통신을 위한 용도로 구성할 수 있다.
Public Subnet
인터넷 게이트웨이를 통한 인터넷 경로가 구성된 Subnet이다. 여기에 배치된 리소스가 실제로 인터넷에서 접근 가능한지는 공인 IP, 보안 그룹 등 다른 조건에도 영향을 받는다.
Private Subnet
일반적으로 인터넷에서 직접 시작되는 연결을 허용하지 않는 리소스를 배치하는 데 사용한다. 외부로 나가는 통신이 필요하다면 NAT Gateway 등의 구성이 필요할 수 있다.
게임 서버 네트워크 구성 예시
- Public Subnet: 외부 요청을 수신하는 로드 밸런서 또는 공개 서비스
- Private Subnet: 게임 서버, 내부 API 서버
- Private Subnet: RDS 데이터베이스
- Private Subnet: ElastiCache 클러스터
위 구성은 대표적인 예시이며, 실제 배치는 서비스의 트래픽 구조와 보안 요구 사항에 따라 달라진다.
핵심은 외부에 공개해야 하는 리소스와 내부에서만 접근해야 하는 리소스를 네트워크 계층에서 분리하는 것이다.
Security Group: 네트워크 접근 제어
Security Group은 EC2, RDS 등 지원되는 AWS 리소스에 적용하는 가상 방화벽이다.
인바운드 규칙으로 들어오는 트래픽을 제어하고, 아웃바운드 규칙으로 나가는 트래픽을 제어한다. Security Group은 상태 저장(Stateful) 방식이므로 허용된 연결의 응답 트래픽은 별도의 반대 방향 규칙 없이 처리된다.
주요 설정
Inbound Rules
외부에서 리소스로 들어오는 연결을 허용한다.
예를 들어 HTTPS 서비스에는 필요한 HTTPS 포트를 허용하고, 관리용 SSH 포트는 신뢰할 수 있는 관리자의 IP 주소 등으로 제한한다.
Outbound Rules
리소스에서 외부로 나가는 연결을 허용한다.
기본 설정은 일반적으로 아웃바운드 트래픽을 폭넓게 허용하지만, 보안 요구 사항에 따라 목적지와 포트를 제한할 수 있다.
Security Group 참조
AWS에서는 IP 주소 대신 다른 Security Group을 참조해 접근을 허용할 수 있다.
예를 들어 다음과 같이 구성할 수 있다.
- 게임 서버 Security Group: 게임 클라이언트의 필요한 포트 허용
- 애플리케이션 서버 Security Group: 게임 서버에서 필요한 API 포트 허용
- 데이터베이스 Security Group: 애플리케이션 서버 Security Group에서 들어오는 DB 포트만 허용
이렇게 구성하면 서버의 IP 주소가 변경되더라도 보안 그룹 간 관계를 기준으로 접근을 제어할 수 있다.
운영 시 주의 사항
- 모든 포트를 전체 인터넷에 공개하지 않는다.
- 데이터베이스 포트를 외부에 직접 공개하지 않는다.
- 실제 서비스에 필요한 포트만 허용한다.
- 네트워크 연결이 실패하면 Security Group뿐 아니라 라우팅, 네트워크 ACL, DNS 설정도 함께 확인한다.
Security Group은 애플리케이션의 인증 및 인가를 대체하지 않는다. 네트워크 접근이 허용되어도 API 자체에서 사용자와 권한을 검증해야 한다.
IAM: AWS 리소스 접근 권한 관리
IAM(Identity and Access Management)은 AWS 리소스에 누가 어떤 작업을 수행할 수 있는지 관리하는 서비스다.
EC2에서 S3에 파일을 업로드하거나, 애플리케이션이 특정 AWS API를 호출하는 경우에도 IAM 권한이 필요할 수 있다.
주요 구성 요소
User
사람이나 특정 사용 주체를 위한 IAM 자격 증명이다. 다만 AWS 환경에서는 가능한 경우 장기 자격 증명보다 연합 인증과 임시 자격 증명을 사용하는 것이 바람직하다.
Group
여러 IAM 사용자에게 공통 권한을 부여하기 위한 구성 요소다.
Role
신뢰할 수 있는 주체가 특정 권한을 임시로 획득할 수 있도록 하는 역할이다. EC2 인스턴스나 AWS 서비스에 권한을 부여할 때 자주 사용한다.
Policy
허용하거나 거부할 작업과 대상 리소스 등을 정의하는 JSON 기반 권한 문서다.
EC2와 IAM Role
예를 들어 게임 서버가 S3에 로그 파일을 저장한다고 가정하자.
서버 코드에 AWS 액세스 키와 시크릿 키를 직접 작성하면 키 유출 위험이 커진다. 대신 EC2에 적절한 IAM Role을 연결하면 애플리케이션은 AWS가 제공하는 임시 자격 증명을 활용할 수 있다.
이때 Role에는 필요한 S3 버킷과 작업에 한정된 권한만 부여하는 것이 좋다.
최소 권한 원칙
IAM을 설계할 때 중요한 기준은 최소 권한 원칙(Principle of Least Privilege)이다.
서비스가 실제로 수행해야 하는 작업만 허용하고, 필요하지 않은 권한은 부여하지 않는다.
예를 들어 파일을 업로드하기만 하는 서버에 모든 S3 버킷의 삭제 권한까지 부여할 이유는 없다.
또한 IAM 권한은 네트워크 접근 제어와 별개의 계층이다. Security Group이 통신 경로를 제한한다면 IAM은 AWS API를 통해 수행할 수 있는 작업을 제한한다.
RDS: 관리형 관계형 데이터베이스
RDS(Relational Database Service)는 AWS에서 관계형 데이터베이스를 관리형 서비스로 운영할 수 있도록 제공하는 서비스다.
MySQL, PostgreSQL 등 지원되는 데이터베이스 엔진을 선택해 사용할 수 있으며, 백업과 복구, 모니터링, 고가용성 구성 등의 운영 기능을 활용할 수 있다.
주요 기능
자동 백업
설정된 보존 기간과 백업 정책에 따라 데이터베이스를 복구할 수 있는 백업을 관리한다.
Multi-AZ
지원되는 구성에서 다른 가용 영역에 대기 인스턴스 등을 배치해 가용성을 높인다. 장애 조치 방식과 읽기 성능은 사용하는 구성에 따라 달라진다.
Read Replica
지원되는 엔진과 구성에서 읽기 요청을 복제본으로 분산할 수 있다. 복제 지연이 발생할 수 있으므로 모든 읽기 요청을 무조건 복제본으로 보내서는 안 된다.
모니터링
CPU, 연결 수, 스토리지, 지연 시간 등 데이터베이스 운영에 필요한 지표를 확인할 수 있다.
게임 플랫폼에서의 활용
RDS는 정합성이 중요한 영속 데이터를 저장하는 데 적합하다.
- 사용자 계정과 프로필
- 포인트 잔액과 거래 원장
- 아이템 구매 기록
- 경기 결과와 보상 지급 기록
- 결제 및 주문 정보
예를 들어 아이템을 구매할 때는 포인트 차감과 아이템 지급 기록이 일관되게 처리되어야 한다. 이를 위해 데이터베이스 트랜잭션, 유니크 제약 조건, 멱등성 키 등을 함께 설계할 수 있다.
RDS와 EC2의 차이
EC2에 직접 MySQL을 설치하면 운영체제와 데이터베이스 설정을 세밀하게 제어할 수 있지만, 백업과 복제, 장애 복구, 패치 등을 직접 관리해야 하는 범위가 넓어진다.
RDS를 사용하면 이러한 운영 부담을 줄일 수 있다. 대신 지원되는 엔진과 구성에 따라 제약이 있고, 인스턴스와 스토리지 등 사용량에 따른 비용이 발생한다.
중요한 점은 RDS를 사용한다고 데이터베이스 운영 문제가 자동으로 해결되는 것은 아니라는 사실이다. 인덱스, 쿼리 성능, 커넥션 풀, 트랜잭션, 백업 복구 검증은 여전히 개발자와 운영자가 관리해야 한다.
ElastiCache: 관리형 인메모리 캐시
ElastiCache는 AWS에서 관리형 인메모리 데이터 저장소를 운영할 수 있도록 제공하는 서비스다. Redis OSS 및 Valkey 등 지원되는 엔진을 활용할 수 있다.
메모리에 데이터를 저장해 데이터베이스보다 빠르게 접근할 수 있으며, 반복 조회되는 데이터나 짧은 시간 동안 유지할 상태를 처리하는 데 유용하다.
주요 활용
캐싱
자주 조회되는 사용자 정보, 게임 설정, 랭킹 데이터를 캐시에 저장해 데이터베이스의 부하를 줄인다.
세션 및 임시 상태 관리
인증 세션이나 임시 게임 상태처럼 빠른 조회와 갱신이 필요한 데이터를 관리할 수 있다. 단, 실제 저장 방식과 영속성 요구 사항에 따라 적절한 구성을 선택해야 한다.
랭킹 시스템
Sorted Set과 같은 자료구조를 활용해 점수 순위를 관리할 수 있다.
온라인 상태 관리
사용자의 접속 상태와 최근 활동 정보를 저장해 온라인 사용자 목록을 관리할 수 있다.
매칭 대기열
대기 중인 플레이어를 관리하고, 조건에 따라 매칭 대상을 탐색하는 데 활용할 수 있다.
RDS와 ElastiCache의 역할 구분
RDS는 영속적인 정합성 데이터의 저장에 주로 사용하고, ElastiCache는 빠른 접근이 필요한 데이터와 임시 상태 관리에 주로 사용한다.
예를 들어 플레이어의 포인트 잔액이 RDS에 저장되어 있다면, 이를 ElastiCache에 캐싱해 조회 성능을 높일 수 있다. 그러나 캐시에 저장된 값만을 근거로 포인트를 차감하면 동시성 문제나 데이터 유실로 인해 정합성이 깨질 수 있다.
따라서 데이터의 중요도에 따라 원본 데이터의 위치를 명확히 정의해야 한다.
- 포인트 원장과 구매 기록: RDS
- 자주 조회되는 프로필 캐시: ElastiCache
- 임시 매칭 대기열: ElastiCache
- 장기간 보존해야 하는 파일: S3
운영 시 고려 사항
- 캐시 데이터의 만료 시간인 TTL을 적절하게 설정한다.
- 캐시 장애 시 원본 데이터 저장소에 발생할 부하를 고려한다.
- 캐시 미스가 집중되는 Cache Stampede를 방지한다.
- 여러 서버가 같은 키를 갱신할 때 동시성 문제를 고려한다.
- 네트워크 접근과 인증 설정을 통해 캐시를 외부에 무분별하게 노출하지 않는다.
캐시는 원본 데이터 저장소를 무조건 대체하는 수단이 아니다. 성능을 개선하는 대신 무효화, 정합성, 장애 복구라는 추가적인 설계 문제를 발생시킨다.
S3: 객체 스토리지
S3(Simple Storage Service)는 파일과 같은 객체 데이터를 저장하는 객체 스토리지 서비스다.
일반적인 파일 시스템과 달리 버킷과 객체 키를 중심으로 데이터를 관리한다. 대용량 파일을 저장하고 여러 서비스에서 접근할 수 있도록 구성하기에 적합하다.
주요 개념
Bucket
객체를 저장하는 논리적인 컨테이너다. 버킷 이름, 리전, 접근 정책 등을 설정한다.
Object
S3에 저장되는 실제 데이터다. 이미지, 로그, 백업 파일, 빌드 결과물 등을 저장할 수 있다.
Object Key
버킷 내부에서 객체를 식별하는 키다. 경로처럼 보이는 문자열을 사용할 수 있지만, 일반적인 파일 시스템의 디렉터리와는 구조가 다르다.
Versioning
객체의 여러 버전을 보존할 수 있는 기능이다. 실수로 덮어쓰거나 삭제했을 때 복구에 활용할 수 있지만, 비용과 보존 정책을 함께 고려해야 한다.
Lifecycle Policy
객체의 수명 주기에 따라 다른 스토리지 클래스로 전환하거나 만료된 객체를 삭제하도록 설정할 수 있다.
게임 플랫폼에서의 활용
S3는 애플리케이션 서버의 로컬 디스크에 저장할 필요가 없는 파일을 관리하는 데 적합하다.
- 게임 리소스와 이미지
- 사용자 업로드 파일
- 경기 리플레이 및 녹화 파일
- 애플리케이션 로그 아카이브
- 데이터베이스 백업 파일
- 빌드 결과물과 배포 아티팩트
특히 사용자에게 파일을 제공하는 기능에서는 S3와 CDN을 함께 사용해 애플리케이션 서버의 트래픽 부담을 줄일 수 있다.
접근 권한 관리
S3 버킷을 공개하지 않고도 권한이 있는 사용자에게 파일을 제공할 수 있다.
예를 들어 서버가 사용자의 권한을 검증한 뒤, 제한된 시간 동안 사용할 수 있는 사전 서명 URL(Presigned URL)을 발급하도록 구성할 수 있다.
이 방식은 클라이언트가 대용량 파일을 직접 업로드하거나 다운로드할 때 유용하다. 다만 URL을 획득한 사람은 만료 전까지 해당 URL의 권한 범위 내에서 작업할 수 있으므로 유출과 만료 시간을 고려해야 한다.
Route 53: DNS와 도메인 관리
Route 53은 AWS에서 제공하는 DNS 및 도메인 관리 서비스다.
DNS(Domain Name System)는 도메인 이름을 IP 주소 등의 네트워크 정보와 연결하는 시스템이다.
예를 들어 사용자가 api.example.com에 접속하면 DNS 조회를 통해 해당 서비스의 목적지를 확인할 수 있다.
주요 기능
Hosted Zone
도메인의 DNS 레코드를 관리하는 영역이다.
DNS Record
도메인이 어떤 대상으로 연결되는지 정의한다. A, AAAA, CNAME, MX, TXT 등의 레코드 유형을 사용할 수 있다.
Alias Record
지원되는 AWS 리소스를 대상으로 도메인을 연결할 수 있는 기능이다. 예를 들어 Application Load Balancer와 같은 AWS 리소스에 연결할 때 활용할 수 있다.
Health Check와 Routing Policy
지원되는 구성에서 대상의 상태를 확인하거나 지연 시간, 가중치, 장애 조치 등의 기준에 따라 DNS 응답을 구성할 수 있다.
게임 서버에서의 활용
api.example.com: API 서버match.example.com: 매칭 서비스assets.example.com: 게임 리소스 배포admin.example.com: 운영자 페이지
이와 같이 기능별 도메인을 분리하면 서비스의 역할을 명확하게 구분하고, 각 도메인의 목적지를 독립적으로 변경할 수 있다.
단, DNS는 목적지를 알려주는 역할이지 자체적으로 모든 트래픽을 프록시하거나 암호화하는 서비스는 아니다. 실제 HTTPS 연결에는 인증서와 적절한 TLS 구성이 필요하다.
또한 DNS 변경 사항은 TTL과 캐싱 정책에 영향을 받으므로, 레코드를 수정하더라도 모든 클라이언트에 즉시 반영되는 것은 아니다.
CloudWatch: 모니터링과 관측성
CloudWatch는 AWS 리소스와 애플리케이션의 지표, 로그, 알람 등을 관리하는 모니터링 서비스다.
서버가 정상적으로 실행 중이라는 사실만으로 서비스가 정상이라고 판단할 수는 없다. 응답 시간이 길어지거나 오류율이 증가하고, 데이터베이스 연결이 고갈되는 상황도 감지해야 한다.
CloudWatch를 활용하면 이러한 운영 상태를 수집하고 분석할 수 있다.
주요 기능
Metrics
CPU 사용률, 네트워크 트래픽, 요청 수 등 시간에 따라 변하는 수치를 수집한다.
Logs
애플리케이션이나 지원되는 AWS 서비스에서 발생한 로그를 수집하고 조회할 수 있다. EC2의 파일 로그를 수집하려면 CloudWatch Agent 등의 별도 구성이 필요할 수 있다.
Alarms
특정 지표가 설정한 조건을 만족하면 알람을 발생시킨다. 예를 들어 CPU 사용률이 일정 수준 이상으로 지속되거나, 오류 지표가 임계치를 넘을 때 알림을 받을 수 있다.
Dashboards
여러 지표를 한 화면에 모아 서비스의 운영 상태를 확인할 수 있다.
CloudWatch Logs Insights
수집된 로그를 쿼리해 특정 오류나 요청 패턴을 분석할 수 있다.
게임 서버에서 확인할 지표
서버 지표
- CPU와 메모리 사용량
- 네트워크 송수신량
- 프로세스 재시작 및 장애 발생
- 인스턴스별 부하 편차
API 지표
- 요청 수와 초당 요청 수(RPS)
- 응답 시간의 p95 및 p99
- HTTP 오류율
- 타임아웃 및 재시도 횟수
데이터베이스 지표
- 데이터베이스 CPU와 메모리
- 연결 수와 커넥션 풀 대기 시간
- 쿼리 지연 시간
- 복제 지연 및 스토리지 여유 공간
실시간 게임 지표
- 활성 WebSocket 연결 수
- 연결 및 재접속 성공률
- 메시지 처리 지연 시간
- 매칭 대기 시간
- 게임 서버별 동시 접속자 수
CloudWatch가 모든 애플리케이션 지표를 자동으로 수집하는 것은 아니다. 게임 서버의 활성 연결 수나 매칭 대기 시간처럼 애플리케이션 내부에서 계산해야 하는 지표는 직접 게시하거나 별도의 수집 체계를 구성해야 한다.
알람 설계
알람은 단순히 CPU 사용률이 높다는 사실을 알려주는 데서 끝나면 안 된다.
서비스의 실제 장애 가능성과 연결되는 지표를 선택하고, 알림 발생 시 어떤 조치를 취할 것인지 정의해야 한다.
예를 들어 API 응답 시간이 증가하면서 오류율과 데이터베이스 연결 대기 시간도 함께 증가한다면 데이터베이스가 병목일 가능성을 조사할 수 있다.
반대로 CPU 사용률이 높더라도 오류율과 응답 시간이 정상이라면 즉시 장애로 판단할 필요는 없다.
운영 모니터링의 목적은 지표를 많이 수집하는 것이 아니라, 장애를 조기에 감지하고 원인을 빠르게 좁히는 것이다.
AWS 서비스 간의 관계
각 AWS 서비스는 독립적으로 동작하지만, 실제 서비스에서는 서로 연결되어 하나의 인프라를 구성한다.
게임 플랫폼의 일반적인 구조를 예로 들면 다음과 같다.
클라이언트
│
▼
Route 53
│
▼
로드 밸런서 또는 공개 엔드포인트
│
▼
VPC
│
├── Public Subnet
│ └── 공개 진입점
│
└── Private Subnet
├── EC2
│ └── 게임 서버 / API 서버
│
├── RDS
│ └── 영속 데이터
│
└── ElastiCache
└── 캐시 / 임시 상태
S3
└── 파일 / 리소스 / 로그 아카이브
IAM
└── AWS 리소스 접근 권한
CloudWatch
└── 지표 / 로그 / 알람이 구조에서 Route 53은 도메인 조회를 담당하고, VPC와 Subnet은 네트워크 경계를 구성한다. Security Group은 리소스 간 통신을 제한하며, IAM은 AWS API에 대한 권한을 제어한다.
EC2는 애플리케이션을 실행하고, RDS는 영속 데이터를 저장하며, ElastiCache는 빠른 데이터 접근을 지원한다. S3는 파일을 보관하고 CloudWatch는 서비스 상태를 관측한다.
실제 운영 환경에서는 로드 밸런서, 인증서 관리, 비밀 정보 관리, 배포 자동화, 백업 정책 등을 추가로 구성할 수 있다.
설계 시 핵심 원칙
AWS 인프라를 설계할 때는 서비스의 이름과 기능을 외우는 것보다 각 구성 요소의 책임과 장애 지점을 이해하는 것이 중요하다.
- 보안: 공개 진입점만 외부에 노출하고, 내부 리소스의 접근을 제한한다.
- 최소 권한: IAM Role과 정책을 활용해 필요한 작업만 허용한다.
- 데이터 정합성: 영속 데이터와 캐시를 구분하고, 중요한 변경은 트랜잭션과 멱등성으로 보호한다.
- 고가용성: 단일 서버나 단일 가용 영역에 장애가 집중되지 않도록 구성한다.
- 관측성: 로그와 지표, 알람을 통해 장애 원인을 추적할 수 있게 한다.
- 비용 관리: 인스턴스 사양, 스토리지, 데이터 전송량, 관리형 서비스의 사용량을 지속적으로 점검한다.
- 자동화: 인프라 설정과 배포 과정을 코드화해 반복 가능한 운영 환경을 만든다.