Amazon ECR 권한이 헷갈리는 이유

Amazon ECR은 컨테이너 이미지를 저장하는 서비스지만 권한 구조는 단순하지 않습니다. 이미지를 push하거나 pull하려면 IAM 권한, repository policy, registry policy, 인증 토큰 권한이 함께 맞아야 합니다.

특히 레포별로 접근을 열어야 하는지, 계정의 ECR 전체에 정책을 걸어야 하는지, IAM Role에만 권한을 주면 되는지 헷갈리는 경우가 많습니다.

이 글에서는 ECR 정책을 세 가지로 나눠 설명합니다. 첫째, 레포별로 설정하는 Repository Policy. 둘째, 레지스트리 전체 수준에서 설정하는 Registry Policy. 셋째, 사용자나 Role에 붙이는 IAM Policy입니다.

ECR 권한 구조 한눈에 보기

공식 문서 기준으로 Amazon ECR repository policy는 개별 repository에 붙는 resource-based policy입니다. 특정 사용자, Role, 계정, 서비스가 해당 repository에서 어떤 작업을 할 수 있는지 제어합니다.

Registry policy는 private registry 수준에서 AWS principal에게 권한을 부여하는 정책입니다. repository creation, pull-through cache, replication 같은 레지스트리 수준 기능에서 중요합니다.

IAM Policy는 principal에 붙는 identity-based policy입니다. 사용자가 ECR API를 호출할 수 있는지, 어떤 repository ARN에 접근할 수 있는지 제어합니다.

레포별로 설정하기: ECR Repository Policy

레포별 권한을 주고 싶다면 Repository Policy를 사용합니다. 예를 들어 특정 CI/CD Role만 특정 repository에 push할 수 있게 하거나, 다른 계정의 ECS/EKS 배포 Role이 특정 이미지만 pull할 수 있게 할 때 사용합니다.

Repository Policy는 resource-based policy이므로 Principal을 명시할 수 있습니다. 같은 계정의 Role뿐 아니라 외부 계정의 Role도 Principal로 지정할 수 있습니다.

다만 모든 권한을 repository policy에 몰아넣는 것은 좋지 않습니다. 내부 사용자와 Role의 일반적인 권한은 IAM Policy로 관리하고, cross-account 접근이나 특정 repository 공유는 Repository Policy로 관리하는 방식이 깔끔합니다.

레포 전체가 아니라 계정 전체에 설정하기: ECR Registry Policy

ECR Registry Policy는 개별 repository가 아니라 private registry 수준에서 권한을 부여합니다. 공식 문서 기준으로 registry policy는 private registry level에서 AWS principal에게 권한을 주는 정책입니다.

Registry Policy는 replication configuration, pull-through cache rule creation, repository creation 같은 레지스트리 수준 기능에서 사용됩니다. 최근 ECR은 registry policy에서 모든 ECR action을 정책에 넣을 수 있고, 모든 ECR 요청에 registry policy를 적용할 수 있습니다.

하지만 `ecr:*`처럼 넓게 여는 것은 권장하지 않습니다. 공식 문서도 필요한 feature에 맞는 구체적인 action만 추가하는 것을 모범 사례로 설명합니다.

IAM Policy로 권한 설정하기

IAM Policy는 사용자나 Role이 어떤 ECR API를 호출할 수 있는지 정합니다. 예를 들어 CI Role에는 push 권한, ECS task execution role에는 pull 권한, 운영자 Role에는 describe와 lifecycle policy 관리 권한을 줄 수 있습니다.

ECR에서 중요한 예외가 있습니다. 이미지를 push하거나 pull하려면 `ecr:GetAuthorizationToken` 권한이 필요합니다. 공식 문서 기준으로 이 권한은 IAM Policy를 통해 허용되어야 registry 인증을 할 수 있습니다.

Repository Policy가 특정 repository 접근을 허용하더라도, Docker login을 위한 authorization token 권한이 없으면 push/pull 전에 인증 단계에서 막힐 수 있습니다.

Repository Policy와 IAM Policy는 둘 다 필요한가

공식 문서 기준으로 ECR repository policy와 IAM policy는 모두 권한 평가에 사용됩니다. 같은 계정의 principal이라면 둘 중 하나가 action을 허용해도 권한이 허용될 수 있습니다. 단 명시적 Deny가 있으면 거부됩니다.

다른 계정 접근은 다르게 봐야 합니다. 외부 계정의 Role이 내 repository에 접근하려면 내 repository policy에서 외부 principal을 허용하고, 외부 계정의 IAM Policy에서도 해당 repository 접근을 허용해야 합니다.

따라서 같은 계정 운영은 IAM Policy 중심으로 단순화하고, cross-account 공유는 Repository Policy와 외부 IAM Policy를 함께 설계하는 것이 좋습니다.

이미지 Pull 권한에 필요한 Action

이미지를 pull할 때는 단순히 `ecr:GetDownloadUrlForLayer`만 있으면 되는 것이 아닙니다. 일반적으로 image manifest 조회와 layer 다운로드를 위한 여러 action이 필요합니다.

ECS, EKS, EC2에서 이미지를 pull하는 Role에는 `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage` 권한이 필요합니다.

repository policy로 외부 계정에 pull 권한을 줄 때도 이 action들을 기준으로 최소 권한을 구성하는 것이 좋습니다.

이미지 Push 권한에 필요한 Action

이미지를 push하려면 layer upload를 시작하고, 분할 업로드하고, 업로드를 완료한 뒤 image manifest를 등록하는 권한이 필요합니다.

CI/CD에서 push 권한을 줄 때는 대상 repository ARN을 좁히는 것이 좋습니다. 운영 계정 전체 repository에 push 권한을 주면 잘못된 이미지가 다른 서비스 repository에 올라갈 수 있습니다.

또한 image tag immutability, scan on push, lifecycle policy 같은 저장소 운영 설정도 함께 고려해야 합니다.

레포별 권한 설계 예시

레포별 권한 설계는 서비스 단위로 repository를 나누는 환경에 적합합니다. 예를 들어 `payment-api`, `user-api`, `batch-worker` repository가 있고 각 서비스 CI Role만 자기 repository에 push하도록 구성할 수 있습니다.

배포 Role은 pull 권한만 가져야 하고, CI Role은 push 권한을 가져야 합니다. 운영자 Role은 describe와 lifecycle policy 관리 권한을 별도로 가질 수 있습니다.

이렇게 역할을 분리하면 이미지 오염, 실수 push, 불필요한 repository 접근을 줄일 수 있습니다.

레지스트리 전체 권한 설계 예시

Registry Policy는 개별 repository push/pull보다 플랫폼 운영 기능에 더 가깝습니다. 예를 들어 중앙 플랫폼 계정이 여러 애플리케이션 계정의 repository를 만들거나, cross-account replication을 구성하거나, pull-through cache를 관리하는 경우에 사용합니다.

조직 단위로 ECR을 운영한다면 registry policy는 매우 강한 권한이 될 수 있습니다. 따라서 특정 feature에 필요한 action만 허용하고, 가능하면 특정 principal로 제한해야 합니다.

레지스트리 전체 정책은 실수 영향 범위가 크기 때문에 변경 전후로 CloudTrail, EventBridge, AWS Config 같은 감사 흐름을 함께 두는 것이 좋습니다.

Tag 기반 ECR 권한 제어

Amazon ECR은 tag 기반 권한 제어에도 사용할 수 있습니다. 공식 문서 기준으로 ECR은 `aws:ResourceTag`, `ecr:ResourceTag`, `aws:RequestTag`, `aws:TagKeys` 같은 조건키를 지원합니다.

예를 들어 `Environment=prod` 태그가 붙은 repository에는 특정 운영 Role만 push할 수 있게 하고, 개발 repository에는 개발팀 CI Role만 접근하게 만들 수 있습니다.

다만 태그 기반 권한은 태그 변경 권한과 함께 봐야 합니다. repository tag를 마음대로 바꿀 수 있는 주체가 있으면 권한 우회가 가능해질 수 있습니다.

Cross-Account ECR 접근 권한 설정

다른 계정에서 이미지를 pull하거나 push해야 한다면 cross-account 권한을 설계해야 합니다. 예를 들어 빌드 계정에서 운영 계정 ECR로 push하거나, 운영 계정 ECS가 중앙 ECR 이미지를 pull하는 구조입니다.

이때 repository owner 계정에서는 repository policy로 외부 Role을 Principal에 추가해야 합니다. 외부 계정에서는 해당 Role의 IAM Policy에 ECR action과 대상 repository ARN을 허용해야 합니다.

권한 오류가 발생하면 양쪽 계정의 CloudTrail을 확인해야 합니다. 한쪽 정책만 보면 원인을 놓치기 쉽습니다.

ECR 권한 오류 점검 순서

ECR 권한 오류는 대부분 인증 토큰, repository ARN, cross-account policy, 명시적 Deny, region 불일치에서 발생합니다.

먼저 `ecr:GetAuthorizationToken` 권한이 있는지 확인합니다. 그다음 Docker가 로그인한 registry와 실제 push/pull 대상 repository의 account, region이 맞는지 확인합니다.

그 후 IAM Policy, Repository Policy, Registry Policy, SCP, Permission Boundary를 순서대로 보면 됩니다.

운영 기준: 어떤 정책을 어디에 써야 하나

운영 기준은 명확하게 나누는 것이 좋습니다. 일반 사용자와 애플리케이션 Role의 권한은 IAM Policy로 관리하고, 외부 계정이나 특정 repository 공유는 Repository Policy로 관리합니다.

Registry Policy는 repository 생성, replication, pull-through cache 같은 registry-level 기능에 제한적으로 사용합니다. 모든 repository 접근을 registry policy 하나로 해결하려 하면 영향 범위가 커집니다.

결론적으로 ECR 권한은 레포별, 레지스트리 전체, IAM 권한을 섞어 쓰되 책임 범위를 명확히 해야 합니다.

FAQ

AWS KMS 권한이 헷갈리는 이유

AWS KMS 권한은 일반적인 IAM 권한보다 헷갈립니다. IAM Role에 `kms:Decrypt`를 줬는데도 AccessDenied가 발생하고, 반대로 Key Policy에는 허용된 것 같은데 서비스가 암호화된 데이터를 읽지 못하는 일이 자주 생깁니다.

이유는 KMS 권한이 하나의 정책만으로 결정되지 않기 때문입니다. KMS 키에는 반드시 Key Policy가 있고, 여기에 IAM Policy, grant, SCP, permission boundary, VPC endpoint policy, AWS 서비스 연동 권한이 함께 영향을 줍니다.

가장 중요한 원칙은 Key Policy가 KMS 키 접근 제어의 출발점이라는 점입니다. IAM 정책만으로 KMS 키 사용을 열 수 없고, Key Policy가 IAM 정책을 통한 권한 위임을 허용해야 IAM 권한이 효과를 가집니다.

KMS Key Policy란 무엇인가

KMS Key Policy는 KMS 키에 붙는 리소스 정책입니다. 공식 문서 기준으로 모든 KMS 키는 정확히 하나의 Key Policy를 가져야 하며, 이 정책이 누가 이 키를 어떤 방식으로 사용할 수 있는지를 결정합니다.

Key Policy는 같은 리전의 해당 KMS 키에만 영향을 줍니다. IAM Policy가 여러 리소스와 여러 서비스 작업을 함께 다룰 수 있는 것과 달리, Key Policy는 특정 KMS 키의 최상위 접근 제어로 동작합니다.

따라서 KMS 문제를 볼 때는 IAM Role부터 보는 것이 아니라 해당 KMS 키의 Key Policy를 먼저 확인해야 합니다.

IAM Policy와 KMS Key Policy의 차이

IAM Policy는 IAM 사용자, 그룹, Role에 붙는 정책입니다. 이 정책은 해당 principal이 `kms:Decrypt`, `kms:GenerateDataKey`, `kms:Encrypt` 같은 KMS API를 호출할 수 있는지 결정합니다.

하지만 KMS에서는 IAM Policy만으로 충분하지 않습니다. 공식 문서 기준으로 Key Policy가 IAM 정책 사용을 허용하지 않으면, IAM 정책에서 KMS 권한을 허용해도 효과가 없습니다.

반대로 IAM Policy의 명시적 Deny, SCP의 Deny, permission boundary의 제한은 Key Policy 허용보다 우선해서 권한을 막을 수 있습니다.

Key Policy의 arn:aws:iam:::root는 무엇을 의미하나

