[클라우드 보안] 2편 - EC2는 어떻게 서버가 되는가? Compute와 Block Storage

Об этом предложении

1편에서는 AWS의 리소스가 Region과 Availability Zone 위에 배치된다는 구조를 살펴봤다. 이제 실제로 AWS에서 가장 기본적인 Compute Resource인 EC2 를 만들어볼 차례다. EC2는 단순히 "AWS에서 만드는 서버"라고만 이해하면 부족하다. 하나의 EC2 Instance가 만들어지기 위해서는 다음과 같은 여러 요소가 함께 결정된다. AMI + Instance Type + Key Pair + Network + Storage + User Data ↓ EC2 Instance 이번 글에서는 EC2가 어떤 요소들로 구성되는지 살펴보고, EC2의 Storage 역할을 하는 EBS 를 직접 연결해 사용해본다. 핵심은 단순히 서버를 생성하는 것이 아니다. 어떤 Image로 서버를 만들고, 어느 정도의 자원을 주고, 어떻게 접속하며, Storage를 어떻게 연결하고, 이 설정들이 보안과 어떤 관계가 있는지 이해하는 것 이 목표다. 1. EC2란? EC2는 Elastic Compute Cloud 의 약자로, AWS에서 가상 Server Instance를 생성하여 사용할 수 있게 해주는 서비스다. 기존 환경에서 Server가 필요하다면 물리 장비를 준비해야 하지만 AWS에서는 필요한 사양을 선택하여 EC2 Instance를 생성할 수 있다. Server 필요 ↓ EC2 설정 ↓ Virtual Server 생성 ↓ OS / Application 실행 여기서 Instance 는 실제로 실행되고 있는 하나의 가상 Server를 의미한다고 생각하면 된다. EC2의 중요한 특징은 1편에서 살펴본 Cloud의 유연성 과 직접 연결된다. 처음 선택한 Server 크기가 너무 작다면 더 큰 Instance Type으로 변경할 수 있고, 반대로 사용률이 낮다면 더 작은 크기로 조정할 수도 있다. 즉 처음 선택한 Hardware 사양에 영구적으로 묶이는 구조가 아니다. 2. EC2를 만들 때 무엇을 결정해야 하는가? EC2 Instance를 생성할 때는 여러 설정이 함께 필요하다. 대표적인 항목은 다음과 같다. 설정 의미 AMI 어떤 OS와 기본 Software 상태로 시작할지 결정 Instance Type CPU, Memory 등 Server 크기 결정 Key Pair SSH 인증에 사용할 Public/Private Key Pair Network 어느 VPC/Subnet에 배치할지 결정 Public IP Internet에서 접근 가능한 주소 사용 여부 Security Group 어떤 Network Traffic을 허용할지 결정 EBS OS와 Data를 저장할 Block Storage User Data Instance 시작 시 자동으로 실행할 Script 이 중 Network와 Security Group은 4편에서 자세히 다룬다. 이번 글에서는 AMI, Instance Type, Key Pair, User Data, EBS 를 중심으로 본다. 3. AMI는 단순한 OS 설치 파일이 아니다 EC2를 만들 때 가장 먼저 선택하는 요소 중 하나가 AMI(Amazon Machine Image) 다. AMI는 EC2의 Root Volume을 만들기 위한 Template 역할을 한다. 쉽게 생각하면 다음과 같다. AMI ↓ Root Volume 생성 ↓ EC2 부팅 ↓ 동일한 기본 환경의 Server 생성 예를 들어 Amazon Linux 2023 AMI를 선택하면 해당 OS 구성을 기반으로 EC2가 생성된다. AMI에는 AWS가 제공하는 Image도 있지만, 사용자가 직접 구성한 EC2를 기반으로 Custom AMI 를 만들 수도 있다. 예를 들어 Server 하나에 필요한 Package와 설정을 모두 완료했다고 하자. EC2 ├─ OS ├─ Package ├─ Application └─ Configuration ↓ Custom AMI ↓ 동일한 환경의 EC2 반복 생성 강의에서는 이렇게 표준 Server 상태를 Image로 만들어두는 것을 Golden Image 를 만드는 방식으로 설명했다. 동일한 구성을 여러 Server에 반복해서 적용해야 할 때 유용하다. 4. AMI Baking Strategy AMI에 어느 정도까지 설정을 미리 넣어둘 것인지에 따라 운영 방식도 달라진다. Full Baking 필요한 Package와 설정을 대부분 AMI에 포함하는 방식이다. OS + Package + Application + Configuration ↓ Custom AMI 장점은 Instance가 생성된 뒤 추가로 구성해야 할 작업이 적기 때문에 빠르게 동일한 환경을 만들 수 있다는 점이다. 반면 Application이나 설정이 자주 바뀐다면 그때마다 새로운 Image를 관리해야 하는 부담이 생긴다. Raw Baking 기본 Image는 최대한 단순하게 유지하고, Instance가 생성된 이후 User Data 등을 이용해 필요한 설정을 적용하는 방식이다. 기본 AMI ↓ EC2 생성 ↓ User Data ↓ Package / Configuration 적용 Image 관리 부담은 줄지만 Instance가 시작될 때 추가적인 구성 시간이 필요할 수 있다. Half Baking 두 방식을 섞는 방법이다. 자주 변하지 않는 기본 Package는 AMI에 포함하고, 변경이 잦은 설정은 User Data 등으로 처리한다. 중요한 것은 어느 방식이 무조건 좋다는 것이 아니다. Server 생성 속도와 Image 관리 부담 사이에서 요구사항에 맞는 방식을 선택해야 한다. 또한 보안 관점에서는 AMI에 Password, Access Key, Private Key와 같은 민감정보가 들어가지 않도록 주의해야 한다. 5. Instance Type은 Server의 크기를 결정한다 AMI가 어떤 환경의 Server를 만들 것인지 결정한다면, Instance Type은 그 Server의 크기 를 결정한다. Instance Type에 따라 다음과 같은 Compute Resource가 달라진다. CPU Memory Storage 특성 Network 성능 강의 실습에서는 t3.micro 수준의 작은 Instance Type을 사용했다. 중요한 것은 Type 이름을 외우는 것이 아니다. 강사가 반복해서 강조한 것은 다음 흐름이다. Instance Type 선택 ↓ Application 운영 ↓ Resource 사용량 Monitoring ↓ 너무 부족함 → Scale Up 너무 남음 → Scale Down 즉, 처음부터 완벽한 크기를 맞히는 것보다 실제 사용률을 보고 적절한 크기로 조정하는 것이 중요하다. 이는 이후 CloudWatch와 Auto Scaling을 배울 때 다시 연결된다. 6. User Data는 무엇인가? Server를 여러 번 만들 때마다 사람이 직접 접속해서 같은 명령을 반복하면 비효율적이다. EC2의 User Data 는 Instance가 생성될 때 초기 구성 작업을 자동화할 수 있도록 Script를 지정하는 기능이다. 예를 들어 강의자료에는 다음과 같은 형태가 소개된다. #!/bin/bash yum update -y service httpd start chkconfig httpd on 즉 다음과 같은 작업을 자동화할 수 있다. EC2 생성 ↓ User Data 실행 ↓ Package 설치 ↓ Service 구성 ↓ Application 실행 준비 따라서 User Data는 AMI와 함께 반복 가능한 Server 구성 을 만드는 데 사용된다. 이번 편의 실습에서는 User Data를 직접 사용하는 것이 핵심은 아니지만, 이후 Web Server와 Auto Scaling 실습에서 다시 등장한다. 7. EC2에 접속하려면 무엇이 필요한가? EC2를 만들었다고 바로 SSH 연결이 가능한 것은 아니다. 외부 PC에서 Public EC2에 SSH로 접근하려면 강의에서는 다음 조건들을 확인했다. EC2 Running + Public IP + Security Group TCP 22 허용 + Key Pair + 올바른 Linux User ↓ SSH 연결 이 관계가 중요하다. 예를 들어 Key Pair가 있어도 Security Group에서 TCP 22가 막혀 있다면 SSH Traffic이 Instance까지 들어갈 수 없다. 반대로 Port가 열려 있어도 올바른 Private Key가 없다면 인증을 완료할 수 없다. 8. Key Pair는 왜 필요한가? 일반적인 SSH 인증에는 ID/Password 방식도 있지만 AWS EC2 실습에서는 Public Key / Private Key 방식 을 사용한다. 구조를 단순화하면 다음과 같다. Local PC Private Key │ │ SSH 인증 ▼ EC2 Public Key EC2를 생성하면서 Key Pair를 만들면 사용자는 Private Key File을 받게 된다. 이 Private Key는 이후 SSH Authentication에 사용되므로 안전하게 관리해야 한다. Amazon Linux 2023 실습에서는 Linux User로 ec2-user 를 사용한다. SSH 명령의 형태는 다음과 같다. ssh -i <Private-Key-File> ec2-user@<EC2-Public-IP> 예를 들어 구조만 보면 다음과 같다. My PC │ │ SSH TCP 22 ▼ Public IP │ Security Group │ ▼ EC2 Instance 9. EC2 Instance Connect 강의에서는 SSH Client를 이용하는 방법 외에도 EC2 Instance Connect 를 이용한 Browser 기반 연결도 확인했다. EC2 Console에서 Instance를 선택한 뒤 연결(Connect) 메뉴를 통해 접근할 수 있다. 이 방법을 이용하면 별도의 SSH Client Program을 직접 실행하지 않고도 Browser에서 Shell을 사용할 수 있다. 다만 연결 방법이 달라졌을 뿐, Network가 연결될 수 있는 조건과 접근 권한이 필요하다는 기본 원리는 그대로다. SSH, Instance Connect, 이후 배울 Systems Manager Session Manager는 모두 EC2에 접속하는 방식이지만 필요한 조건과 보안 특성이 서로 다르다. 10. EC2를 Stop하는 것과 Terminate하는 것은 다르다 EC2를 사용하면서 반드시 구분해야 할 상태가 있다. 작업 의미 Reboot OS를 다시 시작 Stop Instance의 Compute 실행 중지 Start 중지한 Instance 다시 시작 Terminate Instance 삭제 특히 Stop과 Terminate는 다르다. EC2를 Stop하면 Compute는 중지되지만 연결되어 있는 EBS Volume은 그대로 남을 수 있다. EC2 Stop ↓ Compute 중지 ↓ EBS Volume 유지 따라서 EC2를 중지했다고 해서 모든 비용 요소가 사라진다고 생각하면 안 된다. 반면 Terminate는 Instance 자체를 삭제하는 작업이다. 실습 과정에서 강사가 Resource를 사용한 뒤 삭제하라고 반복해서 강조한 이유도 여기에 있다. 11. EC2의 Storage, EBS EC2에서 사용하는 대표적인 Block Storage가 EBS(Elastic Block Store) 다. 물리 Server에 Disk를 연결하는 것과 비슷하게 이해할 수 있다. EC2 │ ├─ Root EBS │ └─ OS │ └─ Data EBS └─ Application Data EC2를 생성하면 OS가 들어 있는 Root Volume이 함께 구성된다. 필요하다면 별도의 EBS Volume을 생성하여 추가 Disk처럼 연결할 수도 있다. EBS의 성능은 Volume Type과 IOPS 등의 설정에 따라 달라질 수 있다. 이번 실습에서는 1GB gp3 EBS Volume 을 추가하여 EC2에 연결한다. 12. EBS에서 가장 중요한 것은 Availability Zone이다 EBS는 Availability Zone 단위의 Resource 다. 따라서 EBS를 EC2에 Attach하려면 두 Resource가 같은 AZ에 있어야 한다. AZ-A EC2 │ └──── EBS 연결 가능 반면 다음과 같은 구조에서는 직접 Attach할 수 없다. AZ-A AZ-B EC2 EBS └────── X ────────┘ 이것이 1편에서 Resource의 Scope를 먼저 이해한 이유다. EC2와 EBS 모두 특정 AZ에 위치하므로 EBS 생성 전에 연결하려는 EC2의 Availability Zone을 먼저 확인 해야 한다. 13. Attach했다고 바로 사용할 수 있는 것은 아니다 처음 EBS를 공부할 때 가장 헷갈리기 쉬운 부분이다. AWS Console에서 EBS Volume을 EC2에 Attach했다고 바로 /appdir 같은 Directory에서 사용할 수 있는 것은 아니다. 다음 과정이 필요하다. EBS 생성 ↓ EC2에 Attach ↓ File System 생성 ↓ Mount Point 생성 ↓ Mount ↓ File 저장 즉 AWS 수준의 Attach 와 Linux OS 수준의 Mount 는 다른 작업이다. Attach는 Disk를 Server에 연결하는 것이고, Mount는 그 Disk의 File System을 Linux Directory에 연결하는 작업이다. 이번 EBS 실습의 가장 중요한 확인 포인트다. 14. EBS Snapshot EBS의 Data를 보호하기 위한 방법으로 Snapshot 을 사용할 수 있다. 구조는 다음과 같다. EBS Volume ↓ Snapshot ↓ Backup / Recovery 강의에서는 EC2와 EBS Data 보호를 위해 AMI와 EBS Snapshot을 활용할 수 있다고 설명한다. 이번 실습에서 Snapshot을 직접 생성하지는 않지만 이후 Backup과 Shared Responsibility를 다룰 때 다시 연결한다. 실습 목표 이번 편에서는 강의의 실습 2, 실습 3, 실습 4 를 연결해서 진행한다. 확인하려는 것은 세 가지다. 실습 2 EC2 Instance를 생성하고 어떤 정보가 만들어지는지 확인한다. 실습 3 Key Pair, Public IP, Security Group을 구성하여 EC2에 Remote Login할 수 있는 구조를 확인한다. 실습 4 EBS Volume을 추가하고 Linux File System으로 실제 사용할 수 있는 상태까지 구성한다. 전체 흐름은 다음과 같다. EC2 생성 ↓ EC2 구성 확인 ↓ SSH 연결 조건 추가 ↓ Remote Login ↓ EBS 생성 ↓ EC2에 Attach ↓ Format + Mount ↓ File 생성 확인 실습 Architecture Local PC │ │ SSH TCP 22 ▼ Public IP │ ▼ Security Group │ ▼ EC2 Amazon Linux 2023 t3.micro │ │ Attach ▼ EBS 1GB gp3 │ ▼ /appdir EC2와 추가 EBS는 반드시 같은 Availability Zone 에 생성한다. 실습 환경 강의자료 기준으로 다음 Resource를 사용한다. 항목 설정 Compute EC2 AMI Amazon Linux 2023 Instance Type t3.micro Network Default VPC Public IP 자동 할당 활성화 Remote Access SSH / EC2 Instance Connect SSH Port TCP 22 Key Pair 실습 중 생성 Root Storage EC2 생성 시 구성되는 EBS 추가 Storage EBS 1GB EBS Type gp3 Mount Point /appdir 일부 실습 참조자료에는 t2.micro , gp2 표기도 있지만, 전체 이론자료와 강의 진행에서는 t3.micro , gp3 구성을 사용한다. 초기 상태 실습 시작 전 다음을 확인한다. 1편에서 확인한 자신의 할당 Region을 사용하고 있는가? 실습용 EC2가 아직 생성되지 않았는가? 추가 EBS Volume이 없는 상태인가? 실습 중 Resource를 생성한 뒤에는 마지막에 다시 삭제한다. 실습 절차 실습 2 - 간단한 EC2 Instance 생성 1. EC2 Console 이동 AWS Management Console에서 다음 경로로 이동한다. Console → EC2 → Instances → Launch instances 먼저 현재 Region이 강의에서 자신에게 할당된 Region인지 확인한다. 2. AMI 선택 AMI는 다음을 사용한다. Amazon Linux 2023 이 AMI를 기반으로 EC2의 Root Volume과 OS 환경이 구성된다. 3. Instance Type 선택 강의 환경에서는 다음 Type을 사용한다. t3.micro 이번 실습의 목적은 성능 Benchmark가 아니라 EC2의 생성 구조를 이해하는 것이므로 작은 Instance Type을 사용한다. 4. Network 설정 강의의 첫 EC2 실습에서는 미리 존재하는 Default VPC 를 사용한다. VPC → Default VPC Public IP 자동 할당이 활성화되어 있는지도 확인한다. VPC와 Subnet이 정확히 어떤 역할을 하는지는 4편에서 자세히 다룬다. 5. Instance 생성 나머지 기본 설정을 확인한 뒤 Instance를 시작한다. Instance 목록에서 상태가 생성 중에서 실행 가능한 상태로 바뀌는 것을 확인한다. 6. EC2 상세 정보 확인 생성된 EC2를 선택하고 다음 정보를 살펴본다. Instance ID Instance State AMI Instance Type Availability Zone Private IP Public IP Security Group Storage 이번 단계의 핵심은 EC2 하나가 만들어졌을 때 어떤 정보들이 함께 생성되는지 확인하는 것 이다. 첫 번째 간단한 생성 실습이 끝났다면 해당 EC2를 종료하여 정리한다. 실습 3 - EC2 생성 후 SSH 연결 이번에는 Remote Login이 가능하도록 EC2를 다시 생성한다. 실습 2와 대부분 동일하지만 두 가지가 추가된다. Key Pair + Security Group TCP 22 1. EC2 생성 다시 다음 경로로 이동한다. Console → EC2 → Instances → Launch instances 다음 값을 사용한다. AMI: Amazon Linux 2023 Instance Type: t3.micro VPC: Default VPC Public IP 자동 할당: 활성화 2. Key Pair 생성 EC2 생성 화면에서 새로운 Key Pair를 생성한다. 생성한 Private Key File은 Local PC에 저장한다. 이 File은 SSH Authentication에 사용되므로 잃어버리거나 외부에 공개하지 않는다. 3. Security Group 설정 SSH 연결을 위해 Inbound Rule에 다음 Service가 허용되어 있는지 확인한다. Type: SSH Protocol: TCP Port: 22 강의 실습에서는 외부 Notebook에서 직접 접속할 수 있도록 설정한다. 단, 전체 Internet에서 접근할 수 있도록 0.0.0.0/0 으로 SSH를 공개하는 방식은 실습 편의를 위한 설정으로 보고 실제 운영에서는 필요한 Source만 허용하는 방향으로 구성해야 한다. 4. EC2 생성 후 정보 확인 Instance가 생성되면 다음 항목을 다시 확인한다. Instance State Public IP Security Group Key Pair Availability Zone 특히 SSH 연결에는 Public IP가 필요하므로 Public IPv4 Address를 확인한다. 5. SSH 연결 Local Terminal 또는 SSH Client에서 다음 형식의 명령을 사용한다. ssh -i <Private-Key-File> ec2-user@<EC2-Public-IP> 각 항목의 의미는 다음과 같다. 항목 의미 ssh SSH Client 실행 -i 사용할 Private Key File 지정 ec2-user Amazon Linux의 실습용 Login User Public IP 접속할 EC2 주소 강의 환경에서는 Git Bash나 PuTTY 같은 SSH Client를 사용할 수도 있다. 6. EC2 Instance Connect로 연결 SSH 외에도 Console에서 다음 경로를 통해 Browser 기반 연결을 확인할 수 있다. EC2 → Instances → 대상 Instan