Nossa equipe está tentando ver se devemos usar o gateway de API gerenciado da AWS em vez do IDC Kong para API Gateway.
Portanto, estou procurando algumas estatísticas concretas para o serviço gerenciado pela AWS (em particular, AWS API Gateway).
Mas as estatísticas regionais de tempo de inatividade total por ano são surpreendentemente difíceis de encontrar no site oficial da AWS.
Eu olhei para o acordo SLA (https://aws.amazon.com/api-gateway/sla/) que parece garantir até 95% de disponibilidade - isso está totalmente fora de questão. 18 dias por ano, poderíamos simplesmente sair do mercado. E eles reembolsam apenas o crédito utilizado - e não as perdas totais incorridas devido ao tempo de inatividade.
Há tambémpainel de integridade do serviçoque mostra o histórico atual de saúde e status. Mas preciso de algo muito melhor do que isso: um gráfico de pizza para o tempo total de inatividade em minutos durante 2019, 2018, 2017 em cada região.
Encontrei esta estatística "Modernize seus aplicativos Microsoft na AWS", mas novamente não é específica o suficiente - ela combina todos os serviços e regiões.
Por que essas estatísticas são tão difíceis de encontrar? Tenho certeza que esta é uma das métricas mais importantes para a escolha do serviço?
Muito obrigado antecipadamente
Responder1
QueDocumento SLAdiz que o SLA é de 99,95%, e não os 95% declarados.
A AWS envidará esforços comercialmente razoáveis para disponibilizar o API Gateway com uma porcentagem mensal de tempo de atividade depelo menos 99,95%para cada região da AWS.
Os 95% são mencionados apenas na tabela que mostra quanto crédito você receberá se violar o SLA.
De qualquer forma, as coisas quebram e os serviços caem. Mas não todos ao mesmo tempo.
Seu API GW pode falhar (por conta própria ou devido às suas ações), mas talvez não todos os API GWs de uma vez. A zona de disponibilidade pode cair, mas talvez nem todas as AZs ao mesmo tempo. Sim, às vezes até algumas regiões ficam inativas, mas outras regiões estão bem.
Se o seu serviço for supercrítico e você não puder pagar uma interrupçãotorná-lo altamente disponível por meio de redundância geográfica. Isso significa implantar a mesma API em regiões diferentes, talvez uma região nos EUA, uma na UE e uma na Ásia-Pacífico.
A AWS fornece muitas ferramentas para fazer isso, desde implantação unificada por meio de modelos CloudFormation, por meio de tabelas globais do DynamoDB, até roteamento baseado em latência com Route53. E mais.
O tempo de atividade de instância única/API GW/etc não importa se sua implantação for HA.
Espero que ajude :)