게임 개발 중소기업의 AWS 활용: 보안 및 유지보수 최적화/ IAM + 3 tier + peering/ 3인 프로젝트

9일 일
ㄷㅇ - aws 구축하는 3 티어 아키텍처 구현(맛보기)
ㅅㅇ- 3 tier 구상 (실현 가능한 방향으로 조사)
ㅇㅈ - 3 tier (실현 가능한 방향으로 조사)

 

10일 월

-> 컨셉 정하기, 아키텍처 구성

 

추가: 

1. 왜 이 권한을 줬는지나, 왜 이 기능을 했는지 구체화해서 생각하기

2. 추가로 할 기능이 있는지에 대해 토론하고, 추가 구현하기

 

IAM 권한 설정

- 권한 정책 - 직접 정책 연결

-> 권한 설정에서 직접 정책 연결을 해주는 이유는? 인프라 담당자한테 권한을 부여해주고 싶기 때문에 직접 정책을 연결해 줌

 root -> 인프라 -> IAM 

이라고 할 때 ec2나 vpc fullaccess를 줘야 됨

-> vpc read only access는 vpc을 읽을 수 있는 권한을 주는 것을 말함.(기존에 있는 걸 사용할 수 있는 정도의 서비스 권한이 생기고, 변경하거나, 인터넷 게이트웨이를 추가하는 행위는 하지 못함)

- vpc full access는 다 수정할 수 있는 권한을 줌

3-Tier가 더 적합함

✅ 보안 및 역할 분리가 더 명확함 → DevOps와 Admin을 분리하면 인프라 관리의 위험성을 줄일 수 있음
✅ 실수 방지 → DevOps가 실수로 IAM을 수정하거나 중요한 네트워크 설정을 변경하는 사고를 방지할 수 있음
✅ 확장성 → 향후 팀이 커질 경우에도 유지보수하기 쉬움

 

즉, 3-Tier가 최선의 선택! 
하지만 팀이 작고 빠른 운영이 필요하면 2-Tier도 가능 (추후 확장 가능하도록 설계)

 

11일 화
오전, 오후

VPC 구성:

• VPC 1 (Public-facing Services): 웹 서버, API 게이트웨이 등 외부 서비스용
• VPC 2 (Internal Services): DB, 내부 API, 배치 서버 등 내부 서비스용
• VPC Peering을 통해 두 네트워크 간 통신 가능하도록 설정

3 - tier 

vpc 만들기

서브넷 만들기

vpc-1

pub_vpc1-1:10.10.5.0/24

pub_vpc1-2:10.10.6.0/24

 

WAS: ip 10.10.0.0/16

->was_vpc1-1_pri: 10.10.3.0/24

->was_vpc1-2_pri:10.10.4.0/24

 

WEB: ip 10.10.0.0/16

-> web_vpc1-1_pri: 10.10.1.0/24

-> web_vpc1-2_pri:10.10.2.0/24

vpc-2

DB: ip 172.16.0.0/16

-> db_vpc2-1:172.16.1.0/24

->db_vpc2-2:172.16.2.0/24

->db_vpc2-3:172.16.3.0/24

vpc - 서브넷 설정해 준 상태

라우팅 테이블

vpc1 

pub_vpc1-1

pub_vpc1-2

 

vpc2

pub_vpc2-1

 

NAT GW

- 하나만 연결해서 az-1에 설치를 하고 image 해서 az-2에 복사 

vpc1-1_ig

3-tier

- 생성 밑에 이미지 참고

web server

- ssm관련 권한을 추가해 주는 것은, ec2인스턴스에서 정상적으로 동작할 수 있도록 만들어주는 것으로, 시스템 매니저의 권한을 허용해 주는 것?

was server

db server

- 위의 과정에서 왜 사용을 안 하는 게 좋을까?

-> 비용적인 측면에서 과한 요금이 부과되기 때문임

1) Backup (Enable automated backups)
무엇을 하는가?
매일 자동 스냅숏을 생성해 주며, Point-In-Time Recovery(PITR)를 가능하게 만들어줌

