aws·2026년 7월 20일·4분 읽기큐레이션 요약

AWS 주간 정리: 원클릭 Lambda 설정 프롬프트, Bedrock의 OpenAI GPT-5.6 모델 등 (2026년 7월 20일) | Amazon Web Services

AWS의 이번 주 주요 소식은 코딩 에이전트의 Lambda 설정 자동화와 Amazon Bedrock의 OpenAI GPT-5.6 모델 출시다. 이와 함께 S3 스토리지 비용 절감, Lambda 코드 저장 방식 개선, Cognito 사용자 가져오기 기능 등이 추가됐다. AWS는 AI 에이전트 개발과 서버리스 운영을 단순화하는 한편, 비용 효율성과 대규모 데이터 처리 기능도 강화하고 있다. ## AWSKRUG와 개발자 커뮤니티 협력 - AWS 팀이 서울을 방문해 AWS Korea User Group(AWSKRUG) 리더들과 교류했다. - AWSKRUG는 주제·지역별 20개 밋업 그룹으로 구성된 한국 최대 규모의 클라우드 개발자 커뮤니티다. - 매년 100회 이상의 행사를 개최하며, AWS Developer Experience 팀에 대한 피드백과 개선 요구를 공유했다. ## 코딩 에이전트의 원클릭 Lambda 설정 - Lambda 콘솔에서 제공하는 프롬프트를 AI 코딩 에이전트에 전달하면 AWS 서버리스 개발 환경을 자동으로 구성할 수 있다. - AWS Serverless 스킬과 Serverless MCP 서버가 포함되어 서버리스 모범 사례를 에이전트에 기본 적용한다. - Claude Code, Kiro, Cursor, GitHub Copilot, Codex, Devin Desktop, OpenCode 등을 지원한다. - 다음 URL을 에이전트에 입력해 설정 가이드를 불러올 수 있다. ```text fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md ``` - AWS Agent Toolkit을 사용하면 에이전트에 최신 AWS 지식과 안전한 리소스 접근 권한을 제공할 수 있다. ```text fetch https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md ``` ## Amazon Bedrock의 OpenAI GPT-5.6 모델 - Amazon Bedrock에서 OpenAI의 GPT-5.6 계열 모델인 Sol, Terra, Luna를 사용할 수 있다. - 모델별 용도는 다음과 같다. - **Sol**: 최고 수준의 추론 성능을 제공하는 플래그십 모델 - **Terra**: 성능과 비용의 균형을 중시하는 모델 - **Luna**: 빠르고 비용 효율적인 추론에 적합한 모델 - Bedrock의 고성능·보안·신뢰성 중심 추론 엔진과 Responses API를 통해 접근할 수 있다. ## S3 저장 클래스의 당일 전환 - 이제 객체 생성 당일부터 S3 Standard-IA 또는 S3 One Zone-IA로 전환할 수 있다. - 기존에는 S3 Standard에 최소 30일 보관해야 했다. - 두 저장 클래스는 S3 Standard보다 최대 40% 저렴하면서도 필요할 때 밀리초 단위로 접근할 수 있다. - 생성 직후 빠르게 사용 빈도가 낮아지는 백업, 로그 분석, 규정 준수 데이터를 저장하는 데 적합하다. ## Lambda 코드의 자체 S3 저장 - 사용자가 직접 관리하는 Amazon S3 버킷에 Lambda 소스 코드를 저장하고 이를 직접 참조할 수 있다. - Lambda가 중간 복사본을 생성하는 과정이 사라진다. - 이에 따라 Lambda 코드 저장 용량 제한을 없애고, 함수 생성·업데이트 후 활성화 시간을 줄일 수 있다. ## Cognito 비밀번호 해시 가져오기 - Amazon Cognito CSV 사용자 가져오기 과정에서 기존 시스템의 비밀번호 해시를 함께 등록할 수 있다. - 사용자는 최초 로그인 시 비밀번호를 재설정하지 않고 기존 자격 증명으로 바로 로그인할 수 있다. - CSV를 생성할 때 원본 시스템에서 사용한 비밀번호 해시 알고리즘을 지정해야 한다. ## SQS 20주년과 AI 에이전트용 개방형 프로토콜 - Amazon SQS가 공개 출시 20주년을 맞았다. - 생산자와 소비자를 분리해 시스템 간 결합도를 낮추는 메시징 패턴이 여전히 핵심 가치다. - Strands Agents SDK를 활용해 MCP, A2A, UTCP, AG-UI, x402 등 AI 에이전트용 개방형 프로토콜이 어떻게 연동되는지 소개했다. - 특정 프레임워크에 종속되지 않고 여러 에이전트 시스템에 적용할 수 있는 통합 패턴을 다룬다. ## DynamoDB 대량 작업 자동화 - 오픈소스 Bulk Executor for DynamoDB가 테이블 전체 항목을 대상으로 하는 대량 작업을 단순화한다. - 별도 코드를 작성하지 않고 다음 작업을 수행할 수 있다. - `count`: 전체 항목 수 계산 - `find`: 조건에 맞는 항목 검색 - `delete`: 항목 대량 삭제 - `update`: 항목 대량 수정 - 대규모 테이블에서도 일괄 작업을 쉽게 실행할 수 있다. ## Kiro CLI를 활용한 AWS Support 자동화 - Kiro CLI의 MCP 통합으로 장애 조사, AWS 문서 검색, 지원 사례 생성 과정을 하나의 대화형 인터페이스로 처리할 수 있다. - 주요 활용 사례는 다음과 같다. - AWS Glue 작업 실패 분석 - AWS Lambda 콜드 스타트 원인 조사 - AWS WAF 오탐 분석 - 지원 담당자가 여러 도구를 오가며 수행하던 작업을 대화형 워크플로로 통합한다. ## Cost Explorer 요금 표시 오류 - 일부 고객의 Cost Explorer에서 예상 청구액과 비용·사용량 데이터가 부정확하게 표시되는 문제가 발생했다. - 잘못된 예산 경고와 비용 이상 탐지 알림이 발생하거나 예상 비용이 부풀려질 수 있었다. - 문제는 해결됐으며 AWS는 재발 방지와 청구 관련 장애 대응 개선을 위한 사후 검토를 진행 중이다. - 자세한 내용은 AWS Health Dashboard에서 확인할 수 있다. 서버리스 개발자는 Lambda 에이전트 설정 프롬프트와 자체 S3 코드 저장 기능을 우선 검토할 만하다. 데이터 저장 비용이 중요한 환경에서는 S3의 당일 IA 전환을 활용하고, 대규모 DynamoDB 일괄 작업이나 AWS 지원 업무에는 Bulk Executor와 Kiro CLI를 적용하면 운영 효율을 높일 수 있다.

원문 읽기(새 탭에서 열림)

amazon-s3AI 에이전트amazon-bedrockaws-lambda+4

aws·2026년 7월 13일·4분 읽기큐레이션 요약

Amazon SQS 20주년: 대규모 환경에서 20년간 이어온 안정적인 메시징 | Amazon Web Services