KMS Key Policy에서 가장 많이 오해하는 문구가 `arn:aws:iam:::root`입니다. 많은 사람이 이것을 root 사용자에게만 권한을 주는 문구로 이해하지만, KMS 문맥에서는 보통 계정 principal을 의미합니다.

공식 문서 기준으로 이 principal은 AWS 계정과 그 관리자들을 대표합니다. 이 문구가 있다고 해서 계정 안의 모든 IAM Role이 자동으로 KMS 키를 사용할 수 있는 것은 아닙니다.

정확한 의미는 해당 계정이 IAM 정책을 사용해 KMS 키 권한을 위임할 수 있게 한다는 것입니다. 즉 Key Policy가 계정 단위 문을 열고, IAM Policy가 실제 사용자나 Role에게 어떤 작업을 허용할지 결정합니다.

root 사용자 권한과 계정 단위 위임의 차이

`arn:aws:iam:::root`가 Key Policy에 있으면 root 사용자만 키를 쓸 수 있다는 뜻이 아닙니다. KMS에서는 이 문구가 계정 principal로 쓰이며, IAM 정책을 통한 권한 위임을 가능하게 합니다.

예를 들어 Key Policy에 account root principal이 있고, 어떤 IAM Role에 `kms:Decrypt`와 `kms:GenerateDataKey` 권한이 있으면 그 Role은 Key Policy가 허용한 범위 안에서 KMS 키를 사용할 수 있습니다.

반대로 Key Policy에 이 문구가 없고 특정 Role도 직접 허용하지 않았다면, IAM Role에 KMS 권한을 붙여도 사용이 막힐 수 있습니다.

IAM 정책만으로 KMS 키를 사용할 수 없는 이유

KMS 키는 일반 리소스와 다르게 계정이나 키 생성자에게 자동 권한을 주지 않습니다. Key Policy, IAM Policy, grant 중 명시적인 허용이 필요합니다.

IAM Policy는 principal에게 권한을 주지만, KMS Key Policy가 그 principal 또는 계정에게 접근 경로를 열어주지 않으면 허용이 완성되지 않습니다.

그래서 KMS AccessDenied가 발생하면 `Role에 kms:Decrypt가 있는가`만 보면 안 됩니다. `키가 그 Role 또는 계정의 IAM 위임을 받아들이는가`를 반드시 함께 봐야 합니다.

Key Administrator와 Key User 차이

KMS 콘솔에서 키를 만들면 Key Administrator와 Key User를 나누는 흐름을 볼 수 있습니다. 두 역할은 목적이 다릅니다.

Key Administrator는 키 정책 변경, 키 활성화/비활성화, rotation, alias, grant 관리 등 키 관리 작업을 담당합니다. 하지만 기본적으로 암호화와 복호화 같은 데이터 사용 권한을 의미하지는 않습니다.

Key User는 `Encrypt`, `Decrypt`, `GenerateDataKey` 같은 cryptographic operation을 수행하는 principal입니다. 운영에서는 관리자와 사용자를 분리해야 실수나 권한 오남용을 줄일 수 있습니다.

Encrypt, Decrypt, GenerateDataKey 권한 이해

KMS 권한에서 가장 자주 쓰는 작업은 `Encrypt`, `Decrypt`, `GenerateDataKey`입니다. 이름은 비슷하지만 의미가 다릅니다.

`Encrypt`는 plaintext를 KMS 키로 암호화할 때 사용합니다. `Decrypt`는 ciphertext를 복호화할 때 사용합니다. `GenerateDataKey`는 envelope encryption에서 실제 데이터 암호화에 쓸 data key를 생성할 때 사용합니다.

S3, EBS, RDS 같은 서비스는 내부적으로 `GenerateDataKey`, `Decrypt`, `CreateGrant`, `DescribeKey` 등을 사용할 수 있습니다. 따라서 단순히 `kms:Encrypt`만 허용하면 서비스 연동이 실패할 수 있습니다.

AWS 서비스가 KMS 키를 사용할 때 필요한 권한

S3, EBS, RDS, CloudWatch Logs, Lambda, EKS 같은 서비스가 KMS 키를 사용할 때는 사용자 principal만 보지 말고 서비스가 어떤 방식으로 KMS를 호출하는지 봐야 합니다.

많은 AWS 서비스는 KMS grant를 사용해 암호화된 리소스를 생성하거나 사용하는 데 필요한 임시 권한을 얻습니다. 공식 문서 기준으로 grant는 Key Policy와 IAM Policy와 함께 KMS 접근 판단에 사용됩니다.

서비스 연동에서는 `kms:ViaService`, `aws:SourceArn`, `aws:SourceAccount` 같은 조건을 활용해 특정 서비스와 리소스 경로에서만 키를 쓰게 제한할 수 있습니다.

Cross-Account KMS 사용 시 권한 구조

다른 계정의 KMS 키를 사용하려면 양쪽 정책이 모두 맞아야 합니다. 키를 소유한 계정의 Key Policy가 외부 계정 또는 외부 Role을 허용해야 하고, 외부 계정의 IAM Policy도 해당 KMS 키 사용을 허용해야 합니다.

공식 문서 기준으로 cross-account KMS 접근은 Key Policy와 외부 계정 IAM Policy가 함께 필요합니다. 둘 중 하나만 있으면 충분하지 않습니다.

또한 cross-account에서 효과가 있는 KMS 작업은 제한적입니다. 암호화 작업, CreateGrant, DescribeKey 등 사용 중심 작업은 가능하지만, 모든 관리 작업이 외부 계정 권한으로 유효한 것은 아닙니다.

S3, EBS, RDS 암호화에서 자주 막히는 사례

S3에서는 객체 업로드는 되지만 다운로드가 안 되거나, replication이 KMS 권한 때문에 실패하는 경우가 많습니다. 이때는 S3 bucket policy와 IAM Policy뿐 아니라 KMS Key Policy도 봐야 합니다.

EBS에서는 encrypted volume 생성이나 snapshot copy가 KMS 권한 때문에 실패할 수 있습니다. 특히 Auto Scaling, EC2 service-linked role, launch template에서 사용하는 IAM Role 권한이 중요합니다.

RDS에서는 snapshot copy, restore, cross-account snapshot 공유에서 KMS 권한 문제가 자주 발생합니다. KMS 키는 리전 단위이므로 다른 리전 복사에서는 대상 리전의 키와 권한도 확인해야 합니다.

KMS AccessDenied를 점검하는 순서

KMS AccessDenied는 정책이 여러 계층에 걸려 있어 원인을 빠르게 찾기 어렵습니다. 하지만 순서를 정해 보면 대부분 좁힐 수 있습니다.

먼저 CloudTrail에서 어떤 principal이 어떤 KMS action을 호출했는지 확인합니다. 사람이 호출한 것인지, AWS 서비스가 대신 호출한 것인지, assumed role인지 구분해야 합니다.

그다음 Key Policy, IAM Policy, SCP, permission boundary, grant, 조건키를 순서대로 확인합니다. 특히 `kms:ViaService`, encryption context, SourceArn 조건은 실제 요청 값과 조금만 달라도 실패합니다.

운영 기준: Key Policy를 어떻게 작성해야 하나

운영 환경에서는 Key Policy를 너무 단순하게 열어두면 위험하고, 너무 좁게 닫으면 키가 관리 불가능해질 수 있습니다. 기본 계정 위임 문구를 유지하되 실제 사용 권한은 IAM Role 단위로 최소 권한을 주는 방식이 일반적으로 관리하기 쉽습니다.

중요한 키는 Key Administrator와 Key User를 분리하고, key deletion 권한은 제한해야 합니다. 서비스용 키는 `kms:ViaService`와 SourceArn 조건을 검토해 특정 서비스 경로에서만 사용되도록 제한할 수 있습니다.

Cross-account 키는 외부 계정 전체를 열기보다 가능하면 특정 Role을 지정하고, 외부 계정 IAM Policy까지 함께 관리해야 합니다.

FAQ

AWS Backup이 필요한 이유

AWS 환경에서는 EBS snapshot, RDS automated backup, S3 versioning, DynamoDB point-in-time recovery처럼 서비스별 백업 기능이 따로 존재합니다. 작은 환경에서는 각각 설정해도 운영할 수 있지만, 계정과 서비스가 늘어나면 백업 기준이 쉽게 흩어집니다.

AWS Backup은 여러 AWS 리소스의 백업 정책을 한곳에서 관리하고, 백업 작업과 복구 작업을 중앙에서 모니터링하기 위한 서비스입니다. 공식 문서 기준으로 AWS Backup은 백업 정책, 스케줄, 보관 기간, Cross-Region Copy, Cross-Account Copy, 감사와 보고 흐름을 제공해 백업 운영을 표준화합니다.

핵심은 백업을 개별 서비스 설정이 아니라 조직의 데이터 보호 정책으로 다루는 것입니다.

서비스별 백업을 따로 관리할 때 생기는 문제

서비스별 백업을 각각 관리하면 어떤 리소스가 백업되고 있는지, 보관 기간이 얼마인지, 삭제 방지는 되어 있는지, 복구 테스트를 했는지 확인하기 어렵습니다.

예를 들어 EBS는 snapshot이 있지만 EC2 인스턴스 단위 복구 기준이 필요하고, RDS는 자동 백업과 snapshot이 있지만 장기 보관과 계정 간 복사 전략이 필요합니다. S3는 버전 관리만으로는 중앙 백업 정책과 감사 증적을 모두 대체하기 어렵고, DynamoDB는 PITR과 AWS Backup 백업의 목적을 나눠야 합니다.

따라서 운영 환경에서는 리소스별 기능을 이해하되, 백업 정책 자체는 AWS Backup Plan과 Backup Vault 기준으로 통일하는 것이 좋습니다.

AWS Backup이 지원하는 주요 리소스

AWS Backup은 EBS, EC2, RDS, Aurora, DynamoDB, S3, EFS, FSx, Storage Gateway 등 다양한 리소스를 지원합니다. 이 글에서는 실무에서 자주 만나는 EBS, RDS, S3, DynamoDB를 중심으로 설명합니다.

주의할 점은 지원 리소스 목록과 세부 기능은 계속 확장될 수 있다는 점입니다. 실제 설계 시점에는 AWS Backup feature availability 문서에서 해당 리소스가 백업, 복구, 콜드 스토리지, Cross-Region Copy, Cross-Account Copy, full AWS Backup management를 지원하는지 확인해야 합니다.

같은 AWS Backup 안에 있어도 리소스별 동작 방식은 다릅니다. 일부는 네이티브 백업 기능과 같은 기반을 쓰고, 일부는 AWS Backup이 별도 계층으로 동작합니다.

Backup Vault와 Backup Plan 구조

AWS Backup 설계의 기본 단위는 Backup Vault와 Backup Plan입니다. Backup Vault는 recovery point를 저장하는 논리적 저장소이고, Backup Plan은 어떤 주기와 보관 기간으로 어떤 리소스를 백업할지 정의하는 정책입니다.

Vault는 보안 경계에 가깝습니다. Vault별 KMS 키, Vault Access Policy, Vault Lock을 통해 백업 데이터 접근과 삭제 방지 정책을 구성할 수 있습니다.

Backup Plan은 운영 기준입니다. 매일 백업, 주간 백업, 월간 장기 보관, Cross-Region Copy 같은 규칙을 plan 안에 넣고, 리소스 태그나 직접 선택 방식으로 대상 리소스에 적용합니다.

백업 주기, 보관 기간, Lifecycle 설계

백업 주기는 RPO와 비용을 함께 고려해야 합니다. 모든 리소스를 매시간 백업하면 비용과 운영 복잡도가 커지고, 너무 드문 백업은 장애나 삭제 사고가 발생했을 때 복구 지점이 부족합니다.

보관 기간은 서비스 중요도와 규정 준수 요구에 따라 나눠야 합니다. 예를 들어 운영 데이터는 35일 보관, 월간 백업은 1년 보관, 감사 목적 백업은 별도 Vault에 장기 보관하는 식으로 설계할 수 있습니다.

AWS Backup Lifecycle은 지원 리소스에 대해 warm storage에서 cold storage로 전환하고, 보관 기간 만료 후 삭제하는 흐름을 자동화합니다. 다만 모든 리소스가 cold storage 전환을 지원하는 것은 아니므로 공식 feature availability를 확인해야 합니다.

EBS 백업 설계 기준

