AWS 공통 기반

먼저 준비Root MFA·연락처·복구 담당자를 정하고 Root access key를 만들지 않습니다.

왜 필요한가

최상위 계정의 탈취와 복구 실패를 예방합니다.

언제 필요한가

학습 계정부터 조직의 관리 계정까지 먼저 확인합니다.

생략 / 대안

보호 자체는 생략하지 않습니다. 조직의 중앙 Root 관리 여부는 별도로 확인합니다.

잘못 구성하면

공유 로그인·장기 키·복구 연락처 방치는 계정 전체에 영향을 줄 수 있습니다.

먼저 준비계정/환경 책임자를 정하고 SCP·Control Tower는 요구와 관리 부담에 맞춰 검토합니다.

왜 필요한가

실험과 운영의 권한·과금·영향 범위를 분리합니다.

언제 필요한가

여러 팀·환경 또는 중앙 정책이 필요할 때 Organizations, OU, Security/Audit 계정과 Landing Zone을 검토합니다.

생략 / 대안

작은 학습 범위는 단일 계정도 가능하지만 운영과 혼용할 위험은 남습니다.

잘못 구성하면

SCP는 권한을 부여하지 않습니다. 영향 검증 없이 제한하면 필요한 작업도 차단할 수 있습니다.

먼저 준비사람은 연동/임시 자격증명·MFA, 워크로드와 자동화는 Role 중심으로 설계합니다.

왜 필요한가

업무에 필요한 권한만 주고 접근 주체를 추적합니다.

언제 필요한가

콘솔·CLI·CI/CD·애플리케이션의 접근을 설계할 때 확인합니다.

생략 / 대안

접근 통제는 생략하지 않습니다. 역할 분리의 세밀함은 규모에 맞춥니다.

잘못 구성하면

공유 사용자와 과도한 권한은 변경 추적과 사고 범위 제한을 어렵게 합니다.

먼저 준비IdP·그룹·Permission set·비상 접근의 책임과 범위를 정합니다.

왜 필요한가

여러 계정과 사람의 접근·퇴사 처리를 일관되게 관리합니다.

언제 필요한가

조직의 로그인·계정별 접근이 필요할 때 검토합니다.

생략 / 대안

작은 범위는 간소화할 수 있지만 장기 키의 위험을 그대로 허용한다는 뜻은 아닙니다.

잘못 구성하면

기존 IdP·비상 접근을 고려하지 않으면 운영자 접근이 끊길 수 있습니다.

먼저 준비관리/데이터 이벤트와 Trail 범위·중앙 로그 위치·보존·열람 권한을 정합니다.

왜 필요한가

장애나 보안 사고에서 변경한 주체와 시점을 확인합니다.

언제 필요한가

리소스를 만들기 전 감사 범위와 보존 요구를 확인합니다.

생략 / 대안

기본 Event history는 최근 90일의 리전별 관리 이벤트입니다. 장기 보존·조직 집계·데이터 이벤트 요구는 별도 검토합니다.

잘못 구성하면

기본 이력만으로 모든 이벤트가 영구 기록된다고 믿으면 조사에 필요한 증거가 빠집니다.

먼저 준비Config 기록 리소스·리전·보존·평가 규칙과 비용 범위를 정합니다.

왜 필요한가

리소스 구성 변화와 정책 준수 확인의 근거를 만듭니다.

언제 필요한가

구성 이력·준수 평가·중앙 조사 요구가 있을 때 기록 대상을 정합니다.

생략 / 대안

단순 학습은 범위를 줄일 수 있습니다. IaC 코드만으로 모든 실제 변경을 추적한다고 가정하지 않습니다.

잘못 구성하면

기록 범위를 과도하게 넓히면 비용이 증가하고, 누락하면 조사 사각이 생깁니다.

먼저 준비공개/Private 접근·암호화 키·관리 접속·비밀 값 취급 기준을 정합니다.

왜 필요한가

배포마다 보안 경계를 새로 추측하지 않게 합니다.

언제 필요한가

서비스 공개와 데이터 취급 범위를 정할 때 먼저 확인합니다.

생략 / 대안

보안 기준은 생략하지 않으며 서비스/데이터별 수준을 결정합니다.

잘못 구성하면

불필요한 공개 포트·저장소 공개·키 권한 누락은 노출이나 복구 실패로 이어집니다.

먼저 준비보안 서비스 범위·담당자·대응 절차·비용을 먼저 합의합니다.

왜 필요한가

발견한 문제를 누가 검토하고 해결할지 일관되게 정합니다.

언제 필요한가

중앙 보안 점검이나 여러 계정의 표준 확인이 필요할 때 검토합니다.

생략 / 대안

기존 보안 도구로 대체/병행할 수 있으나 책임자와 대응 절차는 필요합니다.

잘못 구성하면

서비스를 켜기만 하면 보안이 완성된다는 가정과 미처리 알림은 위험합니다.

먼저 준비CIDR 할당·Public/Private·라우팅·인터넷 경로의 기본 방향을 정합니다.

왜 필요한가

나중에 연결할 환경과 주소가 겹치지 않게 설계합니다.

언제 필요한가

VPC·Subnet 생성과 기존 환경 연결 전 확인합니다.

생략 / 대안

이미 승인된 주소 체계가 있으면 재사용을 검토하되 신규 중복은 확인합니다.

잘못 구성하면

CIDR 중복과 잘못된 Routing은 연결 또는 이행을 어렵게 합니다.

먼저 준비인터넷/Private 접속·온프레 연결·DNS 소유자와 가용성 요구를 정합니다.