Amazon SQS는 서비스 간 결합도를 낮추고 장애 전파를 막기 위해 메시지를 비동기적으로 전달하는 AWS의 관리형 메시지 큐 서비스다. 출시 20년 동안 FIFO 고처리량, 암호화 기본 적용, DLQ 복구, 대규모 메시지 처리 등 기능이 크게 발전했지만, 서비스 간 분리·트래픽 버퍼링·장애 격리라는 핵심 역할은 변하지 않았다. 최근에는 멀티테넌트 시스템과 AI 에이전트·추론 워크로드에도 활용 범위가 확대되고 있다. ## 비동기 메시징을 통한 서비스 결합도 완화 - 서비스가 서로 직접 호출하면 호출 대상의 지연이나 장애가 연쇄적으로 전체 시스템에 영향을 줄 수 있다. - SQS를 사용하면 생산자는 메시지를 큐에 저장한 뒤 작업을 계속하고, 소비자는 처리 가능한 시점에 메시지를 가져갈 수 있다. - 이를 통해 다음과 같은 효과를 얻는다. - 서비스 간 의존성 및 결합도 감소 - 트래픽 급증 시 메시지 큐를 버퍼로 활용 - 특정 서비스 장애가 전체 시스템으로 확산되는 것을 방지 - 소비자의 처리 속도에 맞춘 안정적인 작업 처리 ## FIFO 큐의 처리량과 동시성 향상 - 2021년 FIFO 큐 고처리량 모드가 출시되며 API 작업당 초당 3,000건(TPS)을 지원했다. - 이후 처리량이 단계적으로 증가했다. - 2022년: 6,000 TPS - 2023년 8월: 9,000 TPS - 2023년 10월: 18,000 TPS - 2023년 11월: 일부 리전에서 최대 70,000 TPS - 2024년에는 FIFO 큐의 인플라이트 메시지 한도가 20,000개에서 120,000개로 증가했다. - 소비자가 동시에 처리할 수 있는 메시지가 늘어나 대규모 순서 보장 처리에 유리해졌다. ## 암호화와 세분화된 접근 제어 - 2021년 SQS 관리형 키를 사용하는 서버 측 암호화 방식인 SSE-SQS가 도입됐다. - 2022년 10월부터 새로 생성되는 큐에는 SSE-SQS가 기본 적용됐다. - 고객이 직접 암호화 키를 생성하고 관리하지 않아도 메시지를 보호할 수 있다. - 2022년에는 ABAC(Attribute-Based Access Control)가 추가됐다. - 큐의 고정된 리소스 정책 대신 태그를 기준으로 권한을 부여할 수 있다. - 큐와 환경이 늘어나는 대규모 시스템에서 권한 정책 관리 부담을 줄인다. ## DLQ 메시지 복구 기능 강화 - 처리에 실패한 메시지를 보관하는 Dead-Letter Queue(DLQ)에서 원래 큐로 메시지를 되돌리는 기능이 단계적으로 확대됐다. - 2021년에는 SQS 콘솔에서 DLQ 메시지를 소스 큐로 직접 재전송할 수 있게 됐다. - 2023년에는 SDK와 CLI에서도 다음 API를 사용할 수 있게 됐다. - `StartMessageMoveTask`: 메시지 이동 작업 시작 - `CancelMessageMoveTask`: 이동 작업 취소 - `ListMessageMoveTasks`: 이동 작업 목록 조회 - 같은 해 FIFO 큐에도 redrive 기능이 지원됐다. - 운영 중 실패한 메시지를 수동으로 재처리하거나 별도 개발 없이 복구할 수 있다. ## 메시지 처리 성능과 연동성 개선 - 2023년 AWS SDK에 JSON 프로토콜 지원이 추가됐다. - 5KB 페이로드 기준 종단 간 처리 지연을 최대 23% 줄이고, 클라이언트의 CPU·메모리 사용량도 낮췄다. - SQS 콘솔에서 EventBridge Pipes와 큐를 직접 연결할 수 있게 됐다. - 별도의 통합 코드를 작성하지 않고도 큐 메시지를 다양한 AWS 서비스 대상으로 라우팅할 수 있다. ## 대용량 메시지와 페이로드 확장 - 2024년 Python용 Extended Client Library가 제공됐다. - 최대 2GB 크기의 메시지를 Amazon S3에 저장하고, SQS에는 해당 데이터의 참조 정보만 전달할 수 있다. - 2025년에는 표준 큐와 FIFO 큐의 최대 메시지 크기가 256KiB에서 1MiB로 증가했다. - AWS Lambda의 SQS 이벤트 소스 매핑도 이 새로운 페이로드 크기를 지원하도록 업데이트됐다. ## 멀티테넌트 환경을 위한 공정한 처리 - 2025년 표준 큐에 fair queues가 도입됐다. - 메시지를 보낼 때 메시지 그룹 ID를 포함하면 특정 테넌트가 큐를 독점하는 ‘시끄러운 이웃(noisy neighbor)’ 문제를 완화할 수 있다. - 소비자 측 코드를 변경하지 않고도 한 테넌트의 대량 메시지가 다른 테넌트의 처리 지연을 유발하는 상황을 줄일 수 있다. ## AI 시스템으로 확장되는 SQS의 활용 - SQS의 기본 패턴은 AI 워크로드에도 적용된다. - 활용 사례는 다음과 같다. - 대규모 언어 모델 요청을 큐에 저장해 추론 요청량 조절 - 추론 처리량을 소비자 수와 처리 속도에 맞춰 관리 - 독립적으로 동작하는 AI 에이전트 간 작업과 통신 조정 - AI 서비스가 일시적으로 느려지거나 중단돼도 요청을 큐에 보관해 전체 시스템의 안정성을 유지할 수 있다. 실무에서는 서비스 간 직접 호출이 장애 전파나 트래픽 급증 문제를 일으키는 경우 SQS를 우선 검토할 수 있다. 순서 보장과 중복 처리 방지가 필요하면 FIFO 큐를, 실패 메시지 복구가 중요하면 DLQ와 redrive 기능을 함께 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)

amazon-s3AWS분산 시스템amazon-sqs+4

aws·2026년 6월 22일·4분 읽기큐레이션 요약

전체 수명 주기 제어로 격리된 샌드박스 실행하기: AWS Lambda, MicroVM 도입 | Amazon Web Services

AWS Lambda MicroVMs는 사용자나 AI가 생성한 신뢰할 수 없는 코드를 사용자별로 격리된 실행 환경에서 실행하도록 설계된 서버리스 컴퓨팅 기능이다. Firecracker 기반의 VM 수준 격리, 스냅샷을 활용한 빠른 시작·재개, 메모리와 디스크 상태를 유지하는 실행 세션을 제공하면서도 인프라를 직접 운영할 필요가 없다. 특히 AI 코딩 도구, 온라인 개발 환경, 데이터 분석, 취약점 스캐너처럼 사용자별 장기 실행 환경이 필요한 서비스의 기존 격리·성능 trade-off를 줄이는 것이 핵심이다. ## 사용자별 격리 실행 환경이 필요한 이유 - AI 코딩 어시스턴트, 대화형 코드 실행 환경, 데이터 분석 플랫폼, 취약점 스캐너, 사용자 스크립트를 실행하는 게임 서버 등이 주요 대상이다. - 기존 방식에는 각각 한계가 있다. - **가상 머신**: 강력한 격리를 제공하지만 시작에 수분이 걸릴 수 있다. - **컨테이너**: 빠르게 시작되지만 공유 커널 때문에 신뢰할 수 없는 코드를 안전하게 격리하려면 추가적인 보안 강화가 필요하다. - **서버리스 함수**: 이벤트 기반 요청-응답 처리에 적합하지만, 사용자 상호작용 사이에 상태를 유지하는 장기 세션에는 적합하지 않다. - 직접 가상화 인프라를 구축하면 낮은 지연 시간과 강한 격리를 모두 확보할 수 있지만, 상당한 운영·보안 전문성이 필요하다. ## Firecracker 기반 VM 수준 격리 - 각 사용자 또는 세션은 독립된 MicroVM을 할당받는다. - MicroVM 간 커널과 리소스를 공유하지 않으므로 한 사용자가 실행한 신뢰할 수 없는 코드가 다른 사용자 환경이나 호스트 시스템에 접근하는 것을 막는다. - AWS Lambda에서 대규모로 사용되어 온 Firecracker 기술을 기반으로 하므로, 자체 가상화 시스템을 구축하는 대신 AWS의 운영 성숙도를 활용할 수 있다. ## MicroVM Image 생성 과정 - 애플리케이션 코드와 Dockerfile을 ZIP 파일로 패키징해 Amazon S3에 업로드한다. - `public.ecr.aws/lambda/microvms:al2023-minimal` 기반 이미지에서 Python, pip 등을 설치하고 애플리케이션을 구성할 수 있다. - 예시 애플리케이션은 Gunicorn으로 실행되는 Flask API이며, `0.0.0.0:5000` 포트에서 요청을 처리한다. - 다음과 같은 CLI 명령으로 이미지를 생성한다. ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> \ --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> ``` - Lambda는 ZIP 파일을 가져와 Dockerfile을 빌드하고 애플리케이션을 초기화한다. - 초기화가 끝난 실행 중인 디스크와 메모리 상태를 Firecracker 스냅샷으로 저장한다. - 빌드 로그는 다음 CloudWatch Logs 경로에서 확인할 수 있다. ```text /aws/lambda/microvms/<image-name> ``` ## 스냅샷 기반 빠른 시작과 재개 - MicroVM은 일반적인 콜드 부팅 대신 사전에 초기화된 스냅샷에서 시작한다. - 애플리케이션 프로세스, 설치된 패키지, 메모리 상태 등이 준비된 상태이므로 실행 직후부터 요청을 처리할 수 있다. - 이후 생성되는 MicroVM도 동일한 이미지 스냅샷에서 복원되므로 초기화 시간을 줄일 수 있다. - 대규모 대화형 세션도 사용자 입장에서 즉시 반응하는 수준의 시작·재개 성능을 목표로 한다. ## 상태를 유지하는 세션과 유휴 정책 - 실행 중인 MicroVM은 다음 상태를 세션 동안 유지한다. - 메모리 상태 - 디스크 상태 - 실행 중인 프로세스 - 일정 시간 요청이 없으면 MicroVM을 일시 중지할 수 있다. - 중지 시 메모리와 디스크 상태를 보존하고, 요청이 다시 들어오면 해당 상태에서 자동으로 재개한다. - 예시 설정은 15분 유휴 후 중지하고, 5분 동안 중지 상태를 유지한 뒤 요청이 오면 자동 재개하도록 구성한다. ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` ## 엔드포인트와 요청 인증 - MicroVM을 실행하면 Lambda가 고유 ID와 전용 엔드포인트 URL을 제공한다. - 별도의 네트워킹 구성을 하지 않아도 애플리케이션에 접근할 수 있다. - CLI로 단기 인증 토큰을 생성한 뒤 HTTPS 요청의 `X-aws-proxy-auth` 헤더에 포함해 요청을 보낸다. - MicroVM이 중지된 뒤 다시 요청해도 애플리케이션 상태가 유지된 채 복원되므로 클라이언트는 중지·재개 과정을 직접 처리할 필요가 없다. ## 실용적인 활용과 추천 Lambda MicroVMs는 단순한 단발성 함수보다 사용자별로 지속되는 안전한 실행 환경이 필요한 서비스에 적합하다. 사용자 코드 실행, AI 에이전트의 도구 호출, 온라인 IDE, 샌드박스형 분석 환경을 구축한다면 컨테이너 직접 격리나 VM 운영을 대체할 수 있는 후보로 검토할 만하다. 다만 실제 도입 전에는 IAM 실행 역할, 인증 토큰 관리, 유휴·재개 정책, 상태 보존 범위와 비용을 서비스의 세션 패턴에 맞게 검증하는 것이 좋다.

원문 읽기(새 탭에서 열림)

amazon-s3PythonDocker & 컨테이너flask+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

넷플릭스에서 카산드라 데이터 이동의 진화

