AWS 상태 확인: 추적을 위한 실용 가이드

AWS가 제대로 작동하는지, 아니면 어려움을 겪고 있는지 확인할 때, 단순히 녹색이나 빨간색 표시등을 보는 것만으로는 충분하지 않습니다. 건강 패널, 실시간 신호 및 리소스에 대한 특정 검토를 통과해야 합니다.이러한 결합된 접근 방식을 사용하면 문제가 일반적인지, 지역적인지, 아니면 자체 인프라와 관련된 것인지 알 수 있으며, 무모한 행동을 취하지 않고도 조치를 취할 수 있습니다.

이 가이드에서는 AWS 상태를 확인하는 데 필요한 모든 내용을 잘 정리하여 알려드리겠습니다. AWS Health Dashboard 및 EventBridge와의 통합ACM에서 갱신 상태를 확인하고, EC2 확인을 해석하고, CloudWatch 지표 및 경보에 대응하는 방법을 알아봅니다. 또한 콘솔이 로드되지 않을 때 취해야 할 조치, 공개 상태 페이지를 확인하는 방법, 그리고 Downdetector와 같은 타사 솔루션이 컨텍스트 분석에는 유용하지만 자동화에는 적합하지 않은 이유도 알아봅니다.

AWS Health Dashboard: 시작점

AWS 상태 대시보드는 서비스와 리소스에 영향을 줄 수 있는 중단, 활성 이벤트 및 계획된 유지 관리를 표시합니다. 이 기능은 계정의 일부이며, 구성이 필요 없고 상황에 맞는 가시성을 제공합니다. 무슨 일이 일어나고 있는지 알아보세요. 특정 인스턴스나 콘솔에 로그인하지 않은 경우, 가장 먼저 확인해야 할 곳은 여기입니다.

종종 잊혀지는 세부 사항: AWS는 지역적입니다건강 패널 선택기에서 올바른 지역을 선택하세요. 잘못된 지역을 검색하면 영향을 받는 사건을 놓칠 수 있습니다. 이러한 정밀성은 문제가 특정 지역에 국한될 때 잘못된 진단을 방지합니다.

2023년부터 건강 패널에서 공개 이벤트를 열 때, 브라우저 URL에는 이벤트에 대한 딥 링크가 포함되어 있습니다.이를 통해 보고 있는 정확한 사건을 공유하거나 사건을 다시 열어 팝업 창이 로드된 동일한 보기로 돌아갈 수 있어 사건 발생 시 팀워크가 용이해집니다.

관리 콘솔이 열리지 않거나 브라우저 오류(예: 404)가 발생하는 경우 서두르지 마세요. 먼저 Health Dashboard에 관련 활성 이벤트가 있는지 확인하세요.그런 다음 캐시와 쿠키를 지우고, 다른 브라우저를 사용하고, IT 팀에 네트워크가 Amazon 도메인(amazon.com 및 aws.amazon.com과 같은 하위 도메인)을 차단하지 않는지 확인하는 등 로컬 조치를 적용합니다.

안정적인 이벤트 수집: EventBridge는 RSS보다 낫습니다.

건강 이벤트가 포함된 RSS 피드가 있지만 형식은 다음과 같습니다. 시간이 지남에 따라 변경되어 통합이 중단될 수 있습니다.최소한으로 말해, 중요한 파이프라인에 RSS를 스크래핑하거나 의존하는 것은 위험한 일입니다.

강력한 것은 통합하는 것입니다 Amazon EventBridge를 통한 AWS Health이렇게 하면 안정적인 스키마를 갖춘 이벤트를 실시간으로 수신하고 Lambda, 대기열, 알림 또는 내부 대시보드로 라우팅할 준비가 되어 취약한 부분 없이 인시던트 회로를 만들 수 있습니다.

EventBridge를 사용하면 추적성과 복원력을 얻을 수 있습니다. 응답에 태그를 지정하고, 풍부하게 하고, 상관 관계를 지정하고, 자동화할 수 있습니다. 서비스, 지역 또는 영향에 따라 달라집니다. 공개 피드 표시 세부 정보가 내일 변경되더라도 통합은 그대로 유지됩니다.

ACM: 문제없이 인증서 갱신 검토

AWS Certificate Manager를 사용하면 인증서가 관리되는 방식으로 올바르게 갱신되고 있는지 확인할 수 있습니다. 인증서는 AWS 서비스(예: ELB 또는 CloudFront)와 연결되어 있거나 발급 또는 마지막 갱신 이후에 내보낸 경우 자동 갱신이 가능합니다.이러한 자격은 수동 갱신을 잊는 데 필요한 초석입니다.

