안녕하세요, 오래간만에 인사드립니다. 오늘은 NAT 관련 조치사항에 대해서 Noti 받으신 분들이 취하실 내용에 대해서 설명드리겠습니다. 보통 아래와 같은 메일 받으셨을 텐데요, 내용은 다음과 같습니다. 현재의 NAT 구성이 단일 구성으로 되어 있으니, 리소스 확인하시고 NAT 게이트웨이를 추가하십시오. NAT 게이트웨이에 대한 AWS 공식 문서입니다. 참조 링크 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html NAT 게이트웨이는 하나의 가용 영역에서만 고가용성입니다. 여러 가용 영역에 리소스가 있고 리소스가 하나의 NAT 게이트웨이를 공유하는 경우 NAT 게이트웨이의 가용 영역이 다운되면 다른 가용 영역의 리소스가 인..
분류 전체보기
Amazon Inspector는 지속적으로 스캔하는 취약성 관리 서비스입니다. Amazon Inspector는 Amazon ECR에 있는 Amazon EC2 인스턴스와 컨테이너 이미지를 자동으로 검색하여 소프트웨어 취약성과 의도하지 않은 네트워크 노출이 있는지 검사합니다. 소프트웨어 취약점이나 네트워크 문제가 발견되면 Amazon Inspector에서 검색 결과를 생성해 줍니다. 검색 결과는 취약성을 설명하고, 영향을 받는 리소스를 식별하며, 취약성의 심각도를 평가하며, 수정 지침을 제공합니다. Amazon Inspector 콘솔을 사용하여 계정에 대한 검색 결과에 대한 세부 정보를 여러 가지 방법으로 분석하거나 다른 항목을 통해 검색 결과를 보고 처리할 수 있습니다. ■ Inspector 사용해 보기 ..
그렇다면 어떻게, 클러스터 엔드포인트로의 액세스를 제한할 수 있을까요? EKS 처음 시작 시에 자주 들 수 있는 질문입니다. 기본적으로 클러스터를 생성하였을 때, 퍼블릭하게 액세스가 가능한 엔드포인트가 부여됩니다. 이런저런 내용을 테스트하기에는 좋지만, 프로덕션 레벨에서 사용하기에 모범 사례는 아닙니다. 또한, AWS는 클러스터에 대한 프라이빗 엔드포인트를 제공합니다. 클러스터의 VPC 내부에서 접근 가능합니다. - 가능하다면, 퍼블릭 엔드포인트를 비활성화하고 프라이빗 엔드포인트를 사용하는 것을 권장합니다. 다이어그램에서 보시다시피, 프라이빗 엔드포인트를 활성화하면 모든 트래픽은 VPC 내부의 서브넷 간 그리고 컨트롤 플레인이 돌고 있는 EKS 소유한 내부 VPC 서브넷 간의 통신을 가능케 하는 ENI를..
의사 결정에 앞서서 우리가 유념해야 될 원칙들이 어떤게 있을까요? 가장 중요한 임무는 더 좋은 효율과 더 적은 오버헤드와 함께 쿠버네티스를 서빙하는 것입니다. EKS는 처음부터 Production 준비 서비스로 만들어졌습니다. 그래서 AWS는 다양한 산업군과 스타트업 그리고 대기업에 이르기 까지 여러 워크로드를 지원합니다. 앞서 #1번 포스팅에 다루었다시피, 쿠버네티스가 가능한 한 유연하게 동작하기 위해서 다른 AWS 서비스들과의 통합을 긴밀하게 이루고 있습니다. 또한, 오픈 소스 프로젝트에 참여합니다. 앞서 말씀드린 내용들로 파생된 상기의 다섯 가지 이미지의 내용들이 오늘의 주제입니다. 보안, 신뢰성, 효율성, 클러스터 작업, 편의성입니다. 1. 보안 보안은 EKS의 제일 먼저 꼽히는 특징입니다. 그렇..
1. EKS란, EKS는 AWS에서 제공하는 관리형 쿠버네티스 서비스입니다. AWS 관리형 서비스의 보안, 탄력성을 통해서 쿠버네티스를 사용하기 위한 쿠버네티스의 유연성을 제공합니다. - EKS는 바닐라 업스트림 쿠버네티스(쿠버네티스를 구성하기 위한 핵심요소, 참조 링크 : https://technative.io/kubernetes-must-stay-pure-upstream-open-source/)입니다. Fork 작업 등은 진행하지 않고, 업스트림이 제공하는 것보다 더 오랜 기간 버전에 대한 관리를 진행하기 때문에 유일하게 진행하는 작업은 백포트 보안 패치입니다. 때문에, 만약 오픈소스 쿠버네티스를 사용하신다면 EKS에서 구동하실 경우 동일한 버전을 받으셔서 진행하셔야 합니다. - EKS는 성능, 안정..
마지막 Map state로 Dynamic Parallelism (동적 병렬)을 들 수 있습니다. Fan out 패턴을 통해서 동일한 Task의 리스트를 보내서 이를 병렬적으로 처리하는 것을 가능케 합니다. 예를 들어, 여러 브랜치에서의 워크플로우 혹은 Scatter-Gather 패턴으로, 다수의 리포지토리에서 변화된 코드의 적용이 필요할 경우와 관련이 있습니다. 자, 그럼 언제 커스텀 파이프라인을 사용해야 될까요? 짧게 말해, 존재하는 툴에서 업무에 바로 사용해야 할 기능이 부족할 때, 우리는 종종 배포 환경에서 복잡한 인프라를 배포하고, 구성 요소 간의 상호 의존성이 여럿인 경우를 빈번하게 볼 수 있습니다. - 예를 들어, s3에서 오브젝트 세트를 새로운 계정의 새로운 버킷으로 데이터베이스 테이블에서 ..
aws code suite와 aws partner network의 지원에도 불구하고, 사용자 요구사항에 딱 알맞지 않은 상황들이 있을 수 있습니다. 이런 경우를 위해서 aws는 커스텀하게 파이프라인을 구성할 수 있도록 합니다. 1) aws CodePipeline으로부터 aws step functions로 통합합니다. 2) 더 복잡한 robust 에러 핸들링, 재시도 등과 함께 릴리스 프로세스의 일부로 동작하게 할 수 있습니다. 3) aws step functions는 더 풍부한 시각화와 Cloudwatch 로그를 제공합니다. 4) 비동기 / 수동 승인 태스크 추가를 간편하게 해줍니다. * Step Functions는 CodeBuild의 대체 상품이 아니며, 더 복잡한 커스텀의 워크플로를 제어하기 위한 상..