EBS 백업은 volume 단위 snapshot뿐 아니라 EC2 인스턴스의 복구 관점에서 봐야 합니다. 단일 volume만 복구하면 애플리케이션 구성, 여러 volume 간 정합성, 인스턴스 설정 복원이 누락될 수 있습니다.

AWS Backup은 EBS volume과 EC2 인스턴스 backed by EBS를 백업 대상으로 다룰 수 있습니다. 운영 설계에서는 태그 기반으로 업무 시스템, 환경, 중요도를 분류하고 그에 따라 Backup Plan을 다르게 적용하는 방식이 좋습니다.

중요한 시스템은 단순 snapshot 생성 여부보다 복구 절차가 검증됐는지가 중요합니다. 주기적으로 테스트 계정이나 테스트 VPC에서 복구해 부팅과 서비스 정상 여부를 확인해야 합니다.

RDS와 Aurora 백업 설계 기준

RDS와 Aurora는 자체 자동 백업, snapshot, point-in-time recovery 기능이 있습니다. AWS Backup을 사용할 때는 네이티브 백업과 어떤 관계인지 이해해야 중복 비용과 운영 혼선을 줄일 수 있습니다.

운영 데이터베이스에서는 짧은 RPO를 위한 자동 백업과 PITR, 장기 보관과 계정 간 복사를 위한 AWS Backup 정책을 나눠 생각할 수 있습니다.

RDS 백업 설계에서는 복구 시간, 파라미터 그룹, 옵션 그룹, 네트워크 설정, KMS 키 접근 권한까지 함께 확인해야 합니다. 백업이 있어도 KMS 권한이나 네트워크 준비가 안 되어 있으면 복구가 지연될 수 있습니다.

S3 백업과 버전 관리 차이

S3 Versioning은 객체 변경과 삭제에 대한 이전 버전을 보존하는 기능입니다. 하지만 버전 관리만으로 백업 정책, 중앙 감사, Vault Lock, Cross-Account Copy 같은 요구를 모두 대체하기는 어렵습니다.

AWS Backup for S3는 S3 데이터를 AWS Backup 정책과 Vault 기준으로 관리할 수 있게 합니다. 객체가 많고 변경량이 큰 버킷은 백업 범위, 비용, 복구 시나리오를 신중히 설계해야 합니다.

S3에서는 Versioning, Object Lock, Lifecycle, Replication, AWS Backup의 역할을 구분해야 합니다. Versioning은 객체 변경 이력, Replication은 다른 위치 복제, Object Lock은 객체 삭제 방지, AWS Backup은 중앙 백업 정책과 복구 관리에 가깝습니다.

DynamoDB 백업 설계 기준

DynamoDB는 on-demand backup과 point-in-time recovery를 제공합니다. AWS Backup을 사용하면 DynamoDB 백업도 중앙 백업 정책 안에 넣어 관리할 수 있습니다.

운영 기준으로는 실수 삭제나 잘못된 배포에 대비한 PITR, 장기 보관과 감사 목적의 정기 백업을 나눠 설계하는 것이 좋습니다.

DynamoDB 복구는 테이블 단위로 생각해야 합니다. 복구된 테이블 이름, 인덱스, TTL, Streams, IAM 접근, 애플리케이션 연결 변경까지 절차에 포함해야 합니다.

Cross-Region Copy와 Cross-Account Copy

백업은 원본과 같은 리전, 같은 계정에만 있으면 충분하지 않을 수 있습니다. 리전 장애, 계정 침해, 운영자 실수에 대비하려면 Cross-Region Copy와 Cross-Account Copy를 검토해야 합니다.

AWS Backup은 백업을 다른 리전으로 복사하거나, AWS Organizations 구조 안에서 다른 계정으로 복사하는 기능을 제공합니다. 이를 통해 백업 전용 계정에 recovery point를 모으는 구조를 만들 수 있습니다.

다만 Cross-Account Copy는 Organizations, 권한, KMS 키 정책, Vault Access Policy가 함께 맞아야 합니다. 특히 KMS 암호화 백업은 복사와 복구 권한 설계가 실패 원인이 되기 쉽습니다.

Vault Lock과 삭제 방지 전략

랜섬웨어나 계정 침해 상황에서는 백업 자체가 삭제될 수 있습니다. 따라서 백업 설계에는 보관뿐 아니라 삭제 방지 전략이 필요합니다.

AWS Backup Vault Lock은 Backup Vault에 WORM(write-once-read-many) 모델을 적용해 recovery point의 조기 삭제나 retention 변경을 막는 기능입니다. 공식 문서 기준으로 Governance mode와 Compliance mode가 있으며, Compliance mode는 grace time 이후 훨씬 강한 불변성을 갖습니다.

운영에서는 바로 Compliance mode를 적용하기보다 테스트 Vault에서 보관 기간과 비용 영향을 검증한 뒤 적용해야 합니다. 잘못된 retention을 잠그면 비용과 삭제 불가 문제가 생길 수 있습니다.

복구 테스트와 감사 기준

백업이 성공했다는 것과 복구가 가능하다는 것은 다릅니다. 운영 품질은 백업 성공률보다 복구 테스트 결과로 판단해야 합니다.

정기적으로 EBS, RDS, S3, DynamoDB 복구 테스트를 수행하고, 복구 시간, 데이터 정합성, 애플리케이션 연결, KMS 권한, 네트워크 접근을 확인해야 합니다.

AWS Backup은 작업 이력, CloudWatch, EventBridge, CloudTrail, SNS와 연동해 백업과 복구 활동을 모니터링할 수 있습니다. 감사 관점에서는 Backup Audit Manager도 검토할 수 있습니다.

운영 기준: 백업 정책을 어떻게 나눌까

백업 정책은 모든 리소스에 하나로 적용하기보다 업무 중요도와 복구 요구에 따라 나누는 것이 좋습니다. 예를 들어 Tier 1 서비스는 짧은 RPO와 Cross-Region Copy를 적용하고, 개발 환경은 짧은 보관 기간으로 비용을 줄일 수 있습니다.

태그 기반 백업을 쓰려면 태그 표준이 먼저 필요합니다. 예를 들어 Backup=Daily, Backup=Critical, DataClass=PII, Environment=Prod 같은 태그를 정하고 Backup Plan selection에서 이를 활용할 수 있습니다.

최종 설계 기준은 단순합니다. 백업 대상, 백업 주기, 보관 기간, 삭제 방지, 복사 위치, 복구 테스트, 감사 증적을 문서화하고 자동화해야 합니다.

FAQ

EKS Add-on이란 무엇인가

EKS Add-on은 Amazon EKS 클러스터에서 자주 사용하는 Kubernetes 운영 구성요소를 AWS가 패키징하고 관리할 수 있게 만든 설치 방식입니다. 대표적으로 VPC CNI, CoreDNS, kube-proxy, Amazon EBS CSI Driver, Amazon EFS CSI Driver, AWS Load Balancer Controller 계열 운영 구성요소가 여기에 포함될 수 있습니다.

핵심은 AWS가 해당 Add-on의 호환 버전, 설치 객체, 업데이트 흐름을 EKS API와 연결해 관리한다는 점입니다. 사용자는 kubectl이나 Helm chart를 직접 내려받아 설치하는 대신 EKS 콘솔, AWS CLI, eksctl, Terraform 같은 도구로 Add-on 리소스를 관리합니다.

따라서 EKS Add-on은 단순 설치 편의 기능이 아니라 클러스터 핵심 구성요소의 버전과 수명주기를 AWS 관리 흐름 안에 넣는 방식으로 봐야 합니다.

Helm으로 직접 설치하는 방식과 무엇이 다른가

Helm 설치는 사용자가 chart repository, chart version, values.yaml, image repository, image tag, service account, RBAC, CRD 적용 순서를 직접 통제하는 방식입니다. 자유도가 높고 커스터마이징이 쉽지만 운영 책임도 사용자가 더 많이 가져갑니다.

반면 EKS Add-on은 EKS API가 Add-on 버전과 클러스터 Kubernetes 버전 호환성을 기준으로 설치와 업데이트를 관리합니다. 사용자는 Add-on configuration values로 일부 설정을 바꿀 수 있지만 Helm values처럼 모든 chart 내부 구조를 마음대로 바꾸는 방식은 아닙니다.

즉 Helm은 자유도 중심, EKS Add-on은 AWS 검증과 운영 일관성 중심입니다.

AWS 관리형 Add-on을 쓰면 좋은 경우

EKS Add-on은 클러스터 핵심 구성요소를 표준화하려는 환경에 적합합니다. 특히 여러 EKS 클러스터를 운영하면서 VPC CNI, CoreDNS, kube-proxy, CSI Driver 같은 구성요소 버전을 일관되게 관리해야 한다면 Add-on 방식이 유리합니다.

또한 Kubernetes 버전 업그레이드와 Add-on 버전 호환성을 함께 봐야 하는 조직에서도 유용합니다. AWS가 제공하는 Add-on 버전 목록을 기준으로 어떤 Kubernetes 버전에 어떤 Add-on 버전이 호환되는지 확인할 수 있기 때문입니다.

운영팀 입장에서는 클러스터마다 Helm chart가 제각각인 상황보다 EKS API에서 Add-on 상태와 버전을 조회할 수 있는 구조가 관리하기 쉽습니다.

Helm 설치가 더 적합한 경우

모든 구성요소를 EKS Add-on으로 설치하는 것이 항상 정답은 아닙니다. 특정 chart의 values를 깊게 수정해야 하거나, AWS가 제공하지 않는 버전을 써야 하거나, chart 내부 템플릿을 조직 표준에 맞춰 바꿔야 한다면 Helm이 더 적합합니다.

예를 들어 오픈소스 controller를 빠르게 테스트하거나, 특정 CRD 옵션을 선행 적용해야 하거나, image registry mirror를 강하게 통제해야 하는 환경에서는 Helm이 편할 수 있습니다.

다만 Helm으로 설치한 구성요소는 버전 호환성, 취약점 패치, image tag 관리, rollback, chart repository 변경까지 사용자가 책임져야 합니다.

EKS Add-on 이미지와 버전은 어디서 확인하나

EKS Add-on의 이미지와 버전 정보는 고정된 블로그 글에 적어두기보다 AWS CLI로 확인하는 것이 안전합니다. Add-on 버전과 호환 Kubernetes 버전은 시간이 지나면서 바뀔 수 있기 때문입니다.

AWS CLI의 `describe-addon-versions` 명령은 Add-on 이름, Kubernetes 버전, 아키텍처, compute type, 기본 버전 여부 같은 정보를 확인할 때 사용합니다. 운영 문서에는 특정 버전 문자열을 박제하기보다 확인 명령과 판단 기준을 남기는 것이 좋습니다.

이미지 repository와 실제 pod image는 Add-on 설치 후 Kubernetes 리소스에서 확인할 수 있습니다. 예를 들어 DaemonSet, Deployment, Pod spec의 image 필드를 보면 현재 클러스터에서 실행 중인 이미지를 알 수 있습니다.

Add-on 버전과 Kubernetes 버전 호환성 이해

EKS Add-on에서 가장 중요한 기준은 Kubernetes 버전 호환성입니다. 같은 Add-on이라도 Kubernetes 1.29, 1.30, 1.31에서 권장 버전이 다를 수 있습니다.

`describe-addon-versions` 결과에는 compatibilities 정보가 포함됩니다. 여기서 clusterVersion과 defaultVersion을 확인하면 현재 클러스터 버전에서 기본으로 권장되는 Add-on 버전을 파악할 수 있습니다.

EKS 클러스터를 업그레이드할 때는 control plane 버전만 올리면 끝나지 않습니다. CoreDNS, kube-proxy, VPC CNI, CSI Driver 같은 Add-on 버전도 함께 검토해야 합니다.

AWS Add-on 이미지 레지스트리와 관리 범위

EKS Add-on으로 설치된 구성요소도 결국 Kubernetes Pod로 실행되고, Pod는 컨테이너 이미지를 사용합니다. 차이는 이미지와 manifest 선택을 사용자가 직접 조합하느냐, EKS Add-on 버전을 통해 AWS가 검증한 조합을 쓰느냐입니다.

운영자는 Add-on이 어떤 이미지를 실행하는지 반드시 확인해야 합니다. 보안팀은 이미지 출처, tag, digest, 취약점 스캔 결과를 요구할 수 있고, 플랫폼팀은 특정 버전이 어느 클러스터에 배포됐는지 추적해야 합니다.

