🤔 해도 해도 끝이 없는 AWS

• 오늘은 이번 주 AWS를 배우며 공부했던 내용들과 AWS 서비스를 정갈하게 정리해보는 시간을 가지게 되었습니다.
• 이번 주는 프로젝트와 같이 병행하느라 정신없게 수업을 듣고, 정리를 마무리했었는데 오늘은 시간이 남아 AWS를 총정리할 수 있어서 너무 다행입니다.
• 다음 주에는 전처럼 블로그 작성에 힘써보겠습니다! 아래는 이번 주에 진행한 프로젝트들입니다.

GitHub - RJ-Stony/heated-pavement-planning: 보행 취약 계층 보호 및 제설 사각지대 해소를 위한 열선 설치

GitHub - RJ-Stony/noodle-jobs: IT 기술 면접 준비 플랫폼

GitHub - RJ-Stony/logmin: Let's conquer all logins with React, Spring

 

---

🌐 웹 서비스 배포를 하기 위한 주요 AWS 서비스

• 웹 애플리케이션을 AWS에 배포하려면 컴퓨팅 리소스(서버), 스토리지(파일 저장소), DB, 네트워킹 및 보안, 트래픽 관리 등이 필요합니다.
• AWS에서는 EC2와 같은 가상 서버부터 VPC를 이용한 네트워크 격리, 로드 밸런서, DNS, CDN, DB 서비스 등 여러 서비스를 조합해 확장성 있고 안정적인 웹 아키텍처를 구축할 수 있습니다.
• 웹 서비스 배포에 자주 활용되는 AWS 주요 서비스를 하나씩 나열해보며 설명해보겠습니다.

 

✨ Amazon EC2 (Elastic Compute Cloud)

EC2란?

• Amazon EC2는 AWS의 가상 서버 인스턴스 서비스입니다.
• 사용자는 EC2를 통해 클라우드 상에 필요한 만큼의 서버를 생성하고(OS와 스펙 선택), 애플리케이션을 설치하여 실행할 수 있습니다.
• 주요 기능으로는 다양한 CPU/RAM 스펙의 인스턴스 타입 제공, 서버 수 자동 확장(Auto Scaling), 부하 분산(로드 밸런싱) 연계, 다양한 운영체제 이미지(AMI) 선택 등이 있습니다.

 

💡 왜 사용할까?

• EC2는 웹 서비스 배포의 핵심 컴퓨팅 자원으로 쓰입니다.
• 예를 들어 웹 애플리케이션의 웹 서버나 API 서버를 EC2 인스턴스로 실행합니다.
• 또 필요에 따라 데이터 파이프라인의 일환으로 백그라운드 배치 작업을 EC2에서 수행하기도 하지만, 데이터 처리 분야에서는 종종 서버리스나 관리형 서비스로 대체되기도 합니다.

 

💡 어떤 서비스랑 연계될까?

• EC2는 거의 모든 AWS 인프라 서비스와 연계됩니다.
• VPC 안에서 실행되어서 서브넷 및 라우팅의 영향을 받으며, 보안 그룹으로 인바운드/아웃바운드 트래픽을 제어하기도 하고,
• IAM 역할을 부여해 EC2 인스턴스에서 AWS 리소스에 접근 권한을 관리하기도 합니다.
• EC2에 연결되는 EBS 볼륨은 영구 디스크 역할을 하고, Auto Scaling 그룹과 연계하여 부하에 따라 인스턴스 수를 동적으로 조절합니다.
• 또한 ELB(로드 밸런서)를 통해 여러 EC2 인스턴스로 트래픽을 분산시켜 고가용성을 구현하고, 필요하면 CloudWatch 에이전트를 설치해 시스템 로그와 메트릭(CPU, 메모리 등)을 모니터링합니다.

 

💡 그럼 실제로는 어떻게 사용할까?

