AWS Outposts 랙 FAQ

페이지 주제

일반
8
AWS 서비스
11
주문 및 설치 시작
1
결제
1
보안 및 규정 준수
4
지원 및 유지 관리
4

일반

짧은 대기 시간 또는 로컬 데이터 처리 요구 사항이 있는 애플리케이션을 지원하기 위해 Outposts 랙을 사용할 수 있습니다. 이러한 애플리케이션에서는 최종 사용자 애플리케이션에 대한 실시간에 가까운 응답을 생성하거나 다른 온프레미스 시스템과 통신하거나 현장 장비를 제어해야 할 수도 있습니다. 제조 분야에서 자동화된 운영, 실시간 환자 진단이나 의료 영상, 콘텐츠 및 미디어 스트리밍을 위한 공장의 현장에서 실행되는 워크로드도 포함될 수 있습니다. Outposts 랙을 사용하면 온프레미스에서 또는 AWS 리전이 없는 국가에서 유지해야 하는 고객 데이터를 안전하게 저장하고 처리할 수 있습니다. AWS 리전으로 데이터를 전송하는 작업에 비용과 리소스가 많이 들어가는 경우 데이터 분석, 백업 및 복원에 대한 제어를 향상시키기 위해 Outposts 랙에서 데이터 집약적인 워크로드를 실행하고 로컬로 데이터를 처리할 수 있습니다.

Outposts 랙은 다음과 같은 AWS 리전에서 지원되며, 고객은 Outposts를 다음 AWS 리전에 연결할 수 있습니다.

미국 동부(버지니아 북부) us-east-1
미국 동부(오하이오) us-east-2
미국 서부(캘리포니아 북부) us-west-1
미국 서부(오레곤) us-west-2
캐나다(중부) ca-central-1
남아메리카(상파울루) sa-east-1
EU(프랑크푸르트) eu-central-1
EU(스톡홀름) eu-north-1
EU(아일랜드) eu-west-1
EU(런던) eu-west-2
EU(파리) eu-west-3
EU(밀라노) eu-south-1
EU(스페인) eu-south-2
중동(바레인) me-south-1
중동(UAE) me-central-1
이스라엘(텔아비브) il-central-1
아프리카(케이프타운) af-south-1
아시아 태평양(싱가포르) ap-southeast-1
아시아 태평양(시드니) ap-southeast-2
아시아 태평양(자카르타) ap-southeast-3
아시아 태평양(도쿄) ap-northeast-1
아시아 태평양(서울) ap-northeast-2
아시아 태평양(오사카) ap-northeast-3
아시아 태평양(뭄바이) ap-south-1
AWS GovCloud(미국 서부) us-gov-west-1
AWS GovCloud(미국 동부) us-gov-east-1

 

Outposts 랙은 다음 국가와 지역에서 사용 및 설치할 수 있습니다.

  • NA - 미국, 캐나다, 멕시코
  • EMEA - 모든 유럽 국가, 영국(UK), 스위스, 노르웨이, 바레인, 아랍 에미리트 연합국(UAE), 이스라엘, 남아프리카공화국, 지브롤터, 모로코, 나이지리아, 케냐, 오만, 카자흐스탄, 세르비아, 카타르, 이집트, 아이슬란드, 터키, 사우디아라비아*, 세네갈, 요르단, 쿠웨이트
  • APAC - 오스트레일리아, 뉴질랜드, 일본, 대한민국, 대만, 싱가포르, 인도네시아, 말레이시아, 태국, 필리핀, 브루나이, 인도, 베트남, 방글라데시
  • SA - 브라질, 콜롬비아, 아르헨티나, 칠레, 페루, 에콰도르, 트리니다드 토바고, 우루과이
  • CA - 푸에르토리코, 코스타리카, 파나마, 과테말라

곧 더 많은 국가와 지역에서 지원될 예정입니다.

* 사우디아라비아에 배포하는 고객은 추가 승인이 필요할 수 있습니다. 자세한 내용은 AWS 영업 담당자에게 문의하세요.

아니요, Outposts 랙을 제공 및 지원할 수 있는 국가와 지역에서만 Outposts 랙을 제공 및 설치할 수 있습니다.

