에서 네트워크 액세스를 위한 안티 패턴 AWS 클라우드 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에서 네트워크 액세스를 위한 안티 패턴 AWS 클라우드

안티 패턴은 솔루션이 다른 솔루션보다 비생산적이거나 비효율적이거나 덜 효과적이어서 반복되는 문제에 자주 사용되는 솔루션입니다. 이 단원에서 언급한 설계 옵션은 일반적으로 작동하지만 상당한 단점이 있습니다. 가능하면 더 나은 대안을 사용할 수 있으므로 피해야 합니다.

이 섹션에서는 다음 안티 패턴 및 문제에 대해 설명합니다.

와 가용 영역 불일치 AWS PrivateLink

를 통해 애플리케이션에 대한 액세스를 제공할 때 AWS PrivateLink SaaS 소비자는 애플리케이션이 배포된 가용 영역에서만 인터페이스 VPC 엔드포인트를 생성할 수 있습니다. 예를 들어 애플리케이션이 use1-az1 및에 배포된 경우 use1-az2소비자는에 VPC 엔드포인트를 배포할 수 없습니다use1-az3. 모든 가용 영역에 SaaS 제품을 배포하는 것이 좋습니다. 대부분의 AWS 리전 에는 3개의 가용 영역이 있지만 일부에는 더 많은 가용 영역이 있습니다. 전체 목록은 리전 및 가용 영역을 참조하세요. 를 선택할 때 가용 영역 수를 고려합니다 AWS 리전.

참고

가용 영역 이름은 가용 영역 IDs 다릅니다. 자세한 내용은 AWS 리소스의 가용 영역 IDs를 참조하세요.

SaaS 공급자가 모든 가용 영역에 배포하지 않기로 선택하면 몇 가지 결과가 발생합니다. SaaS 오퍼링이 use1-az1 및에 배포use1-az2되었지만 소비자가를 포함한 세 개의 가용 영역을 모두 사용하고 있다고 가정합니다use1-az3. 인터페이스 VPC 엔드포인트는 use1-az1 및의 소비자 측에 배포되며use1-az2, 이제의 애플리케이션이 이러한 엔드포인트 중 하나에 액세스use1-az3해야 합니다. 먼저 일치하지 않는 가용 영역의 서브넷에서 각 VPC 엔드포인트로 트래픽을 허용해야 합니다. 소비자는 리전 AWS PrivateLink DNS 이름을 사용하기로 결정할 수 있습니다.이 이름은 VPC 엔드포인트 중 하나로 확인될 수 있으며 두 엔드포인트 간에 트래픽을 균등하게 분산합니다. 또는 소비자가와 같은 엔드포인트로 직접 트래픽을 전송하도록 선택할 수 있습니다use1-az2. 이로 인해 트래픽의 67%가의 공급자 측에 도착use1-az2하고의 33%가 도착합니다use1-az1. 다음 그림은이 시나리오를 보여줍니다.

트래픽은 가용 영역에 균등하게 분산되지 않습니다.

소비자 수가 많고 트래픽이 고르지 않게 분산되면 워크로드는 한 가용 영역에서 용량 문제가 발생하고 다른 가용 영역에서는 용량이 부족할 수 있습니다. 이 문제를 해결하기 위해 SaaS 공급자는 Network Load Balancer에서 교차 영역 로드 밸런싱을 활성화하여 트래픽을 균등하게 로드 밸런싱하기로 결정할 수 있습니다. 이로 인해 추가 요금이 발생합니다.

서비스 공급자가 하나의 가용 영역만 일치하면 모든 트래픽이 단일 엔드포인트를 통해 들어갑니다. 이로 인해 불균형이 더욱 커집니다. 따라서 소비자는 더 이상 SaaS 제품을 고가용성으로 사용할 수 없습니다. 자체적으로 사용하지 않는 추가 가용 영역을 통해 애플리케이션을 제공하는 경우 소비자에게는 중요하지 않습니다. 최악의 경우 SaaS 공급자는 동일한 가용 영역을 사용하지 않는 소비자에게 서비스를 제공하지 못할 수 있습니다.

드문 경우지만 SaaS 공급자가 모든 가용 영역에 애플리케이션을 프로비저닝할 수 있는 옵션이 없는 경우 누락된 가용 영역에만 서브넷을 생성한 다음 빈 가용 영역으로 서비스를 확장할 수도 있습니다. 그러면 교차 영역 로드 밸런싱이 다른 가용 영역의 실제 애플리케이션 엔드포인트를 통해 수신 트래픽을 분산할 수 있습니다.

AWS Site-to-Site VPN 간 연결 AWS 계정

온프레미스 환경에서 클라우드로 마이그레이션하는 기업은 때때로 전체 네트워크를 리프트 앤 시프트하려고 합니다. 이로 인해 온프레미스와 클라우드 네트워킹 관행 간에 상당한 차이가 있기 때문에 문제가 발생할 수 있습니다. 이러한 사고방식 전환이 발생하지 않으면 한 VPC에서 다른 VPC로의 AWS Site-to-Site VPN 연결과 같은 일이 발생할 수 있습니다. 이 접근 방식은 관리를 AWS 클라우드간소화하고 성능을 개선하는에서 특별히 구축된 네트워킹 서비스를 활용하지 못합니다. 클라우드 네이티브 설계에 적응하면 운영 오버헤드를 줄이고 VPCs.

SaaS 공급자로서이 연결 옵션을 제공할 생각이라면 자신 또는 소비자에게를 사용해야 AWS Site-to-Site VPN 하는 이유를 물어보십시오. 그런 다음 이러한 요구 사항에서 거꾸로 작업하여 더 나은 연결 옵션을 찾습니다. 이 가이드의 서비스 기능 비교 섹션에는 옵션을 식별하는 데 사용할 수 있는 매트릭스가 포함되어 있습니다. 그런 다음이 가이드의 관련 섹션을 살펴보고 사용 사례를 해결하는 아키텍처 접근 방식을 찾을 수 있습니다.