왜 필요한가

기존 시스템과 통신할 경로와 이름 해석을 함께 결정합니다.

언제 필요한가

온프레 연동 또는 외부/Private 접속 요구가 있을 때 확인합니다.

생략 / 대안

연결 요구가 없으면 VPN/전용 연결은 생략할 수 있습니다. DNS 책임은 별도로 정합니다.

잘못 구성하면

Routing·DNS·보안 규칙을 함께 보지 않으면 연결만 있어도 서비스가 동작하지 않습니다.

먼저 준비지표·로그 보존·Alarm 수신자·Runbook과 점검 방식을 정합니다.

왜 필요한가

이상 징후를 발견하고 담당자에게 전달합니다.

언제 필요한가

운영 서비스는 임계값·수집·보존·대응 책임을 설계부터 정합니다.

생략 / 대안

기존 모니터링으로 대체할 수 있습니다. 학습 환경은 범위를 줄이되 무관찰 운영은 피합니다.

잘못 구성하면

알람이 있어도 전달 대상과 대응 절차가 없으면 장애 대응이 늦어집니다.

먼저 준비접속 권한·Agent/통신·패치 창·실패 복구와 OS 담당자를 정합니다.

왜 필요한가

서버 생성 이후 접속·명령·패치의 책임과 수단을 정합니다.

언제 필요한가

EC2 또는 지원되는 하이브리드 서버를 운영할 때 검토합니다.

생략 / 대안

기존 OS 도구로 대체/병행할 수 있습니다. SSM에는 지원 OS·Agent·등록·권한·endpoint 통신 조건이 필요합니다.

잘못 구성하면

Terraform으로 만들었다고 OS 패치와 운영까지 자동 해결되지는 않습니다.

먼저 준비대상·보존 기간·Snapshot 또는 AWS Backup·RPO/RTO·책임자를 정합니다.

왜 필요한가

잃을 수 없는 데이터와 복구 책임을 먼저 정합니다.

언제 필요한가

데이터 손실/복구 시간 요구와 운영 환경을 결정할 때 확인합니다.

생략 / 대안

폐기 가능한 학습 데이터는 근거를 남기고 범위를 줄일 수 있습니다.

잘못 구성하면

보존/키/계정 접근을 함께 정하지 않으면 백업이 있어도 복구하지 못할 수 있습니다.

먼저 준비격리된 복구 대상·성공 기준·접근·정리 계획을 준비합니다.

왜 필요한가

복구 시간과 데이터 사용 가능 여부를 확인합니다.

언제 필요한가

운영 시작 전과 정책 변경 후 안전한 환경에서 검토합니다.

생략 / 대안

폐기 가능한 환경은 축소할 수 있으나 운영 복구 요구를 자동 충족한다고 간주하지 않습니다.

잘못 구성하면

운영에 바로 복원하면 기존 데이터/서비스에 영향을 줄 수 있습니다. 검증 리소스 비용도 발생할 수 있습니다.

먼저 준비Budget·비용 알림·Owner/Environment 태그와 비용 배분 활성화 범위를 정합니다.

왜 필요한가

예상 지출과 실제 비용의 차이를 빨리 확인합니다.

언제 필요한가

계정 생성과 과금 리소스 구축 전에 알림 수신자와 기준을 정합니다.

생략 / 대안

기존 중앙 관리가 있으면 연결을 확인합니다. Budget 알림은 지출 상한이나 즉시 차단을 보장하지 않습니다.

잘못 구성하면

알림 지연·미수신·Tag 미활성화로 비용을 늦게 발견하거나 배분하지 못할 수 있습니다.

먼저 준비환경별 운영시간·Stop 대상·기동 순서·예외·담당자와 자동화 필요성만 정합니다.

왜 필요한가

불필요한 실행 시간을 줄이되 서비스 중단과 구동 의존성을 고려합니다.

언제 필요한가

개발/테스트의 비업무 시간, SLA와 스케줄 실행 요구가 있을 때 검토합니다.

생략 / 대안

상시 운영은 임의 Stop하지 않습니다. SLA/운영시간 요구가 먼저입니다.

잘못 구성하면

Stop해도 모든 비용이 사라지지 않습니다. 저장소·백업·고정 리소스와 재기동 절차를 확인합니다.

먼저 준비Owner·Environment·Project·Naming 기준과 예외를 정합니다.

왜 필요한가

리소스의 목적·책임·환경을 찾고 비용/정리 기준으로 활용합니다.

언제 필요한가

처음 생성하는 리소스부터 일관된 필수 태그와 이름을 정합니다.

생략 / 대안

학습은 단순화할 수 있습니다. 모든 리소스가 같은 태그 기능을 지원한다고 가정하지 않습니다.

잘못 구성하면

Owner/Environment 누락은 잘못된 삭제와 운영 책임 공백을 만들 수 있습니다.

먼저 준비Repository·환경별 변수·state 접근/잠금·plan 검토·승인·복구 기준을 정합니다.

왜 필요한가

원래 상태·변경 계획·검토·복구의 근거를 연결합니다.

언제 필요한가

팀의 변경 또는 운영 리소스의 반복 구축을 시작할 때 정합니다.

생략 / 대안

학습은 절차를 줄일 수 있습니다. 공유 환경의 승인·변경 기록을 무조건 생략하지 않습니다.

잘못 구성하면

Console 직접 변경과 IaC state가 어긋나면 이후 적용이 예상 밖 변경을 만들 수 있습니다.