Outpost는 상위 AWS 리전에 대한 연결에 의존합니다. Outposts 랙은 연결이 지원되지 않는 제한된 환경이나 연결이 끊어진 작업을 지원하도록 설계되지는 않았습니다. 따라서 고객은 AWS 리전에 대한 고가용성 네트워킹 연결을 다시 확보하는 것이 좋습니다. 유람선이나 멀리 떨어진 채광/채굴지와 같이 연결이 끊어진 환경에서 AWS 서비스를 이용하고 싶다면 연결이 지원되지 않는 제한된 환경에서 운영하도록 최적화된 Snowball Edge와 같은 AWS 서비스에 대해 자세히 알아보세요.

아니요, AWS Outposts 랙은 AWS에서 설계한 인프라를 활용하며, 안전하고 신뢰할 수 있는 고성능 작업을 위해 최적화된 AWS에서 설계한 하드웨어에서만 지원됩니다.

아니요, AWS Outposts 랙은 AWS 서비스에 대한 기본 액세스 권한을 제공하는 완전관리형 서비스입니다.

아니요, AWS Outposts 랙에서는 이상적인 AWS 경험을 위해 내장 TOR(Top-of-Rack) 스위치 및 예비 전원 공급 장치를 포함하는 완벽하게 통합된 AWS에서 설계한 구성을 제공합니다. 사용 가능한 Outposts 랙 옵션의 범위에서 선택하여 컴퓨팅 및 스토리지 인프라를 필요한 만큼 주문하거나, 당사와 협력하여 원하는 Amazon Elastic Compute Cloud(EC2), Amazon Elastic Block Store(EBS), Amazon Simple Storage Service(S3) 용량으로 사용자 정의 조합을 생성할 수 있습니다. 이러한 옵션은 현장에서 추가적인 노력이나 구성 없이도 빠르게 시작할 수 있도록 사전 검증 및 테스트되었습니다.

AWS 서비스

예, EBS gp2 볼륨 유형으로 지원되는 AMI를 사용하여 EC2 인스턴스를 시작할 수 있습니다.

Outposts 랙에 있는 EBS 볼륨의 EBS 스냅샷은 기본적으로 리전에 있는 Amazon S3에 저장됩니다. Outpost가 Amazon S3 on Outposts로 프로비저닝된 경우에 스냅샷을 Outpost에 로컬로 저장할 수 있는 옵션이 있습니다. EBS 스냅샷은 증분식이므로 가장 최근의 스냅샷이 저장된 후 변경된 Outpost의 블록만 저장됩니다. 언제든지 저장된 스냅샷에서 Outposts의 EBS 볼륨을 복원(수화)할 수 있습니다. 자세한 내용은 EBS 스냅샷 설명서를 참조하세요.

EBS Local Snapshots on Outposts 및 AMI 이미지에 대해 Outpost에 리소스 수준의 IAM 정책 및 권한을 설정하여 데이터 레지던시를 적용할 수 있습니다. 각 계정(또는 IAM 사용자 또는 역할)은 단일 또는 여러 Outpost에 대해 데이터 레지던시 적용 정책을 설정할 수 있습니다. 이렇게 하면 지정된 Outposts 랙 ARN 외부의 API/CLI 호출뿐만 아니라 로컬 스냅샷과 이미지의 생성 또는 복사도 차단됩니다. 모든 생성, 업데이트 및 복사 작업이 CloudTrail 감사 로그에 기록되므로 로컬 스냅샷이 사용자 위치에 있는지를 추적할 수 있습니다. 자세한 내용은 EBS 스냅샷 설명서를 참조하세요.

S3 on Outposts는 데이터 레지던시 요구 사항이 있는 고객이나, AWS 리전이 없는 위치나 온프레미스에서 유지해야 하는 고객 데이터를 안전하게 저장 및 처리해야 하는 규제 대상 산업에 종사하는 고객에게 적합합니다. 또한 고객은 S3 on Outposts를 통해 데이터 사용량이 많은 워크로드를 실행하여 데이터를 로컬에서 처리하고 온프레미스에 저장할 수 있습니다. S3 on Outposts는 다른 온프레미스 시스템과 통신하거나 공장, 병원 또는 연구 시설 내의 현장 장비를 제어해야 하는 애플리케이션이 있는 경우에도 도움이 됩니다.

AWS Direct Connect 프라이빗 연결, 퍼블릭 가상 인터페이스 또는 공용 인터넷을 통해 AWS 리전에 대한 Outposts 랙 서비스 링크 VPN 연결을 설정하도록 선택할 수 있습니다.