• 예를 들어 EC2로 웹 서버를 배포하는 과정을 생각해본다면,
• 먼저 새로운 VPC 및 서브넷을 구성한 뒤, EC2 인스턴스를 생성합니다.
• 이때 키 페어를 설정해 SSH로 접속할 수 있게 하고, 보안 그룹을 설정하여 HTTP(80번)와 HTTPS(443번) 포트 등 웹 트래픽을 허용합니다.
• 웹 서버 소프트웨어(Nginx/Apache 등)를 설치하고 애플리케이션을 배포하면, 해당 EC2가 인터넷상의 클라이언트 요청을 처리하는 웹 서버로 동작합니다.
• 만약 서비스 규모가 커지면 Auto Scaling 그룹을 사용해 동일한 설정의 EC2 인스턴스를 다수 운영하며 부하에 따라 인스턴스 수를 늘이거나 줄일 수 있습니다.
• 이 때 앞단에 Application Load Balancer(ALB)를 두어 다수의 EC2에 트래픽을 분산시키고, Route 53을 통해 사용자 도메인 이름을 로드 밸런서에 매핑합니다.
• EC2 인스턴스는 IAM 역할을 통해 필요하면 S3 버킷(정적 파일 저장 등)이나 DynamoDB 등의 자원에 접근할 수 있으며, CloudWatch Logs를 통해 애플리케이션 로그를 중앙에 수집하거나 CloudWatch 알람으로 EC2 상태를 모니터링할 수 있습니다.

 

✨ Amazon S3 (Simple Storage Service)

S3란?

• Amazon S3는 무제한 확장 가능한 객체 스토리지 서비스로, 파일(객체)을 클라우드에 저장하고 HTTP 기반으로 접근할 수 있게 해줍니다.
• 파일을 저장하는 버킷(Bucket) 단위로 관리하며, 높은 내구성(99.999999999% or 11 9’s)과 가용성을 제공하고, 정교한 권한 제어와 버전 관리, 수명주기 관리 등의 기능을 갖추고 있습니다.

 

💡 왜 사용할까?

• S3는 웹 서비스 배포와 데이터 파이프라인 양쪽에서 모두 핵심적인 역할을 합니다.
• 웹 분야에서는 정적 콘텐츠(이미지, CSS, JS 파일 등)나 사용자 업로드 파일을 저장하고 제공하는 데 사용합니다.
  • 예를 들어 웹 서버에서 직접 이미지를 서빙하는 대신 S3에 저장해 두고 사용자 브라우저가 S3에서 바로 다운로드하도록 하면 웹 서버 부하를 줄일 수 있습니다.
• 또한 정적 웹 호스팅 기능을 사용하면 S3 버킷 자체를 웹 서버처럼 사용하여 간단한 정적 웹사이트를 호스팅할 수도 있습니다.
• 데이터 파이프라인 측면에서는 S3가 데이터 레이크(data lake) 역할을 하여, 다양한 소스의 원천 데이터를 저장하고 이후 처리/분석을 위한 중심 저장소로 활용됩니다.
  • 예를 들어서 로그 데이터, 대용량 CSV 파일, 백업 데이터 등을 S3에 모아두고 AWS Glue나 EMR로 읽어서 처리하거나, Athena로 쿼리 분석하는 식으로 활용됩니다.

 

💡 그럼 실제로는 어떻게 사용할까?