실제 실행 이미지는 `kubectl get pod`, `kubectl get deployment`, `kubectl get daemonset`으로 확인하는 것이 가장 직접적입니다.

설정 커스터마이징: Add-on Configuration과 Helm values 차이

Helm은 values.yaml로 chart가 허용하는 거의 모든 값을 조정합니다. 반면 EKS Add-on은 configuration values와 schema를 기준으로 설정을 전달합니다.

이 차이는 운영에서 중요합니다. Helm은 유연하지만 조직마다 설정이 쉽게 갈라질 수 있습니다. EKS Add-on은 설정 범위가 제한될 수 있지만 표준화와 업그레이드 안정성 측면에서 유리합니다.

EKS Add-on을 사용할 때는 `describe-addon-configuration`으로 설정 가능한 schema를 확인하고, 변경 가능한 값과 변경하면 안 되는 값을 분리해야 합니다.

업그레이드와 롤백 관점의 차이

EKS Add-on 업그레이드는 EKS API의 update-addon 흐름을 사용합니다. Add-on 버전과 configuration values를 지정하고, 충돌 처리 방식을 정해 업데이트합니다.

Helm은 helm upgrade와 helm rollback을 사용합니다. chart revision 단위로 롤백할 수 있다는 장점이 있지만, chart가 만든 CRD나 cluster-scoped resource까지 항상 단순하게 되돌릴 수 있는 것은 아닙니다.

운영 기준으로는 EKS Add-on이든 Helm이든 바로 운영 클러스터에 적용하지 말고 테스트 클러스터에서 먼저 확인해야 합니다. 특히 CNI, CoreDNS, kube-proxy, CSI Driver는 클러스터 네트워크와 스토리지에 직접 영향을 줍니다.

EKS Auto Mode에서 Add-on이 달라지는 이유

EKS Auto Mode를 사용하는 경우 일부 클러스터 기능은 AWS가 더 많이 관리합니다. 따라서 기존처럼 모든 네트워크, 스토리지, 로드밸런싱 구성요소를 사용자가 직접 설치·운영하는 방식과 달라질 수 있습니다.

이 글의 핵심은 Auto Mode 여부와 관계없이 관리 경계를 이해하는 것입니다. AWS가 관리하는 영역인지, 사용자가 Helm으로 직접 관리하는 영역인지가 명확해야 장애와 보안 패치 책임을 나눌 수 있습니다.

새 클러스터를 설계할 때는 먼저 EKS Add-on으로 표준화할 항목과 Helm으로 운영할 항목을 나눠야 합니다.

운영 기준: EKS Add-on과 Helm 중 무엇을 선택할까

운영 기준은 단순합니다. 클러스터 핵심 구성요소이고 AWS가 관리형 Add-on으로 제공하며 커스터마이징 요구가 크지 않다면 EKS Add-on을 우선 검토합니다.

반대로 설정 자유도가 중요하거나, AWS Add-on으로 제공되지 않거나, 특정 chart 생태계를 그대로 따라가야 한다면 Helm을 사용합니다.

중요한 것은 한 클러스터 안에서 같은 구성요소를 EKS Add-on과 Helm으로 중복 설치하지 않는 것입니다. 예를 들어 같은 controller나 CNI를 두 방식으로 동시에 관리하면 리소스 충돌과 업그레이드 혼선이 생길 수 있습니다.

FAQ

Amazon Inspector로 EC2와 ECR 취약점을 함께 봐야 하는 이유

EC2와 ECR은 모두 취약점 조사 대상이지만 성격이 다릅니다. EC2는 실행 중인 서버의 운영체제 패키지, 애플리케이션 패키지, 네트워크 도달 가능성까지 함께 봐야 합니다. 반면 ECR은 저장소에 올라간 컨테이너 이미지의 OS 패키지와 언어 패키지 취약점을 중심으로 봅니다.

운영 환경에서는 두 영역이 연결됩니다. 취약한 이미지가 ECR에 남아 있으면 새 배포 때 다시 사용될 수 있고, 취약한 EC2 인스턴스는 이미 실행 중인 워크로드의 공격 표면이 됩니다. 따라서 이미지를 빌드하는 단계, 이미지를 저장하는 단계, 이미지를 실행하는 단계를 나눠서 봐야 합니다.

이 글은 Amazon Inspector를 기준으로 EC2 인스턴스와 ECR 컨테이너 이미지 취약점을 어떻게 조사하고, 어떤 항목을 우선 조치해야 하는지 설명합니다.

Amazon Inspector란 무엇인가: EC2, ECR, Lambda 취약점 관리 범위

Amazon Inspector는 AWS 워크로드의 소프트웨어 취약점과 의도하지 않은 네트워크 노출을 탐지하는 취약점 관리 서비스입니다. EC2, ECR, Lambda 등 여러 리소스 유형을 대상으로 findings를 생성합니다.

EC2에서는 인스턴스에서 수집한 소프트웨어 인벤토리를 보안 권고와 비교해 패키지 취약점을 찾고, 네트워크 도달 가능성도 평가합니다. ECR에서는 private registry에 저장된 컨테이너 이미지를 스캔해 패키지 취약점 finding을 생성합니다.

중요한 점은 Inspector가 단순히 CVE 목록만 보여주는 도구가 아니라는 점입니다. 어떤 리소스에 취약점이 있는지, 심각도는 무엇인지, fix available 여부가 있는지, 실행 중인 컨테이너와 연결되는지까지 운영 우선순위를 판단하는 데 사용할 수 있습니다.

EC2 취약점 스캔 방식: SSM Agent 기반 스캔과 Agentless 스캔 차이

Amazon Inspector의 EC2 스캔은 크게 Agent 기반과 Agentless 방식으로 나눌 수 있습니다. Agent 기반 스캔은 Systems Manager SSM Agent와 Inspector 관련 SSM 리소스를 사용해 인스턴스의 소프트웨어 인벤토리를 수집합니다.

Agentless 스캔은 EBS snapshot을 사용해 인스턴스 볼륨에서 소프트웨어 인벤토리를 수집합니다. 공식 문서 기준으로 Hybrid scanning에서는 SSM으로 관리되는 인스턴스는 Agent 기반으로, SSM 관리가 되지 않는 조건의 일부 인스턴스는 Agentless 방식으로 스캔될 수 있습니다.

실무에서는 SSM 관리 상태가 가장 중요합니다. SSM Agent가 없거나 IAM instance profile이 없거나 VPC endpoint가 누락되면 Inspector가 기대한 방식으로 인벤토리를 수집하지 못할 수 있습니다.

EC2 취약점 스캔 전 체크리스트: SSM Agent, IAM Role, VPC Endpoint

EC2 취약점 조사가 되지 않을 때 가장 먼저 볼 항목은 Inspector 활성화 여부, 리전, SSM managed instance 상태, IAM instance profile, 운영체제 지원 여부입니다.

공식 문서 기준으로 Agent 기반 스캔에서는 EC2 인스턴스가 같은 AWS 계정의 SSM managed instance여야 합니다. SSM Agent 설치 여부만으로는 부족하고, SSM이 인스턴스를 관리할 수 있는 권한과 네트워크 경로가 있어야 합니다.

Private subnet의 인스턴스라면 VPC endpoint도 중요합니다. SSM, ssmmessages, ec2messages, S3, inspector2-telemetry endpoint가 필요한 흐름이 있을 수 있습니다. 인터넷 경로가 없는 서버에서 취약점 스캔이 비정상이라면 이 부분을 먼저 확인해야 합니다.

EC2 Deep Inspection이 필요한 이유: 서버 안의 언어 패키지 취약점 확인

운영체제 패키지만 보는 것으로는 충분하지 않을 수 있습니다. 실제 서버에는 Python, Java, Node.js, Go 같은 언어 생태계의 라이브러리와 애플리케이션 패키지가 함께 존재합니다.

Amazon Inspector의 EC2 agent 기반 스캔은 Linux 인스턴스에서 deep inspection을 통해 애플리케이션 프로그래밍 언어 패키지 취약점도 탐지할 수 있습니다. 이 기능은 서버 안에 설치된 라이브러리 취약점을 더 넓게 볼 때 의미가 있습니다.

다만 deep inspection 결과는 경로 설정과 스캔 방식에 영향을 받을 수 있습니다. 컨테이너 이미지는 ECR에서 보고, 실행 서버의 패키지는 EC2에서 보는 식으로 관점을 분리해야 혼동이 줄어듭니다.

ECR 이미지 스캔 방법: Basic Scanning과 Enhanced Scanning 차이

ECR 이미지 스캔은 Basic scanning과 Enhanced scanning으로 구분됩니다. Basic scanning은 ECR에서 제공하고, Enhanced scanning은 Amazon Inspector와 통합되어 더 넓은 취약점 관리 흐름을 제공합니다.

공식 문서 기준으로 Enhanced scanning을 사용하면 ECR registry 수준에서 운영체제와 프로그래밍 언어 패키지 취약점을 스캔할 수 있습니다. 또한 findings를 Security Hub나 EventBridge 같은 서비스와 연결해 운영 자동화에 활용할 수 있습니다.

실무에서는 운영 저장소에 Enhanced scanning과 continuous scanning을 적용하는 것이 일반적으로 더 유리합니다. 단순히 push 시점만 보는 것이 아니라, 나중에 새 CVE가 추가되었을 때도 기존 이미지의 위험을 다시 평가할 수 있기 때문입니다.

ECR Continuous Scanning이 필요한 이유: 새 CVE와 오래된 이미지 재평가

컨테이너 이미지는 빌드 시점에는 안전해 보일 수 있습니다. 하지만 며칠 뒤 같은 패키지에서 새로운 CVE가 공개되면 이미 저장된 이미지도 위험해집니다. 그래서 push 시점 스캔만으로는 충분하지 않습니다.

Amazon Inspector의 ECR continuous scanning은 새 이미지가 push될 때, 관련 CVE가 데이터베이스에 추가될 때, archived 이미지가 active 상태로 전환될 때 새 스캔을 시작할 수 있습니다.

다만 모든 이미지가 무기한 같은 방식으로 계속 스캔되는 것은 아닙니다. 이미지 push 시점, last-in-use, rescan duration, archived 상태 같은 조건을 이해해야 합니다. 오래된 이미지와 실제 실행 중인 이미지를 구분해서 우선순위를 정하는 것이 좋습니다.

컨테이너 이미지 CVE 우선순위: Severity, Fix Available, In-use Image

취약점 조사는 단순히 Critical 개수만 보는 방식으로 끝내면 안 됩니다. 실제 운영에서는 심각도, exploit 가능성, fix available 여부, 네트워크 노출, 실행 중인 워크로드 여부를 함께 봐야 합니다.

EC2에서는 인터넷에서 접근 가능한 서버인지, 보안 그룹과 네트워크 경로가 어떤지, 패키지 업데이트가 가능한지 확인해야 합니다. ECR에서는 해당 이미지가 실제 ECS task나 EKS pod에서 사용 중인지가 중요합니다.

Amazon Inspector는 finding 단위로 리소스, 취약 패키지, 버전, 수정 버전, 심각도, CVE 정보를 제공합니다. 운영자는 이 정보를 패치 우선순위와 배포 차단 기준으로 바꿔야 합니다.

AWS CLI로 EC2/ECR 취약점 조회하는 방법

콘솔에서 findings를 보는 것도 가능하지만, 운영 자동화나 반복 점검에서는 AWS CLI와 API를 함께 쓰는 것이 좋습니다. 특히 ListCoverage, ListFindings, BatchGetFinding 같은 흐름을 사용하면 스캔 대상과 결과를 분리해서 볼 수 있습니다.

아래 예시는 실제 계정 값 없이 구조만 보여주는 샘플입니다. 운영 환경에서는 리전, 필터 조건, 출력 필드를 조직 기준에 맞게 조정하면 됩니다.

CLI 결과를 그대로 외부 알림에 보내면 리소스명, ARN, 계정 정보가 포함될 수 있습니다. 알림이나 보고서에는 필요한 필드만 추출하는 방식이 안전합니다.

Security Hub와 EventBridge로 취약점 알림 자동화하기

취약점 조사는 발견에서 끝나면 의미가 약합니다. Critical finding이 생성되면 보안 채널에 알림을 보내고, 티켓을 만들고, 담당 서비스 팀이 조치할 수 있어야 합니다.

Amazon Inspector findings는 Security Hub와 통합해 중앙 보안 대시보드로 모을 수 있습니다. EventBridge를 사용하면 특정 심각도나 특정 리소스 유형의 finding을 조건으로 SNS, Lambda, Step Functions, 티켓 시스템 연동을 시작할 수 있습니다.