갱신 주기가 시작되면 ACM은 인증서 세부 정보에 상태 필드를 표시합니다. 콘솔, API 또는 CLI에서 RenewalStatus를 확인할 수 있습니다. 현재 상태를 파악하세요. 주의가 필요한 문제가 있는 경우 건강 대시보드와 관련된 상태도 표시됩니다.

명령을 선호하는 경우 CLI를 사용하면 편리합니다. describe-certificate 작업은 갱신 상태를 포함한 세부 정보를 반환합니다.. 예 :

예 : aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID

JSON 응답에서 RenewalStatus 필드를 살펴보세요. 해당 필드가 아직 나타나지 않으면 ACM에서 관리형 갱신을 시작하지 않은 것입니다.. 미리 계획하는 것이 좋습니다. ACM은 만료일 약 60일 전에 자동으로 갱신을 시도하며, 문제가 발생하는 경우(예: 도메인 유효성 검사) 건강상태에 따라 45일, 30일, 15일, 7일, 3일, 1일 등의 알림을 미리 받으실 수 있습니다..

콘솔이 충전되지 않을 때: 빠르고 효과적인 단계

AWS 콘솔에 접속할 때 발생하는 404 오류나 연결 실패는 일반적으로 해결 가능합니다. 먼저 귀하의 리소스가 위치한 지역의 건강 대시보드를 검토해 보세요. 해당 서비스나 콘솔에 영향을 미치는 진행 중인 이벤트를 해제합니다.

아직 해결되지 않은 사건이 없는 경우 현지 조치를 적용하세요. 브라우저 캐시 및 쿠키 지우기다른 브라우저로 로그인을 시도하고 회사 네트워크가 amazon.com이나 aws.amazon.com과 같은 하위 도메인을 차단하지 않는지 시스템 관리자에게 확인하세요.

문제는 특정 리소스에 국한될 수 있습니다. 예를 들어, EC2 인스턴스가 계획된 유지 관리를 진행 중일 수 있습니다.그리고 상태 패널에는 해당 이벤트의 창과 영향이 표시됩니다. 루트로 이동하면 시간을 절약할 수 있습니다.

또한, 계정이 잠금 상태인 경우 도움말 문서를 항상 준비해 두는 것이 좋습니다. 새 계정을 만들고 활성화하거나, 콘솔에 로그인하거나, 도움을 요청하세요.이런 가이드를 준비해 두면 스트레스가 많은 상황에서 대기 시간을 줄일 수 있습니다.

EC2 세부 정보: 상태 확인 및 실패 시 대처 방법

Amazon EC2는 애플리케이션에 영향을 미치는 플랫폼이나 소프트웨어 문제를 감지하기 위해 인스턴스별로 자동으로 검사를 수행합니다. 이러한 점검은 1분마다 실행되며 결과에 따라 정상 또는 손상으로 표시됩니다.. 끌 수 없으며 조기 경고입니다.

각 유형의 검증은 CloudWatch의 메트릭을 통해 지원됩니다. 검사에 실패하면 관련 지표가 상승하고 경보를 울릴 때가 됩니다.이를 통해 알림과 작업을 자동화하여 가동 중지 시간을 최소화할 수 있습니다.

시스템 검사(기본 플랫폼)

이러한 검사는 인스턴스가 실행되는 인프라를 모니터링합니다. 실패하는 경우는 대개 AWS의 개입이나 인스턴스를 다른 호스트로 옮기는 조치가 필요한 플랫폼 문제입니다..

EBS 지원 인스턴스에서는 효과적인 조치가 필요합니다. 인스턴스를 중지하고 다시 시작하여 새 호스트로 다시 배치합니다.인스턴스가 인스턴스 스토어(Linux)를 사용하는 경우 종료 및 교체를 선택할 수 있으며, 종료 시 임시 볼륨이 손실된다는 사실을 알 수 있습니다.

이 실패를 반영하는 지표는 다음과 같습니다. 상태 확인 실패_시스템상황이 지속될 경우 런북, 자동 복구 또는 지원 사례 개설을 트리거하는 알람에 적합합니다.

Bare Metal에는 특이한 점이 있습니다. 운영 체제를 재부팅하면 일시적으로 시스템 검사 오류가 발생할 수 있습니다.인스턴스가 다시 정상적으로 작동하면 더 이상 개입하지 않아도 상태가 정상으로 돌아갑니다.

인스턴스 검사(연결 및 소프트웨어)

이러한 검사에서는 인스턴스 자체의 OS와 네트워크 상태를 분석합니다. EC2는 NIC에 ARP 요청을 보내서 연결 상태를 검증하고, NIC가 응답하는지 확인합니다.여기서 오류가 발생하면 일반적으로 사용자 측에서 조정이 필요합니다.