넷플릭스는 하루 약 1,200건, 약 3PB의 Cassandra 데이터를 Iceberg로 옮기던 기존 Casspactor를 확장 가능한 계층형 엔진으로 교체했다. 기존 시스템은 여러 메타데이터 서비스에 의존하고 대규모 파티션과 다양한 Cassandra 데이터 모델을 제대로 처리하지 못해 안정성·비용·확장성 문제가 발생했다. 새 구조는 S3 백업을 단일 진실 공급원으로 사용하고, Spark DataFrame과 커넥터 팩토리를 기반으로 각 데이터 모델에 최적화된 커넥터를 구축한다. ## Casspactor의 역할과 한계 - Casspactor는 Cassandra의 SSTable과 메타데이터를 S3 백업에서 읽어 Iceberg 테이블로 변환했다. - 하루 약 1,200건의 데이터 이동과 약 3PB 규모의 전송을 처리하며 핵심 업무를 지원했다. - Cassandra 노드의 사이드카 프로세스가 SSTable과 메타데이터를 S3에 업로드하고, 작업 실행 시 엔진이 필요한 백업 구조를 구성했다. - 이후 SSTable을 다운로드하고 mutation compaction과 변환을 수행한 뒤 Iceberg에 기록했다. - 그러나 단일 커넥터로 설계되어 Key Value, Time Series, Graph 등 여러 데이터 추상화에 공통 기반을 제공하기 어려웠다. ## 분산된 메타데이터 의존성 문제 - Casspactor는 백업의 존재 여부, 완전성, 포함 데이터를 여러 독립 시스템의 메타데이터를 조합해 판단했다. - 각 시스템의 갱신 주기와 정확도, 장애 방식이 달라 실제 백업 상태와 Casspactor의 인식이 불일치할 수 있었다. - 메타데이터가 실제 백업과 어긋나면 오래되거나 잘못된 데이터를 조용히 읽는 문제가 발생했다. - Cassandra 클러스터 유지보수 중 비동기 스냅샷이 만들어졌고, 한 리전에 있는 모든 노드가 같은 시각에 스냅샷을 생성해야 한다는 제약도 있었다. - 노드 하나가 교체되면 리전 전체의 데이터 이동이 실패할 수 있었다. - 새 구조에서는 백업 파일 자체의 메타데이터를 직접 읽어 S3를 백업 존재 여부와 완전성을 판단하는 단일 진실 공급원으로 사용한다. ## 모든 커넥터가 물려받은 제약 - **대규모 파티션 처리 실패** - Key Value와 Time Series에서 흔한 넓은 파티션을 처리하지 못했다. - 일부 작업은 메모리 부족으로 종료됐다. - **데이터 모델 인식 부족** - 원시 Cassandra 테이블만 이동했기 때문에 Key Value 등의 커넥터가 별도의 후처리로 데이터 모델을 복원해야 했다. - 이로 인해 처리 비용과 복잡성, 장애 가능성이 증가했다. - **중간 테이블 증가** - Casspactor는 최종 결과 전에 중간 Iceberg 테이블을 생성했다. - Key Value 커넥터는 추가 중간 테이블과 스냅샷 테이블까지 필요했다. - 상위 데이터 추상화가 추가될수록 중간 저장 공간과 비용이 누적됐다. - **Time Travel 불가** - 여러 서비스를 조합해 백업 단위를 구성했기 때문에 클러스터 토폴로지나 Keyspace 스키마가 변경된 뒤 과거 백업을 복원하기 어려웠다. - **모놀리식 구조** - Casspactor는 재사용 가능한 엔진이 아니라 하나의 커넥터였다. - 데이터 모델별 목적형 커넥터를 공통 기반 위에 구축할 수 없었다. ## 새로운 계층형 아키텍처 - 새 구조는 Apache Cassandra Analytics, 넷플릭스의 Move Data 프레임워크, 내부 백업 표현 방식과 S3 클라이언트를 결합한다. - 가장 아래 계층인 Cassandra Analytics Wrapper가 S3 백업에서 원시 데이터를 읽는다. - 읽은 결과는 표준 Spark DataFrame으로 변환된다. - 상위 계층의 Connector Factory는 Java UDF와 변환 로직을 통해 데이터 추상화별 커넥터를 생성한다. - Key Value나 Time Series 커넥터는 일반적인 DataFrame을 입력으로 받아 자체 데이터 모델에 맞게 처리한다. - 핵심 읽기 엔진의 개선 사항은 모든 커넥터에 적용되고, 각 커넥터는 변환 로직에 집중할 수 있다. ## Spark 기반 처리와 운영 개선 - mutation compaction과 데이터 처리를 Spark Executor 수준으로 이동했다. - 대규모 또는 편향된 파티션을 과도한 셔플 없이 처리해 메모리 부족 문제를 줄였다. - Cassandra 백업에서 바로 Spark DataFrame을 생성하므로 중간 Iceberg 테이블이 필요하지 않다. - 중간 저장 비용과 다단계 파이프라인의 운영 복잡성이 감소한다. - 소스 테이블의 특성에 따라 작업 리소스를 자동 조정하는 auto-sizing 기능을 제공한다. - 엔지니어가 작업별 리소스를 수동으로 조정하지 않아도 성능과 비용을 최적화할 수 있다. - S3의 백업 메타데이터를 직접 사용해 여러 외부 서비스에 대한 의존성을 제거하고 안정성을 높였다. ## 실용적인 결론 대규모 Cassandra 데이터 이동 시스템은 백업 메타데이터를 여러 서비스에서 조합하기보다 실제 저장소를 단일 진실 공급원으로 삼는 편이 안정적이다. 또한 원시 데이터 추출 엔진과 데이터 모델별 변환 커넥터를 분리하면, 공통 성능 개선을 재사용하면서도 Key Value·Time Series 같은 각 도메인에 최적화된 처리를 구현할 수 있다.

원문 읽기(새 탭에서 열림)

amazon-s3apache-sparkapache-icebergapache-cassandra+3

aws·2026년 6월 17일·4분 읽기큐레이션 요약

2026 뉴욕 AWS 서밋의 주요 발표 | Amazon Web Services

AWS Summit New York 2026의 핵심은 AI 에이전트를 더 쉽게 구축하고, 기업 데이터와 웹 지식을 연결하며, 운영·보안·개발 전반을 자동화하는 것이다. AWS는 Bedrock AgentCore, 보안·DevOps 에이전트, Kiro, Amazon Quick 등을 통해 에이전트의 생성부터 배포, 관리, 지속적인 개선까지 지원하는 기능을 공개했다. 또한 S3 객체에 직접 쿼리 가능한 맥락 정보를 저장하는 기능과 AI 봇 대상 콘텐츠 과금 기능도 발표했다. ## 기업 지식과 웹 검색을 활용하는 에이전트 - **Amazon Bedrock Managed Knowledge Base** - 기업용 RAG 파이프라인을 관리형 서비스로 구축할 수 있다. - 네이티브 데이터 커넥터와 다양한 형식의 데이터를 자동 처리하는 **Smart Parsing**을 제공한다. - 복잡한 다단계 질문을 처리하는 **Agentic Retriever**를 지원한다. - Bedrock AgentCore Gateway와 통합되어 인프라 관리 부담을 줄인다. - **Amazon Bedrock AgentCore Web Search** - AI 에이전트가 최신 웹 정보를 검색하고 출처를 포함해 답변할 수 있다. - 고객의 보안 AWS 환경에서 데이터가 외부로 유출되지 않도록 설계됐다. - 개발자가 별도의 검색 인프라를 직접 구축·운영하지 않아도 된다. - **AWS Context** - 기존 데이터 간 관계를 자동으로 분석해 지식 그래프로 구성하는 서비스다. - 에이전트가 실행 시점에 조직의 데이터 관계, 업무 규칙, 도메인 지식을 검색할 수 있도록 한다. - 거버넌스가 적용된 기업 데이터를 에이전트가 활용하는 기반으로 소개됐다. ## AI 에이전트에 대한 통제와 운영 - **Bedrock AgentCore의 새로운 기능** - 조직 내부 지식, 웹 정보, 유료 지식 소스를 에이전트에 연결할 수 있다. - 프로덕션 환경에서 발생한 문제를 찾고 수정하는 기능을 제공한다. - 에이전트의 능력이 확장되어도 적용 가능한 통제 체계를 구축할 수 있다. - **Amazon Bedrock AgentCore Harness 정식 출시** - 오케스트레이션 루프를 직접 코딩하지 않고도 프로덕션 수준의 에이전트를 구축·실행할 수 있다. - 설정 파일에서 모델, 도구, 스킬, 지침을 정의하는 방식이다. - 에이전트 개발 시간을 단축하는 데 초점을 둔다. - **AWS WAF의 AI 트래픽 과금** - 콘텐츠 제공자가 콘텐츠와 API에 접근하는 AI 봇 및 에이전트에 요금을 부과할 수 있다. - 접근량을 측정하고, 제3자 결제 사업자를 통한 결제를 지원한다. - AWS 엣지에서 범위가 제한된 접근 권한을 직접 부여할 수 있다. ## 머신 속도의 애플리케이션 보안 - **AWS Continuum** - 여러 환경에서 수집한 코드 취약점 정보를 통합한다. - 비즈니스 영향도를 기준으로 취약점을 우선순위화한다. - 실제 악용 가능성을 검증하고, 조직의 기존 프로세스를 통해 수정까지 연결한다. - 코드 취약점 기능은 제한된 미리보기로 제공된다. - **AWS Security Agent** - 애플리케이션 전체 맥락을 분석해 위협 모델을 생성한다. - STRIDE 프레임워크를 활용해 위협과 권장 완화책을 제시한다. - 주요 Git 플랫폼의 풀 리퀘스트 코드 검사와 자동 수정 흐름을 지원한다. - Kiro Power, Claude Code 플러그인, MCP를 통한 IDE 연동도 제공한다. ## 개발과 릴리스 자동화 - **Kiro for iOS** - iPhone에서 Kiro 세션을 시작하고 모니터링할 수 있다. - 작업 완료 후 변경 diff를 검토하고 수정 사항을 승인할 수 있다. - 노트북을 계속 켜두지 않아도 개발 작업을 원격으로 관리할 수 있다. - **AWS DevOps Agent의 릴리스 관리** - 프로덕션 배포 전 코드 변경 사항의 릴리스 준비 상태를 검토한다. - 자연어로 정의한 조직의 기준에 따라 변경 사항을 검증한다. - 프로덕션과 유사한 환경에서 변경 사항별 테스트를 자동 실행한다. - **AWS Transform의 지속적 현대화** - 설정 가능한 기준에 따라 코드 저장소를 지속적으로 분석한다. - 기술 부채와 현대화 대상을 수주가 아닌 수시간 내에 식별하는 것을 목표로 한다. - 우선순위가 정해진 문제에 대해 자동으로 수정 풀 리퀘스트를 생성할 수 있다. ## 업무를 수행하는 자율 에이전트 - **Amazon Quick 자율 에이전트** - 특정 전문성, 말투, 도구 접근 권한을 가진 백그라운드 에이전트를 만들 수 있다. - 금융 에이전트가 주문을 처리하거나, 영업 에이전트가 CRM·이메일·Slack을 모니터링할 수 있다. - 후속 연락 초안 작성, 위험 신호 표시, 다음 업무 추천 등을 자동 수행한다. - **새로운 Activity Feed** - 이메일, 메시지, 일정, 작업을 하나의 우선순위 기반 화면에 통합한다. - 사용자가 빠르게 답하는 메시지, 건너뛰는 대화, 업무상 자주 다루는 주제를 학습한다. - 개인의 업무 방식에 맞춰 중요한 활동을 선별한다. ## AI 에이전트를 위한 S3 메타데이터 - **Amazon S3 annotations** - S3 객체에 최대 1GB의 풍부하고 변경 가능한 맥락 정보를 직접 추가할 수 있다. - 저장된 정보는 쿼리 가능하므로 AI 에이전트가 객체의 의미와 관련 정보를 바로 탐색할 수 있다. - 별도의 메타데이터 시스템을 유지하지 않고도 대규모 데이터 처리와 자율 워크플로를 지원한다. 이번 발표는 AWS가 AI 에이전트를 단순한 대화형 기능이 아니라 지식 검색, 보안 대응, 코드 수정, 릴리스 검증, 업무 실행까지 담당하는 운영 시스템으로 확장하고 있음을 보여준다. 실제 도입 시에는 에이전트의 자율성보다 데이터 접근 권한, 비용 통제, 감사 로그, 사람의 승인 절차를 먼저 설계하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

