AWS Certified Solutions Architect – Associate(SAA-C03)는 클라우드 엔지니어나 아키텍트를 지망한다면 반드시 거쳐야 할 '관문' 같은 자격증입니다. 단순히 개별 서비스의 기능을 아는 것을 넘어, 비용 효율적이고 탄력적인 클라우드 아키텍처를 설계할 수 있는 역량을 검증하기 때문입니다.저는 컴퓨터공학을 졸업하고 클라우드 아키텍트를 목표로 준비하며, 지난 25년 9월 CLF 취득을 시작으로 3-Tier 아키텍처를 직접 구축해 보는 등 인프라 운영의 기초를 다져왔습니다. 프로젝트 당시에도 항상 공식 문서를 참고하며 베스트 프랙티스를 찾으려 노력했지만, 특정 기능을 구현하기 위해 파편적으로 정보를 찾는 방식으로는 아키텍처 전체의 유기적인 연결성을 완벽히 이해하는 데 한계가 ..

클라우드 컴퓨팅이 기업 인프라의 표준이 되면서, 이제는 단순히 콘솔에서 버튼을 클릭해 자원을 생성하는 것을 넘어, 코드로 인프라를 관리하고 자동화하려는 IaC(Infrastructure as Code)의 중요성이 그 어느 때보다 커지고 있습니다. 이번 포스팅에서는 AWS의 대표적인 IaC 서비스인 AWS CloudFormation을 활용하여, 인프라를 코드로 정의하고 S3 버킷을 자동으로 생성하는 과정을 상세히 기록해 보았습니다. 특히 이번 실습은 AWS 프리티어 범위 내에서 진행되어 비용 부담 없이 인프라 자동화의 기초를 다질 수 있도록 구성했습니다. 실습에 앞서, 인프라 자동화의 핵심 개념들을 명확히 정리할 필요가 있습니다.IaC (Infrastructure as Code)말 그대로 '코드로 관리하는..

본 포스팅에서는 AWS의 파운데이션 모델인 Amazon Nova Pro와 AWS Lambda를 활용하여, 보안 규제 텍스트를 분석하고 요약하는 서버리스 API를 구축하는 과정을 다룹니다.아키텍처 개요구축할 시스템의 데이터 흐름은 다음과 같습니다.Amazon Bedrock (Nova Pro): AWS 자체 개발 모델. 추론 속도와 비용 효율성이 특징.AWS Lambda: Serverless 컴퓨팅 리소스.API Gateway: REST API 엔드포인트 제공.Bedrock 모델 준비2025년 최신 업데이트로 Model Access 페이지가 폐지되고, 모델 사용 절차가 획기적으로 간소화되었습니다.과거 방식: Model Access 메뉴 진입 → 모델 선택 → 사용 신청 → 승인 대기현재 방식 (Auto-En..

생성형 AI(Generative AI)가 IT 업계의 표준으로 자리 잡으면서, 단순히 제공된 모델을 API로 호출하여 사용하는 것을 넘어 비즈니스 요구사항에 맞춰 최적화하려는 시도가 늘어나고 있습니다.이번 포스팅에서는 AWS의 완전 관리형 서비스인 Amazon Bedrock을 활용하여, Meta의 오픈소스 모델인 Llama 3.1 8B를 직접 파인튜닝(Fine-tuning) 하고, 특정 교육학적 패턴을 준수하는 'AI 튜터'를 만드는 과정을 상세히 기록해 보았습니다. 실습에 앞서, 쏟아지는 생성형 AI 용어들의 개념과 역할을 명확히 정리할 필요가 있습니다.파운데이션 모델 (Foundation Model)말 그대로 모든 AI 서비스의 '기반(Foundation)이 되는 모델'을 의미합니다. 과거의 AI 모..

지난 Part 9에서는 S3와 CloudFront를 연동하여 정적 콘텐츠 서빙을 최적화함으로써, 우리 웹 애플리케이션의 성능을 한 단계 끌어올렸습니다. 이로써 우리는 VPC 네트워크 설계부터 DB 구축, 애플리케이션 배포, 도메인 연결, 성능 최적화까지 클라우드 배포의 전 과정을 완주했습니다. 하지만 인프라 구축이 끝이 아닙니다. 실제 서비스 운영에서는 시스템이 정상적으로 작동하는지 지속적으로 감시(Monitoring)하고, 문제가 발생했을 때 원인을 빠르게 파악(Logging)하며, 장애 상황을 즉시 인지(Alerting)하는 것이 매우 중요합니다. 이것이 바로 운영 우수성의 핵심입니다. 이번 마지막 Part 10에서는 AWS의 대표적인 모니터링 및 로깅 서비스인 Amazon CloudWatch와 AW..

지난 Part 8에서는 외부에서 구매한 도메인을 Route 53에 연결하고 ACM을 통해 무료 HTTPS 인증서까지 적용하여, 사용자가 https://my-service.com과 같은 안전하고 기억하기 쉬운 주소로 우리 서비스에 접근할 수 있는 환경을 완성했습니다.이제 사용자는 우리 웹사이트를 이용할 수 있지만, 아직 최적화되지 않은 부분이 남아있습니다. 바로 웹사이트 로딩 속도입니다. 우리의 아키텍처 다이어그램에는 정적 콘텐츠(CSS, JS, 이미지)를 S3와 CloudFront를 통해 서비스하여 성능을 높이는 계획이 포함되어 있었습니다.하지만 아직 이 S3와 CloudFront 부분을 구성하고 애플리케이션과 연동하지 않았기 때문에, 현재는 아래와 같이 모든 요청이 ALB를 거쳐 EC2 인스턴스의 Sp..

지난 Part 7에서는 드디어 Application Load Balancer (ALB)를 구성하여 외부 사용자가 프라이빗 서브넷의 EC2 애플리케이션에 접근할 수 있는 경로를 만들었습니다. 하지만 지금은 my-app-alb-1234567890.ap-northeast-2.elb.amazonaws.com과 같은 복잡한 주소로 접속해야 하고, 암호화되지 않은 HTTP 통신을 사용하고 있어 보안에도 취약합니다. 이번 Part 8에서는 이 두 가지 문제를 해결합니다. AWS의 DNS 서비스인 Route 53을 이용하여 우리가 소유한 사용자 지정 도메인(예: my-service.com)을 ALB에 연결하고, AWS Certificate Manager (ACM)를 통해 무료 SSL/TLS 인증서를 발급받아 HTTPS..

지난 Part 6에서는 AWS의 최신 보안 권장사항을 따라 Bastion Host 없이 SSM과 VPC 엔드포인트를 이용해 프라이빗 RDS에 원격 접속하는 방법을 완성했습니다. 하지만 아직 우리 웹사이트는 외부 사용자가 접근할 수 없는, 우리만 아는 '비밀 기지' 상태입니다. 이번 Part 7에서는 드디어 이 비밀 기지에 외부로 통하는 안전한 정문을 만듭니다. 바로 Application Load Balancer (ALB)를 구성하여, 인터넷 사용자의 요청을 받아 프라이빗 서브넷에 있는 우리의 EC2 애플리케이션 서버로 안전하게 전달하는 과정을 구축해 보겠습니다.Application Load Balancer (ALB)란 무엇인가? ALB는 AWS에서 제공하는 Layer 7 (HTTP/HTTPS) 로드 밸런..