Um SLA (acordo de nível de serviço) da AWS é o compromisso de disponibilidade que a Amazon Web Services publica para cada serviço, com créditos de serviço se não for cumprido. O Amazon EC2, por exemplo, compromete-se com 99,99% de disponibilidade mensal por região para instâncias distribuídas por duas ou mais Zonas de Disponibilidade. Se falhar, a AWS credita uma fatura futura; não paga o negócio perdido.
Pontos principais
- A AWS afirma oferecer SLA para todos os serviços pagos e em disponibilidade geral. Cada serviço tem a sua própria página de SLA, com a sua percentagem de disponibilidade e escalões de crédito.
- Compromissos típicos: EC2 99,99% por região (multi-AZ) e 99,5% por instância, RDS Multi-AZ 99,95%, Lambda 99,95% e um limiar de crédito de 99,9% para o S3 Standard.
- Os remédios são créditos de serviço de 10%, 25% ou 30% e 100% dos encargos mensais do serviço afetado, consoante a queda da disponibilidade. O SLA é o seu único e exclusivo remédio.
- Os créditos não são automáticos. Abre um caso no AWS Support Center, e o pedido tem de chegar até ao final do segundo ciclo de faturação após o incidente.
- O SLA abrange a infraestrutura da AWS, não a sua aplicação. A sua própria disponibilidade depende da forma como desenha a solução por Zonas de Disponibilidade e regiões.
O que é um acordo de nível de serviço da AWS?
É um documento jurídico curto que define um objetivo de disponibilidade mensurável para um serviço da AWS e o crédito que a AWS lhe dá se esse objetivo não for atingido. A AWS lista-os todos na sua página de Service Level Agreements, agrupados por categoria, da análise de dados ao armazenamento, e afirma que se compromete a oferecer SLA "para todos os serviços pagos e em disponibilidade geral". As funcionalidades em pré-visualização e gratuitas não estão, portanto, abrangidas.
Todos os SLA de serviço seguem o mesmo padrão:
- Um compromisso de serviço: uma percentagem de disponibilidade mensal, medida de uma forma definida para esse serviço (por exemplo, a conectividade externa no EC2 ou a taxa de erro dos pedidos no S3).
- Uma tabela de créditos: a percentagem dos encargos desse mês que recebe de volta como crédito, por cada escalão de disponibilidade não cumprida.
- Um processo de reclamação: como e até quando pedir o crédito.
- Exclusões: causas de indisponibilidade que não contam, como a sua própria configuração ou eventos fora do controlo razoável da AWS.
Percentagens de disponibilidade e escalões de crédito dos principais serviços da AWS
A tabela seguinte usa os valores da página de SLA de cada serviço em outubro de 2026. A AWS atualiza estas páginas de tempos a tempos, por isso verifique a data de "última atualização" da página antes de se apoiar num número num contrato.
| Serviço e âmbito | Compromisso de disponibilidade mensal | Crédito de serviço se não cumprido | Última atualização da página de SLA |
|---|---|---|---|
| Amazon EC2, nível de região (instâncias em 2+ AZ numa região) | 99,99% | 10% abaixo de 99,99%; 30% abaixo de 99,0%; 100% abaixo de 95,0% | 25 mai. 2022 |
| Amazon EC2, nível de instância (cada instância isolada) | 99,5% | 10% abaixo de 99,5%; 30% abaixo de 99,0%; 100% abaixo de 95,0% | 25 mai. 2022 |
| Amazon S3 Standard, Express One Zone, Glacier Flexible Retrieval, Glacier Deep Archive | Os créditos começam abaixo de 99,9% | 10% abaixo de 99,9%; 25% abaixo de 99,0%; 100% abaixo de 95,0% | 28 nov. 2023 |
| Amazon S3 Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval | Os créditos começam abaixo de 99,0% | 10% abaixo de 99,0%; 25% abaixo de 98,0%; 100% abaixo de 95,0% | 28 nov. 2023 |
| Amazon RDS, instância ou cluster Multi-AZ | 99,95% | 10% abaixo de 99,95%; 25% abaixo de 99,0%; 100% abaixo de 95,0% | 22 jan. 2024 |
| Amazon RDS, instância Single-AZ | 99,5% | 10% abaixo de 99,5%; 25% abaixo de 99,0%; 100% abaixo de 95,0% | 22 jan. 2024 |
| AWS Lambda, por região | 99,95% | 10% abaixo de 99,95%; 25% abaixo de 99,0%; 100% abaixo de 95,0% | 5 mai. 2022 |
Fontes: o Amazon Compute SLA, o Amazon S3 SLA, o Amazon RDS SLA e o AWS Lambda SLA. Note que o escalão intermédio de crédito do EC2 é de 30%, enquanto o S3, o RDS e o Lambda usam 25%. Os resumos mais antigos que indicam uma única tabela para todos os serviços estão errados.
O que significam as percentagens em minutos
Num mês de 30 dias (43 200 minutos), os compromissos permitem aproximadamente esta indisponibilidade antes de os créditos se aplicarem:
- 99,99%: cerca de 4,3 minutos
- 99,95%: cerca de 21,6 minutos
- 99,9%: cerca de 43,2 minutos
- 99,5%: cerca de 3,6 horas
É por isso que o valor do EC2 ao nível da região só se aplica quando executa instâncias em pelo menos duas Zonas de Disponibilidade. Uma instância isolada tem o compromisso de 99,5% ao nível da instância, que permite horas, e não minutos, de indisponibilidade por mês.
Como funcionam os créditos de serviço da AWS?
Um crédito de serviço é uma percentagem do que pagou pelo serviço afetado, no âmbito afetado, nesse mês. No EC2 ao nível da região, é uma percentagem da sua fatura mensal de EC2 nessa região, excluindo pagamentos pontuais, como as taxas iniciais das Reserved Instances. Numa reclamação ao nível da instância, é uma percentagem da fatura dessa instância.
Um exemplo prático: gasta 8 000 USD em EC2 em eu-north-1 (Estocolmo) num mês, e a disponibilidade ao nível da região para as suas instâncias multi-AZ fica em 99,95%. Está abaixo de 99,99% mas acima de 99,0%, pelo que o crédito é de 10%, ou seja, 800 USD, aplicados a pagamentos futuros de EC2.
Outras regras do SLA do EC2 que apanham as pessoas desprevenidas:
- Os créditos abatem a pagamentos futuros do mesmo serviço. Não dão direito a reembolso nem a pagamento em dinheiro.
- A AWS só emite um crédito se este valer mais de 1 USD no ciclo de faturação.
- Pode reclamar ao abrigo do SLA ao nível da região ou ao nível da instância para uma instância, não de ambos.
- O SLA é o seu remédio "único e exclusivo" para a indisponibilidade, salvo se o seu contrato com a AWS dispuser em contrário.
Como pedir um crédito de serviço à AWS
- Reúna provas. Registe as datas e horas do incidente, a região afetada (e a Zona de Disponibilidade, nas reclamações ao nível da instância), os IDs dos recursos e os registos que mostram a interrupção. Oculte os dados sensíveis.
- Abra um caso no AWS Support Center. Use a linha de assunto que o SLA exige. No EC2 é "Amazon Compute SLA Credit Request – Region-Level Claim" ou "– Instance-Level Claim"; no S3, o assunto tem de incluir "SLA Credit Request".
- Submeta a tempo. No EC2 e no S3, a AWS tem de receber o pedido até ao final do segundo ciclo de faturação após o incidente.
- Acompanhe o resultado. A AWS confirma se a indisponibilidade é elegível e aplica o crédito a uma fatura posterior.
As equipas que gerem muitas contas perdem muitas vezes créditos porque ninguém é responsável por este processo. Se trabalha com um fornecedor de serviços geridos, inclua o tratamento das reclamações no contrato.
O que não está coberto pelos SLA da AWS?
As exclusões são semelhantes entre serviços. A indisponibilidade não conta para o SLA se for causada por:
- fatores fora do controlo razoável da AWS, incluindo problemas de internet para além da periferia da rede da AWS;
- ações ou omissões suas, como ignorar avisos de estado ou configurar mal os recursos;
- o seu próprio equipamento, software ou outra tecnologia;
- a suspensão ou cessação da sua utilização do serviço pela AWS, nos termos do contrato.
Duas outras coisas confundem-se muitas vezes com o SLA:
- Desempenho. Os SLA principais medem a disponibilidade (conectividade ou taxas de erro), não a latência nem o débito. Um serviço lento mas acessível não é, em regra, "indisponível".
- Tempos de resposta do suporte. Estão no seu plano AWS Support, não num SLA de serviço, e a AWS descreve-os como objetivos que "envidará todos os esforços razoáveis" para cumprir. Os planos atuais indicam, por exemplo, menos de uma hora para um caso de sistema de produção em baixo no Business Support+ e menos de 15 minutos para um caso de sistema crítico para o negócio em baixo no Enterprise Support. Não os cumprir não dá origem a créditos de serviço.
Porque é que a disponibilidade da sua aplicação é responsabilidade sua
O SLA diz-lhe o que a AWS promete para um serviço. Os seus utilizadores sentem a cadeia inteira: balanceador de carga, computação, base de dados, armazenamento, DNS e o seu próprio código. Se cada parte falhar de forma independente, a disponibilidade da cadeia é aproximadamente o produto das partes. Uma aplicação que precise de EC2 a 99,99% e de uma base de dados RDS Multi-AZ a 99,95% tem um teto esperado de cerca de 99,94% antes de contar o seu próprio código e as implementações.
Para ir além do que um único serviço oferece, desenhe a pensar na falha:
- execute a computação em pelo menos duas Zonas de Disponibilidade atrás de um balanceador de carga;
- use implementações Multi-AZ para as bases de dados;
- automatize a recuperação e teste-a, incluindo o restauro de cópias de segurança;
- para os sistemas mais críticos, considere uma segunda região com um plano de failover testado.
O pilar de Fiabilidade do AWS Well-Architected Framework aborda estes padrões em pormenor. O nosso guia sobre SLA de cloud em geral explica como comparar compromissos entre fornecedores, e o artigo sobre o SLA do Azure aborda o equivalente da Microsoft.
Exemplo: desenho multi-AZ na prática
Quando a Opsio migrou o grupo sueco de estâncias de esqui Branäsgruppen de VMware para a AWS, as aplicações críticas foram colocadas em várias Zonas de Disponibilidade, com escalamento automático e bases de dados geridas para suportar o tráfego da época alta. O caso reporta uma disponibilidade das aplicações superior a 99,9% e uma redução de 40% no custo total de propriedade após a migração.
SLA da AWS vs SLA de um fornecedor de serviços geridos
Um SLA da AWS abrange a plataforma. O SLA de um fornecedor de serviços geridos abrange o trabalho feito por cima dela: com que rapidez alguém responde a um alerta, quão depressa começa a corrigi-lo e que disponibilidade garante para o ambiente que opera. Os dois complementam-se. Por exemplo, o SLA padrão de serviços cloud geridos da Opsio inclui triagem em 15 minutos para alertas críticos e remediação ativa em 1 hora, com créditos de serviço se os tempos de resposta não forem cumpridos. Leia o pormenor do SLA de qualquer fornecedor, incluindo o nosso na página de SLA cloud da Opsio, da mesma forma que lê o da AWS: o que é medido, como e o que recebe quando não é cumprido.
Perguntas frequentes
Qual é a disponibilidade do SLA da AWS?
Depende do serviço. O EC2 compromete-se com 99,99% por região para instâncias em duas ou mais Zonas de Disponibilidade e 99,5% por instância isolada. O RDS Multi-AZ e o Lambda comprometem-se com 99,95%. Os créditos do S3 Standard começam quando a disponibilidade desce abaixo de 99,9%.
A AWS garante 100% de disponibilidade?
Não. Nenhum SLA de serviço da AWS promete 100%. O compromisso comum mais elevado é de 99,99%, o que ainda permite cerca de quatro minutos de indisponibilidade num mês de 30 dias. Uma disponibilidade superior tem de vir da sua própria arquitetura.
O que acontece se a AWS não cumprir o seu SLA?
Pode pedir um crédito de serviço de 10% a 100% dos encargos mensais do serviço afetado, consoante a queda da disponibilidade. Os créditos aplicam-se a faturas futuras, não são pagos em dinheiro e são o seu único remédio, salvo se o contrato dispuser em contrário.
De quanto tempo disponho para pedir um crédito de SLA à AWS?
No EC2 e no S3, a AWS tem de receber o seu pedido até ao final do segundo ciclo de faturação após o incidente. Submete-o como um caso no AWS Support Center, com a linha de assunto que o SLA especifica.
O tempo de resposta do AWS Support faz parte do SLA?
Não. Os tempos de resposta pertencem ao seu plano AWS Support e são descritos como objetivos. Os SLA de serviço abrangem apenas a disponibilidade, e só os SLA de serviço dão créditos.
Todos os serviços da AWS estão cobertos por um SLA?
A AWS afirma oferecer SLA para todos os serviços pagos e em disponibilidade geral. Os serviços em pré-visualização não estão cobertos e cada serviço tem as suas próprias condições, por isso verifique a página de SLA específica de cada serviço de que a sua aplicação depende.
Leitura relacionada
Escrito por

Diretor de Inovação
Jacob lidera a inovação na Opsio, especializando-se em transformação digital, IA, IoT e soluções impulsionadas pela cloud que convertem tecnologia complexa em valor empresarial mensurável. Com quase 15 anos de experiência, trabalha em estreita colaboração com os clientes para conceber soluções escaláveis de IA e IoT, otimizar processos de entrega e criar estratégias tecnológicas que impulsionam um crescimento sustentável e um impacto empresarial a longo prazo.
Normas editoriais: Este artigo foi escrito pelo profissional cloud indicado acima. Atualizamo-lo quando a tecnologia ou a regulamentação que aborda muda; as datas desta página indicam a última atualização. A Opsio mantém independência editorial.