DetourCut
← 프로젝트 패턴

AWS WIKI / PROJECT

Terraform 기반 AWS 인프라 구축/운영

신규 웹 인프라 · 팀 단위 변경 관리 · Production

프로젝트 이해

전제조건과 공정별 산출물·완료 조건

Git에서 변경을 검토하고 Terraform으로 AWS 인프라를 구성한 뒤, 서버 운영과 상태 관찰을 별도로 연결합니다.

프로젝트 전체 공정

이 패턴의 중점 단계

설계

일반 인프라 개념과 AWS 구현의 선택

일반적인 작업 구조

일반 개념AWS / 도구 대응

A · 변경 / 배포

  1. Engineer
    개발자 / 운영자
  2. Source Control
    Git 저장소
  3. Review / Pipeline
    CI/CD
  4. IaC Engine
    Terraform
  5. Infrastructure API
    AWS API
  6. Infrastructure
    AWS 리소스

B · 생성 후 운영

  1. OS / Operations
    Systems Manager
  2. Monitoring
    CloudWatch
  • Access ControlIAM
  • State StoreTerraform state
  • Managed ServerEC2

코드·실행 절차·변경 엔진·실제 인프라는 서로 다른 역할입니다. 서버 관리와 모니터링은 필수 실행 순서를 뜻하지 않습니다.

AWS에서 구현하면

기준 흐름: PR → plan 검토 → 승인 → apply

A · 변경 / 배포

리뷰한 코드가 실제 AWS 리소스로

  1. 개발자 / 운영자인프라 코드 작성

B · 생성 후 운영

생성된 리소스에 관리와 관찰을 각각 연결 · SSM → CloudWatch의 필수 순서는 아님

Terraform: 리소스 상태 변경 · Systems Manager: 등록된 서버 관리 · CloudWatch: 상태 관찰

지원 기반 / 관리 대상

  • 변경 이력과 검토
  • 반복 가능한 구성
  • 배포와 운영 역할 분리

주의인프라 생성 ≠ OS 운영 자동 완성

상황별 구성 선택

학습 시나리오 선택

추천 구성

  • PR → fmt / validate → plan → 검토 / 승인 → apply
  • 공유 backend와 환경별 동시 실행 제어

달라지는 점

  • 실제 적용할 plan을 검토하고 변경 시 재승인
  • 배포 Role과 운영 Role을 분리

주의

검증 성공만으로 무승인 apply하지 않습니다. 승인 기능은 CI/CD 제품·플랜별 지원 범위를 확인하세요.

왜 이 구성을 선택했을까?

변경을 검토Git + PR

누가 무엇을 바꿨는지 남깁니다. Git은 리소스를 생성하지 않으며 코드 저장과 리뷰를 맡습니다.

적용 전 확인plan + 승인

검증과 계획을 실제 apply 전에 검토합니다. CI/CD는 Terraform 명령의 실행 순서와 승인 절차를 맡습니다.

구성을 반복IaC + state

원하는 상태를 선언하고 provider로 AWS API를 호출합니다. 리소스 생성만으로 앱 설치나 OS 운영이 끝나는 것은 아닙니다.

서버를 관리명령 / 패치

관리 대상으로 등록된 서버에 운영 절차를 적용합니다. Terraform과 역할을 구분하고 기존 관리 도구와 충돌하지 않게 합니다.

결과를 관찰지표 / 로그 / 알람

배포 성공 이후에도 서비스 상태를 확인합니다. 로그 전송과 알람의 수신 대상은 별도로 구성합니다.

구조 이해 자세히 보기역할 · 필요 이유 · 연결 · 대안

화살표는 변경 작업의 순서입니다. 웹 요청 흐름이 아닙니다. 이 예시의 Terraform은 AWS provider로 인프라를 변경하고, 서버 OS 운영과 모니터링은 별도 설정합니다.

이 프로젝트에 필요한 것

  • Git 저장소와 리뷰
  • Terraform 실행 환경
  • 보호된 state와 동시 실행 제어
  • AWS 배포·운영 권한
  • 서버 관리·모니터링 설정

Git 저장소

역할
인프라 코드와 변경 이력을 보관합니다.
왜 필요한가
변경을 비교하고 리뷰하기 위해 사용합니다.
어떻게 연결되나
개발자 → Git push / PR → CI/CD
없으면 / 대안
로컬 코드만으로도 실행 가능하지만 팀 리뷰와 이력 공유가 어려워집니다.
공식 문서 ↗