amazon-s3AI 에이전트amazon-bedrockRAG+4

aws·2026년 6월 16일·4분 읽기큐레이션 요약

Amazon S3 어노테이션: 풍부하고 쿼리 가능한 컨텍스트를 객체에 직접 첨부하기 | Amazon Web Services

Amazon S3 annotations는 객체에 대규모·구조화된 비즈니스 맥락을 직접 연결하고, 객체를 다시 작성하지 않고도 수정·삭제할 수 있게 하는 새로운 메타데이터 기능이다. 객체당 최대 1,000개의 annotation을 저장할 수 있으며, 각 annotation은 최대 1MB, 전체 최대 1GB까지 지원한다. S3 Metadata를 활성화하면 annotation을 Athena 등으로 대규모 조회할 수 있어 AI 에이전트와 자동화된 데이터 워크플로에 적합하다. ## S3 annotations의 특징과 규모 - JSON, XML, YAML, 일반 텍스트 등 다양한 형식을 지원한다. - annotation마다 고유한 이름을 부여한다. - 객체당 최대: - 1,000개 annotation - annotation 하나당 1MB - 전체 1GB - 객체 데이터를 다시 업로드하지 않고 annotation만 독립적으로 수정하거나 삭제할 수 있다. - 객체를 복사하거나 복제하거나 리전 간 전송할 때 annotation도 함께 이동한다. - 객체를 삭제하면 연결된 annotation도 자동으로 삭제된다. ## 기존 S3 메타데이터의 한계 - 시스템 정의 메타데이터는 객체 크기, 스토리지 클래스 등 S3가 관리하는 기본 속성에 초점을 둔다. - 객체 태그는 접근 제어와 수명 주기 관리 같은 운영 작업에 적합하지만 객체당 10개로 제한된다. - 사용자 정의 메타데이터는 업로드 시 지정하는 소량의 헤더 기반 정보이며, 약 2KB 수준이고 변경이 제한적이다. - 풍부한 설명이나 AI 분석 결과를 저장하려면 별도 데이터베이스나 사이드카 파일을 운영해야 했다. - 별도 메타데이터 시스템을 사용하면 원본 객체와 메타데이터 간 동기화 로직이 복잡해지고, 메타데이터 저장 비용이 객체 자체의 저장 비용보다 커질 수도 있다. ## AI 에이전트와 데이터 검색 - AI가 생성한 음성·영상 트랜스크립트, 요약, 감정 분석, 콘텐츠 등급 등을 객체에 직접 저장할 수 있다. - 메타데이터가 객체와 함께 이동하므로 데이터 복사·복제 과정에서 별도 동기화가 필요하지 않다. - S3 Metadata annotation 테이블을 사용하면 Athena와 다른 분석 엔진으로 annotation을 대규모 조회할 수 있다. - S3 Tables MCP 서버를 활용하면 AI 모델이 자연어 질의로 관련 데이터를 탐색할 수 있다. - 객체를 직접 복원하지 않고도 모든 스토리지 클래스의 annotation을 조회할 수 있으며, Glacier 계열에서도 객체 검색·복원 비용 없이 컨텍스트를 확인할 수 있다. ## 산업별 활용 사례 - **미디어·엔터테인먼트** - 영상별 트랜스크립트, 자막, 콘텐츠 검수 결과, 라이선스 정보를 별도 annotation으로 저장한다. - 여러 미디어 자산 관리 시스템 간 메타데이터 동기화를 줄일 수 있다. - **금융 서비스** - 연구 문서에 AI 기반 투자 요약과 감정 분석 결과를 연결한다. - 자연어 기반 에이전트가 별도 메타데이터 데이터베이스 없이 관련 문서를 탐색할 수 있다. - **생명과학** - 임상시험 데이터에 규제 상태, 환자군 정보, 승인 절차를 추가한다. - 보관된 데이터의 전체 맥락을 유지하면서 규제 감사와 컴플라이언스 검토를 간소화한다. ## annotation 생성·조회·수정·삭제 - IAM 정책 또는 버킷 정책에 다음 권한이 필요하다. - `s3:PutObjectAnnotation` - `s3:GetObjectAnnotation` - `PutObjectAnnotation` API로 기존 객체와 새 객체 모두에 annotation을 추가할 수 있다. - 예시처럼 하나의 영상 객체에 다음과 같이 서로 다른 정보를 저장할 수 있다. - `mediainfo`: 코덱, 해상도, 오디오 트랙 수 등을 JSON으로 저장 - `ai_summary`: AI가 생성한 영상 설명을 일반 텍스트로 저장 - 주요 API: - `GetObjectAnnotation`: 특정 annotation 조회 - `ListObjectAnnotations`: 객체에 연결된 전체 annotation 목록 확인 - `DeleteObjectAnnotation`: 특정 annotation 삭제 - `PutObjectAnnotation`: 같은 이름으로 호출해 기존 annotation 갱신 - 여러 팀이나 워크플로가 서로 다른 이름의 annotation을 사용하면 기술 정보, 콘텐츠 분류, 규제 정보 등을 서로 간섭 없이 동시에 관리할 수 있다. - 멀티파트 업로드 객체는 업로드를 완료한 뒤 `PutObjectAnnotation`으로 annotation을 추가해야 한다. ## 대규모 조회와 관리 - 개별 객체에 annotation을 붙이는 것만으로도 풍부한 컨텍스트를 보존할 수 있다. - S3 Metadata를 활성화하면 annotation이 관리형 annotation 테이블로 자동 전달된다. - 테이블 기반 조회를 통해 수많은 객체의 분류, 요약, 규제 상태, 기술 사양 등을 한 번에 검색할 수 있다. - 객체 본문을 모두 읽지 않고 메타데이터만 조회할 수 있어 대규모 데이터셋과 장기 보관 데이터에 특히 유리하다. S3 annotations는 단순한 태그나 업로드 시점의 헤더 메타데이터를 넘어, 변경 가능하고 대용량이며 조회 가능한 객체 컨텍스트를 제공한다. AI 에이전트, 콘텐츠 enrichment 파이프라인, 규제·감사 시스템처럼 객체의 의미와 상태가 계속 확장되는 환경에서는 별도 메타데이터 저장소를 구축하기 전에 annotations와 S3 Metadata 테이블 조합을 우선 검토할 만하다.

원문 읽기(새 탭에서 열림)

amazon-s3AI 에이전트jsonaws-cli+3

aws·2026년 5월 14일·3분 읽기큐레이션 요약

Amazon Bedrock, 새로운 고급 프롬프트 최적화 및 마이그레이션 도구 출시 | Amazon Web Services

