As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# ROSA arquitetura
Serviço Red Hat OpenShift na AWS (ROSA) tem as seguintes topologias de cluster:
+ Plano de controle hospedado (HCP) - O plano de controle é hospedado na Red Hat Conta da AWS e gerenciado pela Red Hat. Os nós de trabalho são implantados no cliente Conta da AWS.
+ Clássico — O plano de controle e os nós de trabalho são implantados no do Conta da AWS cliente.
O ROSA com HCP oferece uma arquitetura de plano de controle mais eficiente que ajuda a reduzir as taxas de AWS infraestrutura incorridas durante a execução ROSA e permite tempos de criação de clusters mais rápidos. Tanto o ROSA com HCP quanto o ROSA classic podem ser ativados no AWS ROSA console. Você tem a opção de selecionar qual arquitetura deseja usar ao provisionar ROSA clusters usando a ROSA CLI.
**nota**
ROSA oferece certificações de conformidade FedRAMP High e HIPAA Qualified AWS GovCloud em arquiteturas de plano de controle clássicas e hospedadas. Para obter mais informações, consulte [Conformidade](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws_classic_architecture/4/html/introduction_to_rosa/policies-and-service-definition#rosa-policy-process-security) na documentação da Red Hat.
ROSA oferece endpoints do Federal Information Processing Standard (FIPS) AWS GovCloud em arquiteturas de plano de controle clássicas e hospedadas.
## Comparando o ROSA com o HCP e o ROSA classic
A tabela a seguir compara o ROSA com os modelos de arquitetura clássica HCP e ROSA.
| | **ROSA com HCP** | **ROSA classic** |
| --- | --- | --- |
| Hospedagem da infraestrutura do cluster | Os componentes do plano de controle, como etcd, servidor de API e oauth, são hospedados em um local de propriedade da Red Hat. Conta da AWS | Os componentes do plano de controle, como etcd, servidor de API e oauth, são hospedados em um local de propriedade do cliente. Conta da AWS |
| Amazon VPC | Os nós de trabalho se comunicam com o plano de controle [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html). | Os nós de trabalho e os nós do plano de controle são implantados na VPC do cliente. |
| AWS Identity and Access Management | Usa políticas AWS gerenciadas. | Usa políticas gerenciadas pelo cliente que são definidas pelo serviço. |
| Implantação em várias zonas | O plano de controle é implantado em várias zonas de disponibilidade (AZs). | O plano de controle pode ser implantado em uma única AZ ou em várias AZs. |
| Nodos de infraestrutura | Não usa nós de infraestrutura dedicados. Os componentes da plataforma são implantados nos nós de trabalho. | Usa dois nós dedicados Single-AZ ou três Multi-AZ para hospedar os componentes da plataforma. |
| OpenShift capacidades | O monitoramento da plataforma, o registro de imagens e o controlador de entrada são implantados nos nós de trabalho. | O monitoramento da plataforma, o registro de imagens e o controlador de entrada são implantados em nós de infraestrutura dedicados. |
| Atualizações de cluster | O plano de controle e cada pool de máquinas podem ser atualizados separadamente. | O cluster inteiro deve ser atualizado ao mesmo tempo. |
| Amazon EC2 Pegada mínima | São necessárias duas Amazon EC2 instâncias para criar um cluster. | São necessárias sete Amazon EC2 instâncias Single-AZ ou nove Multi-AZ para criar um cluster. |
| Regiões da AWS | Para obter Região da AWS informações sobre disponibilidade, consulte [Serviço Red Hat OpenShift na AWS endpoints e cotas](https://docs.aws.amazon.com/general/latest/gr/rosa.html) no Guia de *referência AWS geral*. | Para obter Região da AWS informações sobre disponibilidade, consulte [Serviço Red Hat OpenShift na AWS endpoints e cotas](https://docs.aws.amazon.com/general/latest/gr/rosa.html) no Guia de *referência AWS geral*. |