• 웹 서비스 시나리오로, 사용자가 이미지 파일을 업로드하는 웹 애플리케이션을 생각해본다면,
• 사용자가 이미지를 업로드하면 애플리케이션 서버(EC2)가 해당 파일을 S3 버킷에 저장합니다.
• 이후 사용자에게 이미지를 보여줄 때는 S3 프리사인드 URL을 생성하거나 CloudFront와 연계된 정적 경로를 제공하여, 사용자가 S3(또는 CloudFront 캐시)에서 직접 이미지를 다운로드하게 합니다. 이렇게 하면 웹 서버의 부하를 줄이고 대용량 콘텐츠도 효율적으로 전달할 수 있습니다.
• 데이터 파이프라인에서의 예로는, 여러 시스템에서 생성된 로그 파일을 주기적으로 S3 버킷에 수집해 놓으면, AWS Glue가 정해진 스케줄에 해당 버킷을 읽어들여 데이터를 정제 및 파싱한 후 다시 S3에 저장하거나 데이터 웨어하우스(Redshift)에 적재하는 식으로 활용할 수 있습니다.
• 이 과정에서 S3에 새로운 파일이 생길 때마다 S3 이벤트 알림을 통해 SNS나 Lambda로 통지해 파이프라인 처리를 트리거할 수도 있습니다.

 

✨ ELB (Elastic Load Balancing)

ELB란?

• AWS Elastic Load Balancing(ELB)은 분산된 서버 그룹 앞단에서 클라이언트 트래픽을 균등하게 분산 처리해주는 서비스입니다.
• 주로 웹 서비스에서 많이 사용하는 Application Load Balancer (ALB)는 7계층(HTTP/HTTPS) 로드 밸런서로서, URL 경로나 호스트별 정교한 라우팅과 HTTPS 종료(SSL 인증서적용) 등의 기능을 제공합니다.
• 이 외에도 TCP/UDP 레벨의 Network Load Balancer (NLB), 레거시 Classic Load Balancer(CLB) 등이 있습니다.

 

💡 왜 사용할까?

