AWS Migration

Uma viso alm de bits and bytes

Giovani Dardani

20/08/2016

Antes de qualquer coisa ...

Sem jab

Sem pretenses

Compartilhar experincia

To the cloud!

Deciso difcil Mudana de cultura

Authentication, Authorization and Accounting

(Access|Secret Access) Key

Dificuldade de gerenciamento

Alternativa

"(Access|Secret Access) Key"

Esse o metodo mais comum utilizado para fornecer acessos a pessoas e aplicacoes

"Dificuldade de gerenciamento"

Ressaltar dificuldade de auditoria e gerenciamento Tenha cuidado, principalmente aplicacoes que se utilizam desse tipo de acesso Resaltar a importancia de nao commitar ker/secret_key com codigo

"Alternativas" Mostrar IAM role como substituto para keys/secret_keys Polycies IAM so bastante flexvies e so bastante teis para controles de acess

Location, location, location

Existem vrias "Regions" disponiveis e basicamente todas disponibilizam os mesmos servicosPreos mudam muito de uma region para outra, sa-east-1 (Sao Paulo) e a mais cara delas

Servios que nao sofrem impactos com alta-latencia devem rodar em regioes mais baratas, isso reduz bastante o custooperacional de um ambiente

Servicos que demandam baixo tempo de resposta podem se valer de servicos de CDNs ou mesmo ter uma arquiteturaque permita a execucao em multiplas regioes (Front-end mais proximo do cliente e back-end em uma regiao com customais baixo)

Tags

Visibilidade

Gerenciamento

Controle de custos

Tags so amigas e devem sem utilizadas sem moderaoOrganizao e acima de tudo facilita a estimativa de custos por produtos/celulas/departamentos e etc

Clen up de recursos nao taggeados pode ser agressivo mas pode apresentar uma economia considervel

NAT

Default GW private networks

NAT gateway X NAT instance

Ponto nico de falha

"Default GW private networks" GW ou Nat possibilitam que instancias contidas em redes privadas possam se conectar com a internet sem a necessidade de um EIP

"NAT gateway X NAT instance" NAT gateway um servico oferecido pela AWS enquanto um "NAT Instance" nada mais do do que uma instancia EC2 com regras de firewall para o roteamento adequado das conexoes

Preferencia pelo NAT Gateway, o mesmo gerenciado pela AWS e j oferece HA por definio e demanda pouca ou nenhuma manutencao

"Ponto nico de falha"

Servio muito critico, tem capacidade de tirar seu ambiente fora do ar (lembrar que tds as mquinas em redes privadas usam esse NAT) Lembrar do incidente onde uma inst. NAT falhou e forou o autoscale a instalar mquinas por conta da falha no health-check das instancias

Subnets

Reside em apenas uma AZ

Especializao de subnets

Acls

"Reside em apenas uma AZ" Uma subnet existe dentro de uma AZ apenas, subnets que residem em AZs diferentes dependem de roteamento para se falarem

"Especializao de subnets" Especialize as subnets de uma forma que cada uma delas tenham "papeis" especficos. Diferenciar subnets que iro conter bancos de dados e aplicacoes facilita a administracao

"Acls" Promovem mais uma nvel de controle de acessos alm do tradicional security group. Feche completamente os acessos e libere estritamente necessrias. Acls de subnet so stateless, sendo assim, temos que gerenciar regras de entrada e saida Tome cuidado com acls muito especficas pelo fato de o nmero total de acls por subnet ser limi

AMI/Snapshot

Recurso bastente til

There's no such thing as a free lunch

Dados sensveis

"Recurso bastente til" Bastante empregado para "backups" e ponto de partida com AMIs customizadas

"There's no such thing as a free lunch Assim como qq outro servio, AMIs e Snapshots sao cobrados. Implementar politica de remoo de recursos nao mais utilizados. Manter somente o necessrio ajuda a manter os custos dentro de um range aceitvel

"Dados sensveis" Geralmente criamos AMIs/Snapshots a partir de instancias que j esto rodando. Essas intancias possuem dados sensiveis como senhas de banco de dados configurados em aplicacoes, Certificados e chaves SSL, chaves SSH e at msm chaves AWS

Se por acidente tornarmos uma dessas AMIs publicas, podemos ter graves incidentes de seguranca

Reserved Instances

Reserved Instances Dedicated Instances

Ideal para recursos 24x7

Diversos planos

Exige planejamento

"Reserved Instances Dedicated Instances" A reserva de instancias se relaciona ao custo de uma instancia EC2 ou RDS e nada tem ver com hardware/recurso dedicado

"Ideal para recursos 24x7" Reserved instances muito indicado para recursos que iro ficar online em regime 24x7, exemplos dissoso instancias RDSs e EC2

"Diversos planos" Existem alguns planos disponiveis e os mais agressivos sao os que apresentam maior grau de economia. PLanos de longo prazo (3 anos) podem prover at 75% de economia