CI/CD

역할
검증·plan·승인·apply 단계를 실행합니다.
왜 필요한가
일관된 실행 환경과 검토 절차를 유지합니다.
어떻게 연결되나
Git 변경 감지 → Terraform 명령 실행 → 결과 보고
없으면 / 대안
개인이 수동으로 실행할 수도 있습니다. GitLab CI / Jenkins 등으로 대체 가능합니다.
공식 문서 ↗

Terraform

역할
코드로 원하는 리소스 상태를 정의하고 차이를 적용합니다.
왜 필요한가
인프라 변경을 계획하고 반복하기 위해 사용합니다.
어떻게 연결되나
CI/CD 또는 로컬 → plan → 승인 → apply → AWS provider / API
없으면 / 대안
AWS 전용 IaC는 CloudFormation으로 대체 가능합니다. 이 흐름은 OS 설정을 자동 완성하지 않습니다.
공식 문서 ↗

AWS API

역할
권한을 확인하고 리소스 생성·변경 요청을 처리합니다.
왜 필요한가
Terraform 코드가 실제 AWS 변경으로 이어지는 접점입니다.
어떻게 연결되나
Terraform AWS provider → IAM 권한 확인 → 서비스별 API
없으면 / 대안
콘솔·CLI·CloudFormation도 결국 AWS API를 사용합니다. 이 접점은 생략되지 않습니다.
공식 문서 ↗

AWS 리소스

역할
VPC·EC2·RDS 등 실제 인프라입니다.
왜 필요한가
서비스를 실행할 네트워크·서버·데이터 저장소가 필요합니다.
어떻게 연결되나
AWS API로 생성 / 변경 → 서버 관리와 관찰을 별도 연결
없으면 / 대안
온프레나 다른 클라우드로 대체하려면 해당 인프라 관리 방식과 연결을 따로 설계합니다.
공식 문서 ↗

IAM

역할
CI/CD와 운영자의 AWS 접근 범위를 제한합니다.
왜 필요한가
불필요한 권한과 장기 접근 키를 줄입니다.
어떻게 연결되나
실행 환경 → IAM Role → 허용된 API
없으면 / 대안
AWS 인증·권한은 생략할 수 없습니다. 배포 권한과 서버 운영 권한을 구분합니다.
공식 문서 ↗

Terraform state

역할
코드의 리소스와 실제 리소스 식별자를 연결합니다.
왜 필요한가
변경 추적과 안전한 협업에 필요합니다.
어떻게 연결되나
plan / apply ↔ 접근 제어된 backend · 지원 시 잠금
없으면 / 대안
state를 잃거나 공유 없이 동시에 적용하면 추적과 협업이 위험해집니다. 모든 backend가 잠금을 지원하는 것은 아닙니다.
공식 문서 ↗

EC2

역할
생성 후 애플리케이션과 OS를 운영할 서버입니다.
왜 필요한가
이 예시에서 웹 앱 실행 환경으로 사용합니다.
어떻게 연결되나
Terraform으로 생성 → Agent·Role·통신 설정 → 서버 운영
없으면 / 대안
온프레 서버도 가능하지만 Terraform 관리용 provider나 기존 인프라 도구, 별도 OS 운영이 필요합니다.
공식 문서 ↗

기술 구성

핵심·검토·추가·대체 요소의 역할

구성 요소의 성격

핵심 구성

이 패턴을 설명하는 중심 요소

  • Terraform원하는 상태를 코드로
  • AWS API권한 확인 · 변경 요청
  • AWS 리소스VPC · EC2 · RDS

일반적으로 함께 검토

Production 설계에서 함께 고려

  • Git 저장소코드와 변경 이력·리뷰를 함께 관리
  • CI/CD팀에서 검증과 승인 절차를 자동화할 때
  • Systems Manager생성한 서버의 접근·설정·패치를 관리
  • CloudWatch변경 후 지표·로그·알람 확인
  • IAM배포와 운영의 AWS 작업 권한 검토
  • Terraform state상태 접근·보관·동시 실행 정책 검토

요구사항에 따라 추가

상황에 맞춰 선택할 요소

  • EC2이 예시처럼 서버 OS를 직접 운영할 때
  • Amazon S3팀에서 Terraform state를 원격으로 공유·보관할 때

대체 가능다른 선택과 주의점

가능Terraform으로 AWS 구성AWS provider가 API 호출

조건provider 설정·AWS 권한·state 관리 필요

