Como otimizar seus custos do Amazon S3?

Você paga em custos de transferência de dados S3 S3
Você paga em custos de transferência de dados S3 S3.

Os Web Services (AWS) da Amazon e, em particular, o Simple Storage Service (S3) são amplamente usados por muitos indivíduos e empresas para gerenciar seus dados, sites e back-ends. Eles variam de indivíduos isolados e pequenas startups a empresas de avaliação de bilhões de dólares, como Pinterest e (anteriormente) Dropbox. Esta página não pretende ser um guia para a integração do S3; você pode encontrar muitos outros guias online. Em vez disso, destina-se a indivíduos e empresas cujos custos S3 esperados estão entre 7,50€ por mês e 7460€ por mês. Outras listas de dicas semelhantes estão disponíveis online.

Esta página também não aborda outros tipos de otimizações S3, como a otimização de nomes de bucket, pasta e arquivo e ordem de operação, com foco em maximizar o rendimento ou minimizar a latência. A maioria dessas otimizações não afeta os custos diretamente (positiva ou negativamente). Além disso, eles geralmente se tornam relevantes apenas em uma escala substancialmente maior do que a escala em que o público-alvo desta página provavelmente estará. Você pode ler mais sobre essas otimizações no guia oficial do S3 e em outros lugares.

Parte 1 de 6: obtendo um amplo entendimento de s3

  1. 1
    Entenda seu caso de uso do s3. S3 pode ser usado para muitos objetivos.
    • Como um local para armazenar arquivos para servir ao vivo em sites, incluindo arquivos de imagem ou um site estático inteiro (geralmente por trás de um CDN, como Amazon CloudFront ou CloudFlare).
    • Como um "data lake", um lugar para dados que você consome ou gera em seus aplicativos: essencialmente, o S3 se torna o armazenamento de longo prazo para seus dados, com os dados gerados inicialmente sendo registrados no S3 e vários aplicativos lendo do S3, transformando os dados e gravando de volta no S3.
    • Como um "data warehouse", um local para armazenar backups de longo prazo de dados estruturados e não estruturados, não destinados ao consumo ativo posterior.
    • Como um local para armazenar executáveis, scripts e configurações necessárias para iniciar novas instâncias EC2 com seus aplicativos (ou atualizar seus aplicativos em instâncias existentes).
  2. 2
    Entenda a principal maneira pela qual o s3 afeta os custos. Os números abaixo são para armazenamento padrão, advertências associadas a outras formas de armazenamento são discutidas mais tarde. Todos os custos são aplicados e relatados separadamente para cada balde e cada hora; em outras palavras, se você baixar seu relatório de faturamento detalhado, verá um item de linha para cada combinação de intervalo, hora e tipo de custo.
    • Custos de armazenamento: o custo é medido em espaço de armazenamento multiplicado pelo tempo. Você não paga adiantado por uma quantidade alocada de espaço de armazenamento. Em vez disso, cada vez que você usa mais armazenamento, paga a mais por esse armazenamento extra pela quantidade de tempo que o usa. Os custos podem, portanto, oscilar com o tempo, conforme a quantidade de dados armazenados é alterada. Os custos de armazenamento são relatados separadamente para cada intervalo a cada hora. O preço varia por região, mas é fixo dentro de cada região. Em março de 2020, o custo variava de 2,3 centavos por GB-mês no US Standard (North Virginia) a 4,05 centavos por GB-mês em São Paulo.
    • Preço de solicitação: para armazenamento padrão, o custo de solicitações PUT, COPY, POST ou LIST varia de 0€ por 1.000 solicitações nas regiões dos EUA a 0€ por 1.000 solicitações em São Paulo. O custo para GET e todas as outras solicitações é uma ordem de magnitude menor, variando de 0€ por 10.000 solicitações em todas as regiões dos EUA a 0€ por 10.000 solicitações em São Paulo. Observe, entretanto, que a maior parte do custo associado a uma solicitação GET é capturada nos custos de transferência de dados (se a solicitação for feita de fora da região). Observe também que, para dados armazenados em outros tipos de armazenamento, o preço de solicitação é um pouco mais alto. Outro tipo de solicitação que se torna relevante ao discutir as políticas de ciclo de vida é a solicitação de transição do ciclo de vida (por exemplo, fazer a transição de algo do armazenamento padrão para IA ou Glacier).
    • Custos de transferência de dados: os custos são zero na mesma região da AWS (ambas as instâncias S3 -> S3 e S3 -> EC2), cerca de 2 centavos por GB para transferência de dados entre regiões e cerca de 9 centavos por GB para transferência de dados para fora da AWS.
    • Preço de recuperação: não se aplica ao armazenamento padrão, mas sim a duas das outras classes de armazenamento, a saber, IA e Glacier. Este preço é aplicado por GB para os dados recuperados.
  3. 3
    Entenda o papel central desempenhado pelos baldes na organização de seus arquivos s3 e o uso de "objeto" para arquivos s3.
    • Você pode criar baldes em sua conta. Um balde é identificado por uma string (o nome do balde). Pode haver apenas um bucket com um determinado nome de bucket em todo o S3, entre os clientes; portanto, você pode não conseguir usar um nome de intervalo se outra pessoa já o usa.
    • Cada bucket é associado a uma região da AWS e é replicado em várias zonas de disponibilidade dentro dessa região. As informações da zona de disponibilidade não estão disponíveis para o usuário final, mas são um detalhe de implementação interno que ajuda o S3 a manter alta durabilidade e disponibilidade de dados.
    • Em cada depósito, você pode armazenar seus arquivos diretamente sob o depósito ou em pastas. As pastas não precisam ser criadas ou excluídas. Se você salvar um arquivo, ele automaticamente criará "pastas" para que o caminho do arquivo faça sentido, se ainda não existirem. Quando não houver arquivos sob ela, a pasta deixará de existir automaticamente.
    • A forma como o S3 armazena as informações é como um armazenamento de valores-chave: para cada prefixo que não seja um nome de arquivo, ele armazena o conjunto de arquivos e pastas com aquele prefixo. Para cada nome de arquivo, ele mapeia para o arquivo real. Em particular, arquivos diferentes em um intervalo podem ser armazenados em partes muito diferentes do data center.
    • O S3 chama seus arquivos de "objetos" e você pode encontrar esse termo ao ler sobre o S3 em outro lugar.
  4. 4
    Compreenda as diferentes maneiras de interagir com arquivos s3.
    • Você pode fazer upload e download de arquivos online, fazendo login através de um navegador.
    • As ferramentas de linha de comando baseadas em Python incluem a AWS Command Line Interface,, o antiquado s3cmd e o mais recente s4cmd.
    • Se estiver usando Java ou outra linguagem baseada na JVM (como Scala), você pode acessar objetos S3 usando o AWS Java SDK.
    • Ferramentas de implantação como Ansible e Chef oferecem módulos para gerenciar recursos S3.
  5. 5
    Entenda os prós e os contras de lidar com o s3 e suas diferenças em relação a um sistema de arquivos tradicional.
    • Com o S3, é necessário um pouco mais de ginástica (e tempo de execução) para obter uma imagem global da quantidade de dados usados em um balde ou nas subpastas desse balde. Isso ocorre porque esses dados não são registrados em nenhum lugar diretamente, mas precisam ser calculados por meio de pesquisas recursivas de valor-chave.
    • Encontrar todos os arquivos que correspondem a uma regex pode ser uma operação muito cara, especialmente quando essa regex inclui curingas no meio da expressão em vez de no final.
    • Não é possível realizar operações como anexar dados a um arquivo: você precisa obter o arquivo, modificá-lo e, em seguida, colocar todo o arquivo modificado de volta (consulte o ponto mais tarde sobre os recursos de sincronização).
    • Mover ou renomear arquivos envolve, na verdade, a exclusão de objetos e a criação de novos. Mover uma pasta envolve excluir e recriar todos os objetos dentro dela. Cada movimento de arquivo envolve uma chamada GET e uma PUT, levando a um aumento no preço da solicitação. Além disso, mover objetos pode ser caro se os objetos forem armazenados em classes de armazenamento (Standard-IA e Glacier) onde a recuperação custa dinheiro.
    • O S3 pode suportar tamanhos de arquivo de até 5 TB, mas a transferência de dados entre regiões pode começar a ficar complicada para tamanhos de arquivo de mais de algumas centenas de megabytes. A CLI usa upload de várias partes para arquivos grandes. Certifique-se de que, se seus programas lidam com arquivos grandes, eles operam por meio de upload de várias partes ou dividem a saída em arquivos menores.
    • S3 não oferece suporte completo para rsync. No entanto, há um comando de sincronização (aws s3 sync no AWS CLI e s3cmd sync no s3cmd) que sincroniza todo o conteúdo entre uma pasta local e uma pasta S3 ou entre duas pastas S3. Para arquivos que existem nas pastas de origem e de destino, ele pode detectar arquivos idênticos e evitar a transferência de dados se os arquivos forem idênticos; entretanto, não é tão eficiente quanto o rsync, pois pode precisar executar uma transferência completa se os arquivos diferirem um pouco, enquanto o rsync envia apenas uma pequena diferença para arquivos altamente semelhantes. A outra diferença com o rsync é que ele se aplica a uma pasta inteira e os nomes dos arquivos não podem ser alterados.