예를 들어 ECR 이미지에서 Critical CVE가 발견되면 CI/CD 배포를 중단하고, EC2에서 네트워크 노출이 있는 Critical finding이 발견되면 운영 알림을 별도로 보내는 방식입니다.

EC2 패치와 ECR 이미지 재빌드 전략 차이

EC2 취약점은 보통 패키지 업데이트, AMI 교체, 인스턴스 재배포, 보안 그룹 조정으로 조치합니다. 운영 중인 서버라면 패치 윈도우와 롤백 계획이 필요합니다.

ECR 이미지 취약점은 기존 컨테이너를 직접 고치는 방식이 아닙니다. Dockerfile, base image, dependency lock file을 수정하고 이미지를 재빌드한 뒤 새 태그 또는 digest로 배포해야 합니다.

따라서 같은 CVE라도 EC2에서는 패치 관리 이슈이고, ECR에서는 이미지 공급망과 CI/CD 이슈입니다. 두 흐름을 하나의 보안 backlog로 모으되 조치 방식은 분리해야 합니다.

EC2/ECR 취약점 조사 운영 절차

실무에서는 취약점 수를 줄이는 것보다 위험이 큰 취약점을 빨리 찾고 조치하는 구조가 중요합니다. 모든 finding을 같은 우선순위로 보면 운영팀이 감당하기 어렵습니다.

가장 먼저 인터넷 노출 EC2, 운영 ECR 이미지, 실행 중인 ECS/EKS workload, Critical/High finding을 우선순위로 둡니다. 그다음 fix available 여부와 서비스 영향도를 기준으로 조치 순서를 정합니다.

반복 운영을 위해서는 주간 리포트, 긴급 알림, 예외 처리, 조치 완료 검증을 분리하는 것이 좋습니다.

Amazon Inspector 사용 시 주의할 한계와 오해

Inspector finding이 없다고 해서 보안 위험이 없다는 뜻은 아닙니다. 지원하지 않는 OS, 스캔 제외 태그, SSM 관리 실패, archived 이미지, 오래된 이미지 정책, private subnet 네트워크 경로 문제 때문에 coverage에서 빠질 수 있습니다.

또한 취약점 스캔은 런타임 행위를 모두 설명하지 않습니다. 컨테이너가 실제로 악성 행위를 하는지, 프로세스가 어떤 네트워크 연결을 만드는지, 권한이 과도한지는 별도의 런타임 보안과 로그 분석이 필요합니다.

그래서 EC2/ECR 취약점 조사는 GuardDuty, Security Hub, CloudTrail, EKS Runtime Monitoring, CI/CD 보안 검사와 함께 봐야 합니다.

FAQ

EventBridge를 실무 트리거 허브로 보는 이유

Amazon EventBridge는 AWS 서비스, SaaS, 사용자 애플리케이션에서 발생한 이벤트를 받아 조건에 맞는 Target으로 전달하는 이벤트 라우팅 서비스입니다. 운영 관점에서는 특정 상황이 발생했을 때 알림, 자동 조치, 후속 워크플로를 실행하는 트리거 허브로 볼 수 있습니다.

예를 들어 Root 계정 로그인은 보안 알림으로 보내고, S3 객체 업로드는 파일 검증 Lambda로 보내고, GuardDuty 탐지는 보안 티켓 생성으로 연결하고, RDS 장애 이벤트는 운영 채널로 보낼 수 있습니다.

EventBridge를 잘 쓰려면 먼저 이벤트를 만드는 주체, 이벤트 패턴, 대상, 실패 처리 방식을 분리해서 이해해야 합니다.

Event Pattern의 기본 구조

EventBridge Rule은 들어온 이벤트가 Event Pattern과 일치할 때 Target을 호출합니다. 패턴은 보통 `source`, `detail-type`, `detail`로 구성됩니다.

AWS 공식 문서 기준으로 EventBridge는 이벤트 패턴에 명시된 필드만 비교하고, 패턴에 없는 다른 필드는 무시합니다. 따라서 너무 넓게 잡으면 의도하지 않은 이벤트까지 매칭될 수 있습니다.

실무에서는 먼저 `source`와 `detail-type`으로 큰 범위를 줄이고, 그다음 `detail.eventName`, `detail.state`, `detail.severity` 같은 세부 필드로 좁히는 방식이 좋습니다.

Root 계정 로그인 알림 트리거

Root 계정 로그인은 운영 환경에서 가장 먼저 자동 알림을 구성해야 하는 이벤트 중 하나입니다. Root는 모든 권한을 가진 계정이므로 로그인 자체를 보안 이벤트로 취급하는 것이 좋습니다.

AWS Sign-In 이벤트는 EventBridge와 CloudTrail 경로로 확인할 수 있습니다. Root 로그인 알림은 CloudTrail 기반 ConsoleLogin 이벤트에서 userIdentity type이 Root인 경우를 잡는 방식이 실무에서 많이 사용됩니다.

대상은 SNS, Slack 연동 Lambda, 보안 운영 티켓 생성 Lambda 등으로 연결할 수 있습니다.

S3 객체 업로드 트리거

S3 객체 업로드 이벤트는 파일 검증, 이미지 변환, 데이터 파이프라인 시작, 메타데이터 등록 같은 자동화에 자주 사용됩니다.

S3가 EventBridge로 이벤트를 보내도록 구성하면 `Object Created` 계열 이벤트를 Rule에서 필터링할 수 있습니다. 특정 버킷 또는 특정 prefix만 처리하도록 조건을 줄이는 것이 좋습니다.

단순 Lambda 실행이면 S3 이벤트 알림도 가능하지만, 여러 대상 라우팅과 중앙 이벤트 관리를 원하면 EventBridge가 더 유연합니다.

S3 객체 삭제 트리거

S3 객체 삭제 이벤트는 중요 파일 삭제 감지, 백업 검증, 데이터 무결성 점검에 사용할 수 있습니다.

특히 로그, 감사 증적, 원본 데이터가 삭제되는 경우에는 알림만 보내지 말고 삭제 주체와 CloudTrail 이벤트를 함께 확인하는 구조가 좋습니다.

버전 관리가 켜진 버킷에서는 삭제 마커 생성과 실제 버전 삭제가 다를 수 있으므로 이벤트 의미를 정확히 해석해야 합니다.

S3 객체 태그 변경 트리거

객체 태그는 데이터 분류, 보존 정책, 처리 상태를 표현하는 데 자주 사용됩니다. 태그 변경 이벤트를 잡으면 데이터 상태 변경에 따라 후속 작업을 실행할 수 있습니다.

예를 들어 `scan=clean` 태그가 붙으면 다음 파이프라인을 실행하고, `retention=long` 태그가 붙으면 별도 보존 정책 검증을 수행하는 식입니다.

태그 이벤트는 객체 업로드 이벤트보다 업무 의미가 명확할 수 있으므로 데이터 처리 자동화에 유용합니다.

GuardDuty Malware Protection for S3 탐지 트리거

GuardDuty Malware Protection for S3는 S3에 업로드된 객체를 스캔하고 결과를 EventBridge 이벤트로 보낼 수 있습니다.

이 이벤트를 활용하면 악성 파일 탐지 시 격리 Lambda를 실행하거나, 보안 채널로 알림을 보내거나, 객체 태그를 기준으로 다운로드 차단 흐름을 만들 수 있습니다.

이벤트 이름은 AWS 공식 EventBridge GuardDuty 이벤트 목록에서 `GuardDuty Malware Protection Object Scan Result`로 확인할 수 있습니다.

GuardDuty 악성 파일 탐지 결과만 필터링하기

모든 스캔 결과를 알림으로 보내면 노이즈가 커집니다. 실무에서는 악성 파일이 발견된 결과만 별도 Rule로 분리하는 편이 좋습니다.

GuardDuty Malware Protection for S3 결과에서 위협이 발견된 상태만 필터링하면 긴급 알림, 격리, 티켓 생성 같은 대응을 자동화할 수 있습니다.

세부 필드명은 이벤트 샘플과 공식 문서의 이벤트 구조를 기준으로 테스트해야 합니다. Rule을 만들기 전 `test-event-pattern`으로 샘플 이벤트가 매칭되는지 확인하는 것이 안전합니다.

GuardDuty Malware Protection 상태 이상 감지

악성 파일 탐지 결과뿐 아니라 보호 상태 자체도 감시해야 합니다. Malware Protection이 Warning 또는 Error 상태가 되면 스캔 누락 가능성이 생길 수 있습니다.

이런 상태 이벤트는 보안 탐지 품질을 보장하기 위한 운영 알림으로 적합합니다. 대상은 SNS, Slack Lambda, OpsItem 생성 Lambda로 연결할 수 있습니다.

탐지 결과와 상태 이상 이벤트는 서로 다른 Rule로 분리하는 것이 좋습니다.

CloudTrail API 이벤트를 EventBridge에서 잡는 방식

EventBridge는 AWS 서비스가 직접 보내는 서비스 이벤트뿐 아니라 CloudTrail을 통해 전달되는 API 이벤트도 처리할 수 있습니다.

CloudTrail 기반 이벤트는 누가 어떤 API를 호출했는지 감지하는 데 유용합니다. 예를 들어 CloudTrail 중지, IAM 권한 변경, 보안 설정 삭제 같은 작업을 잡을 수 있습니다.

패턴은 보통 `detail-type`을 `AWS API Call via CloudTrail`로 두고, `detail.eventSource`와 `detail.eventName`으로 좁힙니다.

IAM 위험 작업 감지

IAM 변경 이벤트는 보안 운영에서 매우 중요합니다. Access Key 생성, 사용자 정책 연결, 인라인 정책 추가, 콘솔 로그인 프로필 생성은 권한 상승이나 계정 탈취 후속 행위일 수 있습니다.

이벤트를 잡으면 보안 담당자에게 알림을 보내거나, 특정 조건에서는 자동으로 키 비활성화나 티켓 생성을 연결할 수 있습니다.

다만 자동 차단은 서비스 장애로 이어질 수 있으므로 초기에는 알림과 승인 워크플로부터 적용하는 것이 좋습니다.

CloudTrail 중지 또는 변경 감지

CloudTrail은 감사 로그의 핵심입니다. 공격자가 흔적을 줄이기 위해 CloudTrail을 중지하거나 Trail을 삭제하려는 시도를 할 수 있습니다.

StopLogging, DeleteTrail, UpdateTrail 같은 이벤트는 긴급도 높은 보안 이벤트로 분류하는 것이 좋습니다.

이 이벤트는 SNS 알림뿐 아니라 Security Hub 커스텀 Finding 생성, Incident Manager 연결, Step Functions 기반 조사 플로우로 확장할 수 있습니다.

Security Hub Findings 라우팅

Security Hub는 여러 보안 탐지 결과를 모으는 서비스입니다. EventBridge를 사용하면 특정 심각도나 워크플로 상태에 따라 Finding을 라우팅할 수 있습니다.

예를 들어 CRITICAL 또는 HIGH Finding만 보안 채널로 보내고, 특정 ProductName에서 들어온 결과는 별도 자동 조치로 연결할 수 있습니다.

Security Hub 이벤트는 보안 운영 자동화의 중앙 입력으로 쓰기 좋습니다.

EC2 상태 변경 트리거

EC2 인스턴스 상태 변경은 EventBridge에서 직접 받을 수 있는 대표적인 서비스 이벤트입니다.

인스턴스가 stopped, terminated 상태가 되었을 때 운영 알림을 보내거나, 태그 기반으로 자동 복구 워크플로를 실행할 수 있습니다.

EC2 이벤트는 best effort 전달로 설명되므로, 중요한 자동 복구는 CloudWatch Alarm, Auto Scaling, SSM Automation과 함께 설계하는 것이 좋습니다.

ECS Task 실패 또는 Batch Job 실패 알림

ECS와 Batch는 작업 실행 상태를 EventBridge로 보낼 수 있습니다. 배치 처리, 파일 변환, 데이터 적재 작업이 실패했을 때 알림과 재처리를 자동화하기 좋습니다.

ECS Task는 STOPPED 상태와 stoppedReason을 함께 보고, Batch Job은 FAILED 상태를 기준으로 잡는 식으로 설계합니다.

실무에서는 단순 알림 외에 실패 이벤트를 SQS에 적재해 재처리 워커가 가져가도록 설계할 수 있습니다.

