AWS 기술 블로그
Category: Compute
Amazon ECS 실행 구조와 선택 기준 – 1부: 컴퓨트와 실행 형태
AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch type)이 변경되지 않아 어려움을 […]
Amazon ECS 실행 구조와 선택 기준 – 2부: 배포 전략과 네트워크, 설계 상한
이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다. 2부에서는 남은 선택지를 다룹니다. 6종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 […]
Amazon EC2 Nitro V6의 Connection Tracking 유휴 타임아웃 변경 대응하기
주말 내내 트래픽이 없던 서비스에서 월요일 아침 첫 요청들만 유독 타임아웃으로 실패합니다. Karpenter가 노드를 교체한 뒤부터는 원인을 알 수 없는 연결 오류가 늘었는데, 부하 테스트를 아무리 돌려도 재현되지 않습니다. 최근 이런 증상을 겪었다면 애플리케이션 코드보다 먼저 확인할 것이 있습니다. 워크로드를 실행 중인 인스턴스 타입의 세대와 Nitro 버전입니다. 2025년 6월부터 출시되고 있는 Nitro V6 기반 인스턴스(m8i, […]
AWS Lambda의 4가지 실행 모델 – 구조와 선택 기준
Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크로드는 […]
LG CNS의 Agentic AI를 활용한 APQR 시스템 설계 및 자동화 구축 사례
본 블로그는 LG CNS 와 AWS 가 공동 작성하였습니다. 품질보증 담당자가 QMS, LIMS, SAP, EDMS를 오가며 자료를 모으고 APQR 리포트 한 건을 완성하는 데는 약 12시간이 걸렸습니다. 종근당과 LG CNS는 Agentic AI로 이 시간을 약 1시간으로 줄였습니다. LG CNS는 AWS 프리미어 파트너로, 다수의 대규모 엔터프라이즈 고객을 대상으로 SM(운영 유지보수)/AM(현대화)/Migration 서비스를 제공하고 있습니다. 이 글은 1941년 […]
실리콘투의 사내 지식 MCP 게이트웨이 구축기
실리콘투는 한국의 뷰티 브랜드를 전 세계 고객에게 유통하는 글로벌 플랫폼 기업입니다. 수많은 브랜드와 상품, 국가별 물류가 실시간으로 맞물려 돌아가고, 이 방대한 흐름을 CMS, WMS, OMS를 비롯한 여러 사내 시스템이 나눠 맡습니다. 사업이 커질수록 업무 규칙도 함께 불어났고, 그 규칙은 저장 프로시저(SP, Stored Procedure. 데이터베이스에 넣어 두고 불러 쓰는 SQL 로직 묶음), 소스 코드, 그리고 여기저기 […]
Amazon Bedrock에서 LLM 게이트웨이의 두 사각지대 메우기: 사라진 호출자와 흐려진 모델 거버넌스
Amazon Bedrock 앞에 LLM 게이트웨이(이하 게이트웨이)를 두면 편의와 통제를 얻지만, 그 대가로 Amazon Bedrock이 보는 호출자 신원과 모델별 관측 지점이 게이트웨이 뒤로 흐려지는 사각지대가 생깁니다. 이 글은 잘 알려진 레퍼런스 아키텍처를 출발점으로, 그 사각지대를 Amazon Bedrock 네이티브 기능으로 보완하는 방법 (호출자 감사 추적과 모델별 관측 및 거버넌스)을 다룹니다. <Claude Code → LLM 게이트웨이 → Amazon Bedrock> […]
분산 학습을 위한 AWS 컴퓨트 선택 가이드 (3편: 클러스터 구축과 운영)
1편에서 모델 규모에 맞는 인스턴스 타입과 인터커넥트 기술을, 2편에서 Amazon EC2 UltraClusters(울트라클러스터) 및 Amazon EC2 UltraServer(울트라서버)와 고성능 GPU 인스턴스 확보 전략을 다뤘습니다. 무엇을 고르고 어떻게 확보할지가 정해졌다면, 이제 실제로 클러스터를 구성하고 운영할 차례입니다. 이번 3편에서는 컨테이너 기반 환경 구성, 클러스터를 구성하기 전 점검사항, 온프레미스 환경과의 비교, GPU와 Trainium의 선택, 그리고 현장에서 자주 마주치는 문제의 해결까지 […]
한화솔루션의 Amazon Bedrock 기반 Claude Cowork 전사 도입 여정 — 사내 LLM Gateway로 완성한 거버넌스
이 블로그는 한화솔루션 분석/AI팀과 AWS의 협업으로 작성되었습니다 한화솔루션은 사내 임직원과 개발자가 Claude 기반 도구(Claude Cowork, Claude Code)를 안전하고 통제 가능한 방식으로 사용할 수 있도록, Amazon Bedrock 위에 단일 사내 LLM Gateway를 구축했습니다. 특히 Claude Cowork를 AWS 기반으로 전사에 안정 배포한 것은 국내 첫 사례입니다. 이 게이트웨이는 계열사별로 분리된 여러 인증 체계를 하나로 수용하는 멀티테넌트 인증에서 […]
합성 데이터 없이 로봇 월드 모델을 학습하는 방법
이 글은 AWS Physical AI Blog에 게시된 Training World Models on Scene Semantics, Not Pixels을 번역 및 편집한 글입니다. 사전학습된 AI 모듈과 고전 컴퓨터 비전을 조합하여, 도메인 데이터나 합성 프레임 없이 일반 단안(monocular) 영상에서 장면 의미론(scene semantics)을 추출하는 새로운 로봇 월드 모델 학습법을 소개합니다. 소개 오늘날 로봇 AI 학습은 어디를 가나 같은 레시피를 따릅니다. 거대 […]