Pagará apenas uma vez pelos custos de transferência de dados
Se você replicar o intervalo no Leste dos EUA, pagará apenas uma vez pelos custos de transferência de dados.

Parte 2 de 6: compactação / compactação de dados

  1. 1
    Antes de começar, certifique-se de compactar os dados onde for permitido pelos requisitos de seu aplicativo.
    • Explore quais formas de compactação e compactação são compatíveis com os processos que você usa para gerar dados e os processos que usa para ler e processar dados.
    • Certifique-se de usar compactação e compactação para seus maiores despejos de dados, desde que não interfira em seu aplicativo. Em particular, logs de usuário brutos e dados estruturados com base na atividade do usuário são os principais candidatos para compactação.
    • Como regra geral, a compactação economizará não apenas nos custos de armazenamento, mas também nos custos de transferência (ao ler / gravar os dados) e pode até tornar seu aplicativo mais rápido se o tempo de upload / download for um gargalo maior do que o tempo de compactação / descompressão local. Frequentemente este é o caso.
    • Para dar um exemplo, a conversão de grandes arquivos de dados estruturados para o formato BZ2 pode fazer com que o espaço de armazenamento diminua por um fator que varia de 3 a 10; no entanto, o BZ2 exige muitos recursos de computação para compactar e descompactar. Outros algoritmos de compactação a serem considerados são gzip, lz4 e zstd.
    • Outras maneiras possíveis de reduzir o espaço incluem o uso de armazenamento baseado em coluna em vez de armazenamento baseado em linha e o uso de formatos binários (como AVRO) em vez de formatos legíveis (como JSON) para retenção de dados de longo prazo.
  2. 2
    Se a compactação de dados não for possível no ponto em que você os está gravando pela primeira vez, considere a execução de um processo alternativo para reinserir e compactar os dados. Esta é geralmente uma solução abaixo do ideal e muito raramente necessária, mas pode haver casos em que seja relevante. Se estiver procurando por uma solução desse tipo, você precisará executar os cálculos cuidadosamente com base no custo de reingestar e compactar os dados e no tempo total que pretende reter os dados.