예. Outposts 랙이 제공되는 모든 AWS 리전(AWS GovCloud(미국) 리전 제외)의 Outposts 랙에서 Application Load Balancer를 사용할 수 있습니다.

예. Amazon RDS on Outposts를 사용하면 온프레미스 데이터와 애플리케이션에 가까운 위치에서 실행해야 하는 대기 시간이 짧은 워크로드를 위해 온프레미스에서 관리형 Microsoft SQL Server, MySQL 및 PostgreSQL 데이터베이스를 실행할 수 있습니다. 동일한 AWS 관리 콘솔, API 및 CLI를 사용하여 클라우드와 온프레미스 모두에서 RDS 데이터베이스를 관리할 수 있습니다. 지연 시간이 극도로 짧아야 하는 애플리케이션의 경우 ElastiCache on Outposts를 사용하면 제조, 실시간 환자 진단, 미디어 스트리밍 부문의 자동화된 작업을 위해 공장 현장에서 실행되는 워크로드를 포함하여 실시간 애플리케이션에 대해 밀리초 미만의 응답 시간을 구현할 수 있습니다.

예. 고객의 온프레미스 위치 또는 지정된 콜로케이션 시설에서 Amazon Elastic Block Store(EBS) 및 Amazon Simple Storage Service(S3) on Outposts 랙을 사용하여 Outposts에서 유지하도록 고객 데이터를 구성할 수 있습니다. Outposts 랙과 AWS 서비스 및 도구를 사용하는 Well-Architected 애플리케이션은 우리가 고객들로부터 가장 흔히 듣는 데이터 레지던시 요구 사항을 해결합니다. AWS Identity and Access Management(IAM)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있습니다. IAM 및 세분화된 데이터 제어 규칙을 사용하여 Outposts 랙에서 유지해야 하며 AWS 리전으로 복제할 수 없는 데이터 유형을 지정할 수 있습니다. S3 on Outposts에서는 기본적으로 데이터를 Outpost에 저장하며, 특정 레지던시 요구 사항에 따라 데이터의 일부 또는 전부를 AWS 리전에 복제하도록 선택할 수도 있습니다. ElastiCache on Outposts 랙을 사용하면 고객 데이터를 Outposts에서 로컬로 안전하게 처리할 수 있습니다. 일부 제한된 메타데이터(예: 인스턴스 ID, 모니터링 지표, 측정 레코드, 태그, 버킷 이름 등)는 다시 AWS 리전으로 전달됩니다.

고유한 데이터 레지던시 요구 사항을 충족하려면 규정 준수 및 보안 팀과 긴밀하게 협력하는 것이 좋습니다.

예. AWS Resource Access Manager(RAM)는 AWS 계정에서 또는 귀사의 AWS Organization 내에서 AWS 리소스를 공유할 수 있게 해 주는 서비스입니다. RAM이 지원됨에 따라 Outpost 소유자는 EC2 인스턴스, EBS 볼륨, 서브넷 및 로컬 게이트웨이(LGW) 같은 Outpost 리소스를 중앙에서 생성 및 관리하고 동일한 AWS 조직 내의 여러 AWS 계정에서 리소스를 공유할 수 있습니다. 이를 통해 다른 사용자가 VPC를 구성하고, 인스턴스를 시작 및 실행하고, 공유 Outpost에서 EBS 볼륨을 생성할 수 있습니다.

인텔 제온 스케일러블 프로세서에서 범용, 컴퓨팅 최적화, 메모리 최적화, 스토리지 최적화 및 GPU 최적화를 위해 AWS Nitro System에 구축된 EC2 인스턴스는 AWS Outposts 랙에서 지원되며, Graviton 프로세서 기반 EC2 인스턴스도 곧 출시될 예정입니다.

Route 53 Resolver를 사용하면 Outposts 랙에서 로컬로 도메인 이름 서버(DNS) 쿼리를 확인하여 온프레미스 애플리케이션의 가용성과 성능을 높일 수 있습니다. Route 53 Resolver on Outposts를 사용하도록 설정하면 Route 53가 DNS 응답을 Outposts 랙에 자동으로 저장하고 상위 AWS 리전과의 네트워크 연결이 예기치 않게 끊긴 경우에도 애플리케이션에 대한 DNS 확인을 지속적으로 제공합니다. 또한 Route 53 Resolver on Outposts는 DNS 응답을 로컬에서 처리함으로써 지연 시간이 짧은 DNS 확인을 가능하게 하여 온프레미스 애플리케이션의 성능을 개선합니다.

