[26WKRD2] EFS 파일 시스템 설계하기
개요
여러 워크로드가 동시에 접근할 수 있는 공유 스토리지가 필요할 때, 단순히 EFS를 생성하는 것만으로는 충분하지 않습니다. 실제 환경에서는 성능 모드, 처리량 방식, 네트워크 배치, Access Point 분리, 보안 정책, 그리고 비용 최적화까지 함께 고려해야 안정적인 파일 시스템을 설계할 수 있습니다.
이번 글에서는 Amazon EFS를 단순히 사용하는 방법을 넘어, 어떤 기준으로 파일 시스템을 설계해야 하는지 살펴보겠습니다. 워크로드 특성에 맞는 EFS 구조를 선택하고, 운영 환경에서 놓치기 쉬운 설계 포인트까지 정리해보겠습니다.
1. 기본 환경 셋업
이 글[1]을 참고하여 VPC, Security Group, EFS, EFS AP, EC2 인스턴스를 셋업합니다.
2. EFS File System Policy 제어하기
EFS에선 파일 시스템 정책을 사용하여 접근 권한을 제어할 수 있습니다.
2-0. Enforce TLS, ReadOnly, Deny Root Access
아래 정책 예시는 TLS를 통한 연결을 강제하고, Root Access를 차단하며, ReadOnly를 강제하는 예시입니다. elasticfilesystem:ClientWrite 권한을 부여해야만 쓰기 작업을 수행할 수 있습니다.
{
"Version": "2012-10-17",
"Id": "combo-basic-policy",
"Statement": [
{
"Sid": "DenyNonTLS",
"Effect": "Deny",
"Principal": { "AWS": "*" },
"Action": "*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "AllowReadOnlyViaMountTarget",
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"elasticfilesystem:ClientMount"
],
"Condition": {
"Bool": {
"elasticfilesystem:AccessedViaMountTarget": "true"
}
}
},
{
"Sid": "DenyRootAccess",
"Effect": "Deny",
"Principal": { "AWS": "*" },
"Action": "elasticfilesystem:ClientRootAccess",
"Condition": {}
}
]
}2-1. Allow Connect via Access Point
아래 정책 값을 사용하여 특정한 Role이 accesspoint만을 통해서 EFS에 접근 가능하도록 할 수 있습니다.
{
"Version": "2012-10-17",
"Id": "restrict-by-access-point-policy",
"Statement": [
{
"Sid": "AllowOnlyViaSpecificAccessPoint",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
},
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Condition": {
"StringEquals": {
"elasticfilesystem:AccessPointArn": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:access-point/<AP_ID>"
}
}
}
]
}2-2. Restrict Origin IP Address
아래 정책 예제를 사용하여 EFS에 10.0.1.0/24, 10.0.2.0/24 CIDR에 속한 리소스들만 접근 가능하게 하고, 10.0.0.100 IP는 접근을 차단할 수 있습니다.
{
"Version": "2012-10-17",
"Id": "restrict-by-ip-policy",
"Statement": [
{
"Sid": "AllowFromSpecificIPs",
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"10.0.1.0/24",
"10.0.2.0/24"
]
}
}
},
{
"Sid": "DenyFromBastionIP",
"Effect": "Deny",
"Principal": "*",
"Action": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.0.0.100/32"
}
}
}
]
}2-3. Restrict by Time
아래 정책 값을 사용하여 특정한 Role이 09시부터 18시까지만 EFS에 접근 가능하도록 할 수 있습니다. 다만, AWS에는 시간만 비교하는 연산자가 없기 때문에 StringNotLike 연산자로 시간 부분을 패턴 매칭하는 방식을 사용합니다. 이 때, 시간과 날짜는 모두 UTC 기준으로 해석된다는 것에 유의하도록 합니다.
{
"Version": "2012-10-17",
"Id": "time-based-access-policy",
"Statement": [
{
"Sid": "DenyOutsideBusinessHours",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
},
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Condition": {
"StringNotLike": {
"aws:CurrentTime": [
"*T09:*",
"*T10:*",
"*T11:*",
"*T12:*",
"*T13:*",
"*T14:*",
"*T15:*",
"*T16:*",
"*T17:*"
]
}
}
}
]
}2-4. Restrict by Date
아래 정책 값을 사용하여 특정한 Role이 2026년 06월 1일부터 2026년 06월 30일 사이에만 EFS에 접근 가능하도록 할 수 있습니다. 이 때, 시간과 날짜는 모두 UTC 기준으로 해석된다는 것에 유의하도록 합니다.
{
"Version": "2012-10-17",
"Id": "date-based-access-policy",
"Statement": [
{
"Sid": "AllowDuringCompetitionWindow",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
},
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Resource": "*",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2026-06-01T00:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2026-06-30T23:59:59Z"
}
}
}
]
}2-5. Attribute-Based Access Control - Tag based
아래 정책 예시를 참고하여 Team: app-team 태그를 가진 IAM Role이 붙어있어야만 EFS에 접근 가능케 하고, 해당 태그가 없는 리소스는 접근을 차단할 수 있습니다.
{
"Version": "2012-10-17",
"Id": "abac-tag-based-policy",
"Statement": [
{
"Sid": "AllowByPrincipalTag",
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Team": "app-team"
}
}
},
{
"Sid": "DenyWithoutRequiredTag",
"Effect": "Deny",
"Principal": { "AWS": "*" },
"Action": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/Team": "app-team"
}
}
}
]
}3. 주의 사항
3-1. 정책만으로 끝나지 않음
EFS는 파일 시스템 정책과 IAM Role 정책을 함께 사용할 수 있지만, 파일 시스템 정책만 작성했다고 해서 곧바로 “특정 Role만 접근 가능한 EFS”가 완성되는 것은 아닙니다. 실제로는 클라이언트가 EFS를 어떤 방식으로 마운트하느냐도 중요하며, IAM 기반 제어를 기대한다면 마운트 시점에도 IAM authorization이 함께 사용되어야 합니다. 즉, EFS 접근 제어는 단순히 정책 문서만 잘 쓰는 문제가 아니라, 네트워크 접근, 마운트 방식, IAM 인증이 함께 맞물려야 의도한 대로 동작합니다.
3-2. Allow보다 Deny가 우선
EFS의 권한 평가는 일반적인 IAM 정책 평가 방식과 동일하게 이해하면 됩니다. IAM Role 정책이나 EFS 파일 시스템 정책 중 하나라도 필요한 작업을 Allow하면 접근이 가능할 수 있지만, 반대로 둘 중 어느 한쪽에라도 명시적 Deny가 존재하면 최종적으로는 거부됩니다. 따라서 운영 환경에서는 “Allow를 하나 더 붙이면 되겠지”라고 생각하기보다, 현재 정책 어딘가에 Deny 조건이 함께 들어가 있지 않은지, 그리고 Access Point나 TLS 같은 조건이 실제 요청과 충돌하지 않는지를 함께 확인하는 것이 중요합니다.
마치며
Amazon EFS는 여러 워크로드가 함께 사용하는 공유 스토리지인 만큼, 단순히 파일 시스템을 생성하고 마운트하는 것만으로 설계가 끝나지는 않습니다. 실제 운영 환경에서는 네트워크 경로, IAM과 파일 시스템 정책의 조합, Access Point를 통한 디렉터리 분리, 그리고 성능 및 비용 특성을 함께 고려해야 원하는 형태의 공유 파일 시스템을 안정적으로 구성할 수 있습니다. EFS는 IAM 기반 접근 제어, Access Point, 성능 모드, 처리량 모드, Lifecycle 정책 같은 기능을 함께 제공하므로, 이를 개별 기능이 아니라 하나의 설계 요소로 보는 것이 중요합니다.
결국 EFS를 잘 설계한다는 것은 “어떻게 붙일 것인가”보다 "누가, 어떤 경로로, 어디까지 접근할 수 있고, 어떤 비용과 성능 특성으로 운영할 것인가"를 먼저 정리하는 일에 가깝습니다. 처음부터 이러한 기준을 함께 잡아두면, 이후 워크로드가 늘어나더라도 권한 충돌이나 운영 복잡도를 줄이면서 보다 예측 가능한 구조로 확장해 나갈 수 있습니다.
참고 문서
[1] EC2에서 EFS 사용하는 법을 알아봅시다. - https://ninejuan.tistory.com/entry/26WKRD2-EC2%EC%97%90%EC%84%9C-EFS-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B2%95%EC%9D%84-%EC%95%8C%EC%95%84%EB%B4%85%EC%8B%9C%EB%8B%A4