Amazon Bedrock의 **Advanced Prompt Optimization**은 여러 모델에서 프롬프트를 자동으로 개선하고, 기존 프롬프트와 최적화된 프롬프트의 성능을 비교하는 도구입니다. 사용자는 예시 입력, 정답 데이터, 평가 기준을 제공하면 되며, 모델 마이그레이션이나 현재 모델의 성능 개선에 활용할 수 있습니다. 최적화 결과로 프롬프트, 평가 점수, 비용 추정치, 지연 시간이 함께 제공됩니다. ## 여러 모델을 동시에 비교하는 프롬프트 최적화 - 최대 5개의 Amazon Bedrock 추론 모델을 선택할 수 있습니다. - 새 모델로 마이그레이션하는 경우: - 현재 모델을 기준선으로 선택 - 최대 4개의 후보 모델과 성능 비교 - 모델을 변경하지 않는 경우에도 현재 모델의 최적화 전후 결과를 비교할 수 있습니다. - 알려진 사용 사례에서 성능 저하가 없는지 확인하거나, 성능이 낮은 작업을 개선하는 데 사용할 수 있습니다. ## 입력 데이터와 JSONL 템플릿 - 프롬프트 템플릿은 JSONL 형식으로 준비해야 합니다. - 각 JSON 객체는 한 줄에 작성해야 합니다. - 주요 필드는 다음과 같습니다. - `version`: 고정값 `bedrock-2026-05-14` - `templateId`: 프롬프트 템플릿 식별자 - `promptTemplate`: 최적화할 프롬프트 - `evaluationSamples`: 입력 변수와 선택적 기준 응답 - `steeringCriteria`: 자연어 기반 최적화 기준 - `customLLMJConfig`: 사용자 정의 LLM 평가 설정 - `evaluationMetricLambdaArn`: Lambda 기반 평가 함수 - 파일은 직접 업로드하거나 Amazon S3에서 가져올 수 있습니다. - 최적화 결과와 평가 데이터가 저장될 S3 출력 위치도 지정할 수 있습니다. ## 멀티모달 프롬프트 지원 - 텍스트 입력뿐 아니라 이미지와 문서가 포함된 프롬프트도 최적화할 수 있습니다. - 지원 파일 형식: - PNG - JPG - PDF - `inputVariablesMultimodal` 필드에 파일 유형과 S3 URI를 지정합니다. - 문서 분석, 이미지 분석과 같은 멀티모달 작업의 프롬프트 개선에 적합합니다. ## 평가 방식 세 가지 ### Lambda 기반 사용자 정의 평가 - 정확도, F1 점수, 실행 정확도, 구조화된 JSON 일치 여부처럼 명확한 수치 평가에 적합합니다. - Python으로 작성한 Lambda 함수에서 모델 응답과 기준 응답을 비교합니다. - `evaluationMetricLambdaArn`을 통해 평가 Lambda를 연결합니다. - 핵심 로직은 모델 출력과 정답을 비교해 점수를 계산하는 `compute_score` 구현입니다. ### LLM-as-a-Judge 평가 - 요약, 생성, 추론 설명처럼 정답이 하나로 정해지지 않은 작업에 적합합니다. - 사용자 정의 평가 프롬프트와 평가 기준, 점수 척도를 설정할 수 있습니다. - Bedrock의 평가 모델이 각 프롬프트와 응답을 평가하고 점수와 판단 근거를 반환합니다. - 기본 평가 모델은 Claude Sonnet 4.6이며, 지원되는 다른 평가 모델을 선택할 수도 있습니다. - 설정은 `customLLMJConfig`에 지정합니다. ### 자연어 기반 Steering Criteria - 브랜드 문체, 출력 형식, 안전 제약 등 원하는 품질을 자연어로 설명할 때 사용합니다. - 직접 복잡한 평가 프롬프트나 점수 체계를 작성하지 않아도 됩니다. - `steeringCriteria` 배열에 원하는 기준을 입력합니다. - 기본 LLM 평가 프롬프트가 해당 기준을 반영해 응답을 종합적으로 평가합니다. - 이 방식에서도 Claude Sonnet 4.6이 평가 모델로 사용됩니다. ## 피드백 루프와 결과 확인 - Bedrock은 프롬프트와 예시 데이터를 선택한 모델에 전달합니다. - 모델 응답을 지정한 평가 방식으로 채점합니다. - 평가 결과를 바탕으로 프롬프트를 다시 작성합니다. - 이 과정을 반복해 평가 지표에 맞는 프롬프트를 탐색합니다. - 최종적으로 다음 정보를 확인할 수 있습니다. - 원본 및 최적화된 프롬프트 템플릿 - 모델별 평가 점수 - 예상 비용 - 응답 지연 시간 - 평가 데이터와 결과 ## 사용 방법과 제공 지역 - Amazon Bedrock 콘솔의 **Advanced Prompt Optimization** 페이지에서 `Create prompt optimization`을 선택합니다. - API를 사용하려면 `CreateAdvancedPromptOptimizationJob`을 호출합니다. - 미국, 아시아 태평양, 캐나다, 유럽, 남미의 여러 리전에서 제공됩니다. - 최적화 과정에서 사용된 Bedrock 모델 추론 토큰에 대해 일반 추론과 동일한 토큰 요금이 부과됩니다. 실무에서는 먼저 정확도나 JSON 일치처럼 측정 가능한 작업은 Lambda 평가로 시작하고, 요약·문체·안전성처럼 정성적인 작업은 LLM-as-a-Judge 또는 Steering Criteria를 사용하는 것이 적합합니다. 모델을 교체할 때는 기존 모델을 기준선으로 포함해 품질뿐 아니라 비용과 지연 시간까지 함께 비교하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)

amazon-s3대규모 언어 모델amazon-bedrock멀티모달 AI+3

aws·2026년 5월 12일·3분 읽기큐레이션 요약

Amazon Redshift, 통합 데이터 레이크 쿼리 엔진을 탑재한 AWS Graviton 기반 RG 인스턴스 출시 | Amazon Web Services

Amazon Redshift의 새로운 RG 인스턴스는 AWS Graviton 기반으로, 기존 RA3보다 데이터 웨어하우스 워크로드를 최대 2.2배 빠르게 처리하면서 vCPU당 가격은 30% 낮춘다. 또한 데이터 웨어하우스와 Amazon S3 데이터 레이크를 하나의 엔진에서 SQL로 조회할 수 있어, Apache Iceberg는 최대 2.4배, Apache Parquet은 최대 1.5배 향상된 성능을 제공한다. 이를 통해 대규모 AI 에이전트 쿼리와 저지연 분석 workload의 비용과 운영 복잡성을 함께 줄이는 것이 핵심이다. ## 데이터 웨어하우스와 데이터 레이크를 함께 처리해야 하는 배경 - 기업은 구조화되고 자주 조회되는 데이터는 데이터 웨어하우스에, 대규모·다양한 데이터는 비용 효율적인 데이터 레이크에 저장하는 방식으로 운영하고 있다. - AI 에이전트가 사람보다 훨씬 많은 쿼리를 실행하면서 쿼리 처리량과 운영 비용이 급증하고 있다. - Redshift는 BI 대시보드, ETL, 실시간 분석, 자율형 AI 에이전트처럼 빠른 응답이 필요한 workload를 대상으로 성능 개선을 이어 왔다. - 2026년 3월에는 신규 쿼리 성능을 최대 7배 높여 BI와 ETL 응답 시간을 단축했다고 설명한다. ## AWS Graviton 기반 RG 인스턴스 - RG 인스턴스는 AWS Graviton 프로세서 기반의 새로운 Amazon Redshift 인스턴스 제품군이다. - RA3 대비 데이터 웨어하우스 workload를 최대 2.2배 빠르게 처리한다. - vCPU당 가격은 RA3보다 30% 낮다. - 고빈도 쿼리와 낮은 지연 시간이 중요한 분석 및 agentic AI workload에 적합하다. - 기존 RA3 인스턴스와 `ra3.xlplus`, `ra3.4xlarge` 및 대응하는 `rg.xlarge`, `rg.4xlarge` 구성을 비교할 수 있다. ## 통합 데이터 레이크 쿼리 엔진 - Redshift의 단일 SQL 엔진으로 데이터 웨어하우스 테이블과 Amazon S3 데이터 레이크를 함께 조회할 수 있다. - Apache Iceberg 데이터 조회 성능은 RA3 대비 최대 2.4배, Apache Parquet은 최대 1.5배 빠르다. - 데이터 레이크 쿼리는 별도의 Spectrum 서비스가 아니라 Redshift 클러스터 노드에서 실행된다. - 기존 외부 테이블, 스키마, 쿼리 문법과 Spectrum 쿼리를 그대로 사용할 수 있어 애플리케이션 코드 수정이나 외부 테이블 재생성이 필요 없다. ## 비용 및 보안상의 변화 - 데이터 웨어하우스와 데이터 레이크를 각각 별도 시스템으로 운영할 필요가 줄어든다. - 데이터 레이크 쿼리가 VPC 내부에서 실행되므로 네트워크 경계를 단순하게 유지할 수 있다. - 기존 IAM 역할을 그대로 사용할 수 있다. - Spectrum의 데이터 스캔 요금인 TB당 5달러가 발생하지 않아 전체 Redshift 비용을 낮출 수 있다. - 실제 절감액은 쿼리량, 데이터 레이크 스캔 규모, 인스턴스 구성에 따라 달라지므로 AWS Pricing Calculator로 산정해야 한다. ## 마이그레이션 방법 - AWS Management Console, AWS CLI, AWS API를 통해 새 RG 클러스터를 생성하거나 기존 클러스터를 이전할 수 있다. - 통합 데이터 레이크 쿼리 엔진은 기본적으로 활성화된다. - **Elastic Resize** - 호환되는 구성에서 인플레이스 마이그레이션을 수행한다. - 약 10~15분의 다운타임이 발생한다. - **Snapshot and Restore** - RA3 스냅샷으로 RG 클러스터를 새로 생성한다. - 마이그레이션 과정에서 클러스터 설정을 변경하려는 경우 적합하다. - 마이그레이션 경로를 통해 비용, 호환성, 실행 계획을 확인하고 자동화할 수 있다. ## 리전 및 요금 옵션 - RG 인스턴스는 미국, 캐나다, 유럽, 아시아 태평양, 남아메리카의 여러 AWS 리전에서 제공된다. - 한국 리전(서울)도 지원 대상에 포함되어 있다. - Provisioned Redshift에서는 약정 없는 시간 단위 온디맨드 요금제와 비용 절감을 위한 Reserved Instance를 선택할 수 있다. - 제공 리전은 변경될 수 있으므로 실제 도입 전 AWS 리전별 지원 현황을 확인해야 한다. 실제로 도입할 때는 기존 RA3 workload의 쿼리 패턴과 S3 데이터 스캔량을 기준으로 RG의 성능·비용을 비교하는 것이 좋다. 호환 가능한 클러스터라면 Elastic Resize를 우선 검토하고, 설정 변경이나 검증이 필요하면 Snapshot and Restore 방식을 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)