추가 책임 / 확인

  • Terraform은 다른 provider도 지원하지만 이 샘플은 AWS 인프라 변경에 한정
  • OS 구성과 앱 배포는 별도 작업
Terraform
대체 가능Terraform → CloudFormationAWS 전용 IaC로 대체

조건템플릿·상태 / 스택·변경 절차가 다름

추가 책임 / 확인

  • 두 도구가 같은 리소스를 중복 관리하지 않기
  • 기존 리소스 이관은 별도 계획 필요
Terraform
대체 가능GitHub Actions → 다른 CI/CDGitLab CI / Jenkins 등

조건실행 환경·인증·승인·동시 실행 제어 구성

추가 책임 / 확인

  • init / plan / apply 흐름을 제품에 맞춰 구성
  • 자체 운영 CI는 실행 서버와 업데이트 책임도 검토
CI/CD
대체 가능SSM ↔ 기존 OS 관리 도구대체 또는 병행 가능

조건대상 OS·권한·접근·감사 요구 확인

추가 책임 / 확인

  • 동일 설정을 서로 덮어쓰지 않도록 역할 구분
  • 패치·명령 실행·실패 복구 체계 확보
Systems Manager
대체 가능EC2 → 온프레미스 서버모든 서버를 옮길 필요 없음

조건연결·기존 인프라·OS 관리 책임 필요

추가 책임 / 확인

  • AWS 사설 리소스 접근 시 네트워크 경로 설계
  • 하드웨어 / 가상화·OS·백업·장애 대응
  • Terraform 관리 여부는 해당 provider 지원과 관리 범위에 따라 결정
EC2
조건 있음온프레 서버의 SSM 연동등록·Agent·권한·통신 필요

조건지원 OS, SSM Agent, hybrid activation / IAM Role, AWS endpoint HTTPS 연결

추가 책임 / 확인

  • 지원 기능과 사용 요금 확인
  • 공개 endpoint 또는 적절한 사설 통신 경로 확보
  • 연동 불가 시 기존 OS 관리 도구 유지
Systems Manager
주의apply 성공 ≠ 운영 완료리소스와 OS 운영은 별개

조건앱 배포·패치·로그 수집·알람을 따로 구성

Terraform

공정 × 기술영역

확인 → 설계 → 검증 → 운영
  • 핵심
  • 일반적 검토
  • 조건부
  • 해당 없음
프로젝트 공정별 기술영역 검토 수준
기술영역01요구사항 정리02기본설계03상세설계04IaC 구축 / 변경05테스트06배포 / 이행07운영08인수인계 / 개선

구축 · 테스트 · 이행

구축 설정과 검증·전환·복구 결과

코드 작성부터 운영까지

  1. 01Terraform 코드 작성

    원하는 VPC·EC2·RDS와 환경별 변수 정의. OS 패치 절차와는 구분합니다.

  2. 02Git push / PR

    변경 이력을 남기고 Pull Request로 코드 리뷰를 요청합니다.

  3. 03CI/CD 변경 감지

    검토할 코드 버전을 고정하고 fmt -check로 형식을 확인합니다.

  4. 04terraform init

    backend와 provider를 초기화한 다음 validate로 구성을 검증합니다. plan 전에 수행합니다.

  5. 05terraform plan

    생성·수정·삭제 / 교체할 대상을 확인합니다. plan과 state는 민감 정보로 보호합니다.

  6. 06검토 / 승인

    Production에서 실제 적용할 계획을 검토합니다. 코드 / 계획이 달라지면 재검토합니다.

  7. 07terraform apply

    승인한 plan을 적용합니다. 환경별 잠금·동시 실행 제어와 실행 권한이 필요합니다.

  8. 08AWS 생성 / 변경

    AWS API가 허용된 리소스 변경을 처리합니다. 실패 시 부분 적용 상태를 확인합니다.

  9. 09Systems Manager 운영

    등록과 통신이 준비된 서버에 명령·초기 설정·패치를 수행합니다. apply가 자동으로 실행해 주지는 않습니다.

  10. 10CloudWatch 관찰

    지표·로그·알람으로 변경 이후 상태를 확인합니다. SSM 성공과 무관하게 관찰 체계가 필요합니다.

실제 설정과 동작

실제 설정값 보기기준 구성 · 네트워크 · 접근 제어

시나리오별 참고안과 별개인 학습용 기준 설정입니다. 정답 구성이나 실제 배포 절차를 뜻하지 않습니다.