Parte 3 de 6: otimização dos custos de armazenamento

  1. 1
    Compreenda as diferenças entre os quatro tipos de armazenamento S3.
    • O armazenamento padrão é o mais caro para armazenamento, mas é o mais barato e mais rápido para fazer alterações nos dados. Ele é projetado para durabilidade de 99,999999999% (mais de um ano, ou seja, esta é a fração esperada de objetos S3 que irão sobreviver ao longo de um ano) e disponibilidade de 99,99% (disponibilidade referindo-se à probabilidade de que um determinado objeto S3 seja acessível em um dado instante). Observe que, na prática, é muito raro perder dados no S3 e há fatores de risco maiores para a perda de dados do que o desaparecimento de dados do S3 (esses fatores maiores incluem exclusão acidental de dados e alguém invadindo sua conta de forma maliciosa para excluir conteúdo, ou até mesmo a Amazon sendo forçada a excluir seus dados por causa da pressão dos governos).
    • O armazenamento com redundância reduzida (RRS) costumava ser 20% mais barato do que o armazenamento padrão e oferece um pouco menos de redundância. Você pode querer usá-lo para muitos dos seus dados que não são altamente críticos (como registros completos do usuário). Isso é projetado para durabilidade de 99,99% e disponibilidade de 99,99%. No entanto, a partir de dezembro de 2016, as reduções de preço feitas para armazenamento padrão não foram acompanhadas por reduções de preço correspondentes para RRS, portanto, RRS é igual ou mais caro no momento.
    • Armazenamento padrão - Acesso infrequente (denominado S3 - IA) é uma opção lançada pela Amazon em setembro de 2015, que combina a alta durabilidade do S3 com uma baixa disponibilidade de apenas 99%. É uma opção para armazenar arquivos de longo prazo que não precisam ser acessados com frequência, mas que, quando precisam ser acessados, precisam ser acessados rapidamente. S3 - IA é cobrado por um mínimo de 30 dias (mesmo se os objetos forem excluídos antes disso) e um tamanho mínimo de objeto de 128 KB. Custa aproximadamente a metade do preço do S3, embora o desconto exato varie por região.
    • A geleira é a forma mais barata de armazenamento. No entanto, o Glacier custa dinheiro para desarquivar e disponibilizar novamente para leitura e gravação, com o valor que você precisa pagar dependendo do número de solicitações de recuperação, a velocidade com que você deseja que os dados sejam recuperados e o tamanho dos dados recuperados. Além disso, os arquivos do Glacier têm um período mínimo de armazenamento de 90 dias: os arquivos excluídos antes dessa data são cobrados pelo restante dos 90 dias após a exclusão.
  2. 2
    Tenha uma ideia de como seus custos estão crescendo.
    • Em um caso de uso em que você tem um conjunto fixo de arquivos que atualiza periodicamente (efetivamente removendo versões mais antigas), seus custos mensais de armazenamento são aproximadamente constantes, com um limite superior bastante restrito. Seu gasto cumulativo de armazenamento cresce linearmente. Este é um cenário típico para um conjunto de executáveis e scripts.
    • Em um caso de uso em que você está gerando novos dados continuamente a uma taxa constante, seus custos mensais de armazenamento aumentam linearmente. Seu custo de armazenamento cumulativo cresce quadraticamente.
    • Em um caso de uso em que a taxa de geração de dados em si está crescendo linearmente, seus custos mensais de armazenamento aumentam quadraticamente e seu custo cumulativo de armazenamento cresce continuamente.
    • Em um caso de uso onde a taxa de geração de dados está crescendo exponencialmente, tanto o seu custo de armazenamento de dados mensais e seu custo de armazenamento de dados cumulativos crescer exponencialmente bem.
  3. 3
    Explore se o controle de versão de objeto faz sentido para seus objetivos.
    • O controle de versão de objeto permite que você mantenha versões anteriores de um arquivo. Uma vantagem é que você pode revisitar uma versão mais antiga.
    • Ao usar o controle de versão de objeto, você pode combiná-lo com políticas de ciclo de vida para retirar versões anteriores a uma certa idade (se não a versão atual).
    • Se estiver usando o controle de versão de objeto, lembre-se de que apenas listar arquivos (usando aws s3 ls ou a interface online) fará com que você subestime o armazenamento total usado, porque você é cobrado por versões mais antigas que não estão incluídas na lista.
  4. 4
    Explore as políticas de ciclo de vida de seus dados.
    • Você pode definir políticas para excluir dados automaticamente em depósitos específicos, ou mesmo com prefixos específicos dentro de depósitos, com mais de um certo número de dias. Isso pode ajudá-lo a controlar melhor seus custos S3 e também a cumprir várias políticas de privacidade e dados. Observe que algumas leis e políticas de retenção de dados podem exigir que você mantenha os dados por um período mínimo; eles colocam um limite inferior no tempo após o qual você pode excluir dados em sua política de ciclo de vida. Outras políticas ou leis podem exigir que você exclua dados dentro de um determinado período de tempo; isso coloca um limite superior no tempo após o qual precisa excluir dados em sua política de ciclo de vida.
    • Com uma política de ciclo de vida para exclusão, a maneira como seus custos crescem muda muito. Agora, com um fluxo constante de dados recebidos, seus custos mensais de armazenamento permanecem constantes em vez de crescerem linearmente, já que você está armazenando apenas uma janela móvel de dados, em vez de todos os dados até agora. Mesmo que o tamanho dos dados recebidos cresça linearmente, seus custos mensais de armazenamento aumentam apenas linearmente, em vez de quadraticamente. Isso pode ajudá-lo a vincular seus custos de infraestrutura ao seu modelo de receita: se sua receita mensal for aproximadamente proporcional à taxa na qual você recebe os dados, seu modelo de armazenamento é escalável.
    • Uma limitação técnica: você não pode definir duas políticas com o mesmo intervalo, onde um prefixo é um subconjunto do outro. Lembre-se disso ao pensar em como armazenar seus dados S3.
    • Além das políticas de ciclo de vida para exclusão, você também pode definir políticas para arquivar os dados (ou seja, convertê-los do armazenamento padrão para Glacier), reduzindo os custos de armazenamento. No entanto, o Glacier tem um período mínimo de retenção de 90 dias: você é cobrado por 90 dias de armazenamento no Glacier, mesmo se optar por excluí-lo antes disso. Portanto, se você pretende excluir em breve, provavelmente não é uma boa ideia ir para o Glacier.
    • Você também pode ter uma política de ciclo de vida para converter dados em S3 (armazenamento padrão) para S3-IA. Essa política é ideal para dados que você espera que sejam acessados com frequência logo após sua criação, mas raramente depois disso. Os arquivos em IA têm um tamanho mínimo de objeto (você é cobrado por um tamanho de arquivo de 128 KB para arquivos menores do que isso) e um período mínimo de retenção de 30 dias.
    • Observe que as próprias transições do ciclo de vida custam dinheiro e, muitas vezes, é melhor criar objetos diretamente na classe de armazenamento desejada em vez de fazer a transição. Você precisará fazer os cálculos para o seu caso de uso para saber se e quando a transição do ciclo de vida faz sentido.
  5. 5
    Use a seguinte heurística para determinar a melhor classe de armazenamento com base em seu caso de uso. Enquanto falamos como se estivéssemos lidando com um único arquivo, estamos realmente pensando em uma configuração em que isso aconteça de forma separada e independente para um grande número de arquivos.
    • A primeira etapa para determinar a classe de armazenamento certa é obter uma estimativa para o tamanho do arquivo, período de retenção, número esperado de acessos (bem como como esse número varia ao longo do tempo com base na idade) e a quantidade máxima de tempo que você pode esperar quando você precisa acessar algo. Você pode usar todos esses como parâmetros em uma fórmula que calcula o custo esperado de uso de cada classe de armazenamento. A fórmula fica bastante complicada.
    • Observe que os limites exatos para eles podem variar com base nos preços atuais em sua região. Os preços variam de acordo com a região e mudam com o tempo. Em particular, o seguinte assunto: preço de armazenamento para cada classe de armazenamento, preço de solicitação para cada classe de armazenamento, preço de recuperação para cada classe de armazenamento e tamanho mínimo e requisitos de período mínimo de retenção. Com essas ressalvas, as heurísticas estão abaixo.
    • Se você pretende reter os dados por duas semanas ou menos, o armazenamento padrão é preferível tanto ao armazenamento IA quanto ao Glacier. A razão é que os períodos mínimos de retenção (30 dias para IA, 90 dias para Glacier) cancelam as vantagens de custo (no máximo o dobro para IA, cerca de seis vezes para Glacier) em duas semanas ou menos.
    • Se o tamanho do arquivo for 64 KB ou menos, o armazenamento padrão sempre superará o armazenamento IA. Isso ocorre porque o requisito de tamanho mínimo de IA (128 KB) cancela a vantagem de custo (no máximo o dobro).
    • Se você pretende acessar cada arquivo uma vez por mês ou com mais frequência, o armazenamento padrão ganha em relação ao IA e ao Glacier. Isso porque o custo extra de até mesmo uma recuperação de dados destrói a economia de armazenamento mensal.
    • Digamos que você tenha dados que precise inicialmente manter no armazenamento padrão por um mês, após o qual você está bem em movê-los para IA por um mês ou mais, pois espera não precisar acessá-los depois disso. Faz sentido movê-lo para IA apenas se o número total de megabytes-meses no estado de IA por arquivo for pelo menos 1. Isso porque o custo de transição do ciclo de vida da mudança para IA precisa ser superado pela economia de custos. Por exemplo, se você deseja manter os dados por mais um mês, o tamanho do arquivo deve ser de pelo menos 1 MB para que valha a pena gastar. Observe que o período mínimo de 30 dias torna as transições para períodos mais curtos ainda menos compensadores.
    • Da mesma forma, para a migração para o Glacier, o ponto de equilíbrio é de cerca de 2,5 megabytes-meses para cada arquivo. Observe, entretanto, que o período mínimo de retenção de 90 dias na geleira complica as coisas; se você pretende se beneficiar com a movimentação de dados para o Glacier por um mês, o tamanho do arquivo deve ser 7,5 MB ou mais.
    • Se você espera não precisar acessar o conteúdo depois de gravá-lo no S3, a estratégia ideal geralmente é padrão ou Glacier, com a compensação dependendo do período de retenção. No entanto, existe um ponto ideal entre onde IA é a melhor opção (por exemplo, armazenar 128 KB por um mês). Para ilustrar isso, abaixo está uma imagem para o caso simples em que você precisa manter um único arquivo de um tamanho por um período fixo de tempo, com zero acessos esperados após o armazenamento. O tempo em meses está no eixo horizontal e o tamanho do arquivo em GB está no eixo y. Um ponto é colorido em azul, vermelho ou amarelo, dependendo se a classe de armazenamento ideal de uma perspectiva de custo é padrão, IA ou Glacier. Usamos os custos como na região US Standard em dezembro de 2016.
    • Conforme você aumenta o número esperado de acessos aos dados, o padrão torna-se ideal para mais e mais casos de uso (ou seja, para tamanhos de dados maiores e para períodos de retenção mais longos). IA também começa a se tornar ideal nos casos em que o Glacier teria sido ideal anteriormente. Em outras palavras, o padrão assume o lugar de IA e o IA assume o lugar do Glacier.
  6. 6
    Use os seguintes benchmarks de bom senso com base em seu caso de uso de armazenamento. Isso ajudará você a ter uma noção de quanto esperar em custos de armazenamento.
    • Se você estiver exibindo ao vivo um site ou imagens estáticos: Os custos de armazenamento provavelmente serão de alguns centavos, com detalhes dependendo do tamanho do seu site. Os principais custos de servir um site ao vivo são os preços de solicitação e os custos de transferência.
    • Se você estiver armazenando um data lake com o fluxo principal gerado pelo usuário sendo atividade da web ou de aplicativo (ou seja, logs de solicitação da web): Uma linha de log de solicitação da web individual pode variar em tamanho máximo de 1 KB (se você mantiver todos os cabeçalhos e campos) a 10 KB (se você também incluir informações periféricas sobre o usuário e contexto). Se você recebe um milhão de solicitações da Web por mês e mantém registros de solicitações da Web antigos por um mês, isso se traduz em algo entre 1 GB e 10 GB de armazenamento, o que representa entre 2,3 centavos e 40,5 centavos de custo de armazenamento mensal. O custo é dimensionado linearmente com seu tráfego e com sua decisão sobre por quanto tempo armazenar. Por exemplo, com um bilhão de solicitações da web por mês e armazenamento de dados por um ano, seu custo mensal de armazenamento de dados dispara até algo entre 210€ e 3630€ Usar formatos binários e compactar / compactar pode reduzir ainda mais os custos.
    • Se você estiver armazenando arquivos de imagens e filmagens: Por exemplo, se você for uma rede de televisão que faz filmagens regularmente e deseja manter arquivos de filmagens antigas disponíveis para o caso de se tornarem relevantes mais tarde. Este é um caso de uso em que o espaço total para armazenamento pode ser bastante significativo. Por exemplo, com 10 horas de vídeo diário, você pode adicionar algo na faixa de 100 GB (descompactado) todos os dias. Se você colocar essa filmagem em armazenamento padrão no primeiro ano e, em seguida, arquivar no Glacier por mais nove anos, seus dados totais chegarão a 365 TB (36,5 TB em armazenamento padrão) e seus custos mensais de armazenamento S3 (antes da compressão) seria de cerca de 1640€ (dois terços para o Glacier, um terço para o armazenamento padrão). A compactação de vários tipos pode reduzir os custos de armazenamento por um fator que varia de 2 a 10.
    • É instrutivo olhar as contas de alguns usuários avançados do S3 para ter uma noção de quanto uma conta pode variar.
      • O Dropbox foi relatado como tendo 500 petabytes de dados no S3 antes de movê-lo para seus próprios servidores. A preços atuais cotados online, isso custaria cerca de 7,80 milhões de euros por mês. Embora o Dropbox provavelmente tenha obtido um desconto significativo e obtido benefícios com a desduplicação e compactação de dados, sua conta provavelmente ainda era de pelo menos centenas de milhares de dólares por mês.
      • Outro exemplo extremo de um grande usuário é o DigitalGlobe, que está movendo 100 PB de imagens de satélite de alta resolução para o S3.
      • O Pinterest informou que adiciona 20 terabytes de dados por dia, o que no armazenamento padrão significa que sua fatura mensal aumentaria 450€ / mês todos os dias. Se essa taxa de adição de dados continuar por dez anos, eles teriam armazenamento total de cerca de 75 PB e uma conta mensal da ordem de centenas de milhares de dólares.
      • Além desses casos de uso extremos, no entanto, até mesmo algumas das maiores empresas do mundo têm contas S3 razoavelmente baixas. Por exemplo, no final de 2013, o Airbnb relatou ter 50 TB de dados de fotos caseiras de alta resolução, um valor que custaria cerca de 860€ por mês aos preços de hoje.