언제 필요한가?
프로덕션 환경이나 데이터 복구가 중요한 개발/테스트 환경: 항상 켜 두는 것이 일반적.
데이터 손실을 허용할 수 없는 시스템이라면 필수.
굳이 백업이 필요 없는 임시 DB라면 비활성화할 수도 있지만, 보통은 켜두는 편이 안전함.

2) Encryption (Enable encryption)
무엇을 하는가?
RDS 스토리지(데이터 파일)와 자동 백업, 스냅샷 등을 AWS KMS를 통해 암호화함.

 

3) Maintenance → Auto minor version upgrade
무엇을 하는가?
DB 엔진의 마이너 버전(예: MySQL 8.0.x에서 x가 업데이트되는 경우)이 출시되면, RDS가 자동으로 새로운 마이너 버전으로 업그레이드를 수행함.
이 업그레이드는 설정해 둔 Maintenance Window(유지 관리 시간대)에 진행됨.

 

 

4) Maintenance → Maintenance window
무엇을 하는가?
AWS RDS가 패치나 업그레이드, 내부 유지 관리 작업을 수행할 수 있는 시간대를 지정함.
이 시간대에 RDS가 재부팅되거나 잠시 연결이 끊길 수 있음

 

오류/ 해결

db서버 생성 과정에서 오류를 만남

-> api를 호출할 수 있는 권한이 없어 발생한 오류

-> 해결 방안으로는 권한을 추가해 주는 것인데

-> 그래서 권한을 추가해 줌

- db를 만들기 위해 AWSKeyManagementServicePowerUser 정책을 추가해줘야 하는 이유
Reasoned for a couple of seconds
AWS RDS에서 암호화(DB 인스턴스 및 스냅숏 암호화)를 활성화하려면, 내부적으로 KMS(Key Management Service)를 사용해야 함. 이때 KMS에 대한 특정 권한이 필요함. 예컨대 콘솔이나 API에서 암호화(Encryption) 옵션을 선택할 때, KMS 키 목록(Alias)을 조회하거나 해당 KMS 키를 RDS에 연결하는 과정을 거치게 됨.

즉, KMS 권한이 없는 상태에서 RDS 생성 시 암호화를 사용하려고 하면, KMS 서비스와 연동이 되지 않아 에러(Access Denied)가 발생할 수 있습니다. 그래서 KMS 관련 권한을 부여하기 위해 AWSKeyManagementServicePowerUser 정책을 추가하는 것 임.

- 왜 AWSKeyManagementServicePowerUser가 필요한가?
암호화된 DB 생성 시 KMS Key 사용

aws/rds라는 AWS 관리형 키나, 사용자 생성 키(CMK)를 선택해서 사용함.
선택된 키에 대해 ListAliases, DescribeKey, Encrypt/Decrypt(특정 상황) 등 다양한 KMS 액션이 필요할 수 있음
KMS Aliases, Keys 조회 권한

콘솔에서 ‘암호화 활성화(Enable encryption)’ 옵션을 켜면, 사용 가능한 KMS 키 목록을 불러와야 함.
이 목록을 불러오기 위해 kms:ListAliases, kms:ListKeys 권한이 필요함.
AWSKeyManagementServicePowerUser에는 이와 같은 목록/설정 변경 권한이 포함되어 있음.
사용자 관리형 CMK를 사용할 경우(BYOK, Key Policy 등)

별도의 키 정책(Key Policy) 설정이 필요할 수 있고, kms:CreateAlias, kms:DeleteAlias, kms:TagResource 등 액션도 사용하게 될 수 있음.
AWSKeyManagementServicePowerUser 정책은 KMS 관련 작업을 광범위하게 허용하므로, 사용자 관리형 CMK를 사용할 때도 편리하게 설정할 수 있음.

 

IAMReadOnlyAccess 정책은 IAM 사용자 또는 역할이 AWS 리소스를 읽을 수 있는 권한을 부여하는 정책임.
즉, AWS 리소스를 수정하거나 생성할 수는 없지만, 해당 리소스의 정보를 조회할 수 있음.

 