RDS 이벤트 알람 트리거

RDS는 DB 인스턴스와 클러스터 상태 변화, 장애 조치, 백업, 스냅샷 관련 이벤트를 EventBridge로 보낼 수 있습니다.

운영에서는 DB instance failover, stopped, restarted, backup failure, snapshot failure 같은 이벤트를 알림 대상으로 잡는 것이 좋습니다.

RDS는 서비스 영향도가 크기 때문에 EventBridge 알림과 CloudWatch Alarm, RDS Event Subscription, 장애 대응 런북을 함께 설계하는 편이 안전합니다.

Target 연결 패턴

EventBridge Rule은 최대 여러 Target으로 이벤트를 보낼 수 있습니다. 공식 문서 기준으로 Rule은 이벤트 패턴과 일치하는 이벤트를 Target으로 전달합니다.

일반적인 Target은 Lambda, SNS, SQS, Step Functions, ECS Task, Batch Job, CloudWatch Logs입니다. 알림은 SNS, 비동기 버퍼링은 SQS, 워크플로는 Step Functions, 실행 작업은 Lambda/ECS/Batch가 적합합니다.

대상에 따라 EventBridge가 권한을 가져야 합니다. Lambda나 SNS처럼 리소스 기반 정책이 필요한 경우도 있고, ECS나 Batch처럼 RoleArn이 필요한 경우도 있습니다.

실패 재시도와 DLQ 설계

EventBridge Target 호출이 실패할 수 있으므로 RetryPolicy와 DeadLetterConfig를 함께 설계해야 합니다.

AWS 공식 문서 기준으로 DLQ는 실패한 이벤트를 나중에 처리할 수 있도록 보관하는 SQS 표준 큐입니다. 권한 누락, 대상 리소스 없음, 타임아웃 같은 오류를 분석하는 데 도움이 됩니다.

운영 환경에서는 중요한 보안 이벤트와 자동화 이벤트에 DLQ를 붙이고, DLQ 메시지가 쌓이면 별도 알림을 보내도록 구성하는 것이 좋습니다.

EventBridge 트리거 설계 시 주의할 점

첫째, 패턴을 너무 넓게 잡지 않아야 합니다. `source`만 지정하면 해당 서비스의 많은 이벤트가 Target으로 흘러갈 수 있습니다.

둘째, 자동 조치 루프를 주의해야 합니다. Lambda가 이벤트를 처리한 뒤 다시 같은 조건의 이벤트를 만들면 무한 반복이 발생할 수 있습니다.

셋째, 이벤트 안의 민감정보를 외부 알림으로 그대로 보내지 않아야 합니다. 알림에는 계정 ID, ARN, 사용자명, 객체 키, IP 등이 포함될 수 있으므로 필요한 필드만 InputTransformer로 줄이는 방식이 좋습니다.

넷째, 모든 이벤트가 동일한 보장 수준으로 전달되는 것은 아닙니다. 직접 서비스 이벤트, CloudTrail 기반 이벤트, 각 서비스의 delivery type을 확인하고 중요한 자동화는 보조 탐지 수단을 함께 둬야 합니다.

FAQ

S3 수명 주기 설정이 필요한 이유

S3는 저장 용량이 늘어날수록 비용 구조를 함께 관리해야 합니다. 오래된 로그, 백업 파일, 분석 원본 데이터, 임시 업로드 객체를 계속 Standard에 두면 운영 비용이 커질 수 있습니다.

S3 Lifecycle은 객체의 보관 기간과 접근 패턴에 따라 스토리지 클래스를 전환하거나, 더 이상 필요 없는 객체를 만료 처리하는 규칙입니다. AWS 공식 문서에서도 Lifecycle은 객체를 비용 효율적으로 저장하기 위한 핵심 기능으로 설명합니다.

중요한 점은 수명 주기 규칙이 단순 삭제 기능이 아니라는 것입니다. 전환, 만료, 이전 버전 정리, 삭제 마커 정리, 멀티파트 업로드 삭제까지 포함한 데이터 관리 정책으로 봐야 합니다.

수명 주기 규칙 범위 설정

수명 주기 규칙은 버킷 전체에 적용할 수도 있고, 특정 prefix, 객체 태그, 객체 크기 조건으로 제한할 수도 있습니다. 모든 객체에 같은 정책을 적용하면 단순하지만, 실제 운영에서는 데이터 성격이 다르기 때문에 범위를 나누는 것이 좋습니다.

예를 들어 `logs/` 경로는 30일 후 저비용 클래스로 전환하고, `tmp/` 경로는 7일 후 삭제하며, `archive/` 경로는 장기 보존용으로 Glacier 계열에 보내는 방식입니다.

규칙 범위를 잘못 잡으면 아직 필요한 객체가 저비용·저속 저장소로 이동하거나 삭제될 수 있습니다. 적용 전 prefix와 태그 체계가 실제 객체 구조와 맞는지 확인해야 합니다.

수명 주기 규칙 생성 화면에서는 먼저 규칙 이름과 적용 범위를 정하고, 그다음 현재 버전 전환, 이전 버전 전환, 객체 만료, 멀티파트 업로드 정리 같은 작업을 선택합니다.

접두사, 태그, 객체 크기 필터

prefix 필터는 객체 키 경로를 기준으로 규칙을 적용합니다. 로그, 백업, 업로드 임시 파일처럼 경로 설계가 명확한 버킷에서 가장 많이 사용됩니다.

태그 필터는 객체의 업무 의미를 기준으로 적용할 때 유용합니다. 예를 들어 `retention=long`, `data-class=raw`, `delete-after=30d` 같은 태그를 기준으로 수명 주기를 다르게 적용할 수 있습니다.

객체 크기 필터는 작은 객체를 저비용 클래스로 전환할 때 발생할 수 있는 비효율을 줄이는 데 도움이 됩니다. 일부 스토리지 클래스는 최소 객체 크기나 최소 보관 기간을 고려해야 하므로 비용 구조를 같이 봐야 합니다.

현재 버전 스토리지 클래스 전환

현재 버전 전환은 객체가 생성된 뒤 일정 기간이 지나면 Standard에서 Standard-IA, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Deep Archive 같은 스토리지 클래스로 이동시키는 작업입니다.

접근 빈도가 줄어드는 데이터라면 저비용 스토리지 클래스로 전환해 비용을 줄일 수 있습니다. 다만 조회 비용, 최소 보관 기간, 복원 시간이 달라지므로 단순히 저장 단가만 보고 결정하면 안 됩니다.

로그나 백업처럼 일정 기간 이후 거의 조회하지 않는 데이터는 전환 효과가 큽니다. 반대로 자주 읽히거나 예측이 어려운 데이터는 Intelligent-Tiering을 먼저 검토하는 편이 안전할 수 있습니다.

이전 버전 스토리지 클래스 전환

버전 관리가 켜진 버킷에서는 같은 객체 키에 여러 버전이 쌓입니다. 현재 버전은 서비스에서 사용되지만, 이전 버전은 복구 목적 외에는 자주 읽히지 않는 경우가 많습니다.

이전 버전 전환 규칙을 사용하면 오래된 버전을 저비용 스토리지 클래스로 이동할 수 있습니다. 실수 삭제나 덮어쓰기 복구 가능성은 유지하면서 저장 비용을 낮추는 방식입니다.

다만 이전 버전을 너무 빨리 아카이브하면 장애 복구나 운영 복원이 느려질 수 있습니다. 복구 목표 시간과 비용 절감을 함께 고려해야 합니다.

객체 만료와 삭제 마커 정리

만료 규칙은 일정 기간이 지난 객체를 S3가 자동으로 삭제하도록 하는 설정입니다. 임시 파일, 처리 완료 데이터, 오래된 로그처럼 보존 기간이 명확한 데이터에 적합합니다.

버전 관리가 켜진 버킷에서는 삭제가 곧바로 객체 제거를 의미하지 않을 수 있습니다. 삭제 마커가 생성되고 이전 버전이 남을 수 있기 때문입니다.

따라서 버전 관리 버킷에서는 현재 버전 만료, 이전 버전 만료, 만료된 객체 삭제 마커 정리를 함께 봐야 합니다. 삭제 마커를 방치하면 객체 목록과 운영 관리가 복잡해질 수 있습니다.

불완전 멀티파트 업로드 삭제

대용량 파일 업로드 중 실패하거나 중단되면 완료되지 않은 멀티파트 업로드 조각이 남을 수 있습니다. 이 조각들은 객체로 보이지 않아도 저장 비용을 발생시킬 수 있습니다.

수명 주기 규칙에는 완료되지 않은 멀티파트 업로드를 일정 기간 후 삭제하는 작업이 있습니다. 대용량 업로드가 많은 버킷에서는 이 설정을 기본 점검 항목으로 보는 것이 좋습니다.

특히 데이터레이크 적재, 백업 업로드, 미디어 파일 업로드처럼 대용량 객체가 많은 환경에서는 멀티파트 업로드 정리만으로도 불필요한 비용을 줄일 수 있습니다.

복제 규칙과 수명 주기를 함께 볼 때 주의할 점

복제와 수명 주기를 함께 사용할 때는 원본 버킷과 대상 버킷의 정책을 분리해서 봐야 합니다. 원본에서 객체가 전환되거나 만료되는 시점과 대상 버킷에서 복제본이 보존되는 시점이 다를 수 있습니다.

백업 목적의 복제라면 대상 버킷에서 원본보다 긴 보존 기간을 둘 수 있습니다. 분석 목적의 복제라면 대상 버킷에서 더 빨리 저비용 클래스로 전환할 수도 있습니다.

복제된 객체의 태그, 삭제 마커, KMS 암호화 상태가 수명 주기 규칙에 어떤 영향을 주는지도 확인해야 합니다. 복제와 수명 주기는 모두 비용 최적화와 데이터 보존에 직접 영향을 줍니다.

관리 화면에서는 수명 주기 규칙, 복제 규칙, 인벤토리 구성이 함께 보입니다. 비용 최적화는 수명 주기만 보는 것이 아니라 복제본 보존 기간과 인벤토리 보고서까지 함께 확인해야 합니다.

Intelligent-Tiering Archive 구성

S3 Intelligent-Tiering은 접근 패턴이 변하거나 예측하기 어려운 데이터의 비용을 자동으로 최적화하기 위한 스토리지 클래스입니다. AWS 공식 문서에 따르면 접근 패턴을 모니터링해 비용 효율적인 액세스 계층으로 자동 이동합니다.

Intelligent-Tiering에는 자주 접근하는 계층과 드물게 접근하는 계층 외에도 Archive Access, Deep Archive Access 같은 선택적 아카이브 계층을 활성화할 수 있습니다.

아카이브 계층은 장기간 거의 접근하지 않는 객체에 적합하지만, 접근 시 비동기 복원이 필요할 수 있습니다. 따라서 바로 읽어야 하는 데이터에는 신중하게 적용해야 합니다.

Intelligent-Tiering Archive 구성은 장기간 접근하지 않는 객체를 아카이브 계층으로 자동 이동시키는 설정입니다. 접근 시 복원이 필요할 수 있으므로 즉시 조회가 필요한 데이터에는 적용 범위를 제한해야 합니다.

실무 권장 설정

수명 주기 규칙은 데이터 유형별로 나눠 설계하는 것이 좋습니다. 로그, 백업, 임시 파일, 분석 원본 데이터는 보존 기간과 조회 패턴이 다릅니다.

삭제 규칙은 가장 신중하게 적용해야 합니다. 한 번 만료된 객체는 복구가 어렵거나 불가능할 수 있으므로 테스트 버킷이나 제한된 prefix로 먼저 검증하는 것이 좋습니다.

접근 패턴을 예측하기 어려운 데이터는 무리하게 Glacier 계열로 직접 전환하기보다 Intelligent-Tiering을 검토합니다. 반대로 보존 기간과 접근 패턴이 명확한 데이터는 Lifecycle 전환과 만료 규칙이 더 단순하고 예측 가능합니다.

FAQ

S3 복제 규칙이 필요한 이유

S3 복제는 소스 버킷에 새로 생성되거나 변경된 객체를 다른 버킷으로 자동 복사하는 기능입니다. 같은 리전 복제와 교차 리전 복제를 모두 지원하며, 대상 버킷은 같은 계정 또는 다른 계정에 있을 수 있습니다.