Entenda o papel central desempenhado pelos baldes na organização de seus arquivos s3
Entenda o papel central desempenhado pelos baldes na organização de seus arquivos s3 e o uso de "objeto" para arquivos s3.

Parte 4 de 6: otimização dos custos de transferência de dados

  1. 1
    Se estiver usando s3 para conteúdo de exibição ao vivo, coloque-o atrás de um CDN, como amazon cloudfront, cloudflare ou maxcdn.
    • O CDN tem um grande número de pontos de presença em diferentes partes do mundo, geralmente variando de dezenas a centenas.
    • A solicitação do usuário para a página é roteada para o ponto de presença do CDN mais próximo. Esse ponto de presença verifica se há uma cópia atualizada do recurso. Caso contrário, ele o obtém no S3. Caso contrário, ele exibe a cópia que possui.
    • Resultado: os usuários finais veem maior disponibilidade e menor latência (já que os recursos são servidos de um local fisicamente próximo a eles) e o número de solicitações e a quantidade de transferência de dados do S3 são mantidos baixos. Explicitamente, o número de solicitações é limitado por (número de pontos de presença) X (número de arquivos) se você nunca estiver atualizando arquivos; se você estiver atualizando arquivos, também terá que multiplicar pelo número de atualizações de arquivo.
  2. 2
    Entenda a principal vantagem de co-localização de ec2 / s3. Se o seu uso principal para S3 é ler e gravar dados em instâncias EC2 (ou seja, qualquer um dos casos de uso que não seja a instância de serviço ao vivo), então esta vantagem é melhor aproveitada se o seu bucket S3 estiver localizado na mesma região AWS que o Instâncias EC2 que leem ou gravam nele. Isso terá várias vantagens:
    • Baixa latência (menos de um segundo)
    • Largura de banda alta (superior a 100 Mbit / segundo): observe que a largura de banda é realmente muito boa entre as diferentes regiões dos EUA, portanto, este não é um problema significativo se todas as suas regiões estão nos EUA, mas pode ser significativo entre os EUA e UE, UE e Ásia-Pacífico ou os EUA e Ásia-Pacífico.
    • Sem custos de transferência de dados (no entanto, você ainda paga o preço do pedido)
  3. 3
    Determine a localização (região AWS) de seu (s) bucket (s) s3.
    • Se você estiver executando instâncias EC2 que leem ou gravam nos depósitos S3: Conforme observado na Etapa 1, a colocação de S3 e EC2, na medida do possível, ajuda com os custos de largura de banda, latência e transferência de dados. Portanto, uma consideração importante ao localizar seu bucket S3 é: onde você espera ter as instâncias EC2 que irão interagir com este bucket S3? Se as instâncias do EC2 são, em sua maioria, instâncias de back-end, você deve considerar os custos dessas instâncias. Se forem instâncias de front-end, considere de quais regiões você espera obter a maior parte do tráfego. Em geral, você deve esperar que as considerações da instância EC2 sejam mais importantes do que as considerações S3 na determinação da região. Portanto, geralmente faz sentido primeiro decidir onde você espera que a capacidade da sua instância EC2 esteja e, em seguida, ter seus buckets S3 lá. Em geral,Os custos do S3 são mais baixos nas mesmas regiões que as instâncias do EC2, portanto, felizmente, isso não cria um conflito.
    • Se houver outros serviços da AWS que você deve ter, mas que não estão disponíveis em todas as regiões, isso também pode restringir sua escolha de região.
    • Se você costuma enviar arquivos de seu computador doméstico para o S3, pode considerar obter um balde em uma região mais próxima de sua casa, para melhorar a latência de upload. No entanto, esta deve ser uma consideração secundária em relação às outras.
    • Se você pretende usar S3 para imagens estáticas de exibição ao vivo, decida o local com base em onde você espera obter seu tráfego.
    • Em alguns casos, as políticas que você é obrigado a seguir com base na lei ou no contrato restringem sua escolha de região para armazenamento de dados S3. Além disso, lembre-se de que a localização física de seu bucket S3 pode afetar o que os governos são capazes de obrigar legalmente a Amazon a liberar seus dados (embora tais ocorrências sejam bastante raras).
  4. 4
    Investigue se a replicação entre regiões faz sentido para seu intervalo. A replicação entre regiões entre depósitos em diferentes regiões sincroniza automaticamente as atualizações de dados em um depósito com dados em outros depósitos. A mudança pode não acontecer imediatamente, e grandes mudanças em arquivos em particular são restringidas por limitações de largura de banda entre regiões. Lembre-se dos seguintes prós e contras da replicação entre regiões.
    • Você paga mais em custos de armazenamento S3, porque os mesmos dados são espelhados em várias regiões.
    • Você paga em custos de transferência de dados S3 <-> S3. No entanto, se os dados estiverem sendo lidos ou gravados por instâncias do EC2 em várias regiões, isso pode ser compensado pela economia nos custos de transferência de dados S3 -> EC2. A principal maneira pela qual isso pode ajudar é se você estiver carregando os mesmos dados S3 em instâncias EC2 em muitas regiões diferentes. Por exemplo, suponha que você tenha 100 instâncias em cada um no leste dos EUA e no oeste dos EUA, onde você precisa carregar os mesmos dados de um balde S3 no oeste dos EUA. Se você não replicar este depósito no Leste dos EUA, você pagará pelo custo de transferência das 100 transferências de dados do depósito S3 para as máquinas do Leste dos EUA. Se você replicar o intervalo no Leste dos EUA, pagará apenas uma vez pelos custos de transferência de dados.
    • A replicação entre regiões, portanto, faz muito sentido para executáveis, scripts e dados relativamente estáticos, onde você valoriza a redundância entre regiões, onde as atualizações dos dados são raras e onde a maior parte da transferência de dados ocorre no S3 -> EC2 direção. Outra vantagem é que, se esses dados forem replicados entre regiões, será muito mais rápido ativar novas instâncias, permitindo arquiteturas de instância EC2 mais flexíveis.
    • Para aplicativos de registro (onde os dados estão sendo lidos por muitas instâncias de front-end e precisam ser registrados em um local central no S3), é melhor usar um serviço como o Kinesis para agrupar fluxos de dados entre regiões em vez de usar buckets S3 replicados entre regiões.
    • Se você estiver usando o S3 para veiculação ao vivo de imagens estáticas em um site, a replicação entre regiões pode fazer sentido se o tráfego do seu site for global e o carregamento rápido de imagens for importante.
  5. 5
    Se estiver sincronizando atualizações regulares para arquivos já existentes, escolha uma estrutura de pastas que permita o uso do recurso de sincronização do AWS cli.
    • O comando "aws s3 sync" se comporta como rsync, mas só pode ser executado no nível de uma pasta. Portanto, mantenha sua estrutura de pastas de forma que você possa usar este comando.
  6. 6
    Lembre-se das seguintes heurísticas para estimar os custos de transferência.
    • Para um site estático de exibição ao vivo, a transferência mensal de dados, sem CDN, é igual ao tamanho do tráfego total de cada página visitada (incluindo imagens e outros recursos carregados na página). Por exemplo, para um milhão de visualizações de página e um tamanho médio de página de 100 KB, o total de dados de saída é de 100 GB, custando 6,70€ por mês.
    • Para um site estático de serviço ao vivo por trás de um CDN, o CDN impõe um limite superior na transferência total de dados. Especificamente, se você não atualizar os dados de forma alguma, para que o CDN sirva seu próprio cache, a transferência total de dados será limitada pelo produto do tamanho total do seu site e pelo número de pontos de presença do CDN, independentemente do tráfego volume. Por exemplo, se o seu site tiver um total de 1000 páginas de 100 KB cada, o tamanho total será 100 MB. Se houver 100 pontos de presença, isso dará um limite total de transferência de dados de 10 GB por mês ou um limite de custo de 90 centavos por mês. No entanto, se você atualizar alguns dos arquivos, terá que contar cada arquivo novamente após cada atualização.
    • Até que ponto os CDNs economizam em relação a não ter CDN depende da diversidade de acesso ao seu conteúdo e também da distribuição geográfica do acesso. Se o seu conteúdo for acessado em uma região geográfica, você economizará mais. Se as pessoas acessarem um pequeno número de páginas em seu site, você economizará mais. Se, em cada região, as pessoas acessarem um pequeno número de páginas em seu site (mesmo que as páginas sejam diferentes por região), você economizará mais. A economia de CDN pode variar de 50% a 99%.