• 웹 애플리케이션을 고가용성 및 확장성 있게 운영하려면 여러 대의 서버가 함께 서비스해야 하고, 사용자의 요청을 그 중 적절한 서버로 분배해 주어야 합니다.
• 로드 밸런서는 이러한 역할을 담당하여 다수의 EC2 인스턴스 또는 컨테이너에 트래픽을 분산시킵니다.
• 또한 한 대의 서버 장애 시 자동으로 헬스체크(Health Check)로 감지하여 트래픽을 제외함으로써 장애 대응을 해줍니다.
• ALB는 URL 기반으로 정적 콘텐츠와 동적 콘텐츠를 서로 다른 서버군으로 보낸다거나(/images/* 요청은 정적 서버로, 나머지는 애플리케이션 서버로),
• 마이크로서비스 아키텍처(MSA)에서 여러 서비스로 경로를 분기시키는 등 스마트 라우팅에도 활용됩니다.
• NLB는 주로 게임 서버나 IoT 서버 등 초당 수십만 연결의 대용량 트래픽, 또는 고정 IP가 필요한 서비스에 활용됩니다.

 

💡 어떤 서비스랑 연계될까?

• 로드 밸런서는 대상(Target) 리소스와 연계됩니다.
• ALB의 경우 Target Group을 만들고 대상에 EC2 인스턴스, IP, Lambda 함수 등을 등록합니다.
• 일반적으로 Auto Scaling 그룹을 사용하면 EC2 인스턴스들이 자동으로 Target Group에 등록/해제되어 동적으로 스케일 됩니다.
• ALB는 IAM의 AWS Certificate Manager(ACM)과 연계하여 HTTPS 인증서 관리를 맡기고, WAF(Web Application Firewall)와도 통합되어 웹 공격 트래픽 필터링을 적용할 수 있습니다.
• 또한 CloudWatch에서 로드 밸런서의 요청 수, 응답 시간, HTTP 상태 코드 등의 지표를 모니터링하고 액세스 로그를 S3에 저장할 수도 있습니다.
• Route 53 DNS 서비스와 통합하면 ALB의 도메인 이름을 CNAME 또는 Alias 레코드로 등록하여 사용자 트래픽을 받아옵니다.
• NLB의 경우 Global Accelerator나 프라이빗 링크(Endpoint Service)와 연계되어 하이브리드 클라우드 시나리오에 쓰이기도 합니다.

 

💡 그럼 실제로는 어떻게 사용할까?

• 3티어 웹 애플리케이션에서 프론트엔드(웹 서버) 계층과 백엔드(애플리케이션 서버) 계층에 각각 로드 밸런서를 둘 수 있습니다.
• 예를 들어 외부 ALB를 생성해서 인터넷에서 들어오는 HTTP/HTTPS 요청을 받아주고, 이를 웹 서버 역할의 EC2로 분산시킵니다.
• 웹 서버들은 다시 백엔드 요청이 필요하면 내부에서 내부용 ALB를 통해 애플리케이션 서버 그룹으로 요청을 전달합니다. 이러한 이중 로드 밸런싱을 통해 웹 계층과 앱 계층을 분리하고 확장성을 높일 수 있습니다.
• 단일 레이어만 있는 간단한 웹앱이라면 외부 ALB 하나만 두고 바로 EC2/컨테이너 그룹으로 보내면 됩니다.
• 설정 시 ALB의 리스너(Listener)를 80/443 포트로 두고 대상 그룹의 헬스체크 경로를 지정하여 자동으로 인스턴스 상태를 확인하도록 합니다.
  • 예를 들어 /health 엔드포인트를 주기적으로 요청해서 200 OK를 받으면 정상 인스턴스로 간주하고, 3번 이상 실패하면 자동으로 대상에서 제거합니다.
•  이렇게 하면 장애난 인스턴스는 트래픽에서 제외되어 사용자는 중단 없는 서비스를 받게 됩니다.
• 또한 ACM에 등록된 SSL 인증서를 ALB 리스너에 연결하면 HTTPS 트래픽을 ALB단에서 종료(SSL Offloading)하고 백엔드로는 HTTP로 보내어, 각 EC2에는 인증서 설치 부담 없이도 보안 트래픽 처리가 가능합니다.
• ALB의 규칙(Rules)을 활용해서 특정 경로에 WAF 규칙을 추가하거나, 특정 쿠키/헤더 값에 따라 다른 대상 그룹으로 라우팅하는 것도 가능합니다.

 

✨ Amazon RDS (Relational Database Service)

RDS란?

• Amazon RDS는 관리형 관계형 데이터베이스 서비스로, MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, 그리고 AWS 고유 DB엔진인 Amazon Aurora 등을 클라우드에서 손쉽게 운영할 수 있게 해줍니다.
• RDS를 사용하면 데이터베이스 소프트웨어의 설치, 패치, 백업, 복제, 복구 등 관리 작업의 많은 부분이 자동화되며, 고가용성을 위한 다중 AZ 복제나 읽기 전용 복제본(Read Replica) 구성도 클릭 몇 번으로 설정할 수 있습니다.

 

 

💡 왜 사용할까?

• 대부분의 웹 애플리케이션의 백엔드 데이터 저장소로 관계형 데이터베이스를 사용하는데, RDS는 이를 위한 최적의 선택입니다.
• EC2에 직접 DB를 설치할 수도 있지만, RDS를 사용하면 더욱 안정적이고 관리 부담이 적습니다.
• 예를 들어 사용자 정보나 게시글, 거래 내역 등을 저장하고 질의하기 위해 웹 서비스는 RDS의 MySQL 혹은 PostgreSQL 엔진을 사용할 수 있습니다.
• RDS는 자동 백업과 장애 조치(Failover)를 지원하므로 운영 데이터베이스의 신뢰성을 높여줍니다.
• 데이터 파이프라인 측면에서는 RDS가 원천 데이터 소스나 최종 결과 저장소로 쓰이기도 합니다.
  • 예를 들어 온프레미스 Oracle DB에서 클라우드로 데이터를 이전할 때 RDS Oracle을 대상으로 쓰거나, ETL 파이프라인의 처리 결과를 RDS에 적재하여 웹 애플리케이션이 활용하도록 하는 경우입니다.

 

💡 어떤 서비스랑 연계될까?

• RDS 인스턴스는 VPC 내의 DB 서브넷 그룹에 생성되며, 보안 그룹 규칙을 통해 애플리케이션 서버(EC2 등)로부터의 DB 접속(TCP 3306 등)을 허용해야 합니다.
• AWS DMS(Database Migration Service)를 사용하면 외부 데이터베이스에서 RDS로 데이터 마이그레이션을 수행할 수 있고, 반대로 RDS 데이터를 S3 등에 내보낼 수도 있습니다.
• RDS의 이벤트 알림을 SNS로 받아 DB 인스턴스 상태 변화를 모니터링하거나, CloudWatch 지표(RDS CPU, Connections, FreeStorage 등)를 통해 성능을 모니터링 및 스케일링 기준으로 활용합니다.
• 예컨대 CloudWatch 경보로 연결 수 증가를 감지하여 읽기 복제본을 늘리는 등의 대응을 고려할 수 있습니다.
• RDS는 AWS Secrets Manager와 통합해 DB 자격증명을 안전하게 저장/교체할 수 있고, CloudTrail로 어떤 관리 작업이 발생했는지 기록을 남깁니다.

 

💡 그럼 실제로는 어떻게 사용할까?

• 웹 서비스에서 RDS MySQL을 사용하는 예를 들어보자면!
• 관리 콘솔에서 RDS 인스턴스를 생성할 때, 엔진(MySQL), 버전, 인스턴스 클래스(성능/크기), 멀티 AZ 여부, 스토리지 용량, VPC/서브넷 그룹, 보안 그룹 등을 설정합니다.
• 멀티 AZ를 선택하면 마스터 DB가 한 AZ에, 동기화된 스탠바이 DB가 다른 AZ에 만들어져서 하나에 장애가 발생하면 자동으로 페일오버됩니다.
• 애플리케이션 서버 EC2의 보안 그룹에서 아웃바운드 3306 포트를 열고, RDS 보안 그룹에서는 해당 EC2 보안그룹으로부터의 인바운드 3306을 허용하여 통신이 이뤄지도록 합니다.
• 웹 애플리케이션은 DB 엔드포인트(호스트명)으로 RDS에 접속하여 질의합니다.
• RDS는 매일 자동 백업을 수행하고 지정된 보관 기간동안 스냅샷을 보관하므로, 개발자는 데이터 백업/복구에 신경쓸 일이 줄어듭니다.
• 만약 읽기 트래픽이 매우 많은 서비스라면 RDS의 Read Replica(읽기 전용 복제본)를 활성화해서 여러 개의 복제본 엔드포인트로 읽기 질의를 분산시키고, 쓰기는 여전히 마스터로 보내도록 애플리케이션을 수정할 수 있습니다.
• 데이터 파이프라인 시나리오로는, 온프레미스에 있던 Oracle DB를 AWS로 옮기기 위해 AWS DMS를 활용하여 RDS Oracle 인스턴스로 지속적인 CDC(Change Data Capture) 복제를 수행하거나, 반대로 RDS에서 누적된 데이터를 정기적으로 S3에 덤프하여 Athena로 분석하는 경우가 있습니다.

 

✨ Amazon VPC (Virtual Private Cloud)

VPC란?

• Amazon VPC는 AWS 상에서 사용자가 독립적으로 구성할 수 있는 가상 네트워크 환경입니다.
• 한 AWS 계정 내에 여러 개의 VPC를 만들 수 있으며, 각 VPC는 IP 대역대(CIDR)를 갖고 그 안에 서브넷, 라우팅 테이블, 게이트웨이 등을 설정하여 마치 독자적인 데이터센터 네트워크를 구축하는 것처럼 사용할 수 있습니다.
• VPC를 통해 AWS 리소스(EC2, RDS 등)를 퍼블릭 네트워크로부터 격리하고 세밀한 트래픽 제어 및 보안을 구현할 수 있습니다.

 

💡 왜 사용할까?

• 웹 서비스 배포 환경에서는 기본적으로 VPC 내부에 모든 리소스가 생성됩니다.
• VPC를 사용함으로써 외부에 노출되어야 하는 리소스(웹 서버용 EC2, ALB 등)와 내부에서만 작동해야 하는 리소스(DB 서버, 캐시 서버 등)를 네트워크 레벨에서 분리할 수 있습니다.
• 가령 퍼블릭 서브넷에는 인터넷 게이트웨이를 통해 외부 통신이 가능한 자원만 두고, 프라이빗 서브넷에는 내부 자원만 두어 보안을 강화하는 식입니다.
• 데이터 파이프라인의 경우에도, Glue나 Redshift 같은 서비스가 VPC 내에서 동작하며 S3나 인터넷에 접근할 때 VPC 엔드포인트나 NAT를 통해 통신하도록 구성할 수 있습니다.
• 즉, VPC는 AWS 리소스들의 통신 범위를 지정하고 네트워크 구조를 설계하는 기본 토대입니다.

 

💡 용어가 너무 어렵다...

• VPC에는 여러 하위 개념들이 함께 사용됩니다.
• 서브넷(Subnet): VPC CIDR 내에 분할된 IP 블록으로, 퍼블릭 서브넷은 인터넷 게이트웨이(IGW)에 라우팅되어 외부와 통신 가능하고 프라이빗 서브넷은 외부에서 직접 접근 불가한 내부망입니다. 일반적으로 멀티 AZ 아키텍처를 위해 각 AZ별로 퍼블릭/프라이빗 서브넷을 1개 이상씩 만듭니다.
• 라우팅 테이블(Route Table): 서브넷에 연결되서, 해당 서브넷의 트래픽 방향을 결정합니다. 예를 들어 퍼블릭 서브넷의 라우팅 테이블에는 0.0.0.0/0 -> IGW(인터넷 게이트웨이) 경로가 있고, 프라이빗 서브넷은 대신 0.0.0.0/0 -> NAT 경로가 있습니다. 또한 VPC 내 통신은 Local 경로로 자동 허용됩니다.
• 인터넷 게이트웨이(IGW): VPC를 인터넷에 연결시켜주는 게이트웨이입니다. 하나의 VPC에 하나의 IGW를 연결할 수 있고, 퍼블릭 서브넷의 자원들은 IGW를 통해 공인 IP로 인터넷 왕래가 가능합니다.
• NAT 게이트웨이/인스턴스: 프라이빗 서브넷의 리소스가 아웃바운드로만 인터넷에 접속할 수 있게 해주는 장치입니다. NAT 게이트웨이는 관리형으로 고가용성으로 제공되며 퍼블릭 서브넷에 위치시켜 사용합니다. 이것으로 프라이빗 자원들도 소프트웨어 업데이트나 외부 API Call 등을 할 수 있지만, 외부에서 해당 자원으로는 들어올 수 없습니다.
• VPC 엔드포인트: AWS의 특정 서비스(S3, DynamoDB 등)에 접근할 때 인터넷을 거치지 않고 AWS 내부망으로 직접 연결하는 인터페이스입니다. 게이트웨이 엔드포인트와 인터페이스 엔드포인트 두 종류가 있으며, 예를 들어 S3 게이트웨이 엔드포인트를 설정하고 라우팅 테이블에 추가하면 프라이빗 서브넷의 EC2가 NAT 없이도 S3에 접근 가능합니다.
• 보안 그룹 & NACL: VPC 레벨에서의 방화벽 개념으로, 보안 그룹(Security Group)은 인스턴스/ENI 레벨에서 적용되는 상태 저장형(Stateful) 방화벽이고, 네트워크 ACL은 서브넷 레벨에서 적용되는 stateless 방화벽입니다. 보안 그룹은 주로 EC2나 RDS 등에 직접 붙여서 인바운드/아웃바운드 트래픽 포트를 제어하며, NACL은 서브넷 경계에서 IP/포트 단위의 필터링을 하는데 주로 광범위한 거부 규칙(잘 알려진 악성 IP 차단 등) 등에 쓰입니다.

 

💡 그럼 실제로는 어떻게 사용할까?

• 웹서비스 VPC 아키텍처를 예로 들어보겠습니다.
• 예컨대 10.0.0.0/16 CIDR을 가진 VPC를 만들고, 이를 ap-northeast-1a AZ에 퍼블릭 서브넷(10.0.0.0/24)과 프라이빗 서브넷(10.0.1.0/24), ap-northeast-1b AZ에도 퍼블릭(10.0.2.0/24)과 프라이빗(10.0.3.0/24) 서브넷을 각각 만들었습니다.
• VPC에 IGW를 연결하고 퍼블릭 서브넷 2개에는 라우팅 테이블에 IGW 경로를 추가합니다.
• 두 개의 퍼블릭 서브넷에는 각각 NAT 게이트웨이를 하나씩 배치하고, 프라이빗 서브넷들의 라우팅 테이블에 0.0.0.0/0 -> 해당 AZ의 NAT를 설정합니다.
• 이제 퍼블릭 서브넷에는 ALB와 Bastion용 EC2(필요 시)를 넣고, 프라이빗 서브넷에는 웹서버 EC2나 RDS 같은 것을 배치합니다.
• ALB SG는 0.0.0.0/0에서 80/443을 받고 EC2 SG로 전달, EC2 SG는 ALB SG로부터 80을 허용, RDS SG는 EC2 SG로부터 3306을 허용 등 보안 그룹 체인을 구성합니다.
• 이렇게 하면 인터넷 -> ALB -> 웹 EC2 -> (필요 시) RDS 흐름이 이 VPC 안에서 완성됩니다.
• 또한 웹 EC2가 소프트웨어 업데이트를 받거나 외부 API를 호출할 때 NAT를 거쳐나가므로 외부에서는 EC2의 프라이빗 IP가 드러나지 않습니다.
• S3 연동이 많다면 S3 엔드포인트를 추가해 프라이빗하게 통신하도록 설정합니다.
• 결과적으로 이 VPC 환경에서는 외부에 노출되는건 ALB와 NAT Gateway 뿐이고, 애플리케이션 서버와 DB는 외부 접근이 차단되어 보안이 향상됩니다.

 

---

🤔 57일차 회고

• 이번 주는 단순히 AWS 서비스들을 나열하는 데 그치지 않고, 웹 서비스를 구성하는 전체 구조 안에서 각 서비스들이 어떤 역할을 맡고, 서로 어떻게 연결되는지를 정리해보는 데 집중해 보았습니다.
• 처음엔 각각의 서비스가 너무 많고 용어도 생소해서 막막했지만, 하나하나를 실제 시나리오에 녹여서 생각해보니 머릿속에서 구조도가 그려지기 시작한 느낌입니다.
• 특히 EC2와 S3, RDS, VPC 같은 핵심 서비스들을 중심으로, '왜 이걸 써야 하지?'라는 질문을 던져보며 연결 지점을 찾는 과정이 흥미로웠던 것 같아요 !
• 이번 정리를 통해 깨달은 건, AWS는 단순히 서비스를 쓰는 플랫폼이 아니라, 설계하고 운영하는 '마인드셋'을 요구하는 플랫폼이라는 점인 것 같습니다.
• 단순히 서버를 띄우는 것뿐 아니라, 네트워크 구조와 보안까지 고려해야 하다 보니, 자연스럽게 인프라 관점에서의 사고를 배우게 되는 것 같습니다.
• 아직 완벽히 이해한 건 아니지만, 이번 기회를 통해 '내가 운영하고 싶은 웹서비스를 AWS 위에 어떻게 안정적이고 효율적으로 올릴 수 있을까?'를 조금 더 구체적으로 그려볼 수 있었던 것 같습니다.