복제는 백업, 재해 복구, 데이터 주권, 로그 중앙화, 분석 환경 분리, 다른 계정으로의 데이터 배포에 사용됩니다. 단순 복사와 달리 규칙, 권한, 암호화, 버전 관리가 함께 얽혀 있습니다.

중요한 점은 라이브 복제는 규칙을 설정한 뒤 새로 쓰이는 객체를 대상으로 한다는 것입니다. 기존 객체까지 복제하려면 S3 Batch Replication 같은 별도 방식을 검토해야 합니다.

복제 규칙 이름, 상태, 우선순위 의미

복제 규칙에는 이름, 상태, 우선순위가 있습니다. 이름은 운영자가 규칙을 식별하기 위한 값이고, 상태는 Enabled 또는 Disabled로 복제 수행 여부를 정합니다.

우선순위는 여러 복제 규칙이 같은 객체에 적용될 수 있을 때 어떤 규칙을 먼저 적용할지 결정하는 기준입니다. 같은 대상에 충돌 가능성이 있는 규칙을 여러 개 만들 때 특히 중요합니다.

운영에서는 규칙 이름에 목적과 대상 리전, 데이터 범위를 포함하는 것이 좋습니다. 예를 들어 `logs-to-dr`, `images-to-analytics`처럼 나중에 봐도 의도를 알 수 있어야 합니다.

이 화면에서는 복제 규칙의 기본 식별자와 소스 버킷 범위를 정합니다. prefix나 태그 필터를 사용하면 버킷 전체가 아니라 특정 객체 그룹만 복제할 수 있습니다.

소스 버킷과 필터 범위 설정

복제 규칙은 버킷 전체 객체에 적용할 수도 있고, prefix나 태그를 사용해 일부 객체에만 적용할 수도 있습니다. 모든 객체를 복제하면 단순하지만 비용과 대상 버킷 용량이 커질 수 있습니다.

prefix 필터는 특정 경로 구조를 기준으로 복제 대상을 제한합니다. 예를 들어 `logs/`, `raw/`, `customer-a/`처럼 객체 키 구조가 명확할 때 유용합니다.

태그 필터는 객체 메타데이터 기반으로 복제 대상을 고를 때 사용합니다. 민감 데이터, 장기 보존 대상, 분석 대상처럼 업무 의미를 기준으로 복제 범위를 나눌 수 있습니다.

대상 버킷과 대상 리전 선택 기준

대상 버킷은 같은 리전에 둘 수도 있고 다른 리전에 둘 수도 있습니다. 같은 리전 복제는 로그 중앙화, 계정 분리, 운영/분석 환경 분리에 적합합니다.

교차 리전 복제는 재해 복구, 지리적 분산, 데이터 주권, 사용자 위치 기반 지연 시간 개선에 적합합니다. 다만 리전 간 데이터 전송 비용과 KMS 키 구성을 함께 검토해야 합니다.

대상 버킷이 다른 계정에 있으면 소유권과 권한 문제가 더 중요해집니다. 복제본 소유자 변경 옵션과 대상 버킷 정책을 함께 확인해야 합니다.

대상 설정 화면에서는 복제본을 받을 버킷, S3가 사용할 IAM 역할, KMS 암호화 객체 복제 여부, 대상 스토리지 클래스를 함께 결정합니다. 이 구간은 복제 실패가 가장 자주 발생하는 권한과 암호화 조건이 모이는 부분입니다.

복제용 IAM 역할이 필요한 이유

S3 복제는 Amazon S3가 사용자를 대신해 소스 객체를 읽고 대상 버킷에 쓰는 구조입니다. 이 작업을 수행하려면 S3가 AssumeRole 할 수 있는 IAM 역할이 필요합니다.

이 IAM 역할에는 소스 버킷에서 객체와 버전 정보를 읽는 권한, 대상 버킷에 객체를 쓰는 권한, 필요한 경우 태그와 ACL, 객체 잠금 정보를 복제하는 권한이 포함되어야 합니다.

KMS 암호화 객체를 복제한다면 IAM 역할에 KMS 복호화와 암호화 권한도 필요합니다. 단순히 S3 권한만 주면 KMS 암호화 객체 복제에서 실패할 수 있습니다.

KMS 암호화 객체 복제 시 주의할 점

SSE-KMS 또는 DSSE-KMS로 암호화된 객체를 복제하려면 복제 규칙에서 KMS 암호화 객체 복제를 명시적으로 고려해야 합니다. 대상 버킷에서 사용할 KMS 키도 정해야 합니다.

소스 객체를 읽기 위해서는 소스 KMS 키에 대한 복호화 권한이 필요하고, 대상 객체를 쓰기 위해서는 대상 KMS 키에 대한 암호화 권한이 필요합니다. 계정이 다르면 키 정책과 IAM 정책을 모두 확인해야 합니다.

KMS 권한 누락은 복제 실패의 흔한 원인입니다. 복제 규칙이 Enabled인데도 객체가 복제되지 않는다면 먼저 Replication status, CloudWatch 지표, KMS AccessDenied 여부를 확인하는 것이 좋습니다.

대상 스토리지 클래스 변경 옵션

S3 복제는 대상 객체의 스토리지 클래스를 다르게 지정할 수 있습니다. 예를 들어 원본은 Standard에 두고, 대상 복제본은 장기 보관 목적에 맞춰 Glacier 계열로 전환하는 전략을 검토할 수 있습니다.

다만 복제 시점에 바로 낮은 비용 스토리지 클래스로 보내면 이후 복구 시간이나 조회 비용이 달라집니다. 백업인지, 분석용인지, 즉시 장애 전환용인지에 따라 대상 스토리지 클래스를 선택해야 합니다.

장기 비용 최적화가 목적이라면 복제 규칙에서 바로 변경할지, 대상 버킷의 Lifecycle 정책으로 일정 기간 후 전환할지 비교하는 것이 좋습니다.

복제 시간 제어와 복제 지표

S3 Replication Time Control, 즉 RTC는 새 객체의 대부분을 15분 안에 복제하도록 설계된 기능입니다. AWS 문서 기준으로 S3 RTC는 15분 복제 시간에 대한 SLA를 제공합니다.

RTC는 규제나 복구 시간 요구사항 때문에 예측 가능한 복제 시간이 필요한 경우에 유용합니다. 단순 백업이나 장기 보관 목적이라면 추가 비용을 고려해 꼭 필요한지 판단해야 합니다.

복제 지표는 복제 대기 객체 수, 복제 지연 시간, 실패 여부를 모니터링하는 데 사용합니다. 복제 실패를 조기에 확인하려면 CloudWatch 지표와 이벤트 알림을 함께 보는 것이 좋습니다.

추가 복제 옵션에서는 RTC, 복제 지표, 삭제 마커 복제, 복제본 수정 동기화를 선택합니다. 복구 시간 목표가 명확하거나 복제 실패를 모니터링해야 하는 환경에서는 이 설정을 별도로 검토해야 합니다.

삭제 마커 복제와 복제본 수정 동기화

버전 관리가 켜진 버킷에서 객체를 삭제하면 실제 객체가 바로 사라지는 것이 아니라 삭제 마커가 생성될 수 있습니다. 삭제 마커 복제는 이 삭제 상태를 대상 버킷에도 반영할지 결정하는 옵션입니다.

삭제 마커를 복제하면 원본에서 삭제된 것처럼 보이는 상태가 대상에도 반영됩니다. 반대로 복제하지 않으면 대상 버킷에는 이전 복제본이 남을 수 있습니다. 백업 목적이라면 이 차이를 명확히 이해해야 합니다.

복제본 수정 동기화는 복제된 객체의 태그, ACL, 객체 잠금 같은 메타데이터 변경을 다시 동기화하는 데 사용됩니다. 양방향 복제나 장애 전환 구조에서는 메타데이터 동기화 요구가 있는지 확인해야 합니다.

실무 권장 설정

복제 규칙을 만들기 전에 소스와 대상 버킷 모두 버전 관리가 켜져 있는지 확인합니다. S3 복제는 버전 관리와 강하게 연결되어 있으므로 이 조건을 놓치면 설정이 정상적으로 진행되지 않습니다.

대상 버킷은 목적별로 분리하는 것이 좋습니다. 재해 복구용, 로그 중앙화용, 분석용 버킷은 권한, 수명 주기, 암호화, 접근 패턴이 다르기 때문입니다.

KMS 암호화 객체를 복제한다면 S3 권한만 보지 말고 KMS 키 정책과 IAM 역할 권한을 함께 검토합니다. RTC는 규제나 복구 시간 요구가 명확할 때만 비용을 확인한 뒤 적용하는 것이 좋습니다.

FAQ

S3 로깅과 이벤트 알림을 왜 구분해야 하나

S3에는 비슷해 보이는 기록·알림 기능이 여러 개 있습니다. 서버 액세스 로깅, CloudTrail 데이터 이벤트, S3 이벤트 알림, EventBridge가 대표적입니다.

이 기능들은 모두 S3에서 발생한 일을 다루지만 목적이 다릅니다. 서버 액세스 로깅은 요청 기록에 가깝고, CloudTrail 데이터 이벤트는 감사 로그에 가깝고, 이벤트 알림과 EventBridge는 자동화 트리거에 가깝습니다.

따라서 운영자는 먼저 질문을 나눠야 합니다. 누가 언제 접근했는지 감사하려는지, 객체 생성 시 후속 작업을 실행하려는지, 장애 분석용 요청 로그가 필요한지에 따라 선택해야 하는 기능이 달라집니다.

서버 액세스 로깅이 기록하는 것

S3 서버 액세스 로깅은 버킷에 들어오는 요청에 대한 상세 기록을 대상 버킷에 객체 형태로 저장하는 기능입니다. 요청자, 버킷, 시간, 작업, 응답 코드, 전송 바이트 같은 정보를 분석할 수 있습니다.

이 로그는 보안 감사, 접근 패턴 분석, 비용 원인 파악에 도움이 됩니다. 다만 AWS 문서 기준으로 서버 액세스 로그는 best-effort 방식으로 전달되며, 완전성과 즉시성이 보장되는 회계성 로그로 보면 안 됩니다.

로그 대상 버킷은 소스 버킷과 같은 리전에 있어야 하며, 관리 편의상 소스 버킷과 다른 버킷을 사용하는 것이 좋습니다. 같은 버킷에 로그를 저장하면 로그 기록 자체가 다시 로그를 만들어 불필요한 객체가 늘어날 수 있습니다.

이 화면에서는 서버 액세스 로깅, CloudTrail 데이터 이벤트, 이벤트 알림, EventBridge가 한 영역에 모여 있습니다. 화면상 가까이 있지만 각각의 목적은 로그 분석, 감사 추적, 이벤트 자동화로 나뉩니다.

CloudTrail 데이터 이벤트가 필요한 이유

CloudTrail은 AWS API 호출 기록을 남기는 감사 서비스입니다. S3의 경우 버킷 수준 관리 이벤트와 객체 수준 데이터 이벤트를 구분해서 봐야 합니다.

객체 수준의 `GetObject`, `PutObject`, `DeleteObject` 같은 작업을 감사하려면 CloudTrail 데이터 이벤트를 활성화해야 합니다. 기본 CloudTrail 이벤트 기록만으로 모든 객체 접근을 확인할 수 있다고 생각하면 안 됩니다.

CloudTrail 데이터 이벤트는 보안 감사와 사고 조사에 강합니다. 누가 어떤 객체를 읽었는지, 삭제했는지, 업로드했는지를 추적해야 하는 버킷이라면 서버 액세스 로그보다 CloudTrail 데이터 이벤트가 더 적합합니다. 다만 데이터 이벤트는 비용이 발생할 수 있으므로 대상 버킷과 이벤트 범위를 신중하게 정해야 합니다.

S3 이벤트 알림 구조

S3 이벤트 알림은 버킷에서 특정 이벤트가 발생했을 때 SNS, SQS, Lambda, EventBridge 같은 대상으로 알림을 보내는 기능입니다. 객체 생성, 객체 삭제, 복원, 복제, 수명 주기 전환 같은 이벤트를 트리거로 사용할 수 있습니다.

이 기능은 로그 저장보다 자동화에 가깝습니다. 예를 들어 이미지가 업로드되면 Lambda로 썸네일을 만들거나, 객체 생성 이벤트를 SQS로 보내 후속 처리 워커가 가져가도록 설계할 수 있습니다.