Parte 5 de 6: otimização de custos devido à solicitação de preços

  1. 1
    Se o preço da solicitação for uma preocupação significativa, mantenha seus dados no armazenamento padrão. Consulte a Parte 3, Etapa 5 para obter mais informações.
  2. 2
    Se estiver exibindo ao vivo um site estático ou imagens ou vídeo estáticos por meio do s3, coloque-o atrás de um CDN. Isso é pelos mesmos motivos discutidos na Parte 4, Etapa 1.
  3. 3
    Se estiver usando s3 como um armazenamento de dados para pesquisa de valor-chave, você precisa negociar o preço da solicitação PUT com o preço de transferência de dados ao determinar os tamanhos dos arquivos nos quais você precisa fragmentar seus dados.
    • Se você particionar os dados em um grande número de arquivos pequenos, precisará de um grande número de PUTs para inserir os dados, mas cada pesquisa é mais rápida e usa menos transferência de dados, pois você precisa ler um arquivo menor do S3.
    • Por outro lado, se você particionar os dados em um pequeno número de arquivos grandes, precisará de um pequeno número de PUTs, mas cada acesso custa muito em custo de transferência de dados (já que você precisa ler um arquivo grande).
    • A compensação geralmente acontece em algum lugar no meio. Matematicamente, o número de arquivos que você deve usar é a raiz quadrada da proporção de um termo de custo de transferência de dados para um termo de custo PUT.
  4. 4
    Em geral, usar um número menor de arquivos de tamanho médio é melhor para um data lake.
  5. 5
    Se você estiver subdividindo dados entre arquivos, use um pequeno número de arquivos de tamanho médio (algo entre 1 MB e 100 MB) para minimizar a sobrecarga e o preço da solicitação.
    • Um número menor de arquivos maiores reduz o número de solicitações necessárias para recuperar e carregar os dados, bem como para gravar os dados.
    • Uma vez que há uma pequena quantidade de latência associada a cada arquivo lido, os processos de computação distribuída (como os processos baseados em Hadoop ou Apache Spark) que os arquivos lidos geralmente prosseguem mais rápido com um pequeno número de arquivos de tamanho médio do que com um número de pequenos arquivos.
    • Quanto menor for o número geral de arquivos, menos caro será a execução de consultas que tentam corresponder a expressões regulares arbitrárias.
    • Uma advertência importante é que, em muitos casos, o tipo de saída natural é um grande número de arquivos pequenos. Isso é verdadeiro para as saídas de cargas de trabalho de computação distribuída, em que cada nó no cluster calcula e gera um pequeno arquivo. Também é verdade se os dados estão sendo gravados em tempo real e queremos gravar os dados em um curto intervalo de tempo. Se você espera ler e processar esses dados repetidamente, considere uni-los em arquivos maiores. Além disso, para dados que chegam em tempo real, considere o uso de serviços de streaming, como Kinesis, para agrupar os dados antes de gravá-los no S3.
  6. 6
    Se você observar grandes custos de solicitação inesperados, procure processos invasores que estão fazendo correspondência de regex. Certifique-se de que qualquer correspondência de regex usa curingas o mais próximo possível do final do arquivo.
  7. 7
    Lembre-se das seguintes heurísticas para custos de solicitação.
    • Os custos de solicitação devem estar entre 0% e 20% dos custos de armazenamento. Se eles forem maiores, considere se você está usando a classe de armazenamento certa, fragmentando os dados nos tamanhos certos ou executando operações desnecessárias ou ineficientes. Verifique também se há transições de ciclo de vida desnecessárias, bem como processos de correspondência de regex desonestos.
    • Os custos de solicitações devem ser menores do que os custos de transferência se seus dados forem enviados principalmente para fora da AWS (se seus dados estiverem sendo enviados dentro da mesma região da AWS, não deve haver custos de transferência de dados, portanto, isso não se aplica, pois os custos de solicitação serão positivo, enquanto os custos de transferência serão zero).