Route 53 Resolver 엔드포인트를 통해 Route 53 Resolvers on Outposts 랙을 온프레미스 데이터 센터의 DNS 서버에 연결할 수도 있습니다. 이렇게 하면 Outposts 랙과 다른 온프레미스 리소스 간의 DNS 쿼리를 확인할 수 있습니다.

주문 및 설치 시작

현장에서 Outpost를 호스팅하기 위한 기본적인 전력, 네트워킹 및 공간 요구 사항을 지원해야 합니다. Outposts 랙에는 5-15kVA의 전력이 필요하고, 1/10/40/100Gbps 업링크와 42U 랙(203 X 61 X 122cm)의 공간을 지원할 수 있습니다. Outposts 랙에는 AWS 리전과의 안정적인 네트워크 연결이 필요하므로 퍼블릭 인터넷 연결을 계획해야 합니다. 고객은 선택한 Support 플랜에 따라 15분 이내 또는 30분 이내 상시 원격 지원을 제공하는 Enterprise Support 또는 Enterprise On-Ramp Support를 보유해야 합니다.

결제

Outposts 랙 기간이 만료되면 구독을 갱신하고 기존 Outposts 랙을 유지하거나 Outposts 랙을 반환할 수 있습니다. 어떤 옵션을 선택할지 AWS에 알리지 않으면 Outposts 랙이 AWS Outposts 랙 구성에 해당하는 선결제 없음 옵션의 요율로 월 단위로 갱신됩니다. 자세한 내용은 여기에서 기간 만료 설명서를 참조하세요.

보안 및 규정 준수

AWS Outposts 랙 자체는 HIPAA 적격 서비스이고 PCI, SOC, ISMAP, IRAP, FINMA를 준수하며, ISO 및 CSA STAR와 HITRUST 인증을 받았고, 다음 몇 달 동안 규정 준수 자격증을 더 추가할 수 있을 것으로 기대합니다. 최신 인증 현황은 범위 내 서비스에서 Outposts 랙의 AWS 서비스 페이지를 참조하시기 바랍니다. RDS 또는 Elasticache Redis처럼 PCI와 같은 인증을 받은 Outposts 랙 기반 AWS 서비스도 Outposts 랙에서 인증된 것으로 간주됩니다. AWS Outposts 랙은 고객 데이터 센터에서 실행되기 때문에, AWS Shared Responsibility Model에 따라 규정 준수 인증을 위한 Outpost 주변의 물리적 보안 및 액세스 제어 책임은 고객에게 있습니다.

예. AWS Outposts 랙은 GxP와 호환 가능합니다. AWS Outposts 랙은 AWS 서비스를 물리적으로 고객 사이트에 위치한 AWS 관리형 인프라로 확장합니다. Outposts 랙 용량은 AWS 리전으로 연결 경로를 다시 구성하는 방법 외에도, 고객의 로컬 네트워크에 매핑된 로컬 게이트웨이를 통해 로컬로 액세스할 수 있습니다. 여기에서 GxP 시스템을 위해 Outposts 랙을 포함하여 AWS 클라우드를 사용하는 방법에 대해 자세히 알아보세요. GxP의 규제를 받으며 AWS 서비스를 사용하는 생명 과학 조직은 GxP 규정 준수를 설계하고 검증할 책임이 있습니다.

AWS는 저장 중 및 전송 중에 데이터를 암호화할 수 있는 서비스와 기타 세분화된 보안 통제 및 감사 메커니즘을 제공합니다. 또한 고객 데이터는 물리적 Nitro 보안 키로 래핑됩니다. 디바이스를 파괴하는 것은 데이터를 파괴하는 것과 같습니다.  공동 책임 모델의 일환으로, 고객이 Outpost에 대한 물리적 보안 및 액세스 제어는 물론, 시설, 네트워킹 및 전력에 관한 환경 요구 사항(여기에 게시됨)을 입증할 책임을 집니다. Outposts 랙 하드웨어를 반환하기 전에, 고객 콘텐츠의 암호화가 폐기되도록 Nitro 보안 키를 제거해야 합니다.