주의할 점은 이벤트 알림이 적어도 한 번 전달될 수 있다는 점입니다. 중복 이벤트가 발생할 수 있으므로 처리 로직은 멱등성을 가져야 합니다. 또한 같은 버킷에 다시 객체를 쓰는 Lambda를 연결하면 이벤트 루프가 생길 수 있어 prefix나 별도 버킷으로 분리해야 합니다.

EventBridge로 S3 이벤트를 보내는 방식

EventBridge는 S3 이벤트를 더 넓은 이벤트 라우팅 구조로 연결할 때 유용합니다. S3 이벤트를 EventBridge로 보내면 이벤트 패턴을 기준으로 여러 대상에 라우팅하고, 재시도와 실패 처리 구조를 더 유연하게 설계할 수 있습니다.

S3 직접 이벤트 알림은 특정 버킷 이벤트를 SNS, SQS, Lambda 등에 연결하는 데 간단합니다. 반면 EventBridge는 여러 서비스 이벤트를 한 곳에서 필터링하고, Step Functions, Lambda, SQS, 다른 이벤트 버스 같은 대상으로 확장하기 좋습니다.

운영 자동화가 단순하면 S3 이벤트 알림으로 충분할 수 있습니다. 하지만 여러 팀이나 여러 애플리케이션이 같은 이벤트를 소비하거나, 이벤트 라우팅 규칙을 중앙에서 관리해야 한다면 EventBridge를 검토하는 것이 좋습니다.

로그 저장 버킷 설계 시 주의할 점

S3 로그 저장 버킷은 일반 데이터 버킷과 분리하는 것이 좋습니다. 로그는 분석·감사·보존 목적이 강하므로 수명 주기, 접근 권한, 암호화, 삭제 방지 기준이 다르게 적용됩니다.

서버 액세스 로그 대상 버킷에는 S3 로그 전달 주체가 객체를 쓸 수 있어야 합니다. Object Ownership에서 ACL을 비활성화한 버킷이라면 ACL이 아니라 버킷 정책으로 로그 전달 권한을 부여해야 합니다.

CloudTrail 로그를 저장하는 버킷은 중앙 보안 계정이나 로그 아카이브 계정에 두는 구성이 흔합니다. 여러 계정의 감사 로그를 한곳에 모으면 분석은 쉬워지지만, 접근 권한과 수명 주기 정책을 더 엄격하게 관리해야 합니다.

보안 감사와 장애 분석에서 보는 항목

보안 감사에서는 CloudTrail 데이터 이벤트를 먼저 봅니다. 객체 읽기, 업로드, 삭제, 권한 변경과 관련된 API 호출을 추적해야 하기 때문입니다.

트래픽 패턴이나 응답 코드, 특정 요청자의 접근량을 보고 싶다면 서버 액세스 로그가 도움이 됩니다. 다만 즉시성과 완전성이 보장되는 실시간 탐지 로그로 설계하기보다는 장기 분석과 추세 확인 용도로 보는 편이 안전합니다.

이벤트 기반 자동화는 S3 이벤트 알림과 EventBridge를 봅니다. 파일 업로드 후 처리, 백업 후 검증, 데이터 파이프라인 시작처럼 후속 작업을 실행해야 하는 경우 로그보다 이벤트가 더 적합합니다.

실무 권장 설정

중요 버킷은 CloudTrail 데이터 이벤트를 우선 검토합니다. 개인정보, 고객 데이터, 감사 대상 데이터처럼 객체 접근 이력이 중요한 경우 객체 수준 API 기록이 필요합니다.

서버 액세스 로깅은 트래픽 분석과 운영 참고 자료로 활용합니다. 대상 버킷은 분리하고, 날짜 기반 prefix와 수명 주기 정책을 함께 적용해 로그 비용을 관리합니다.

업로드 후 처리나 데이터 파이프라인 시작처럼 자동화가 목적이라면 S3 이벤트 알림 또는 EventBridge를 사용합니다. 간단한 단일 대상이면 S3 이벤트 알림, 복잡한 라우팅과 중앙 관리는 EventBridge가 더 적합합니다.

FAQ

S3 웹 접근 설정을 왜 이해해야 하나

S3는 객체 저장소이지만 웹 애플리케이션에서 직접 접근하는 경우가 많습니다. 이미지, 정적 파일, 프론트엔드 빌드 결과물, 다운로드 파일, 대용량 업로드 대상이 S3에 저장되기 때문입니다.

이때 단순히 버킷을 만들고 객체를 올리는 것만으로는 충분하지 않습니다. 브라우저에서 접근할 것인지, CloudFront를 앞에 둘 것인지, 다른 도메인에서 호출할 것인지, 사용자가 다운로드 비용을 부담해야 하는지에 따라 설정 기준이 달라집니다.

이 글에서는 S3 웹 접근과 관련된 대표 설정인 CORS, 정적 웹사이트 호스팅, 전송 가속화, 요청자 지불을 한 흐름으로 정리합니다.

CORS란 무엇인가

CORS는 Cross-Origin Resource Sharing의 약자입니다. 브라우저에서 로드된 웹 애플리케이션이 다른 도메인의 리소스를 호출할 수 있도록 허용 범위를 정의하는 방식입니다.

예를 들어 프론트엔드가 `https://app.example.com`에서 실행되고, 이미지나 업로드 대상은 S3 버킷 엔드포인트에 있다면 브라우저는 출처가 다르다고 판단합니다. 이때 S3 버킷에 CORS 설정이 없으면 브라우저가 요청을 차단할 수 있습니다.

중요한 점은 CORS가 인증이나 권한을 대체하지 않는다는 것입니다. CORS는 브라우저의 교차 출처 호출 허용 조건이고, 실제 S3 접근 권한은 IAM 정책, 버킷 정책, 객체 권한이 계속 판단합니다.

CORS 화면에서는 JSON 형식으로 허용할 Origin, Method, Header를 정의합니다. 설정이 비어 있다면 브라우저 기반 교차 출처 호출은 허용되지 않은 상태로 보면 됩니다.

S3 CORS 설정이 필요한 상황

CORS는 주로 브라우저 기반 애플리케이션에서 필요합니다. 웹 페이지가 S3에 저장된 이미지, 폰트, JSON, 다운로드 파일을 직접 호출하거나, Presigned URL을 사용해 브라우저에서 S3로 직접 업로드할 때 자주 등장합니다.

특히 `PUT`, `POST`, 커스텀 헤더, 인증 헤더가 포함되는 요청은 브라우저가 사전 요청을 보낼 수 있습니다. 이때 S3 CORS 규칙의 AllowedOrigin, AllowedMethod, AllowedHeader가 요청과 맞지 않으면 실제 S3 권한이 있어도 브라우저에서 실패합니다.

반대로 서버 백엔드가 S3 API를 호출하는 구조라면 CORS가 핵심 문제가 아닙니다. CORS는 브라우저 보안 모델과 관련된 설정이므로, 어디에서 요청이 발생하는지를 먼저 구분해야 합니다.

CORS 설정 시 주의할 Origin, Method, Header

CORS 규칙에서 가장 중요한 값은 Origin, Method, Header입니다. Origin은 허용할 웹 사이트 출처이고, Method는 GET, PUT, POST 같은 HTTP 메서드이며, Header는 브라우저 요청에 포함될 수 있는 헤더입니다.

운영 환경에서는 `*`를 넓게 쓰기보다 실제 프론트엔드 도메인을 명시하는 것이 좋습니다. 업로드가 필요한 경우에는 `PUT`과 필요한 헤더를 허용하고, 단순 조회만 필요한 경우에는 `GET` 중심으로 제한합니다.

CORS 문제는 S3 권한 오류와 혼동하기 쉽습니다. 브라우저 개발자 도구에서 CORS 오류가 보이면 먼저 Origin, Method, Header가 규칙과 일치하는지 확인하고, 그다음 IAM 또는 버킷 정책을 확인하는 순서가 좋습니다.

정적 웹사이트 호스팅이란 무엇인가

S3 정적 웹사이트 호스팅은 HTML, CSS, JavaScript, 이미지 같은 정적 파일을 S3 버킷에서 웹 사이트처럼 제공하는 기능입니다. 서버 사이드 렌더링이나 백엔드 실행은 하지 않고, 정적 파일을 웹 엔드포인트로 노출합니다.

이 기능을 사용하면 인덱스 문서와 오류 문서를 지정할 수 있습니다. 다만 정적 웹사이트 엔드포인트는 일반 S3 REST 엔드포인트와 다르며, 보안과 HTTPS 구성을 고려하면 CloudFront를 함께 쓰는 경우가 많습니다.

AWS 문서 기준으로도 S3에 저장된 정적 콘텐츠를 안전하게 전역 배포하려면 CloudFront 또는 Amplify Hosting 같은 구성을 함께 검토하는 것이 좋습니다.

CloudFront와 S3 정적 웹사이트 호스팅의 차이

S3 정적 웹사이트 호스팅은 S3 버킷 자체를 웹 사이트 엔드포인트로 사용하는 방식입니다. 단순한 정적 페이지를 빠르게 노출할 수 있지만, HTTPS, 캐싱, WAF, 전역 성능, 오리진 보호 관점에서는 CloudFront가 더 적합합니다.

CloudFront를 사용하면 S3를 오리진으로 두고 CDN 캐시, TLS 인증서, AWS WAF, Origin Access Control을 함께 설계할 수 있습니다. 특히 SSE-KMS로 암호화된 객체를 안전하게 제공하려면 CloudFront OAC 구성을 검토해야 합니다.

따라서 실무에서는 S3 정적 웹사이트 호스팅을 단독 서비스처럼 보기보다, CloudFront와 함께 정적 콘텐츠를 제공하는 구조로 이해하는 것이 좋습니다.

전송 가속화는 언제 필요한가

S3 Transfer Acceleration은 전 세계 사용자가 S3 버킷으로 대용량 파일을 업로드하거나 다운로드할 때 CloudFront 엣지 로케이션을 활용해 전송 경로를 최적화하는 기능입니다.

모든 버킷에 기본으로 켤 필요는 없습니다. 여러 국가에서 중앙 S3 버킷으로 대용량 데이터를 자주 업로드하거나, 대륙 간 전송에서 인터넷 경로 품질이 불안정한 경우에 검토하는 기능입니다.

주의할 점은 추가 비용이 발생할 수 있고, 버킷 이름이 DNS 호환 형식이어야 하며 점이 포함된 버킷 이름은 제약이 생길 수 있다는 점입니다. 활성화 후에도 실제 성능 차이는 사용자 위치와 네트워크 상태에 따라 달라집니다.

이 화면의 항목은 모두 웹 접근과 비용, 보존 정책에 영향을 줍니다. 이 글에서는 전송 가속화, 요청자 지불, 정적 웹사이트 호스팅을 중심으로 보고, 객체 잠금은 별도 보존 정책 설정으로 분리해 이해하는 것이 좋습니다.

요청자 지불은 왜 일반 웹 서비스에 맞지 않나

요청자 지불은 버킷 소유자가 아니라 요청자가 요청 비용과 데이터 다운로드 비용을 부담하게 하는 설정입니다. 공개 데이터셋처럼 많은 사용자가 데이터를 가져가지만 버킷 소유자가 전송 비용을 모두 부담하기 어려운 경우에 사용할 수 있습니다.

하지만 일반 웹 서비스나 정적 웹사이트 호스팅에는 잘 맞지 않습니다. 요청자 지불 버킷은 익명 접근을 허용하지 않으며, 요청자는 비용 부담을 명시하는 헤더나 CLI 옵션을 포함해야 합니다.

따라서 웹 사이트 파일 제공, 이미지 제공, 프론트엔드 정적 파일 제공에는 보통 사용하지 않습니다. 데이터 공유용 버킷과 서비스 제공용 버킷은 목적을 분리하는 것이 좋습니다.

실무 권장 설정

브라우저에서 S3 객체를 직접 호출한다면 CORS를 최소 범위로 설정합니다. Origin은 실제 서비스 도메인으로 제한하고, Method는 필요한 작업만 허용합니다.

정적 웹사이트를 외부에 제공해야 한다면 S3 단독 호스팅보다 CloudFront, ACM 인증서, Route 53, AWS WAF를 함께 검토하는 것이 좋습니다. S3 버킷은 직접 공개하지 않고 CloudFront를 통해 접근시키는 구조가 운영상 안전합니다.

전송 가속화는 글로벌 대용량 전송이 확인된 경우에만 테스트 후 적용합니다. 요청자 지불은 공개 데이터셋 배포 목적이 아니라면 일반 서비스 버킷에는 적용하지 않는 것이 좋습니다.

FAQ