Você pode desejar relatar uma divisão de seus custos entre armazenamento
No nível mais alto, você pode desejar relatar uma divisão de seus custos entre armazenamento, transferência e solicitar preços.

Parte 6 de 6: monitoramento e depuração

  1. 1
    Configure o monitoramento para seus custos de s3.
    • Sua conta da AWS tem acesso aos dados de faturamento que fornecem o detalhamento completo dos custos. Configure um alerta de cobrança para que os dados comecem a ser enviados para o Amazon CloudWatch. Você pode então configurar mais alertas usando CloudWatch. Os dados do CloudWatch chegam como pontos de dados a cada poucas horas, mas não incluem uma análise detalhada ao longo de todas as dimensões de interesse.
    • A qualquer momento, você pode baixar o detalhamento por hora e tipo de serviço de sua conta root. Esses dados geralmente estão 24 a 48 horas atrasados, ou seja, você não verá as informações das 24 a 48 horas mais recentes. Para o S3, você pode baixar em uma planilha ou formato CSV os dados com detalhamento por hora, intervalo, região e tipo de operação (GET, POST, LIST, PUT, DELETE, HEADOBJECT ou quaisquer que sejam suas operações).
  2. 2
    Escreva scripts para fornecer relatórios diários fáceis de ler sobre seus custos discriminados de várias maneiras.
    • No nível mais alto, você pode desejar relatar uma divisão de seus custos entre armazenamento, transferência e solicitar preços.
    • Em cada um deles, você pode querer dividir ainda mais os custos com base na classe de armazenamento (Standard, RRS, IA e Glacier).
    • Na precificação de solicitação, você pode querer dividir os custos pelo tipo de operação (GET, POST, LIST, PUT, DELETE, HEADOBJECT ou quaisquer que sejam suas operações).
    • Você também pode fornecer uma divisão por segmento.
    • Como regra geral, você precisa decidir o número de dimensões que detalha, trocando a facilidade de entendimento rápido por granularidade suficiente. Em geral, uma boa compensação é incluir detalhamentos ao longo de uma dimensão de cada vez (por exemplo, um detalhamento por balde, um detalhamento por armazenamento vs. transferência vs. solicitação de preços, um detalhamento por classe de armazenamento) em seu relatório diário e aprofundar mais apenas se algo parece fora do comum.
  3. 3
    Construa um modelo de custo esperado e use seu script para identificar discrepâncias entre os custos reais e seu modelo.
    • Sem um modelo de quais deveriam ser os custos, é difícil dar uma olhada nos custos e saber se eles estão errados.
    • O processo de construção de um modelo de custo é um bom exercício para articular claramente sua arquitetura e potencialmente pensar em melhorias, mesmo sem olhar para o padrão de custos reais.
  4. 4
    Depure altos custos.
    • Se o culpado forem os custos de armazenamento, consulte a Parte 3.
    • Se o culpado são os enormes custos de transferência de dados, consulte a Parte 4.
    • Se o culpado for o preço da solicitação, consulte a Parte 5.