"Exige planejamento" necessrio ter certeza da utilizacao do recurso antes de realizar a aquisio. Msm existindo a possibilidade de venda de uma Reserved Instance muito importante termos garantia de que iremos utilizar o recurso pelo tempo contratado

Spot Instances

Mais economia

Preo oscila de acordo com oferta/demanda

Exige flexibilidade do seu servio

"Mais economia"

Outro recursos muito que gera muita economia com instancias EC2

"Preo oscila de acordo com oferta/demanda"

O valor/hora varia de acordo com o tipo de instancia e tambm a AZ. Esse valor definido pela EC2 e muda de acordo com oferta e demanda

"Exige flexibilidade do seu servio"

Uma Spot instance pode nao ser iniciada imediatamente, sendo assim noa deve ser aplicadas servio que possuem picos de consumo ou que devam escalar de forma gil. Muito bom para ser usada com instancias empregadas em ambiens de DEV/QA, batch Jobs, workers ou servicos que toleram algum dowmtime.

o "problema" que instancia Spot nao podem ser instaladas dentro de stacks Opswors

Instncias Time-based

Desligue recursos no necessrios

Ambientes de DEV/QA

"Desligue recursos no necessrios" Recursos que nao so utilizados em regime 24x7 podem ser desligados quando necessrio. Para facilitar essa tarefa podemos configurar instancias Time Based que ser]ao ligadas e desligados em intervalos especficos de tempo

"Ambientes de DEV/QA" Ambientes dessa natureza geralmente devem funcionar em horario comercial salvo algumas excees. Sendo assim eles so exemplos perfeitos de ambientes que podem e devem se utilizar desse recurso

Automao

Recurso mandatrio

Treat Your Servers Like Cattle, Not Like Pets

Sei que pode-se "sobreviver sem automao mas em um ambiente to voltil automao uma obrigao e no um "sonho".Treat Your Servers Like Cattle, Not Like Pets

Lambrar da apresent. de Chef do Du! Dizer que chef minha opao tambm e mensionar o OPsWo

S3

Big data sets

Cold files

Bucket policy

A facilidade de utilizao do servio pode nos colocar em uma situao complicada.Analisar td a massa de dados antes de empurrar esse contedo para um bucket S3!! POrque? Inbound traffic de uma region nao tarifada, td o trafico de saida custa $$ Requests para as APis tb custam $$

"Cold files" (arquivos que nao sero utilizados dentro de um curto perdo de tempo) devem utilizar outros tipos de servios de storages. Infrequent Access Storage e Glacier so bons condidatos tem um alto tempo para restore!!!

Bucket Policy

Facilita a autorizao de acessos buckets

RDS

RDS > EC2 + SGBD

MultiAZ

Snapshots

De preferncia ao servios de RDS ao invs de SGBD instalado em instancia EC2

MultiAZ mais do que recomendado.

Lembrar dificuldade por conta da nao possibilidade de acesso SSH para manuteno de bancos

Snapshots peridicos (tomar cuidado porque isso tb custa $$ e pode "sair de controle")

Cloudformation

KISS Keep it simples, stupid

Acesso restrito

Version Control

"KISS" Keep it simples stupid! Recurso muito valioso mas que tem uma enorme capacidade para se tornor complexo caso utilizado de forma equivocada

"Acesso restrito" Restrinja o acesso apenas algumas pessoas e tenha certeza que elas e somente elas possam atualizar suas stacks. IAM policies podem fazer esse controle de forma bastante satisfatria

"Version Control" Versione seus template CFN em um repositrio onde seja fcil o tracking de modificaes e que facilite o rollback caso necessario

** Lembrar do problema que tivemos com CFN - OpsWorks

Mtricas

Mudana drstica

Tenha mtricas!

Reclamaes VO acontecer

Antes vs Depois

A migrao para um servio de cloud bastante significativa e com ctz vai trazer muitas mudanas para o seu ambiente.

Mtricas pr e ps migrao sero extremamente teis/necessrias uma vez que o seus servios iro se comportar de maneira diferenteaps a migrao e inevitavelmente reclamacoes do tipo "o site est lento" ou "funcionava bem antes de vcs mecherem" vo acontecer com ctz.

Otimizao de Recursos

Passada a tormenta

CPU, IO, Network e etc

Containers, Orchestration, Microservices e Configuration management

Passada a tormenta da migracao iremos notar certa "ociosidade" de recursos, isso acontece e natural.Otimizacao de recursos (CPU, IO, NetWork e etc) deve estar no nosso radar.Ttecnologias como containers, Orchestration e micro-servicesdevem ser analisados.

Dvidas e/ou sugestes?

Obrigado

@gdardani

giovanidardani@gmail.com

br.linkedin.com/in/gdardani