가정한 상황

  • 신규 웹 시스템: VPC·EC2·RDS 필요
  • 팀 단위 변경 관리 / Production
  • GitHub Actions를 CI/CD 예시로 사용
  • 전체 Terraform 코드나 실제 배포 구성은 제공하지 않음

Repository

network.tf
VPC / Subnet / Security Group 정의
ec2.tf
앱 서버 EC2와 서버용 IAM Role 연결
rds.tf
DB와 subnet group / 접근 제어 정의
variables.tf
CIDR·크기·환경 등 입력 변수 정의
environments/
dev / prod 변수·backend 분리; 비밀 값은 저장소 외부
파일의 의미
.tf 파일명은 정리용; 같은 디렉터리의 코드는 하나의 모듈로 함께 평가

CI/CD

검증
terraform fmt -check → init → validate → plan
검토
PR 리뷰 + 실제 적용 plan 검토 / 승인
실행
승인한 plan으로 apply; 변경 시 재검토
보호
배포 Role / 환경별 동시 실행 제한 / plan 접근·보관 제한

AWS 네트워크

관리 대상
VPC / Subnet / Security Group
역할
서버·DB 배치와 허용 통신 경로 정의

AWS 서버 / DB

EC2
웹 앱 실행 서버; OS / 앱 설정은 별도 운영 작업
RDS
관계형 데이터 저장; 백업 / 가용성 정책 별도 검토

State / 권한

State
접근 제어된 공유 backend; 지원 시 locking 사용
권한
배포와 운영 Role 분리; 최소 권한과 단기 인증 검토
정상 / 장애 동작 보기조건 → AWS 동작 → 결과

검토한 변경을 적용

조건 / 입력팀원이 서버 구성 변경 PR을 제출

AWS 동작

  1. CI/CD가 init / validate / plan 수행
  2. 검토자가 실제 적용 계획을 확인하고 승인
  3. Terraform이 AWS API로 허용된 리소스를 변경
  4. 운영 절차로 서버 설정을 확인하고 CloudWatch로 상태 관찰

결과코드와 적용 이력이 남고 AWS 구성이 변경됩니다. 앱 정상 동작은 별도 확인합니다.

plan에 예상 밖 삭제가 표시

조건 / 입력Production DB의 삭제 / 교체 계획이 나타남

AWS 동작

  1. 검토 단계에서 apply를 승인하지 않음
  2. 변수·리소스 정의·실제 상태 차이와 영향을 확인
  3. 수정 후 새 plan을 생성해 다시 검토

결과이 흐름에서는 승인 전 AWS 변경을 멈춥니다. Terraform 자체가 모든 위험을 자동 차단하는 것은 아닙니다.

이 구성으로 이해할 수 있는 것

  • Git은 코드 / 이력, CI/CD는 실행 절차, Terraform은 리소스 변경, AWS는 실제 인프라
  • Systems Manager와 CloudWatch는 생성 후 관리·관찰을 각각 담당
  • 온프레 서버는 지원·등록·권한·통신 조건과 별도 관리 범위를 확인

운영

서버 관리·관찰·백업과 운영 책임

운영 공정 · 절차와 산출물 →인수인계 · 개선 →운영 비용 확인 →
운영OS / 관찰 체계
  • Terraform 생성 성공만으로 OS 설정·패치가 해결되지 않음
  • SSM Agent·등록·권한·통신 상태 확인
  • CloudWatch 로그 / 알람과 실패 시 대응 체계 마련
운영 역할 자세히 보기역할 · 필요 이유 · 연결 · 대안

Systems Manager

역할
관리 대상으로 등록된 서버의 명령·설정·패치를 수행합니다.
왜 필요한가
서버 접근과 반복 운영 작업을 관리합니다.
어떻게 연결되나
EC2 / 온프레 서버 → Agent·권한·통신 준비 → Systems Manager
없으면 / 대안
기존 OS 자동화 도구와 대체·병행 가능합니다. 온프레 서버는 자동으로 등록되지 않습니다.
공식 문서 ↗

CloudWatch

역할
리소스 지표·로그·알람을 관찰합니다.
왜 필요한가
변경 후 상태와 장애 징후를 확인합니다.
어떻게 연결되나
기본 AWS 지표 / 별도 전송한 앱 로그 → 알람 → 운영자
없으면 / 대안
다른 관찰 도구로 대체 가능합니다. 로그 수집·알람·수신 경로는 따로 설정해야 합니다.
공식 문서 ↗
운영 설정값 보기관리 · 지표 · 로그 · 알람