Os principais custos de servir um site ao vivo são os preços de solicitação
Os principais custos de servir um site ao vivo são os preços de solicitação e os custos de transferência.

Pontas

  • Acompanhe seus custos do Amazon S3. Você não pode otimizar o que você não mede. Uma das maiores vantagens do S3 é que você não precisa pensar muito sobre o armazenamento de arquivos: você tem um armazenamento de arquivos efetivamente ilimitado que não está vinculado a uma instância específica. Isso oferece muita flexibilidade, mas, por outro lado, também significa que você pode perder o controle de quantos dados está usando e quanto estão custando. Você deve revisar periodicamente seus custos S3 e também configurar Alertas de faturamento AWS no Amazon CloudWatch para alertá-lo quando os custos S3 de um determinado mês excederem um limite.
  • Não use o Amazon S3 para nenhuma operação que requeira latências de menos de um segundo. Você pode usar o S3 para iniciar instâncias que executam tais operações ou para atualizações periódicas dos dados e configurações nessas instâncias, mas não confie nos GETs do arquivo S3 para operações em que você precisa responder em milissegundos. Se estiver usando o S3 para registro, armazene as atividades localmente em sua instância de front-end (ou grave-as em um stream como o Kinesis) e depois registre-as periodicamente no S3.
  • Não use o S3 para aplicativos que envolvem leitura e gravação frequentes de dados. O Amazon S3 é mais adequado para registro de dados de médio e longo prazo do que como um lugar para armazenar e atualizar e consultar dados rapidamente. Considere o uso de bancos de dados (e outros armazenamentos de dados) para atualizar os dados rapidamente. Uma coisa importante a lembrar com o S3 é que a consistência imediata de leitura / gravação não é garantida: pode levar alguns segundos após uma gravação para que a leitura busque o arquivo recém-gravado. Além disso, você também verá uma fatura enorme se tentar usá-lo dessa forma, porque o preço da solicitação fica muito alto se você usar o S3 dessa forma.

Aviso Legal O conteúdo deste artigo é para sua informação geral e não se destina a ser um substituto para consultoria jurídica profissional ou financeira. Além disso, não se destina a ser invocado pelos usuários na tomada de quaisquer decisões de investimento.
Artigos relacionados
  1. Como iniciar uma lista de registro de presentes no destino?
  2. Como excluir uma conta Groupon no Android?
  3. Como rastrear um pedido no Groupon no Android?
  4. Como se tornar um membro do Bloomspot?
  5. Como criar uma vitrine na Amazon?
  6. Como vender DVDs na Amazon?
Este site usa cookies para analisar o tráfego e para personalização de anúncios. Ao continuar a navegar neste site, você indica que aceita o uso de cookies. Para mais informações visite nossa Política de Privacidade.
FacebookTwitterInstagramPinterestLinkedInGoogle+YoutubeRedditDribbbleBehanceGithubCodePenWhatsappEmail