amazon-s3AI 에이전트sqlapache-iceberg+4

aws·2026년 4월 7일원문

S3 Files 출시, S3 버킷을 파일 시스템으로 액세스 가능하게 지원 | Amazon Web Services (새 탭에서 열림)

Amazon S3 Files는 S3 버킷을 고성능 파일 시스템으로 변환하여 AWS 컴퓨팅 자원과 원활하게 연결하는 혁신적인 서비스입니다. 기존의 객체 스토리지와 파일 시스템 간의 기술적 경계를 허물어, 사용자는 S3의 비용 효율성과 내구성을 유지하면서도 NFS v4.1 기반의 인터랙티브한 데이터 수정 및 공유 기능을 활용할 수 있습니다. 이를 통해 ML 모델 학습, AI 에이전트 협업 등 다양한 워크로드에서 데이터 중복 없이 실시간 동기화가 가능한 중앙 데이터 허브를 구축할 수 있게 되었습니다. **S3 Files의 주요 특징과 장점** * S3 버킷을 EC2, ECS, EKS, Lambda 등 다양한 컴퓨팅 서비스에서 네이티브 파일 시스템으로 마운트하여 직접 접근할 수 있습니다. * 파일 시스템에서 변경된 데이터는 자동으로 S3 버킷에 반영되며, 반대로 S3 객체의 변경 사항도 파일 시스템에 수 초 내로 동기화됩니다. * 여러 컴퓨팅 리소스에서 동시에 접근하여 데이터를 공유할 수 있어, 클러스터 간 별도의 데이터 복제 과정이 필요하지 않습니다. * NFS v4.1+ 표준 프로토콜을 지원하여 파일 및 디렉토리의 생성, 읽기, 업데이트, 삭제 등 모든 표준 파일 작업을 수행할 수 있습니다. **성능 최적화 및 동작 메커니즘** * 내부적으로 Amazon EFS 기술을 활용하여 활성 데이터에 대해 약 1ms 수준의 매우 낮은 지연 시간을 제공합니다. * 저지연 액세스가 필요한 파일의 메타데이터와 콘텐츠는 고성능 스토리지에 배치되며, 대규모 순차 읽기가 필요한 파일은 S3에서 직접 제공하여 처리량을 극대화합니다. * 바이트 범위 읽기(Byte-range reads)를 지원하여 요청한 데이터만 전송함으로써 데이터 이동량과 비용을 최소화합니다. * 지능형 프리페칭(Pre-fetching) 기능을 통해 사용자의 데이터 액세스 패턴을 예측하고 고성능 스토리지에 데이터를 미리 로드할 수 있는 제어권을 제공합니다. **보안 및 관리 아키텍처** * AWS IAM과 통합되어 ID 및 리소스 정책을 기반으로 파일 시스템과 객체 수준에서 세밀한 접근 제어가 가능합니다. * 데이터 전송 시에는 TLS 1.3으로 암호화되며, 저장 시에는 SSE-S3 또는 AWS KMS를 통한 고객 관리 키 암호화를 지원합니다. * S3 객체 메타데이터 내에 UID(사용자 ID)와 GID(그룹 ID) 정보를 저장하여 POSIX 표준 권한 체계를 유지합니다. * Amazon CloudWatch를 통해 드라이브 성능을 모니터링하고, AWS CloudTrail로 모든 관리 이벤트에 대한 로깅을 수행할 수 있습니다. **간편한 설정 및 배포 프로세스** * S3 콘솔의 'File systems' 메뉴에서 대상 버킷을 선택하는 것만으로 파일 시스템을 빠르게 생성할 수 있습니다. * VPC 내에 네트워크 엔드포인트인 '마운트 타겟'을 생성하여 컴퓨팅 자원이 파일 시스템에 안전하게 접근하도록 구성합니다. * 최신 버전의 amazon-efs-utils 패키지를 사용하여 표준 리눅스 마운트 명령어로 S3 데이터를 로컬 디렉토리처럼 즉시 사용할 수 있습니다. S3 Files는 객체 스토리지의 경제성과 파일 시스템의 유연성을 동시에 요구하는 현대적인 클라우드 아키텍처에 최적화된 솔루션입니다. 특히 데이터가 지속적으로 변하는 AI 에이전트 워크플로우나 여러 컨테이너가 동일한 데이터셋에 접근해야 하는 ML 파이프라인을 운영 중인 팀에게 강력히 추천합니다. 기존 S3 기반 데이터 레이크를 별도의 데이터 이전 없이 즉시 고성능 공유 파일 시스템으로 확장해 보시기 바랍니다.

amazon-s3aws-cliaws-ec2aws-eks+4

aws·2026년 3월 16일원문

AWS 주간 요약: Amazon S3 출시 20주년, Amazon Route 53 글로벌 리졸버 정식 출시 및 기타 소식 (2026년 3월 16일) | Amazon Web Services (새 탭에서 열림)

2026년 3월 14일, 클라우드 인프라의 초석인 Amazon S3가 출시 20주년을 맞이하며 500조 개 이상의 객체를 관리하는 거대 플랫폼으로 성장했습니다. 이번 주 AWS는 S3의 역사적인 이정표와 함께, 전 세계 어디서나 보안 DNS 쿼리가 가능한 Route 53 Global Resolver의 정식 출시를 발표했습니다. 이외에도 생성형 AI 에이전트 개발을 위한 Bedrock의 상태 저장 기능 강화와 Windows Server 2025 지원 등 보안과 효율성을 높이는 다양한 업데이트가 포함되었습니다. ### Amazon S3 20주년과 계정 지역 네임스페이스 도입 - **성장 지표**: 출시 이후 20년 동안 S3는 전 세계적으로 초당 2억 건 이상의 요청을 처리하며, 기가바이트당 비용을 출시 대비 약 85% 절감하는 혁신을 이루었습니다. - **계정 지역 네임스페이스**: 일반 범용 버킷 이름에 계정별 고유 접미사를 추가할 수 있는 기능이 도입되어, 원하는 버킷 이름을 다른 계정의 선점 걱정 없이 독점적으로 예약하고 사용할 수 있습니다. - **거버넌스 강화**: `s3:x-amz-bucket-namespace` 조건 키를 활용해 IAM 정책이나 AWS Organizations의 서비스 제어 정책(SCP) 수준에서 조직 내 네임스페이스 채택을 강제할 수 있습니다. ### Amazon Route 53 Global Resolver 정식 출시 - **애니캐스트(Anycast) DNS**: 특정 VPC나 리전에 국한되지 않고 전 세계 어디서나 승인된 클라이언트가 공용 및 사설 도메인을 해석할 수 있는 애니캐스트 방식의 DNS 리졸버를 제공합니다. - **보안 필터링**: 악성 도메인, 업무 부적합 콘텐츠, DNS 터널링 및 도메인 생성 알고리즘(DGA)을 이용한 지능형 위협을 차단하며, 특히 이번 정식 출시를 통해 사전 기반 DGA 위협 방어 기능이 추가되었습니다. - **통합 관리**: IPv4와 IPv6 쿼리 트래픽을 모두 지원하며, 중앙 집중식 쿼리 로깅을 통해 네트워크 보안 가시성을 확보할 수 있습니다. ### Amazon Bedrock AgentCore의 상태 저장 MCP 지원 - **상태 저장 MCP 서버**: Model Context Protocol(MCP)을 지원하여 개발자가 사용자 세션 컨텍스트를 유지하는 에이전트를 구축할 수 있으며, 각 세션은 격리된 마이크로VM(microVM)에서 실행됩니다. - **세션 관리 및 상호작용**: `Mcp-Session-Id` 헤더를 통해 여러 상호작용 간에 컨텍스트를 유지하며, 정교한 입력 수집(Elicitation) 및 샘플링 기능을 통해 사용자 맞춤형 결과 생성이 가능합니다. - **진행 알림**: 장시간 실행되는 작업 중에 클라이언트에게 실시간 진행 상황을 공유하여 사용자 경험을 개선할 수 있습니다. ### 인프라 및 개발자 생산성 업데이트 - **Amazon WorkSpaces**: Windows Server 2025를 지원하여 TPM 2.0, UEFI 보안 부팅, Credential Guard 등 최신 보안 기능이 포함된 가상 데스크톱 환경을 구성할 수 있습니다. - **AWS Builder ID 로그인 확장**: 기존 구글, 애플 계정 외에도 GitHub 및 Amazon 계정 정보를 사용하여 AWS 빌더 센터 및 교육 사이트에 간편하게 로그인할 수 있습니다. - **Amazon Redshift COPY 템플릿**: 자주 사용하는 데이터 적재 파라미터를 템플릿으로 저장하고 재사용할 수 있어, 데이터 수집 작업의 일관성을 유지하고 유지보수 노력을 줄여줍니다. 이번 업데이트는 대규모 데이터 관리의 편의성과 글로벌 네트워크 보안, 그리고 차세대 AI 애플리케이션 개발 환경 구축에 초점을 맞추고 있습니다. 특히 S3의 네임스페이스 기능과 Route 53 Global Resolver는 엔터프라이즈 급 보안과 명명 규칙 관리에 큰 도움이 되므로 즉시 도입을 검토해 보시기 바랍니다.