- DB 생성 시 IAMReadOnlyAccess 정책이 필요한 이유
1. AWS 리소스 정보를 조회해야 함
DB를 만들려면 VPC, Subnet, Security Group 등 네트워크 리소스를 확인해야 함.
IAMReadOnlyAccess가 없으면 VPC, 서브넷, 보안 그룹 등의 정보를 가져올 수 없음.
예를 들어, AWS RDS를 생성할 때 다음 정보를 조회해야 함:
사용할 VPC 목록 조회 (ec2:DescribeVpcs)
DB를 배치할 서브넷 목록 조회 (ec2:DescribeSubnets)
연결할 보안 그룹(Security Group) 조회 (ec2:DescribeSecurityGroups)

 

DB를 만들기 위해 SecretsManagerReadWrite 정책을 추가해야 하는 이유
AWS에서 데이터베이스(DB)를 생성할 때, 보안 강화를 위해 DB 인증 정보를 안전하게 저장하는 것이 중요함.
이때 AWS Secrets Manager를 활용하면 DB 접속 정보(사용자 이름, 비밀번호 등)를 안전하게 저장하고 자동으로 관리할 수 있어.
따라서 SecretsManagerReadWrite 정책이 필요한 이유는 DB의 자격 증명(비밀번호 등)을 안전하게 저장하고, 관리할 수 있도록 하기 위해서야.

SecretsManagerReadWrite 정책이 필요한 이유
1. DB 접속 정보를 안전하게 저장
DB를 만들 때, 관리자 계정(username)과 비밀번호(password)를 설정해야 함.
하지만 보안상 비밀번호를 환경 변수 또는 코드에 직접 입력하는 것은 매우 위험함.
AWS Secrets Manager를 사용하면 DB의 비밀번호를 안전하게 저장하고 관리할 수 있음.
SecretsManagerReadWrite 정책을 부여하면, IAM 역할이 AWS Secrets Manager에 DB의 접속 정보를 저장할 수 있음.

 

peering

- peering 연결을 해준 후 라우팅 테이블에 상대방 대역을 추가해 주는 과정 

-> web - db 

-> db - web

로드밸런서

 피어링이 안됨;;;;

- 그래서 db에 퍼블릭 서브넷을 만들어서 인스턴스를 생성한 후 피어링이 문제인지, db가 문제인지 확인을 해보겠습니다. 

- 연결됨 db비번이 달라서 연결이 안 된 거였음;;;

12일 수
오전, 오후 

1. 

- 어제는 web에서 was서버 하나를 리버시프록시를 해줬고, 오늘은 ALB로 톰캣 서버들을 묶어줘서 웹 서버에서 리버시프록시 주소를 톰캣서버 ALB의 DNS주소로 변경하는 것까지가 목표

- ALB로 묶었기 때문에 ALB의 dns 주소로만 접속이 되기 때문에 웹에서 ALB주소로 접근 가능하도록 설정을 해준다.

2. 

- 클라우드와치를 활용해서 오토스케일이 인스턴스를 생성하지 못할 때, sns가 관리자에게 알림을 주도록 설정

3.

-  web + was + db가 연동된 것 까지 확인했고, 오늘은 python 게임 배포해고 RDS db랑 연동하는 것 까지 실행해 볼 예정

- 내일 계속...

 

13일 목

오전, 오후 
저녁 - 조윤지: ppt, 발표 준비

 

최종 아키텍처

목표

- CloudFront vs. Global Accelerator 비교해서 우리가 만든 게임을 전 세계로 서비스를 제공하고 싶을 때, 어떤 서비스를 사용해야 하는지 결정 그리고 구축

-  web + was + db가 연동된 것까지 확인했고, 오늘은 python 게임 배포해고 RDS db랑 연동하는 것 까지 실행해 볼 예정

- AWS budgets을 사용해서 우리가 할당받은 3만 원을 넘지 않도록 설정

- Route 53 웹페이지 dns 변경

 

추가 고려 목표

- 서비스별 비용 비교

 

시간이 남는다면 고려

- 리전 별로 금액을 비교해서 차이점을 설명할지

- 아니면 서버리스랑 ec2를 비교했을 때 어떤 서비스가 더 좋은지 차이점을 비교해서 찾아보기

14일 금
오전 - 조윤지: 발표 준비
오후 - 발표