검사에 실패하면 조치를 취해야 합니다. 인스턴스를 재부팅하고 방화벽/iptables를 확인하고, 시스템 로그를 확인하고, 네트워크가 응답하는지 확인하세요.원인이 소프트웨어나 구성인 경우, 기다리는 것만으로는 충분하지 않습니다.

주의해야 할 지표는 다음과 같습니다. StatusCheckFailed_Instance이를 사용하여 진단 절차(로그 수집, 제어된 재부팅 또는 복구되지 않는 경우 롤백)를 실행하는 알람을 트리거합니다.

또한, Bare Metal에서는 OS에서 재부팅할 때 일시적인 오류가 나타날 수 있습니다. 인스턴스 부팅이 완료되면 일반적으로 검사 결과가 정상으로 돌아갑니다.그러니 당황하지 마세요.

EBS 첨부 검사(볼륨의 I/O)

이러한 검사는 첨부된 EBS 볼륨에 액세스할 수 있는지, 입출력 작업을 완료할 수 있는지 여부를 검증합니다. StatusCheckFailed_AttachedEBS 바이너리 메트릭은 하나 이상의 볼륨이 실패할 때 성능이 저하되었음을 나타냅니다..

이런 오류는 기본적인 계산 문제나 EBS의 문제로 인해 발생할 수 있습니다. AWS에서 완화 조치를 기대하거나 조치를 취할 수 있습니다.: 볼륨을 교체하고, 인스턴스를 중지했다가 다시 시작하여 다른 호스트로 옮기거나, 병목 현상이 나타나면 IOPS 크기를 검토합니다.

부하가 I/O를 하지 않지만 성능 저하가 나타나는 경우, 중지 및 시작 주기를 통해 볼륨 접근성에 영향을 미치는 호스트 문제를 해결할 수 있습니다.CloudWatch의 기본 EBS 메트릭과 함께 사용하여 성능 저하 패턴을 감지합니다.

자동 크기 조정 그룹에서 정책을 구성합니다. 첨부된 EBS 검사에서 지속적인 실패가 있는 인스턴스를 제거합니다.수동 개입 없이도 차량대의 상태를 건강하게 유지하고 장기간의 가동 중지 시간을 피할 수 있습니다.

알람 및 자동화: CloudWatch + 자동 확장

CloudWatch는 모든 건강 지표를 통해 사용자의 신경계가 됩니다. 임계값 정의, 알람 생성, 작업 조정: 알림, 람다, 인스턴스 복구 또는 교체이는 자동적이고 일관된 응답의 기초입니다.

비즈니스 연속성이 필요한 경우 다음을 자동화하고 교체하는 것을 고려하세요. 자동 크기 조정은 실패한 인스턴스를 폐기하고 새 인스턴스를 시작할 수 있습니다.알람이 적절한 알림 채널(이메일, Slack, PagerDuty 또는 사용하는 채널)을 활성화하는 동안.

전체 견해는 다음과 같은 관련 출처에서 나왔습니다. EventBridge를 통한 CloudWatch 메트릭 및 로그, 추적 및 AWS Health 이벤트이 타일을 사용하면 문제가 앱, 인스턴스, 볼륨 또는 플랫폼 중 어디에 있는지 구별하고 정확하게 대응할 수 있습니다.

AWS가 실패하는지 알아보는 공식적이고 상황적 소스

추락에 대한 소문이 돌 때 - AWS 글로벌 중단 이로 인해 엄청난 실패가 발생했기 때문에 공식적인 출처를 우선시하는 것이 이상적입니다. 서비스 및 지역별 상태를 보려면 공개 페이지 status.aws.amazon.com을 확인하세요.계정별 정보를 확인하려면 AWS Health Dashboard에 로그인하세요.

제3자 소스는 추가적인 사회적 맥락과 신호를 제공합니다. Downdetector는 사용자 보고의 급증을 반영하고, The Stack Status는 여러 공급업체의 상태를 요약합니다.공식 채널을 대체하지는 않지만 도달 범위를 추산하는 데 유용합니다.

하지만 가시성과 자동화는 구별됩니다. 프로그래밍 방식의 이벤트 수집의 경우 RSS 피드나 스크래핑보다 EventBridge가 더 좋습니다.외부 형식이 변경되어 사고가 발생할 수 있기 때문입니다.

큰 하락이 나타나는 방식과 예상할 수 있는 것

주요 사고는 일반적으로 많이 사용되는 지역(예: 미국 동부 해안)에 집중되는 경향이 있습니다. 영향은 저장소, 컴퓨팅, 데이터베이스 또는 DNS와 같은 체인에서 느껴집니다.S3, EC2, RDS, Route 53, Kinesis와 같은 서비스가 오류 급증의 영향을 받는 서비스로 나열되는 것은 드문 일이 아닙니다.