amazon-s3데이터베이스 설계aws-iamamazon-redshift+4

aws·2026년 3월 13일원문

Amazon S3 20주년과 다음 단계 구축 | Amazon Web Services (새 탭에서 열림)

Amazon S3는 2006년 출시 이후 20년 동안 단순한 객체 스토리지를 넘어 전 세계 데이터 및 AI 워크로드의 핵심적인 보편적 기반으로 진화했습니다. 기술적 혁신을 통해 11나인(99.999999999%)의 내구성과 완벽한 하위 호환성을 유지하면서도, 비용을 85% 절감하고 엑사바이트 단위의 확장을 실현하며 클라우드 인프라의 표준을 제시하고 있습니다. **비약적인 규모의 확장과 경제성 확보** * 2006년 당시 1PB 수준이었던 총 용량은 현재 500조 개 이상의 객체와 수백 엑사바이트의 데이터를 수용하는 규모로 성장했습니다. * 최대 객체 크기는 5GB에서 50TB로 1만 배 증가했으며, 초당 요청 수는 전 세계적으로 2억 건을 상회합니다. * 기가바이트당 비용은 출시 초기 15센트에서 현재 약 2센트로 85% 감소했으며, 'S3 Intelligent-Tiering'을 통해 고객들은 표준 대비 60억 달러 이상의 비용을 절감했습니다. * S3 API는 업계 표준이 되어 수많은 벤더가 이를 채택하고 있으며, 2006년에 작성된 코드가 수정 없이 오늘날에도 그대로 동작할 만큼 엄격한 하위 호환성을 보장합니다. **규모의 한계를 극복하는 엔지니어링 혁신** * **지속적 데이터 감사:** 마이크로서비스 기반의 감사(Auditor) 시스템이 모든 바이트를 실시간으로 검사하며, 열화 징후가 발견되는 즉시 자동 복구 시스템을 가동하여 데이터 손실을 방지합니다. * **수학적 정확성 증명:** 인덱스 하위 시스템과 액세스 정책 등에 정형 기법(Formal methods)과 자동 추론을 적용하여 시스템의 일관성과 정확성을 수학적으로 증명합니다. * **Rust 언어 전환:** 성능에 민감한 요청 경로와 디스크 스토리지 코드를 Rust로 재작성하여 메모리 안전성을 확보하고, 대규모 운영 환경에서 발생할 수 있는 버그를 컴파일 단계에서 제거했습니다. * **규모의 경제 활용:** "규모가 곧 장점"이라는 철학 아래 시스템이 커질수록 개별 워크로드 간의 상관관계가 낮아지도록 설계하여 전체적인 안정성을 높였습니다. **데이터와 AI를 위한 미래 지향적 기능** * **S3 Tables:** Apache Iceberg 테이블을 완전 관리형으로 제공하며, 자동화된 유지보수를 통해 쿼리 효율을 높이고 스토리지 비용을 최적화합니다. * **S3 Vectors:** RAG(검색 증강 생성) 및 시맨틱 검색을 위해 최대 20억 개의 벡터를 인덱싱하며, 100ms 미만의 낮은 지연 시간으로 네이티브 벡터 검색을 지원합니다. * **S3 Metadata:** 대규모 버킷을 일일이 나열(List)하지 않고도 중앙 집중식 메타데이터를 통해 즉각적으로 데이터를 발견할 수 있어 데이터 레이크 분석 시간을 획기적으로 단축합니다. **권장 사항** S3는 이제 데이터를 저장만 하는 공간이 아니라, 데이터를 이동시키지 않고도 직접 분석하고 AI 모델에 활용할 수 있는 통합 플랫폼입니다. 비용 효율성을 극대화하기 위해 'Intelligent-Tiering'을 기본적으로 활용하고, 복잡한 데이터 파이프라인 대신 'S3 Tables'나 'S3 Metadata' 같은 최신 기능을 도입하여 데이터 관리의 복잡성을 줄이는 전략이 필요합니다.

amazon-s3데이터베이스 설계RustAPI+4

aws·2026년 3월 12일원문

Amazon S3 범용 버킷을 위한 계정 리전별 네임스페이스 소개 | Amazon Web Services (새 탭에서 열림)

Amazon S3에서 일반 용도 버킷(General Purpose Bucket)을 위한 '계정 리전별 네임스페이스(Account Regional Namespace)' 기능을 새롭게 출시했습니다. 이제 사용자는 계정 고유의 접미사를 활용해 버킷 이름을 생성함으로써 전역적인 이름 중복 문제를 해결하고 원하는 이름을 즉시 확보할 수 있습니다. 이 기능은 버킷 생성 및 관리 프로세스를 대폭 간소화하며, 조직 전체의 보안 정책을 통해 일관된 명명 규칙을 강제할 수 있도록 지원합니다. ### 계정 리전별 네임스페이스의 동작 방식 * 기존의 S3 버킷 이름은 전 세계 모든 AWS 계정에서 유일해야 했으나, 새 기능을 사용하면 특정 계정과 리전 내에서만 고유하면 됩니다. * 버킷 이름은 `[사용자 정의 접두사]-[AWS 계정 ID]-[리전명]-an` 형식을 따릅니다. (예: `mybucket-123456789012-us-east-1-an`) * 계정 고유 접미사가 포함된 이름은 해당 계정에서만 점유할 수 있으며, 타인의 계정에서 동일한 접미사로 버킷을 생성하려는 시도는 자동으로 차단됩니다. ### 보안 및 거버넌스 관리 * 보안 팀은 IAM 정책이나 AWS Organizations의 서비스 제어 정책(SCP) 내에서 `s3:x-amz-bucket-namespace` 조건 키를 사용할 수 있습니다. * 이를 통해 사내 직원이 버킷을 생성할 때 반드시 계정 리전별 네임스페이스를 사용하도록 규정할 수 있어, 전역 네임스페이스 혼용으로 인한 관리상의 혼선을 방지합니다. ### 인프라 자동화 및 개발 도구 활용 * **AWS CLI 및 SDK**: 버킷 생성 시 `--bucket-namespace account-regional` 파라미터를 추가하여 간단히 적용할 수 있으며, Python(Boto3) 등 다양한 언어의 SDK를 지원합니다. * **CloudFormation**: `BucketName` 속성에 의사 매개변수(`AWS::AccountId`, `AWS::Region`)를 조합하거나, 신규 속성인 `BucketNamePrefix`를 사용하여 접미사가 자동으로 붙도록 템플릿을 구성할 수 있습니다. * **콘솔 UI**: S3 콘솔에서 버킷 생성 시 'Account regional namespace' 옵션을 선택하는 것만으로 기능을 활성화할 수 있습니다. ### 주요 고려 사항 및 제약 * 이 기능은 일반 용도 버킷에만 적용되며, 이미 고유한 네임스페이스 체계를 가진 S3 테이블, 벡터, 디렉터리 버킷에는 해당되지 않습니다. * 기존에 전역 네임스페이스로 생성된 버킷의 이름을 계정 리전별 형식으로 직접 변경(Rename)할 수는 없으므로, 필요 시 새 버킷을 생성해야 합니다. * 전체 버킷 이름 길이는 기존과 동일하게 3자에서 63자 사이여야 하며, 현재 한국을 포함한 37개 AWS 리전에서 추가 비용 없이 즉시 사용 가능합니다. 새로운 프로젝트를 시작하거나 IaC(코드형 인프라) 템플릿을 설계할 때 계정 리전별 네임스페이스를 기본으로 채택하는 것을 권장합니다. 이를 통해 버킷 이름 중복으로 인한 생성 실패 오류를 원천 차단하고, 여러 계정과 리전에 걸친 인프라 배포 효율성을 극대화할 수 있습니다.

amazon-s3aws-cliaws-cloudformationaws-iam+3

pinterest·2026년 2월 24일원문

Piqama: 핀터레 (새 탭에서 열림)

