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á.

# Considerações sobre o design multilocatário do Amazon Verified Permissions
<a name="avp-design-considerations"></a>

Há várias opções de design a serem consideradas quando você implementa a autorização usando Amazon Verified Permissions em uma solução SaaS multilocatária. Antes de explorar essas opções, vamos esclarecer a diferença entre *isolamento* e *autorização* em um contexto SaaS multilocatário. O [isolamento de](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) um inquilino evita que os dados de entrada e saída sejam expostos ao inquilino errado. A autorização garante que o usuário tenha as permissões para acessar um inquilino.

Em Permissões verificadas, as políticas são armazenadas em um repositório de políticas. Conforme descrito na [documentação de Permissões verificadas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html), você pode isolar as políticas dos inquilinos usando um repositório de políticas separado para cada inquilino ou permitir que os inquilinos compartilhem políticas usando um único repositório de políticas para todos os inquilinos. Esta seção discute as vantagens e desvantagens dessas duas estratégias de isolamento e descreve como elas podem ser implantadas usando um modelo de implantação em camadas. Para obter mais contexto, consulte a documentação de permissões verificadas.

Embora os critérios discutidos nesta seção se concentrem nas permissões verificadas, os conceitos gerais estão enraizados na [mentalidade de isolamento](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html) e na orientação que ela fornece. Os aplicativos SaaS devem sempre considerar o [isolamento do inquilino](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) como parte de seu design, e esse princípio geral de isolamento se estende à inclusão de permissões verificadas em um aplicativo SaaS. [Esta seção também faz referência aos principais modelos de isolamento de SaaS, como o modelo SaaS em [silos e o modelo SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) em pool.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Para obter informações adicionais, consulte os [principais conceitos de isolamento](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html) no AWS Well-Architected Framework, SaaS Lens.

As principais considerações ao projetar soluções SaaS multilocatário são o isolamento e a integração de inquilinos. O isolamento do inquilino afeta a segurança, a privacidade, a resiliência e o desempenho. A integração de inquilinos afeta seus processos operacionais no que se refere à sobrecarga operacional e à observabilidade. Organizações que passam por uma jornada de SaaS ou implementam soluções multilocatárias devem sempre priorizar como a locação será tratada pelo aplicativo SaaS. Embora uma solução SaaS possa se inclinar para um modelo de isolamento específico, a consistência não é necessariamente necessária em toda a solução SaaS. Por exemplo, o modelo de isolamento escolhido para os componentes de front-end do seu aplicativo pode não ser o mesmo que o modelo de isolamento escolhido para um microsserviço ou serviços de autorização.

**Topics**
+ [Integração de inquilinos e registro de inquilinos de usuários](avp-design-onboarding-registration.md)
+ [Armazenamento de políticas por inquilino](avp-design-per-tenant-store.md)
+ [Um repositório de políticas compartilhado para vários locatários](avp-design-shared-store.md)
+ [Modelo de implantação hierárquica](avp-design-tiered.md)