FedRAMP는 서비스의 하드웨어 구성 요소를 제외하고 AWS Outposts에 권한을 부여했습니다. 고객 사이트에 있는 동안 AWS Outposts 보호를 위한 물리적 및 환경적 제어는 고객의 책임입니다. 고객과 기관은 위험 기반 결정을 내려 AWS Outposts를 사용하거나, 유형 승인을 수행하여 FedRAMP 워크로드를 처리하기 위한 AWS Outposts의 하드웨어 구성 요소를 검토할 수 있습니다. 이전에 AWS의 서드 파티 평가 기관에서 수행한 평가 결과는 CapLinked를 통해 액세스할 수 있습니다.

지원 및 유지 관리

AWS 관리 콘솔에서 Outpost를 설치하고 볼 수 있는 경우 AWS는 퍼블릭 리전의 일부로 이를 모니터링하고, 자동으로 소프트웨어 업그레이드 및 패치를 실행합니다.

물리적 유지 관리가 필요한 경우 AWS는 현장을 방문할 시간을 예약하기 위해 연락을 드립니다. AWS에서는 해당되는 경우 특정 모듈을 교체할 수는 있지만, 고객 현장에서 호스트 또는 네트워크 스위치에 대한 수리 서비스를 제공하지 않습니다.

Outpost의 EC2 인스턴스 및 EBS 볼륨은 정상적으로 계속 운영되며, 로컬 게이트웨이를 통해 로컬로 액세스할 수 있습니다. 마찬가지로, AWS 서비스 리소스(예: ECS 작업자 노드)도 계속 로컬로 실행됩니다. 그러나 API 가용성이 저하될 수 있습니다. 예를 들어, run/start/stop/terminate API가 작동하지 않을 수 있습니다. 인스턴스 지표 및 로그는 몇 시간 동안 로컬로 계속 캐시되며, 연결이 복구되면 AWS 리전으로 푸시됩니다. 그러나 몇 시간 넘도록 연결이 끊어져 있으면 지표 및 로그가 유실될 수 있습니다. 네트워크 연결이 끊어질 것으로 예상되면 정기적으로 워크로드를 테스트하여 Outpost 연결이 끊어졌을 때 이 상태로 적절히 작동하는지 확인하는 것이 좋습니다. Outposts의 S3의 경우 Outpost에 대한 네트워크 연결이 끊어지면 객체에 액세스할 수 없습니다. 객체 저장 및 검색 요청은 리전별 AWS Identity and Access Management(IAM) 서비스를 사용하여 인증되며, Outpost가 홈 AWS 리전에 연결되어 있지 않으면 데이터에 액세스할 수 없습니다. 연결이 끊어져 있는 동안에도 데이터는 Outpost에서 안전하게 저장된 상태로 유지되며, 연결이 복원되면 인증 및 요청도 재개할 수 있습니다.

예를 들어, 인스턴스 상태, 인스턴스 활동(시작됨, 중지됨), 기본 하이퍼바이저 시스템에 대한 정보가 상위 AWS 리전으로 다시 전송될 수 있습니다. 이 정보를 통해 AWS는 인스턴스 상태 및 용량에 대한 경고를 제공하고 Outpost에 패치 및 업데이트를 적용할 수 있습니다. 사용자 팀에서 이러한 요소를 관리하거나 Outpost에 적극적으로 보안 업데이트 및 패치를 푸시하기 위한 도구를 구현하지 않아도 됩니다. S3 on Outposts의 경우 특정 데이터 관리 및 원격 측정 데이터(예: 버킷 이름 및 지표)는 보고 및 관리를 위해 AWS 리전에 저장할 수도 있습니다. 연결이 끊어지면 이러한 정보는 상위 리전으로 다시 전송할 수 없습니다.

AWS Outposts 랙의 컴퓨팅 및 스토리지 용량을 증가시키는 데에는 두 가지 메커니즘이 있습니다. 첫째, Outposts 랙 카탈로그에서 Outposts 랙을 추가하여 용량을 증가시킬 수 있습니다. 둘째, 기존 Outposts 랙 내에 사용 가능한 용량과 포지션이 있는 경우 “스몰”에서 “미디엄” 또는 “라지” 구성으로, 또는 “미디엄”에서 “라지” 구성으로 증가시킬 수 있습니다. 10KVA~15KVA 전력 소비를 지원하는 랙 내에서 최대 2회까지 컴퓨팅 및 스토리지 용량을 추가할 수 있습니다. 참고: 1U 및 2U Outpost 서버는 42U Outpost 폼 팩터에 설치할 수 있습니다.