시나리오별 참고안과 별개인 학습용 기준 설정입니다. 정답 구성이나 실제 배포 절차를 뜻하지 않습니다.

서버 운영

준비
지원 OS / SSM Agent / IAM Role / endpoint 통신
역할
초기 설정·명령 실행·패치 작업을 별도 구성

상태 관찰

지표
EC2 / RDS 등 기본 지표 확인
로그 / 알람
필요한 앱 로그 전송, 임계값·수신 경로·보존 기간 설정

실무 판단

요금·변경·중단·데이터·보안 위험

실무 판단

기준 프로젝트 · 요구사항에 따라 달라짐
예상 비용구성에 따라 다름IaC 흐름에는 고정 AWS 청구액이 없음

IaC 흐름에는 고정 AWS 청구액이 없음

계산 / 판단 가정

  • 리소스 수·크기·실행 시간은 이 패턴에 고정하지 않음
  • CI 실행 환경, backend, 생성된 AWS 리소스의 비용을 따로 확인

별도 확인할 범위

  • Terraform 자체 흐름을 3-Tier 비용과 동일하게 계산하지 않음

생성된 AWS 리소스 별도 과금

apply 이후 EC2·RDS·네트워크·스토리지 사용 비용이 발생합니다. IaC를 쓰는 것과 요금은 별개입니다. AWS Pricing ↗

Backend / CI/CD 사용량에 따라

S3 저장·요청 및 CI 실행 시간/플랜을 확인합니다. 로컬 실행과 관리형 실행의 비용 구조는 다릅니다. Terraform 실행 방식 ↗

SSM / CloudWatch 무료 범위 확인

기능·대상·로그량에 따라 비용이 달라집니다. 운영 체계 전체를 무료라고 가정하지 않습니다. Systems Manager 요금 ↗

언제 과금되는가?

plan과 apply리소스 과금 별도plan만으로 리소스를 생성하지 않음
  • CI 실행이나 state 접근 비용은 생길 수 있음
  • apply로 생성된 리소스는 각 서비스 조건에 따라 과금; 코드 삭제/Git 종료만으로 청구가 끝나지 않음
Terraform plan ↗
정리 / destroy잔여 항목 확인삭제 계획·데이터와 남은 리소스를 확인
  • Terraform 관리 범위 밖 리소스·스냅샷·state backend 등은 남을 수 있음
  • 비용을 줄이려고 운영 DB를 무작정 삭제하지 않기
Terraform destroy ↗
변경 난이도plan으로 판단업데이트 · 교체 · 삭제를 구분

Production apply

조건에 따라 다름

검토한 plan의 수정·삭제·교체 여부로 서비스 영향을 판단

Terraform plan ↗영향 상세 →

교체가 필요한 속성 변경

재생성 필요 가능

provider가 교체로 계획한 속성은 새 리소스와 삭제 순서 확인

Terraform plan ↗영향 상세 →

State / 동시 실행

조건에 따라 다름

지원 backend 잠금과 환경별 실행 제한을 확인

State 잠금 ↗영향 상세 →

CI/CD IAM Role

온라인 변경

권한 변경에 재시작은 없지만 다음 API 실행과 신뢰 정책에 영향

