aws

AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스 온라인 세계는 우호적인 장소는 아닐 수 있습니다. 웹 사이트를 온라인으로 올리자마자 다운되거나 침입 당할 수 있는 여러 가지 유형의 공격 대상이 될 수 있습니다. DDoS (Distributed Denial of Service) 공격은 흔히 발생하는 문제 중 하나입니다. 인터넷 전체에서 취약한 자원을 모아서 특정 대상을 공격할 수 있게 됩니다. 아래에 세 가지 일반적인 유형의 DDoS 공격 타입이 있습니다. 응용 프로그램 계층 공격: 응용 프로그램 리소스를 사용하도록 설계되어 있지만, 실제로는 악의적인 요청 (HTTP GET 및 DNS 쿼리가 많이 사용됨)으로 구성됩니다. 예를 들어, 여러 개의 HTTP 연결을 열어 몇 초 또는 몇 분 동안 요청을 해서 과도한 메모리가 소모되도록 합니다. 고갈 상태 공격 상태 별 프로토콜을 어뷰징하고, 각 통신 연결 당 많은 리소스를 소비함으로써 방화벽 및 로드 밸런서에 강한 스트레스를 유발합니다. 볼륨 공격 실제 처리 할 수 있는 것보다 많은 트래픽을 네트워크에 보내거나, 가짜 쿼리를 발행하여 [ more… ]

AWS CodeBuild – 완전 관리형 빌드 서비스 출시 모든 개발자는 소스 코드 변경이 일어날 때, 지속적인 통합 빌드(build) 생성 및 테스트를 실행하기 위해 공유 빌드 서버를 설정하고 운영 해야합니다. 유지 관리에 대한 부담으로 인해 다수 개발자들이 로컬 컴퓨터에서만 빌드를 만들어, 정식 서버에서 실행함으로서 한 명의 개발자에게는 동작하는데 다른 개발자에게는 동작하지 않는 상황을 초래합니다. 많은 개발 팀은 지속적 통합(Continuous Integration, CI) 및 배포 (Continuous Deployment, CD) 파이프 라인의 일부를 사용할 수 있습니다. 이러한 빌드팜의 설치 및 유지 보수 비용은 여전히 높으며 전혀 다른 운영 기술이 필요합니다. 사용률이 100%에 도달하고 빌드 요청 백 로그가 증가하는 경우를 제외하고는 가볍게 사용합니다. AWS CodeBuild 서비스 소개 오늘 이러한 문제를 해결 해줄 AWS CodeBuild를 출시합니다. 빌드 서버를 설치, 설정 및 확장 및 패치 등에 신경쓰지 않고, CodeBuild를 활용하여 개발 과정에서 유연상을 보장하고 여러 형태의 빌드 상태나 호환성의 불일치 문제를 해결할 수 있습니다. CodeBuild를 사용 하면, 사전에 [ more… ]

AWS X-Ray – 분산 애플리케이션 추적 및 디버깅 서비스 지난 11월 미국 대통령상 수상자인 Grace Hopper는 디버깅(Debugging)이라는 용어를 처음으로 사용한 분입니다. 이것은 프로그램에서 오류를 식별하고 제거하는 과정을 말합니다. 저도 컴퓨터에서 실제 버그를 추출하지는 못했지만, 예전에는 어셈블리 언어 프로그램을 디버깅 하는 데 많은 시간을 할애했습니다. 당시 디버깅은 코드를 한 단계 수행하고, 각 단계 전후의 각 프로세서 레지스터 내용을 검사하여 실제로 발생한 상황과 일치하는지 계속 확인했습니다. 상당히 지루한 과정이지만, 버그를 숨기지는 못하며 코드 작동 방식에 대한 심층적인 이해를 할 수 있었다는 보람이었습니다. 나중에 single-stepping은 출력(hello, stderr)을 디버깅하고 거기에서 로그 파일과 로그 분석 도구를 다시 디버깅하였습니다. 지난 십 년 동안 복잡한 분산 시스템이 등장하면서, 디버깅을 하는 방법도 변화되어 새로운 의미를 가지게 되었습니다. 개별 기능과 모듈이 예상대로 작동하는지 확인하는 단위 테스트와 함께 확장 시 실행 패턴도 검토해야 하는 문제가 있습니다. 클라우드 컴퓨팅, 마이크로 서비스 및 비동기식 알림을 기반한 새로운 아키텍처가 결합되어, 수백 혹은 수천 [ more… ]

AWS Snowmobile – 엑사 바이트(Exabyte)급 데이터를 몇 주 만에 클라우드로 클라우드 이전 중 기존 데이터 센터 혹은 회사에 대용량 데이터가 있다면, 이전이 매우 어려울 수 있습니다. 고속 인터넷을 통해서도 영상 파일, 금융 기록, 위성 이미지 등 페타바이트에서 엑사 바이트(Exabyte)에 이르는 데이터를 옮기는 건 매우 어렵고, 간단히 계산을 해봐도 수년에서 수십 년이 걸릴 수 있습니다. 작년에 AWS Snowball (출시 뉴스 참고)를 통해 손쉽게 대용량 장치를 통해 마이그레이션을 하기 위한 첫 단계를 밟았습니다. 80TB의 스토리지를 담은 전용 스토리지 장치를 배송 받아 데이터를 클라우드로 업로드 하는 방식을 통해 많은 고객들이 도움을 받고 있습니다. 그러나 여전히 엑사 바이트급 데이터를 운용하는 경우라면, 80TB 장치 관점에서 보면 엄청나게 많은 수의 장비와 이동에 대한 곤란한 점이 많습니다. AWS Snowmobile 저장 콘테이너 이러한 고객들의 요구 사항에 맞추어, 오늘 Snowmobile을 출시합니다. 최고 100PB의 데이터를 실을 수 있는 전용 트럭을 통해 몇 주 안에 엑사 바이트 데이터를 AWS로 이전할 수 [ more… ]

AWS Snowball Edge – 클러스터링 및 용량 추가, 로컬 엔드포인트와 Lambda 함수 지원 작년에 AWS Snowball을 출시(블로그 참고) 한 뒤, 많은 업데이트가 있었습니다. 물리적 50TB 데이터 전송 저장 장치로 보안 및 운송의 편리성을 통한 클라우드 데이터 이동에 대한 아주 간단한 해법으로서  그 이후에도, 용량 확대 및 리전 추가 지원 (80 TB), 작업 관리 API 및 S3 어댑터, HIPAA 호환, HDFS 가져오기 지원 등의 업데이트가 이루어졌습니다. 위의 모든 개선 사항 역시 중요했지만, 제품 기본 특성은 변경하지 않았습니다. 지난 1년간 많은 AWS 고객이 Snowball을 활용하여 다양한 유형의 대용량 데이터 이전, 유전학 데이터 수집 작업 등에서 물리적 환경에 필요한 다양한 작업을 진행하였습니다. 그 와중에 좀 더 기능적으로 필요한 몇 가지 여지가 있음을 알게 되었습니다. 어떤 고객은 네트워크 연결이 제한적이거나 아예 존재하지 않는 극단적인 상황에서도 많은 양의 데이터 (수백 테라 바이트)를 생성하기도 합니다. 예를 들어, 농장, 공장, 병원, 항공기 및 석유 시추 위치에서 생성하는 [ more… ]