이런 경우 스트리밍 회사, 협업 도구, 전자 상거래 또는 모바일 앱에서 지연, 인증 오류, 간헐적 오류가 발생할 수 있습니다. 패턴은 고르지 않습니다. 일부 사용자에게는 효과가 있지만 다른 사용자에게는 효과가 없습니다.경로, 접속 지점 및 활성 지역에 따라 다릅니다.

공식 채널에서는 일반적으로 정기적인 업데이트를 게시합니다. 원인의 사전 식별(예: API의 DNS 확인 문제), 완화책 배포 및 재시도 권장 사항복구가 진행됨에 따라 오류가 감소하고 트래픽이 정상으로 돌아옵니다.

특정 국가나 분야에서는 영향을 받는 특정 서비스에 대한 헤드라인이 표시됩니다. Netflix, Disney+, Slack, 은행 또는 매우 인기 있는 앱과 같은 플랫폼이 영향을 받을 수 있습니다. 그들이 의존하는 지역이 어려움을 겪고, 심지어 LATAM 지역의 기업(과거에 iFood, Mercado Livre, PicPay 등)도 그 여파를 느꼈습니다.

추락으로 인한 경제적, 평판적 영향

기술적인 측면을 넘어 클라우드 중단에는 실제 비용이 발생합니다. 분당 손실, 과부하된 지원, 좌절한 고객 및 미디어 압력네트워크 효과는 인터넷의 특정 기둥이 중앙집중화됨에 따라 더욱 확대됩니다.

중요한 서비스를 운영하는 조직이라면 이 사실을 너무나 잘 알고 있습니다. 실패가 반복되면 신뢰가 침식됩니다. 브랜드 이미지를 회복하는 데 드는 비용은 기술적인 수리 비용보다 더 많이 듭니다.

이러한 위기는 명백하지만 불편한 교훈을 안겨줍니다. 우리는 공유 인프라에 크게 의존합니다회복성과 현실적인 실패 가정을 고려한 설계는 더 이상 선택 사항이 아닙니다.

다음 사건에 더 탄력적으로 대처하기 위한 전략

사업을 중단할 수 없다면 운영상의 위험을 줄이는 전략이 있습니다. 다양한 AWS 영역 간에 부하를 분산하기 위해 다중 지역 아키텍처를 고려하세요. 그리고 지리적 실패의 단일 지점을 피합니다.

사용 사례가 타당하다면 멀티 클라우드를 평가하세요. 핵심 기능을 다른 공급자(Azure, GCP)에 배포하면 안전망을 확보할 수 있습니다.하지만 복잡성과 조정 비용이 더 큽니다.

전달 계층에서 잘 구성된 CDN은 폭풍을 헤쳐나가는 데 도움이 됩니다. CloudFront와 같은 서비스나 Cloudflare와 같은 대안을 사용하면 원본에 문제가 있어도 정적 콘텐츠를 제공할 수 있습니다.사용자와 시스템에 휴식을 제공합니다.

이 모든 것은 조직 없이는 불가능합니다. 역할, 채널, 에스컬레이션 및 외부 커뮤니케이션을 통해 사고 대응 계획을 정의합니다.더운 순간에는 선명함이 소중한 시간을 절약해줍니다.

길을 잃지 않고 AWS 상태를 확인하기 위한 모범 사례

Centraliza la observabilidad: 플랫폼 컨텍스트에는 AWS Health Dashboard를 사용하고 운영 지표에는 CloudWatch를 사용합니다.이러한 이중 접근 방식을 사용하면 어느 한 계층에 의해 갑자기 방해받는 일이 없습니다.

인증서를 사용하면 자동화할 수 있습니다. ACM에서 RenewalStatus를 모니터링하고 Health 대시보드에서 증가하는 알림에 대응합니다. 잘못된 발걸음으로 유통기한을 맞이하지 않도록 하기 위해서입니다.

주요 EC2 지표에 대한 알람을 설정합니다. StatusCheckFailed_System, StatusCheckFailed_Instance 및 StatusCheckFailed_AttachedEBS는 필수입니다.SLA에 따라 자동 크기 조정을 통해 복구, 재시작, 장애 조치 또는 교체 작업과 연결됩니다.

콘솔이 저항하는 경우 체크리스트를 기억하세요. 올바른 지역의 건강 이벤트를 확인하세요캐시와 쿠키를 삭제하고, 브라우저를 변경하고, AWS 도메인이 차단되지 않았는지 IT 부서에 확인하세요. 이러한 간단한 확인만으로도 생각보다 많은 문제를 해결할 수 있습니다.

CreativosOnline