IAM 권장 사항 ↗영향 상세 →
서비스 영향리소스별 영향apply 실패 시 부분 적용 확인
Production apply조건에 따라 다름
기존 환경 조건부
변경 대상과 의존 리소스에 영향; plan은 무중단 보장이 아님
중단 가능성 조건부
교체·서버 정지·DB 변경과 애플리케이션 구조에 따라 다름
데이터 영향 높음
DB 삭제·교체와 데이터 보존/백업 정책을 승인 전에 검토
복구 난이도 높음
Git revert가 데이터/리소스 복구를 자동 보장하지 않음; 새 plan과 복구 절차 필요
비용 영향 조건부
추가·교체 중 병행 리소스 비용을 확인
보안 영향 높음
최소 권한 Role·실제 적용할 plan·Production 승인 보호
Terraform plan ↗
교체가 필요한 속성 변경재생성 필요 가능
기존 환경 높음
주소·식별자·연결 대상이 바뀔 수 있음
중단 가능성 조건부
교체 순서·병행 구성·리소스 제약에 따라 서비스 중단 가능
데이터 영향 높음
데이터 리소스 교체는 백업/이행을 별도 설계
복구 난이도 높음
이전 리소스가 삭제되면 코드만 되돌려 복원할 수 없음
비용 영향 조건부
교체 중 이중 비용과 잔여 스토리지 확인
보안 영향 중간
새 리소스의 Role·SG·암호화 정책 확인
Terraform plan ↗
State / 동시 실행조건에 따라 다름
기존 환경 높음
같은 state의 동시 apply나 잘못된 backend 전환은 추적을 훼손할 수 있음
중단 가능성 조건부
잠금 자체는 서비스 중단이 아님; 충돌한 변경의 결과는 별도
데이터 영향 높음
state의 민감 정보·이력·암호화·접근 제어 보호
복구 난이도 높음
실제 리소스와 일치 여부 확인 없이 과거 state 덮어쓰기 금지
비용 영향 낮음
backend 저장·요청 비용과 충돌로 남은 리소스 확인
보안 영향 높음
state/plan을 공개 저장소나 비신뢰 PR에 노출하지 않기
State 잠금 ↗
CI/CD IAM Role온라인 변경
기존 환경 중간
진행 중/다음 배포의 권한 실패와 부분 적용 확인
중단 가능성 조건부
Role 변경만으로 기존 앱이 중단되는 것은 아님; 공유 역할 변경은 영향 범위 확인
데이터 영향 조건부
과도한 권한이 데이터 삭제/열람을 허용할 수 있음
복구 난이도 중간
이전 정책 복원·새 인증·전파 시간을 확인
비용 영향 낮음
IAM 자체보다 허용된 리소스 생성 범위 확인
보안 영향 높음
단기 인증·최소 권한·비신뢰 PR 분리
IAM 권장 사항 ↗
주요 주의사항state · 승인 · 권한동시 실행과 비밀 값 보호
코드 관리state / plan / 환경
  • state·plan·비밀 값은 Git 제외; backend 접근·암호화·보관 정책 확인
  • 변경 전 plan의 삭제 / 교체 대상 확인
  • dev / prod 변수와 state 관리 범위 분리
배포승인 / 동시 실행
  • Production apply에는 검토 / 승인 단계 고려
  • 같은 state에 여러 apply를 동시에 실행하지 않기
  • backend 잠금 지원과 CI/CD 동시 실행 제한 확인; 잠금 해제는 신중히
권한최소 권한 / Role
  • CI/CD에 관리자 권한을 무조건 부여하지 않기
  • 허용 API·리소스 범위를 제한한 IAM Role 검토
  • 비신뢰 PR에 배포 자격 증명이나 apply 권한 제공하지 않기
변경 / Drift코드와 실제 상태
  • 콘솔 직접 변경은 선언한 코드와 실제 상태를 어긋나게 할 수 있음
  • 다음 plan이 차이를 보여주면 코드를 수정할지 원복할지 검토
  • apply 실패 시 부분 변경과 state를 확인; 무작정 재실행하지 않기
비용 주의CI / backend / 잔여 리소스
  • 생성된 AWS 리소스·backend·CI 실행 비용을 분리해서 확인
  • 교체 중 병행 인프라와 삭제 뒤 남은 스토리지·스냅샷 확인
  • Terraform 적용만으로 OS 관리·로그 비용이 없어지는 것은 아님
운영 주의사항 →

일반적으로 많이 검토하는 선택

절대적인 정답은 아니며 요구사항에 따라 달라집니다.

Production 변경plan 검토 → 승인 → apply

실제 적용할 계획을 검토하고 코드나 상태가 달라지면 다시 계획합니다. 실패한 apply는 부분 적용 상태부터 확인합니다.

Terraform 작업 흐름 ↗
State 협업접근 제어된 원격 backend · 잠금 확인

원격 저장과 환경 분리는 자주 사용하는 방식입니다. 모든 backend가 잠금을 지원하지 않으며 Production 실행 제한도 별도로 구성합니다.

State 잠금 ↗
학습 메모
  • 학습용 참고 흐름입니다. 실제 AWS 배포, 자격 증명, Terraform 전체 코드나 실행 자동화는 추가하지 않습니다.
  • Terraform·Git·CI/CD는 AWS 서비스가 아닌 연결 기술로 구분합니다.
  • SSM 관리 대상은 주로 서버입니다. RDS의 OS를 SSM으로 패치하는 흐름이 아닙니다.
  • 온프레 SSM 연결은 AWS endpoint HTTPS 통신 조건이며, AWS 사설 리소스 접근을 위한 VPN 등의 요구와 별개입니다.