핀터레스트는 빅데이터 플랫폼과 온라인 서비스 전반에서 발생하는 다양한 자원 임계치를 효율적으로 관리하기 위해 통합 쿼타 관리 에코시스템인 'Piqama'를 구축했습니다. Piqama는 CPU, 메모리 같은 물리적 자원부터 QPS, 네트워크 대역폭 등 서비스 지표에 이르기까지 광범위한 리소스의 생명주기를 관리하며, 실시간 쿼타 전파와 사용량 예측을 통한 최적화 기능을 제공합니다. 이를 통해 조직 내 리소스 활용도를 극대화하는 동시에 시스템의 안정성과 가용성을 동시에 확보하고 있습니다. ### 통합 쿼타 관리 아키텍처 및 포털 * Piqama는 다양한 플랫폼과 시나리오를 수용할 수 있는 범용 플랫폼으로 설계되어, 서비스별로 고유한 강제 로직을 사용하거나 Piqama의 기본 메커니즘을 선택하여 적용할 수 있습니다. * REST 및 Thrift API를 지원하는 중앙 집중식 관리 포털을 통해 사용자가 쿼타 설정을 시각화하고 검색할 수 있어 운영상의 실수를 최소화합니다. * 전체 시스템 아키텍처는 관리 포털, 실시간 업데이트 디스패처, 그리고 오프라인 거버넌스 및 최적화 도구들로 구성되어 유기적으로 동작합니다. ### 쿼타 생명주기 관리 * **스키마 및 검증:** 워크로드 간의 계층적 관계를 포함한 쿼타 스키마를 정의하며, 플러그형 프레임워크를 통해 할당량이 전체 클러스터 용량을 초과하지 않도록 보수적인 검증을 수행합니다. * **업데이트 승인 및 배포:** 소유권 기반의 권한 모델을 통해 안전하게 쿼타를 수정하며, 핀터레스트의 설정 배포 시스템(PinConf) 등을 활용해 변경된 쿼타 값을 지연 시간 없이 각 클라이언트 시스템에 방송합니다. * **강제 적용 전략:** 리소스 사용량이 할당량을 초과할 경우, 데이터 경로에서 즉각적으로 요청을 차단하거나 서비스의 중요도에 따라 차등적인 제재를 가하는 기능을 제공합니다. ### 거버넌스 및 자동 최적화(Auto-rightsizing) * **데이터 피드백 루프:** Piqama 클라이언트는 실제 사용량 및 강제 적용 통계를 투명하게 수집하며, 이 데이터는 분석을 위해 Amazon S3의 Apache Iceberg 포맷으로 저장 및 사전 집계됩니다. * **예측 기반 조정:** 수집된 통계를 바탕으로 과거 사용 패턴, 유기적 성장, 트래픽 급증 사례를 분석하여 리소스 부족을 방지하고 활용되지 않는 자원을 회수하는 자동 권장 규모 설정 서비스를 운영합니다. * **비용 관리 연계:** 자원 사용량을 실제 비용으로 환산하는 차지백(Chargeback) 시스템을 통해, 예산 범위를 초과한 프로젝트의 자원 우선순위를 자동으로 낮추는 등의 비용 통제 기능을 수행합니다. ### 실제 적용 사례: 용량 기반 및 속도 제한 쿼타 * **빅데이터 플랫폼(Moka):** Apache Yunikorn 스케줄러와 연동하여 각 프로젝트별로 최소 보장 자원(Guaranteed)과 최대 자원(Maximum)을 동적으로 할당하며, 배치 작업의 병렬 실행 수를 제어합니다. * **온라인 저장 서비스:** 실시간 서비스의 안정성을 위해 QPS 및 대역폭 기반의 속도 제한(Rate-limiting) 쿼타를 적용하여 특정 서비스의 폭주가 전체 시스템에 영향을 주지 않도록 관리합니다. 성공적인 쿼타 관리를 위해서는 단순히 상한선을 설정하는 것에 그치지 않고, 실제 사용량 데이터를 기반으로 한 자동화된 우측 최적화(Right-sizing)와 비즈니스 예산을 연계한 거버넌스 체계를 구축하는 것이 중요합니다. Piqama와 같은 통합 에코시스템은 대규모 인프라 운영 환경에서 자원 낭비를 줄이고 운영 효율을 획기적으로 높이는 핵심 도구가 됩니다.

amazon-s3apache-icebergrate-limitingresource-scheduling+4

aws·2025년 12월 2일원문

Amazon S3 테이블을 (새 탭에서 열림)

AWS가 Amazon S3 Tables를 위한 '인텔리전트 티어링(Intelligent-Tiering)'과 '복제(Replication)' 기능을 새롭게 출시했습니다. 이번 업데이트를 통해 사용자는 데이터 액세스 패턴에 따라 스토리지 비용을 자동으로 최적화하고, 별도의 복잡한 아키텍처 없이도 여러 리전 및 계정 간에 Apache Iceberg 테이블 복제본을 일관되게 유지할 수 있습니다. 결과적으로 대규모 정형 데이터 관리의 비용 효율성과 글로벌 데이터 가용성이 획기적으로 향상되었습니다. **S3 테이블 인텔리전트 티어링을 통한 비용 최적화** * 데이터 액세스 빈도에 따라 Frequent Access, Infrequent Access(40% 저렴), Archive Instant Access(IA보다 68% 저렴) 등 세 가지 저지연 계층으로 데이터를 자동 이동합니다. * 30일 동안 접근이 없으면 IA 계층으로, 90일이 지나면 AIA 계층으로 전환되며, 이 과정에서 애플리케이션 코드 수정이나 성능 저하가 발생하지 않습니다. * 테이블 압축(Compaction), 스냅샷 만료, 미참조 파일 제거와 같은 유지 관리 작업은 데이터의 액세스 계층에 영향을 주지 않고 수행됩니다. * 특히 압축 작업은 Frequent Access 계층의 데이터만 대상으로 실행되어, 활발하게 쿼리되는 데이터의 성능은 높이고 차가운(Cold) 데이터에 대한 불필요한 처리 비용은 줄입니다. * AWS CLI의 `put-table-bucket-storage-class` 명령을 사용해 테이블 버킷 수준에서 기본 스토리지 클래스를 설정할 수 있습니다. **리전 및 계정 간 S3 테이블 복제 지원** * 수동 동기화 없이도 AWS 리전 및 계정 간에 일관된 Apache Iceberg 읽기 전용 복제본(Read Replica)을 생성하고 유지합니다. * 소스 테이블에서 발생한 모든 업데이트를 시간 순서대로 복제하며, Iceberg 테이블의 핵심인 스냅샷의 부모-자식 관계를 그대로 보존합니다. * 소스 테이블이 업데이트된 후 몇 분 이내에 복제본에 반영되며, 각 복제본은 소스와 독립적인 암호화 설정 및 데이터 보존 정책을 가질 수 있습니다. * 전 세계에 분산된 팀들이 로컬 리전에서 복제된 데이터를 쿼리하게 함으로써 네트워크 지연 시간을 최소화하고 데이터 보호 및 규정 준수 요건을 충족합니다. 대규모 Iceberg 데이터셋을 운영하는 조직은 인텔리전트 티어링을 통해 운영 부담 없이 스토리지 비용을 절감하고, 복제 기능을 활용해 글로벌 규모의 데이터 메쉬 아키텍처를 보다 쉽게 구축할 수 있습니다. 특히 데이터가 늘어남에 따라 수동으로 비용을 관리하기 어려운 환경에서 이 두 기능은 필수적인 관리 도구가 될 것입니다.

amazon-s3apache-icebergdata-replicationamazon-s3-tables+3

aws·2025년 12월 2일원문

Amazon S3 Storage Lens, 성능 지 (새 탭에서 열림)

Amazon S3 Storage Lens에 성능 지표 추가, 수십억 개의 접두사(Prefix) 지원, S3 테이블(S3 Tables)로의 데이터 내보내기 등 세 가지 주요 기능이 업데이트되었습니다. 이번 업데이트를 통해 사용자는 스토리지 성능과 사용 패턴에 대한 더 깊은 통찰력을 얻고, 데이터 기반의 의사결정을 통해 애플리케이션 성능 최적화와 비용 절감을 실현할 수 있습니다. 특히 대규모 데이터 세트 관리의 복잡성을 해결하고 분석 효율성을 대폭 향상시킨 것이 특징입니다. ### 8가지 신규 성능 지표 카테고리 도입 * **성능 병목 현상 파악**: 읽기/쓰기 요청 크기, 객체 크기 분포, 동시 PUT 503 에러 등의 지표를 통해 애플리케이션 성능을 저하시키는 요인을 식별합니다. * **최적화 가이드 제공**: 작은 객체가 성능을 저하시키는 경우 객체 번들링이나 S3 Express One Zone 스토리지 클래스 활용을 제안하며, 대용량 요청은 멀티파트 업로드(MPU)나 AWS CRT 사용을 권장합니다. * **데이터 전송 효율성 분석**: 리전 간 데이터 전송량과 요청 수를 확인하여 교차 리전 액세스로 인한 성능 저하 및 비용 증가 문제를 파악하고, 컴퓨팅 자원과 데이터의 배치를 최적화할 수 있습니다. * **활성 데이터 식별**: 특정 기간 내에 액세스된 고유 객체의 비율을 분석하여 빈번하게 사용되는 '핫 데이터'를 고성능 스토리지 계층으로 이동시키는 근거로 활용합니다. ### 수십억 개 규모의 접두사(Prefix) 분석 지원 * **대규모 확장성**: 기존의 분석 범위를 뛰어넘어 수십억 개의 접두사가 포함된 거대한 스토리지 구조에서도 세밀한 가시성을 제공합니다. * **계층적 가시성**: 조직, 계정, 버킷뿐만 아니라 매우 깊고 복잡한 접두사 수준에서도 성능 및 사용량 지표를 모니터링할 수 있어 대규모 데이터 레이크 관리에 용이합니다. ### S3 테이블로의 직접 내보내기 및 분석 통합 * **데이터 통합 분석**: S3 Storage Lens의 지표 데이터를 신규 기능인 S3 Tables로 직접 내보낼 수 있어, 별도의 복잡한 ETL 과정 없이도 대규모 메타데이터를 효율적으로 쿼리할 수 있습니다. * **SQL 기반 분석**: 내보낸 데이터를 S3 테이블 형식으로 저장하면 표준 SQL을 사용하여 장기적인 스토리지 트렌드를 분석하거나 커스텀 보고서를 생성하기가 훨씬 수월해집니다. S3 Storage Lens의 고급 티어(Advanced Tier)를 활성화하면 이러한 신규 성능 지표를 즉시 활용할 수 있습니다. 특히 성능에 민감한 워크로드를 운영 중이라면, '고유 객체 액세스' 지표를 통해 자주 사용되는 데이터를 식별하고 이를 S3 Express One Zone으로 이전하여 지연 시간을 최소화하고 비용 효율성을 극대화할 것을 추천합니다.

amazon-s3cloud-monitoringamazon-s3-tablesstorage-optimization+2