Artigos on Fabio Lopes

Automatizando a Previsão de Capacidade do Ceph com Grafana Mimir

Wed, 17 Sep 2025 00:00:00 +0000

Contexto e decisões na época

Nossa equipe precisava com urgência das informações geradas para o processo de aquisição de hardware, então construí o que era essencial e coloquei em funcionamento o mais rápido possível. Como não sou especialista em análises, um colega forneceu a lógica e inicialmente tudo foi desenvolvido em um Jupyter Notebook, sendo depois migrado para um ambiente com agendamento e acesso direto ao Mimir.

As decisões foram orientadas por essa necessidade: integrar coleta, tratamento, projeção e comunicação em um único fluxo; usar uma projeção simples e compreensível para apoiar o planejamento; e entregar os gráficos e resumos no Teams, sem depender de preparação manual a cada execução. Os modelos mais sofisticados e as demais evoluções ficaram para depois da entrega mais urgente.

Introdução

O planejamento de capacidade para clusters de armazenamento distribuído é um desafio constante, especialmente em ambientes onde o crescimento rápido de dados pode se transformar rapidamente em riscos de capacidade ou em cenários de aquisições urgentes. No SERPRO, desenvolvi uma solução baseada em Python que automatiza a coleta de métricas de uso do Ceph a partir do Grafana Mimir, analisa tendências históricas de utilização, aplica correção de outliers e projeta o consumo previsto até um ano à frente para múltiplos sites e classes de dispositivos. O sistema não apenas visualiza o uso da capacidade com tendências dinâmicas, robustas a outliers, e indicadores de limite, mas também gera blocos concisos de resumo — automaticamente postados em canais do Microsoft Teams em Adaptive Cards estruturados. Ao integrar ciência de dados com comunicação fluida entre equipes, esse fluxo oferece insights acionáveis que ajudam o time a atuar de forma proativa na gestão da previsão de capacidade de armazenamento.

O que foi feito

O objetivo principal deste projeto é automatizar a previsão de capacidade para clusters de armazenamento Ceph, integrando recuperação, processamento, visualização e relatórios em um único fluxo de trabalho Python. O processo começa consultando o Grafana Mimir via sua API Prometheus para buscar métricas históricas e recentes de bytes brutos e usados, segmentados por classes de dispositivos e sites (neste caso, São Paulo e Brasília). O fluxo utiliza consultas PromQL estruturadas para coletar não só o uso de armazenamento, mas também a classificação dos dispositivos, para uma análise mais detalhada.

Após a coleta, os dados brutos são mesclados em um DataFrame unificado do pandas. A abordagem lida com lacunas e valores ausentes por interpolação diária, garantindo que a série temporal necessária para análise estatística e plotagem permaneça contínua e regularizada. O tratamento de outliers consiste no cálculo dos deltas diários e aplicação de um filtro baseado no desvio padrão móvel. Saltos repentinos e anômalos no uso diário, provavelmente causados por falhas temporárias ou eventos excepcionais, são substituídos pela mediana do delta diário, assegurando que as tendências de longo prazo não sejam distorcidas por artefatos momentâneos.

A previsão é realizada com um método simples e robusto: o sistema projeta o crescimento do uso para frente usando o aumento diário mediano histórico, assumindo crescimento linear para os próximos 365 dias. Isso se alinha às necessidades práticas do planejamento de capacidade, onde tendências rápidas e compreensíveis têm prioridade sobre modelos complexos e excessivamente ajustados.

Para cada dimensão (site e classe de dispositivo), o script gera gráficos de previsão utilizando matplotlib e seaborn, sobrepondo uso atual, projeções e limiares coloridos (75%, 85% e 100% da capacidade disponível) para melhor clareza visual. Juntamente com os gráficos, o fluxo prepara um resumo textual contendo métricas-chave como datas previstas de saturação, taxas de crescimento e tempos estimados para atingir limites críticos.

Por fim, todo o conteúdo é organizado e enviado ao Microsoft Teams via webhook, utilizando Adaptive Cards para dashboards estruturados e legíveis de forma inline. A automação garante que esses insights estejam sempre atualizados e disponíveis para stakeholders, sem necessidade de intervenção manual ou pipelines separados de relatórios.

Tratamento dos Dados e Abordagem de Previsão

A fase de tratamento dos dados é fundamental para garantir que as previsões de uso sejam confiáveis e robustas. As métricas brutas recuperadas do Grafana Mimir geralmente contêm ruídos, valores ausentes e outliers ocasionais — picos ou quedas irregulares que não representam padrões típicos de uso, mas podem distorcer a análise de tendências se não corrigidos.

Para mitigar isso, o fluxo primeiro alinha as séries temporais reamostrando para frequência diária e preenche quaisquer pontos faltantes via interpolação linear. Isso garante uma linha do tempo contínua, essencial para cálculos estatísticos consistentes e modelagem de regressão.

O tratamento dos outliers foca nos incrementos diários de uso (a diferença entre dias consecutivos). O script calcula esses deltas para métricas de uso e aplica uma verificação estatística utilizando o desvio padrão móvel para identificar saltos anormais. Valores que ultrapassam essa faixa são considerados outliers e substituídos pela mediana dos deltas calculada a partir dos dados não anômalos. Esse método suaviza flutuações erráticas preservando a tendência subjacente de crescimento.

Ao corrigir os outliers no nível do delta, e não diretamente nos valores brutos, o modelo mantém a consistência cumulativa da métrica. Os deltas corrigidos são somados cumulativamente para reconstruir uma série temporal de uso corrigida. Essa abordagem mitiga efetivamente distorções causadas por pontos anômalos sem eliminar os sinais reais de crescimento.

Para a previsão, os incrementos históricos corrigidos são usados para projetar o crescimento futuro de forma linear ao longo de um horizonte definido (365 dias). O delta diário mediano serve como uma estimativa estável e robusta do aumento esperado de uso por dia. Embora existam modelos mais sofisticados, esse método combina simplicidade e praticidade, fornecendo resultados facilmente interpretáveis e úteis para o planejamento de capacidade. Evita o risco de sobreajuste que pode ocorrer com modelos complexos aplicados a dados operacionais reais ruidosos.

No geral, essa combinação de interpolação cuidadosa, correção estatística de outliers e previsão linear baseada em mediana cria uma base sólida para compreender e antecipar as tendências de consumo do Ceph com complexidade computacional mínima e alta transparência.

O Código

forecast.pypython · 412 linhasBaixar


 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412


import os
import io
import json
import base64
import logging
import urllib3
import requests
import pandas
from datetime import datetime, timedelta, timezone
import seaborn as sns
import matplotlib.pyplot as plt
import matplotlib.dates as mdates
import matplotlib.ticker as ticker

output_dir = '/srv/scripts'
TiB = 1099511627776 # Is this really necessary?

logging.basicConfig(
 level=logging.INFO,
 format='%(asctime)s - %(levelname)s - %(message)s',
 filename=os.path.join(output_dir,'capacidade-forecast.log'),
 filemode='w'
)
logger = logging.getLogger(__name__)
logger.info(f"-----Inicio-----")

## 1. Query Configuration
logger.info("1. Configuração da Query")
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

url = "https://mimir-endpoint/prometheus/api/v1/query_range"
headers = {
 'X-Scope-OrgID': 'anonymous'
}

queries = {
 "Capacidade SPO": "sum by (device_class) (ceph_osd_stat_bytes{site='spo'} + on(site,ceph_daemon) group_left(device_class) (0*ceph_osd_metadata{site='spo'}))",
 "Capacidade BSA": "sum by (device_class) (ceph_osd_stat_bytes{site='bsa'} + on(site,ceph_daemon) group_left(device_class) (0*ceph_osd_metadata{site='bsa'}))",
 "Uso SPO": "sum by (device_class) ((ceph_osd_stat_bytes_used{site='spo'}) + on(site,ceph_daemon) group_left(device_class) (0*ceph_osd_metadata{site='spo'}))",
 "Uso BSA": "sum by (device_class) ((ceph_osd_stat_bytes_used{site='bsa'}) + on(site,ceph_daemon) group_left(device_class) (0*ceph_osd_metadata{site='bsa'}))"
}

current_utc = datetime.now(timezone.utc)
end_date = (current_utc).replace(hour=0, minute=0, second=0, microsecond=0)
start_date = datetime(2024, 9, 27, 0, 0, 0) # No data prior to this date

params_template = {
 "start": start_date.strftime("%Y-%m-%dT%H:%M:%SZ"),
 "end": end_date.strftime("%Y-%m-%dT%H:%M:%SZ"),
 "step": "1d"
}

## 2. Query Execution
logger.info("2. Execução da Query")
dataframe = pandas.DataFrame()

for query_name, query in queries.items():
 params = params_template.copy()
 params["query"] = query
 response = requests.get(url, params=params, headers=headers, verify=False)
 try:
 response.raise_for_status()
 mimir_data = response.json()['data']['result']
 if not mimir_data:
 logger.error(f"No data returned for query: {query_name}")
 continue
 for result in mimir_data:
 if 'device_class' not in result['metric']:
 continue
 device_class = result['metric']['device_class']
 temp_df = pandas.DataFrame(result['values'], columns=['timestamp', f'{query_name} {device_class}'])
 temp_df['timestamp'] = pandas.to_datetime(temp_df['timestamp'], unit='s')
 if dataframe.empty:
 dataframe = temp_df
 else:
 dataframe = pandas.merge(dataframe, temp_df, on='timestamp', how='outer')
 except requests.exceptions.HTTPError as err:
 logger.error(f"HTTP error for query '{query_name}': {err}\nResponse body: {response.text}")
 except KeyError:
 logger.error(f"Unexpected response format for query '{query_name}': {response.json()}")

# Save as CSV
#output_file = 'device_data.csv'
#dataframe.to_csv(output_file, index=False)

## 3. Treat the Data
logger.info("3. Tratamento dos Dados")
# Define the index
dataframe = dataframe.rename(columns={'timestamp': 'Time'})
dataframe.set_index('Time', inplace=True)

# Convert values to numeric
numeric_columns = dataframe.columns.drop('Time') if 'Time' in dataframe.columns else dataframe.columns
for col in numeric_columns:
 dataframe[col] = pandas.to_numeric(dataframe[col], errors='coerce')

# Interpolate missing values
dataframe = dataframe.resample('D').interpolate(method='linear')
dataframe.reset_index(inplace=True)

## Treat the Outliers
cols_uso = [col for col in dataframe.columns if col.startswith('Uso')]
std_dev = {}
medianas = {}

# Calculate Delta and Standard Deviation
for col in cols_uso:
 _, site, device_class = col.split(' ')
 delta_col = f'Delta {site} {device_class}'
 delta_corrigido_col = f'Delta Corrigido {site} {device_class}'
 uso_corrigido_col = f'Uso Corrigido {site} {device_class}'
 
 # Calculate Delta
 dataframe[delta_col] = dataframe[col].diff()
 
 # Calculate Standard Deviation
 std_dev = dataframe[delta_col].iloc[1:].std()
 logger.debug(f"Desvio Padrão {site} {device_class}: {std_dev/TiB:.2f} TiB")
 
 # Apply the outlier correction
 dataframe[delta_corrigido_col] = dataframe[delta_col].where(
 (abs(dataframe[delta_col]) <= std_dev) | (dataframe.index == dataframe.index[0]), 0
 )
 
 # Calculate the delta median without the outliers
 medianas[col] = dataframe[delta_corrigido_col].iloc[1:].median()
 
 # Fill zero/empty values with the median
 dataframe[delta_corrigido_col] = dataframe[delta_corrigido_col].where(
 (dataframe[delta_corrigido_col] != 0) | (dataframe.index == dataframe.index[0]), 
 medianas[col]
 )

# Calculate Corrected raw usage
cols_delta = [col for col in dataframe.columns if col.startswith('Delta Corrigido')]
for col in cols_delta:
 _, _, site, device_class = col.split()
 uso_col = f"Uso {site} {device_class}"
 corrigido_col = f"Uso Corrigido {site} {device_class}"
 
 # Initialize the 'Corrected Usage' column with the first value from the 'Usage' column
 dataframe[corrigido_col] = dataframe[uso_col].iloc[0]
 
 # Calculate the cumulative sum of the corrected delta, starting from the second row
 dataframe.loc[1:, corrigido_col] += dataframe.loc[1:, col].cumsum()

# Drop unecessary columns
cols_drop = [col for col in dataframe.columns if col.startswith('Delta')]
dataframe = dataframe.drop(columns=cols_drop)

# Save to .csv
# output_file = 'device_data.csv'
# dataframe.to_csv(os.path.join(output_dir, output_file), index=False)


## 4. Calculation of the Linear Regression
logger.info("4. Cálculo da Regressão Linear")
# Gerar o Horizonte da Previsão
ultima_coleta = dataframe['Time'].max()
data_inicial = ultima_coleta.replace(hour=0, minute=0, second=0, microsecond=0) + timedelta(days=1)
forecast_horizonte = 365
forecast_datas = pandas.date_range(start=data_inicial, periods=forecast_horizonte)
forecast_df = pandas.DataFrame({'Time': forecast_datas})

# Generate Forecasts
for col in cols_uso:
 _, site, device_class = col.split(' ')
 forecast = [dataframe[col].iloc[-1]]
 for _ in range(1, forecast_horizonte):
 forecast.append(forecast[-1] + medianas[col]) 
 column_name = f"{site}_{device_class}"
 forecast_df[column_name] = forecast

forecast_df.tail()

## 5. Generate the Summary
logger.info(f"5. Geração do Resumo")
results = {}
summary_text = ""
current_date = datetime.now().replace(hour=0, minute=0, second=0, microsecond=0)

for col in cols_uso:
 _, site, device_class = col.split(' ')
 forecast_col = f"{site}_{device_class}"
 
 # Obtain the Capacity and calculate the Rate
 capacidade = dataframe[f'Capacidade {site} {device_class}'].iloc[-1] * 0.75 / TiB
 uso_atual = dataframe[col].iloc[-1] / TiB
 uso_final = forecast_df[forecast_col].iloc[-1] / TiB
 taxa = (uso_final - uso_atual) / forecast_horizonte 
 
 # Check the Threshold
 threshold_mask = (forecast_df[forecast_col] / TiB) >= capacidade
 if threshold_mask.any():
 threshold_date = forecast_df.loc[threshold_mask, 'Time'].min().strftime('%d-%m-%Y')
 else:
 threshold_date = "Limite não atingido no período"
 
 # Calculate remaining Days
 days_remaining = abs((capacidade - uso_atual) / taxa)
 years, months, days = int(days_remaining // 365), int((days_remaining % 365) // 30.42), round((days_remaining % 365) % 30.42)
 doomsday = (dataframe['Time'].iloc[-1] + timedelta(days=days_remaining)).strftime('%d-%m-%Y')
 doomsday_f = (f"{years} anos, {months} meses e {days} dias")
 
 # Generate the Summary
 summary_text += f"""
Resumo {site} {device_class}:
Capacidade (75%): {capacidade:.2f} TiB
Uso em 31/12/2025: {uso_final:.2f} TiB
Taxa de crescimento diária: {taxa:.2f} TiB/dia
Quando atinge 75%: {doomsday}
Tempo até atingir 75%: {doomsday_f}
"""

## 6. Generate the Graphs
logger.info("6. Geração dos Gráficos")
# Obter Sites e Classes
sites = set()
device_classes = set()

for col in dataframe.columns:
 if col.startswith('Uso'):
 parts = col.split()
 sites.add(parts[1])
 device_classes.add(parts[2])

# Generate the Plots
plots = {}
for site in sites:
 for device_class in device_classes:
 try:
 # Verify the columns
 uso_col = f'Uso {site} {device_class}'
 uso_corrigido_col = f'Uso Corrigido {site} {device_class}'
 capacidade_col = f'Capacidade {site} {device_class}'
 forecast_col = f'{site}_{device_class}'
 
 if not all(col in dataframe.columns for col in [uso_col, uso_corrigido_col, capacidade_col]):
 continue

 if forecast_col not in forecast_df.columns:
 continue

 plt.figure(figsize=(12, 6))

 # Plot Lines
 sns.lineplot(x=dataframe['Time'], y=dataframe[uso_col]/TiB,
 label='Uso Bruto', linewidth=1.5, color='purple')
 sns.lineplot(x=forecast_df['Time'], y=forecast_df[forecast_col]/TiB,
 label='Previsão', linestyle='--', linewidth=2, color='navy')

 # Plot Thresholds
 capacity_tib = dataframe[capacidade_col].iloc[-1]/TiB
 limits = [
 (capacity_tib * 0.75, '75%', 'gold'),
 (capacity_tib * 0.85, '85%', 'darkorange'),
 (capacity_tib, '100%', 'crimson')
 ] 
 for value, label, color in limits:
 plt.axhline(y=value, color=color, linestyle='-.',
 linewidth=1.5, alpha=0.8, label=label)

 # Format
 plt.gca().xaxis.set_major_locator(mdates.MonthLocator())
 plt.gca().xaxis.set_major_formatter(mdates.DateFormatter('%Y-%m'))
 plt.xticks(rotation=45, ha='right')
 plt.gca().yaxis.set_major_formatter(ticker.FuncFormatter(lambda x, _: f'{x:,.1f} TiB'))
 plt.gca().yaxis.set_major_locator(ticker.MaxNLocator(10))
 plt.title(f'Previsão Ceph {site} - Classe {device_class.upper()}', fontsize=16, pad=20)
 plt.xlabel('Data', fontsize=12, labelpad=10)
 plt.ylabel(f'Uso {device_class.upper()} (TiB)', fontsize=12, labelpad=10)
 plt.grid(True, linestyle='--', alpha=0.6)

 # Configure Subtitles
 handles, labels = plt.gca().get_legend_handles_labels()
 order = [0, 1, 2, 3, 4]
 plt.legend([handles[idx] for idx in order], [labels[idx] for idx in order], 
 loc='upper left', frameon=True, shadow=True, fontsize=12)
 plt.tight_layout()
 
 # Save Graphs
 buffer = io.BytesIO()
 plt.savefig(buffer, format='png', dpi=100, bbox_inches='tight')
 buffer.seek(0)
 plots[f'{site}_{device_class}'] = base64.b64encode(buffer.getvalue()).decode('utf-8')
 buffer.close()
 plt.close()
 
 except Exception as e:
 print(f"Error generating plot for {site} {device_class}: {str(e)}")
 plt.close()

## 7. Send to Teams
logger.info(f"7. Envio para o Teams")
# Create the message
def create_teams_message(summary_data, plots):
 cards = []
 sections = parse_summary_text(summary_data)
 
 for site in ['SPO', 'BSA']:
 card = {
 "type": "message",
 "attachments": [{
 "contentType": "application/vnd.microsoft.card.adaptive",
 "content": {
 "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
 "type": "AdaptiveCard",
 "version": "1.2",
 "body": [
 {
 "type": "TextBlock",
 "text": "São Paulo" if site == "SPO" else "Brasília",
 "weight": "Bolder",
 "size": "Large",
 "color": "Accent"
 },
 *create_device_sections(sections.get(site, {}))
 ]
 }
 }]
 }
 
 # Add site-specific plots
 site_plots = {k: v for k, v in plots.items() if k.lower().startswith(site.lower())}
 for plot_name, plot_data in site_plots.items():
 image_block = {
 "type": "Image",
 "url": f"data:image/png;base64,{plot_data}",
 "size": "auto"
 }
 card['attachments'][0]['content']['body'].append(image_block)
 
 cards.append(card)
 
 return [json.dumps(card) for card in cards]

# Convert the Summary Text
def parse_summary_text(text):
 sections = {}
 current_section = None
 for line in text.split('\n'):
 line = line.strip()
 if not line:
 continue
 if line.startswith('Resumo'):
 parts = line.replace('Resumo ', '').replace(':', '').split()
 site = parts[0]
 device_class = parts[1]
 if site not in sections:
 sections[site] = {}
 current_section = sections[site].setdefault(device_class, {}) 
 elif line and current_section is not None:
 key_value = line.split(':')
 if len(key_value) == 2:
 key = key_value[0].strip()
 value = key_value[1].strip()
 current_section[key] = value 
 return sections

# Create the Sections
def create_device_sections(devices):
 sections = []
 for device_class, data in devices.items():
 section = {
 "type": "Container",
 "style": "emphasis",
 "items": [
 {
 "type": "TextBlock",
 "text": f"Classe {device_class.upper()}",
 "weight": "Bolder",
 "size": "Small"
 },
 {
 "type": "FactSet",
 "facts": [
 {"title": "Capacidade (75%):", "value": data.get('Capacidade (75%)', 'N/A')},
 {"title": "Uso em 31/12/2025:", "value": data.get('Uso em 31/12/2025', 'N/A')},
 {"title": "Taxa de crescimento:", "value": data.get('Taxa de crescimento diária', 'N/A')},
 {"title": "Quando atinge 75%:", "value": data.get('Quando atinge 75%', 'N/A')},
 {"title": "Tempo até atingir 75%:", "value": data.get('Tempo até atingir 75%', 'N/A')}
 ]
 }
 ]
 }
 sections.append(section)
 return sections
 
# Send to Teams
def send_to_teams(payloads):
 # Chat Capacidade
 WEBHOOK_URL = "https://corp.webhook.office.com/webhookb2/id"

 PROXIES = {'https': 'http://proxy:3128'}
 headers = {'Content-Type': 'application/json'}
 statuses = []
 for payload in payloads:
 response = requests.post(
 WEBHOOK_URL,
 data=payload,
 headers=headers,
 proxies=PROXIES,
 verify=False
 )
 statuses.append(response.status_code)
 
 return statuses

# Create and send the message
messages = create_teams_message(summary_text, plots)
status = send_to_teams(messages)
logger.info(f"-----Fim-----")

Melhorias Futuras

Modelos de Previsão Avançados: Em vez de uma extrapolação linear com medianas, incorporar métodos de séries temporais como ARIMA, Prophet, ou modelos de machine learning para capturar sazonalidade, tendências e padrões não lineares com maior precisão;
Processamento em Tempo Real ou Próximo disso: Adaptar a coleta e previsão para suportar atualizações frequentes (ex.: horárias), permitindo reações mais rápidas a variações repentinas ou falhas;
Detecção de Anomalias e Alertas: Integrar métodos automáticos para identificar picos inesperados ou degradações, combinados com alertas proativos em Teams ou outros canais para notificar imediatamente as equipes;
Parâmetros de Limite Configuráveis: Permitir ajuste dinâmico dos limiares (75%, 85%, 100%) via arquivos de configuração ou variáveis de ambiente, aumentando a flexibilidade para diferentes ambientes ou políticas;
Visualizações Melhoradas: Incluir intervalos de confiança nas previsões, dashboards interativos com Plotly Dash ou painéis Grafana, e suporte a cenários múltiplos de longo prazo (ex.: otimista, pessimista);
Melhorias de Segurança e Autenticação: Proteger chamadas de API com autenticação adequada (tokens OAuth, certificados) e gerenciar com segurança URLs de webhook e credenciais de proxy;
Extensibilidade para Outras Métricas: Generalizar o pipeline para incorporar indicadores adicionais de saúde e performance do Ceph (latência, IOPS, status de recuperação) para dashboards mais completos de capacidade e saúde do cluster.

Guia Exaustivo para o Exame AWS Certified Solutions Architect – Professional (SAP-C02)

Tue, 15 Jul 2025 00:00:00 +0000

Guia Exaustivo para o Exame AWS Certified Solutions Architect – Professional (SAP-C02)

Este documento tem como objetivo fornecer um guia completo e detalhado para o exame AWS Certified Solutions Architect – Professional (SAP-C02), cobrindo todos os tópicos e subdomínios conforme o guia oficial da AWS. O conteúdo será estruturado para facilitar o estudo, a consulta rápida e a compreensão aprofundada dos conceitos necessários para a certificação.

Domínios do Exame e Pesos

O exame SAP-C02 é dividido em quatro domínios principais, cada um com um peso específico no conteúdo avaliado:

Domínio 1: Design de Soluções para Complexidade Organizacional (26% do conteúdo)
Domínio 2: Design para Novas Soluções (29% do conteúdo)
Domínio 3: Melhoria Contínua para Soluções Existentes (25% do conteúdo)
Domínio 4: Acelerar a Migração e Modernização de Workloads (20% do conteúdo)

Domínio 1: Design de Soluções para Complexidade Organizacional

Este domínio foca na capacidade de projetar soluções que abordem os desafios de ambientes complexos e em larga escala, incluindo estratégias de rede, segurança, governança e gerenciamento de contas.

Tópicos e Subtópicos:

1.1. Arquitetar estratégias de conectividade de rede.

Conhecimento de:
- Infraestrutura Global da AWS
- Conceitos de rede AWS (por exemplo, Amazon Virtual Private Cloud [Amazon VPC], AWS Direct Connect, AWS VPN, roteamento transitivo, serviços de contêiner AWS)
- Conceitos de DNS híbrido (por exemplo, Amazon Route 53 Resolver, integração de DNS on-premises)
- Segmentação de rede (por exemplo, sub-redes, endereçamento IP, conectividade entre VPCs)
- Monitoramento de tráfego de rede

1.2. Arquitetar estratégias de segurança para ambientes complexos.

Conhecimento de:
- AWS Organizations e Unidades Organizacionais (OUs)
- Service Control Policies (SCPs)
- AWS Identity and Access Management (IAM) avançado (por exemplo, permission boundaries, ABAC, roles cross-account)
- AWS Security Hub, Amazon GuardDuty, Amazon Detective, AWS Config, AWS Inspector
- Gerenciamento de chaves (por exemplo, AWS Key Management Service [AWS KMS] multi-região)
- Segurança de dados (por exemplo, criptografia em trânsito e em repouso, tokenização, mascaramento de dados)
- Gerenciamento de segredos (por exemplo, AWS Secrets Manager)
- Auditoria e log (por exemplo, AWS CloudTrail, Amazon CloudWatch Logs)
- Princípio do menor privilégio

1.3. Arquitetar estratégias de governança e conformidade.

Conhecimento de:
- AWS Control Tower
- AWS Config e Conformance Packs
- AWS Audit Manager
- AWS License Manager
- AWS Systems Manager
- AWS Resource Access Manager (AWS RAM)
- AWS Service Catalog
- AWS Organizations e gerenciamento de contas
- Tags e políticas de tagging

1.4. Arquitetar estratégias de gerenciamento de contas e multi-contas.

Conhecimento de:
- AWS Organizations e OUs
- AWS Control Tower
- AWS Single Sign-On (AWS SSO)
- AWS IAM Identity Center
- Landing Zones
- AWS Resource Access Manager (AWS RAM)
- Compartilhamento de recursos entre contas
- Faturamento consolidado

Domínio 2: Design para Novas Soluções

Este domínio aborda a capacidade de projetar novas soluções na AWS, focando na escolha de serviços, padrões de arquitetura, resiliência, escalabilidade e otimização de performance.

Tópicos e Subtópicos:

2.1. Arquitetar soluções de computação.

Conhecimento de:
- Amazon EC2 (por exemplo, instâncias spot/mixed fleets, Auto Scaling)
- AWS Lambda
- Containers (por exemplo, Amazon Elastic Container Service [Amazon ECS], Amazon Elastic Kubernetes Service [Amazon EKS], AWS Fargate)
- AWS Outposts
- AWS Wavelength
- AWS Local Zones
- AWS Batch
- AWS ParallelCluster
- AWS Serverless Application Model (AWS SAM)
- AWS Amplify

2.2. Arquitetar soluções de armazenamento.

Conhecimento de:
- Amazon S3 (por exemplo, classes de armazenamento, pontos de acesso, políticas de ciclo de vida)
- Amazon Elastic File System (Amazon EFS)
- Amazon FSx (por exemplo, FSx for Lustre, FSx for Windows File Server, FSx for NetApp ONTAP)
- Amazon Elastic Block Store (Amazon EBS)
- AWS Backup
- Amazon Glacier
- AWS Storage Gateway
- AWS Snow Family

2.3. Arquitetar soluções de banco de dados.

Conhecimento de:
- Amazon Relational Database Service (Amazon RDS)
- Amazon Aurora
- Amazon DynamoDB
- Amazon DocumentDB (com compatibilidade MongoDB)
- Amazon Neptune
- Amazon Redshift
- Amazon ElastiCache
- Amazon Quantum Ledger Database (Amazon QLDB)
- Amazon Managed Blockchain
- Amazon Keyspaces (para Apache Cassandra)
- Amazon Timestream
- Amazon Kinesis
- AWS Database Migration Service (AWS DMS)
- AWS Schema Conversion Tool (AWS SCT)

2.4. Arquitetar soluções de rede.

Conhecimento de:
- Amazon VPC (por exemplo, sub-redes, tabelas de rotas, gateways de internet, gateways NAT, endpoints de VPC)
- AWS Transit Gateway
- AWS PrivateLink
- VPC Peering
- AWS Direct Connect
- AWS VPN
- Amazon Route 53 (por exemplo, DNS multi-região, políticas de roteamento)
- Amazon CloudFront (por exemplo, URLs assinadas, cookies assinados, geo-restrições)
- AWS Global Accelerator
- AWS App Mesh
- AWS Cloud Map
- VPC Lattice

2.5. Arquitetar soluções de mensageria e integração.

Conhecimento de:
- Amazon Simple Notification Service (Amazon SNS)
- Amazon Simple Queue Service (Amazon SQS)
- Amazon EventBridge
- AWS Step Functions
- Amazon Kinesis (por exemplo, Kinesis Data Streams, Kinesis Data Firehose, Kinesis Data Analytics)
- Amazon Managed Streaming for Apache Kafka (Amazon MSK)
- AWS AppSync
- Amazon API Gateway
- AWS IoT Core

Domínio 3: Melhoria Contínua para Soluções Existentes

Este domínio concentra-se na otimização e aprimoramento de arquiteturas existentes para melhorar a performance, resiliência, segurança e eficiência operacional.

Tópicos e Subtópicos:

3.1. Arquitetar soluções para alta disponibilidade e resiliência.

Conhecimento de:
- Estratégias de recuperação de desastres (por exemplo, RTO, RPO, padrões de DR: backup e restauração, piloto leve, multi-site ativo-ativo)
- AWS Well-Architected Framework (Pilar de Confiabilidade)
- Amazon Route 53 (por exemplo, failover, roteamento baseado em latência)
- AWS Global Accelerator
- Elastic Load Balancing (ELB)
- Amazon EC2 Auto Scaling
- Amazon CloudFront
- AWS Shield, AWS WAF
- Circuit Breaker pattern
- Sagas pattern

3.2. Arquitetar soluções para otimização de performance.

Conhecimento de:
- AWS Well-Architected Framework (Pilar de Performance Efficiency)
- Otimização de computação (por exemplo, escolha de instâncias, otimização de containers, Lambda provisioned concurrency)
- Otimização de armazenamento (por exemplo, escolha de classes de S3, otimização de EBS, EFS, FSx)
- Otimização de banco de dados (por exemplo, escolha de tipo de DB, otimização de consultas, caching com ElastiCache)
- Otimização de rede (por exemplo, Direct Connect, Global Accelerator, CloudFront)
- Caching (por exemplo, Amazon CloudFront, Amazon ElastiCache, AWS Global Accelerator)
- Content Delivery Networks (CDNs)

3.3. Arquitetar soluções para monitoramento e observabilidade.

Conhecimento de:
- Amazon CloudWatch (por exemplo, métricas, logs, alarmes, dashboards)
- AWS X-Ray
- AWS CloudTrail
- AWS Config
- Amazon Kinesis (para ingestão de logs e métricas)
- AWS Systems Manager (por exemplo, OpsCenter, Explorer)
- AWS Health Dashboard
- AWS Trusted Advisor
- Feature flags com CloudWatch Evidently

3.4. Arquitetar soluções para segurança contínua.

Conhecimento de:
- AWS Security Hub, Amazon GuardDuty, Amazon Detective, AWS Inspector
- AWS WAF, AWS Shield
- AWS Firewall Manager
- AWS Certificate Manager (ACM)
- AWS Secrets Manager
- AWS Systems Manager Parameter Store
- AWS Single Sign-On (AWS SSO) / AWS IAM Identity Center
- Princípio do menor privilégio
- Automação de segurança (por exemplo, AWS Security Hub, AWS Config Rules)

Domínio 4: Acelerar a Migração e Modernização de Workloads

Este domínio aborda as estratégias e ferramentas para migrar e modernizar workloads para a AWS, incluindo a avaliação, planejamento e execução de migrações complexas.

Tópicos e Subtópicos:

4.1. Arquitetar estratégias de migração.

Conhecimento de:
- Estratégias de migração (por exemplo, 7 Rs: Rehost, Replatform, Refactor/Re-architect, Repurchase, Retain, Retire, Relocate)
- AWS Migration Acceleration Program (MAP)
- AWS Application Migration Service (AWS MGN)
- AWS Database Migration Service (AWS DMS)
- AWS Schema Conversion Tool (AWS SCT)
- AWS DataSync
- AWS Snow Family
- AWS Transfer Family
- AWS Direct Connect
- AWS VPN
- AWS CloudEndure Migration

4.2. Arquitetar estratégias de modernização.

Conhecimento de:
- Modernização de aplicações (por exemplo, microsserviços, serverless, containers)
- Refatoração de código
- Uso de serviços gerenciados (por exemplo, Amazon RDS, Amazon DynamoDB, AWS Lambda)
- Integração de serviços (por exemplo, Amazon EventBridge, AWS Step Functions)
- Padrões de modernização (por exemplo, Strangler Fig, Branch by Abstraction)
- Ferramentas de modernização (por exemplo, AWS Migration Hub Refactor Spaces, AWS App2Container)

4.3. Arquitetar estratégias de otimização de custos.

Conhecimento de:
- AWS Well-Architected Framework (Pilar de Otimização de Custos)
- Modelos de precificação da AWS (por exemplo, On-Demand, Reserved Instances [RIs], Savings Plans, Spot Instances)
- Otimização de recursos (por exemplo, dimensionamento correto, desligamento de recursos ociosos)
- AWS Cost Explorer, AWS Budgets, AWS Cost Anomaly Detection
- AWS Compute Optimizer
- AWS Trusted Advisor (Otimização de Custos)
- Políticas de ciclo de vida do Amazon S3
- Otimização de rede (por exemplo, uso de CloudFront, Direct Connect)

Novidades Relevantes (Exemplos)

IAM Roles Anywhere
VPC Lattice
CloudFront Signed URLs
Feature flags com CloudWatch Evidently

Tabelas Comparativas e Cenários Práticos

Esta seção será preenchida com tabelas comparativas detalhadas, exemplos de cenários práticos que caem na prova, decisões arquiteturais e armadilhas comuns, consolidando o aprendizado e facilitando a consulta rápida.

Este documento será continuamente expandido e detalhado em cada um dos tópicos e subtópicos listados, fornecendo um guia completo para a preparação do exame SAP-C02.

1.1. Arquitetar estratégias de conectividade de rede.

Conceitos Fundamentais e Avançados

A conectividade de rede em um ambiente AWS complexo é a espinha dorsal de qualquer arquitetura bem-sucedida. Ela abrange desde a conectividade básica dentro de uma VPC até topologias de rede híbridas e globais. O exame SAP-C02 espera que o candidato tenha um profundo conhecimento sobre como projetar, proteger e otimizar essas conexões.

Infraestrutura Global da AWS: A AWS possui uma infraestrutura global composta por Regiões, Zonas de Disponibilidade (AZs), Local Zones, Wavelength Zones e Pontos de Presença (PoPs). Compreender como esses componentes se interligam é fundamental. As Regiões são geograficamente isoladas, enquanto as AZs dentro de uma Região são conectadas com baixa latência. Local Zones e Wavelength Zones estendem os serviços da AWS para mais perto dos usuários finais ou de dispositivos 5G, respectivamente, para aplicações de latência ultrabaixa.

Amazon VPC: A VPC é o bloco de construção fundamental para a rede na AWS. Permite provisionar uma seção logicamente isolada da Nuvem AWS, onde você pode lançar recursos da AWS em uma rede virtual que você define. Você tem controle total sobre seu ambiente de rede virtual, incluindo a seleção de seu próprio intervalo de endereços IP, criação de sub-redes e configuração de tabelas de rotas e gateways de rede.

Conectividade Híbrida: A conectividade híbrida refere-se à conexão de sua rede on-premises com a sua VPC na AWS. As duas principais opções para isso são:

AWS Direct Connect (DX): Fornece uma conexão de rede privada e dedicada de seu data center para a AWS. O Direct Connect pode reduzir os custos de rede, aumentar a largura de banda e fornecer uma experiência de rede mais consistente do que as conexões baseadas na Internet.
AWS Site-to-Site VPN: Cria uma conexão segura entre sua rede on-premises e suas VPCs. As conexões VPN são estabelecidas através da Internet pública e são criptografadas com IPsec.

Roteamento Transitivo: Em uma topologia de rede complexa com múltiplas VPCs e conexões on-premises, o roteamento transitivo torna-se essencial. O AWS Transit Gateway (TGW) é um serviço gerenciado que atua como um hub central para conectar suas VPCs e redes on-premises. Ele simplifica a topologia de rede, eliminando a necessidade de conexões de emparelhamento de VPC (VPC Peering) complexas e full-mesh.

DNS Híbrido: O Amazon Route 53 Resolver permite a resolução de DNS bidirecional entre suas redes on-premises e a AWS. Você pode criar endpoints do Route 53 Resolver em suas VPCs que encaminham consultas de DNS de seus sistemas on-premises para o Route 53 e vice-versa. Isso é crucial para que os aplicativos em ambos os ambientes possam se comunicar usando nomes de domínio familiares.

Segmentação de Rede: A segmentação de rede é uma prática de segurança fundamental que envolve a divisão de uma rede em sub-redes menores e isoladas. Na AWS, isso é alcançado através do uso de VPCs, sub-redes, Network Access Control Lists (NACLs) e Security Groups. A segmentação ajuda a conter o impacto de uma violação de segurança e a aplicar políticas de segurança granulares.

Monitoramento de Tráfego de Rede: Para garantir a segurança e a performance de sua rede, é essencial monitorar o tráfego. A AWS oferece várias ferramentas para isso, incluindo:

VPC Flow Logs: Captura informações sobre o tráfego IP que entra e sai das interfaces de rede em sua VPC.
AWS CloudTrail: Registra todas as chamadas de API feitas em sua conta, incluindo as relacionadas a alterações na configuração da rede.
Amazon CloudWatch: Coleta e monitora métricas de rede de vários serviços da AWS, permitindo que você crie alarmes e dashboards.

Comparações entre Serviços e Quando Usar Cada Um

AWS Transit Gateway vs. VPC Peering:

VPC Peering: É uma conexão de rede entre duas VPCs que permite que elas se comuniquem como se estivessem na mesma rede. O VPC Peering é ideal para um número pequeno de VPCs. No entanto, ele não suporta roteamento transitivo (ou seja, se a VPC A está emparelhada com a VPC B e a VPC B está emparelhada com a VPC C, a VPC A não pode se comunicar com a VPC C através da VPC B). Isso leva a uma topologia de malha complexa à medida que o número de VPCs aumenta.
AWS Transit Gateway: Atua como um hub central que conecta múltiplas VPCs e redes on-premises. Ele simplifica o gerenciamento da rede, pois cada VPC só precisa se conectar ao Transit Gateway. O TGW suporta roteamento transitivo e é a solução recomendada para arquiteturas com um grande número de VPCs.

AWS Direct Connect vs. AWS Site-to-Site VPN:

AWS Site-to-Site VPN: É uma solução rápida e de baixo custo para estabelecer uma conexão segura entre sua rede on-premises e a AWS. No entanto, como a conexão é feita pela Internet pública, a performance pode ser inconsistente.
AWS Direct Connect: Oferece uma conexão privada e dedicada com alta largura de banda e performance consistente. É a escolha ideal para workloads que exigem alta performance, baixa latência e segurança aprimorada. O custo inicial do Direct Connect é maior do que o da VPN.

Configurações, Limitações, Boas Práticas e Casos de Uso

AWS Transit Gateway:

Configuração: Crie um Transit Gateway em sua conta e anexe suas VPCs e conexões VPN/Direct Connect a ele. Configure as tabelas de rotas do Transit Gateway para controlar o fluxo de tráfego.
Limitações: Existem limites para o número de anexos, tabelas de rotas e rotas por tabela de rotas. Consulte a documentação da AWS para obter os limites mais recentes.
Boas Práticas: Use uma conta de rede dedicada para hospedar o Transit Gateway. Use tabelas de rotas separadas para isolar diferentes ambientes (por exemplo, produção, desenvolvimento, teste). Monitore o tráfego do Transit Gateway usando o CloudWatch.
Casos de Uso: Redes corporativas com múltiplas VPCs, conectividade híbrida em escala, compartilhamento de serviços centralizados.

AWS Direct Connect:

Configuração: Solicite uma conexão Direct Connect através do Console da AWS. Trabalhe com um parceiro da AWS para estabelecer a conexão física entre seu data center e um local do Direct Connect. Configure as Virtual Interfaces (VIFs) para se conectar às suas VPCs.
Limitações: A largura de banda é limitada pela porta que você provisiona (de 50 Mbps a 100 Gbps). A localização física de seu data center pode ser um fator limitante.
Boas Práticas: Use conexões redundantes do Direct Connect para alta disponibilidade. Use o Link Aggregation Group (LAG) para combinar várias conexões em uma única conexão lógica de maior largura de banda. Monitore a utilização da conexão.
Casos de Uso: Migração de grandes volumes de dados, workloads de baixa latência, aplicações que exigem alta largura de banda.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Rede Hub-and-Spoke com Transit Gateway: Este é o modelo de arquitetura mais comum para redes complexas na AWS. O Transit Gateway atua como o hub, e as VPCs e conexões on-premises são os spokes. Isso simplifica o gerenciamento da rede e melhora a escalabilidade.

Segurança: Use NACLs e Security Groups para controlar o tráfego em nível de sub-rede e de instância, respectivamente. Use o AWS Network Firewall para inspecionar e filtrar o tráfego em sua VPC. Use o AWS Shield para proteção contra ataques de DDoS.

Resiliência: Projete sua rede para ser altamente disponível, usando múltiplas AZs e Regiões. Use conexões redundantes de VPN e Direct Connect. Use o Route 53 para failover de DNS.

Governança: Use o AWS Organizations para gerenciar centralmente suas contas e políticas de rede. Use o AWS Control Tower para provisionar um ambiente de várias contas seguro e bem arquitetado. Use o AWS Resource Access Manager (RAM) para compartilhar recursos de rede, como o Transit Gateway, entre contas.

Estratégias de Migração e Modernização

Ao migrar para a AWS, comece com uma base de rede sólida. Use o Transit Gateway para conectar suas VPCs e sua rede on-premises. À medida que você moderniza suas aplicações, use serviços como o AWS PrivateLink para expor serviços de forma segura entre VPCs sem expô-los à Internet pública.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa possui 50 VPCs em uma única Região e precisa que todas elas se comuniquem entre si. Qual a solução mais escalável e gerenciável?

Decisão Arquitetural: Usar o AWS Transit Gateway. O VPC Peering exigiria uma malha de quase 1225 conexões, o que seria impossível de gerenciar.

Armadilha Comum: Não entender as implicações de custo do tráfego de dados entre AZs. O tráfego de dados entre AZs incorre em custos, o que pode ser significativo em arquiteturas com alto volume de tráfego. Otimize a localização de seus recursos para minimizar o tráfego entre AZs.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Resiliência: Projete sua rede para ser altamente disponível, usando múltiplas AZs e Regiões. Use conexões redundantes de VPN e Direct Connect. Use o Route 53 para failover de DNS.

Estratégias de Migração e Modernização

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa possui 50 VPCs em uma única Região e precisa que todas elas se comuniquem entre si. Qual a solução mais escalável e gerenciável?

Decisão Arquitetural: Usar o AWS Transit Gateway. O VPC Peering exigiria uma malha de quase 1225 conexões, o que seria impossível de gerenciar.

Detalhamento sobre políticas de IAM, SCPs, redes multi-VPC e multi-região, landing zones, observabilidade, custos e otimização

Estratégias Multi-Account e Landing Zones:

Uma estratégia multi-account é uma prática recomendada pela AWS para isolar workloads, gerenciar custos, aplicar segurança e governança de forma granular. O AWS Organizations permite que você gerencie centralmente várias contas AWS que você possui. Uma Landing Zone é um ambiente AWS bem arquitetado e multi-account que é escalável e seguro, servindo como um ponto de partida para a implantação de workloads. O AWS Control Tower é um serviço que automatiza a configuração de uma landing zone, aplicando as melhores práticas da AWS para identidade, acesso federado e estrutura de contas. Ele cria uma estrutura de Unidades Organizacionais (OUs) e contas pré-configuradas (como Log Archive e Audit), além de configurar guardrails (políticas de prevenção e detecção).

Service Control Policies (SCPs):

SCPs são um tipo de política que você pode usar para gerenciar permissões em sua organização no AWS Organizations. SCPs oferecem controle centralizado sobre as permissões máximas disponíveis para todas as contas em sua organização ou em OUs específicas. Eles não concedem permissões; em vez disso, eles definem os limites para as permissões que os usuários e funções do IAM podem ter. Por exemplo, você pode usar um SCP para impedir que qualquer conta em uma OU específica lance instâncias EC2 em uma região não aprovada. É uma boa prática testar SCPs em OUs de teste antes de aplicá-los em produção para evitar bloqueios acidentais.

IAM Avançado:

Permission Boundaries: Uma permission boundary é uma política gerenciada pelo IAM que define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade IAM (usuário ou função). Ela não concede permissões por si só, mas funciona como um filtro para as permissões efetivas. É útil para delegar a criação de funções e usuários sem conceder permissões excessivas.
Attribute-Based Access Control (ABAC): ABAC é uma estratégia de autorização que define permissões com base em atributos. Na AWS, esses atributos são chamados de tags. Você pode projetar permissões que permitem ou negam acesso a recursos com base em tags anexadas a esses recursos, ou tags anexadas ao principal que faz a solicitação. Isso simplifica o gerenciamento de permissões em ambientes dinâmicos e em larga escala.
Roles Cross-Account: Funções IAM podem ser usadas para conceder acesso seguro entre contas AWS. Em vez de compartilhar credenciais de acesso de longo prazo, uma função IAM permite que uma conta confie em outra conta para assumir essa função e acessar seus recursos. Isso é fundamental para cenários como implantação de CI/CD, acesso de auditoria ou compartilhamento de recursos.

Redes Multi-VPC e Multi-Região:

AWS Transit Gateway: Conforme mencionado, o TGW é a solução preferencial para conectar múltiplas VPCs e redes on-premises, simplificando o roteamento e a conectividade em arquiteturas complexas. Ele suporta conectividade inter-regiões, permitindo que você crie uma rede global.
AWS PrivateLink: Permite que você exponha serviços em sua VPC para outras VPCs (suas ou de outros clientes) ou para redes on-premises, sem expor o tráfego à Internet pública. Isso é ideal para criar conectividade privada e segura para serviços SaaS ou serviços internos compartilhados.
VPC Peering: Embora útil para um número limitado de conexões ponto a ponto, não é escalável para redes complexas devido à sua natureza não transitiva.
DNS Multi-Região com Amazon Route 53: O Route 53 oferece recursos avançados de roteamento de DNS, como roteamento baseado em latência, roteamento de failover e roteamento de geolocalização, que são cruciais para arquiteturas multi-região, garantindo alta disponibilidade e baixa latência para os usuários.

Observabilidade:

Em um ambiente multi-account e complexo, a observabilidade é vital. Ferramentas como Amazon CloudWatch (para métricas e logs centralizados), AWS X-Ray (para rastreamento de requisições distribuídas), AWS CloudTrail (para auditoria de API calls) e AWS Config (para monitoramento de conformidade da configuração dos recursos) são essenciais para ter uma visão unificada do comportamento e da saúde de suas aplicações e infraestrutura.

Custos e Otimização:

Gerenciar custos em um ambiente multi-account requer visibilidade e controle. O AWS Cost Explorer e o AWS Budgets ajudam a monitorar e controlar os gastos. A aplicação de tags consistentes em todos os recursos e contas é fundamental para alocar custos e identificar oportunidades de otimização. O AWS Compute Optimizer fornece recomendações para otimizar o uso de recursos de computação, enquanto o AWS Trusted Advisor oferece insights sobre otimização de custos, segurança, performance e tolerância a falhas.

Domínio 2: Design para Novas Soluções

Este domínio aborda a capacidade de projetar novas soluções na AWS, focando na escolha de serviços, padrões de arquitetura, resiliência, escalabilidade e otimização de performance. É crucial entender as características de cada serviço para tomar decisões arquiteturais informadas que atendam aos requisitos de negócios e técnicos.

Tópicos e Subtópicos:

2.1. Arquitetar soluções de computação.

Conceitos Fundamentais e Avançados

A AWS oferece uma vasta gama de serviços de computação, cada um otimizado para diferentes tipos de workloads. A escolha do serviço de computação correto é uma decisão arquitetural crítica que impacta diretamente a escalabilidade, performance, custo e gerenciamento da solução.

Amazon EC2 (Elastic Compute Cloud): Fornece capacidade computacional segura e redimensionável na nuvem. É a base para muitas arquiteturas e oferece controle granular sobre as instâncias (tipo, sistema operacional, armazenamento, rede). O EC2 é ideal para workloads que exigem controle total sobre o ambiente de servidor, como aplicações legadas, bancos de dados específicos ou cargas de trabalho que precisam de GPUs.
- Instâncias Spot/Mixed Fleets: Instâncias Spot permitem que você solicite capacidade EC2 não utilizada da AWS com grandes descontos. São ideais para workloads tolerantes a falhas, como processamento em lote, renderização ou testes. Mixed Fleets combinam instâncias On-Demand, Reserved Instances e Spot para otimizar custos e disponibilidade.
- Auto Scaling: Permite escalar automaticamente a capacidade do EC2 para cima ou para baixo de acordo com a demanda. Garante alta disponibilidade e otimização de custos, lançando ou encerrando instâncias automaticamente.
AWS Lambda: Um serviço de computação serverless que permite executar código sem provisionar ou gerenciar servidores. Você paga apenas pelo tempo de computação consumido. Ideal para funções de curta duração, orientadas a eventos, como processamento de dados em tempo real, backends de API ou automação de tarefas. Suporta várias linguagens de programação.
Containers (Amazon ECS, Amazon EKS, AWS Fargate): A AWS oferece várias opções para executar workloads em contêineres:
- Amazon Elastic Container Service (ECS): Um serviço de orquestração de contêineres totalmente gerenciado que facilita a execução, interrupção e gerenciamento de contêineres Docker em um cluster. É bem integrado com outros serviços AWS.
- Amazon Elastic Kubernetes Service (EKS): Um serviço gerenciado de Kubernetes que facilita a execução de aplicações Kubernetes na AWS sem a necessidade de instalar, operar e manter seu próprio plano de controle Kubernetes. Ideal para quem já usa Kubernetes ou busca portabilidade.
- AWS Fargate: Um mecanismo de computação serverless para contêineres que funciona com ECS e EKS. Com Fargate, você não precisa provisionar, configurar ou escalar clusters de máquinas virtuais. Você paga apenas pelos recursos de computação que seus contêineres usam. Ideal para simplificar a operação de contêineres.
AWS Outposts, Wavelength, Local Zones: Estendem a infraestrutura e os serviços da AWS para locais on-premises (Outposts), para a borda da rede 5G (Wavelength) ou para áreas metropolitanas (Local Zones), permitindo que os clientes executem aplicações com baixa latência para usuários finais ou equipamentos locais.
AWS Batch: Permite executar workloads de computação em lote em escala. Ele provisiona dinamicamente a quantidade ideal de recursos de computação (EC2, Spot) com base nos requisitos da workload.
AWS ParallelCluster: Uma ferramenta de código aberto que facilita a implantação e o gerenciamento de clusters de computação de alto desempenho (HPC) na AWS.
AWS Serverless Application Model (AWS SAM) e AWS Amplify: Ferramentas para simplificar o desenvolvimento e a implantação de aplicações serverless e web/mobile, respectivamente.

Comparações entre Serviços e Quando Usar Cada Um

EC2 vs. Lambda vs. Fargate:

Característica	Amazon EC2	AWS Lambda	AWS Fargate
Nível de Abstração	Servidores Virtuais (IaaS)	Funções (Serverless, FaaS)	Contêineres (Serverless, CaaS)
Gerenciamento	Alto (SO, patches, escalabilidade)	Baixo (apenas código)	Médio (apenas contêineres, sem infra)
Escalabilidade	Auto Scaling Groups (minutos)	Automática (milissegundos)	Automática (segundos)
Custo	Por hora/segundo (instância)	Por execução e tempo de computação	Por vCPU e GB de memória por segundo
Casos de Uso	Aplicações legadas, DBs, controle total	Funções orientadas a eventos, APIs sem estado	Microsserviços, aplicações conteinerizadas
Tempo de Execução	Contínuo	Curta duração (até 15 min)	Longa duração

Use EC2 quando: Você precisa de controle total sobre o sistema operacional, tem aplicações legadas que não podem ser facilmente conteinerizadas ou refatoradas, ou precisa de tipos de instância específicos (GPUs, HPC).
Use Lambda quando: Você tem workloads orientadas a eventos, funções de curta duração, precisa de escalabilidade instantânea e não quer gerenciar servidores. Ideal para backends de API, processamento de arquivos, automação.
Use Fargate quando: Você quer executar contêineres sem gerenciar a infraestrutura subjacente. Ideal para microsserviços, aplicações web conteinerizadas, onde a portabilidade do contêiner é importante, mas o gerenciamento de VMs não é desejado.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon EC2:

Configurações: Escolha o tipo de instância (família, tamanho), AMI (Amazon Machine Image), armazenamento (EBS), rede (VPC, sub-rede, Security Groups). Configure Auto Scaling Groups com políticas de escalabilidade.
Limitações: Limites de serviço para o número de instâncias, vCPUs, volumes EBS por região. Custos podem escalar rapidamente se não forem otimizados.
Boas Práticas: Use instâncias Spot para workloads flexíveis. Use Auto Scaling para resiliência e otimização de custos. Use User Data para automação de inicialização. Monitore com CloudWatch.
Casos de Uso: Servidores web, servidores de aplicação, bancos de dados relacionais (com RDS ou self-managed), clusters de Big Data.

AWS Lambda:

Configurações: Defina a função (código), runtime, memória, tempo limite, variáveis de ambiente, gatilhos (eventos). Configure VPC para acesso a recursos privados.
Limitações: Tempo limite de execução (15 minutos), tamanho do pacote de implantação, memória máxima. Cold starts podem impactar a latência.
Boas Práticas: Mantenha as funções pequenas e com uma única responsabilidade. Use Provisioned Concurrency para reduzir cold starts em workloads sensíveis à latência. Monitore com CloudWatch Logs e X-Ray.
Casos de Uso: Processamento de eventos (S3, DynamoDB Streams), backends de API (com API Gateway), chatbots, automação de infraestrutura.

AWS Fargate (com ECS ou EKS):

Configurações: Defina a definição da tarefa (imagem do contêiner, vCPU, memória), políticas de escalabilidade. Integre com Load Balancers e Service Discovery.
Limitações: Não há acesso ao sistema operacional subjacente. Custos podem ser mais altos que EC2 para workloads de longa duração e alta utilização.
Boas Práticas: Use imagens de contêiner otimizadas e pequenas. Implemente health checks para garantir a disponibilidade. Monitore com CloudWatch Container Insights.
Casos de Uso: Microsserviços, APIs conteinerizadas, aplicações web, processamento de dados em contêineres.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Microsserviços: Frequentemente implementada com contêineres (ECS/EKS/Fargate) e Lambda para componentes serverless. Cada serviço é independente, escalável e resiliente.
Padrões de Segurança: Use IAM Roles para conceder permissões mínimas aos serviços de computação. Isole recursos em sub-redes privadas. Use Security Groups para controlar o tráfego de rede. Criptografe dados em trânsito e em repouso.
Resiliência: Distribua workloads por múltiplas AZs. Use Auto Scaling para lidar com picos de tráfego e falhas de instâncias. Implemente health checks e circuit breakers.
Governança: Use AWS Config para monitorar a conformidade das configurações. Implemente políticas de tagging para rastreamento de custos e recursos.

Estratégias de Migração e Modernização

Rehost (Lift-and-Shift): Migrar VMs on-premises para EC2. É a estratégia mais rápida, mas não aproveita totalmente os benefícios da nuvem.
Replatform: Migrar aplicações para EC2 com algumas otimizações, como o uso de RDS para bancos de dados ou Auto Scaling. Pode envolver a conteinerização de aplicações para ECS/EKS.
Refactor/Re-architect: Refatorar aplicações para usar serviços serverless (Lambda, Fargate) e microsserviços. Esta é a estratégia que mais aproveita os benefícios da nuvem, mas também a mais complexa e demorada.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação web tem picos de tráfego imprevisíveis e precisa de escalabilidade rápida e custos otimizados. A aplicação é composta por um frontend estático e um backend de API RESTful.

Decisão Arquitetural: Hospedar o frontend estático no Amazon S3 e usar o Amazon CloudFront para entrega de conteúdo. Para o backend, usar AWS Lambda com Amazon API Gateway. Isso proporciona escalabilidade automática, alta disponibilidade e um modelo de custo pay-per-use.

Armadilha Comum: Usar EC2 para workloads que seriam mais adequadas para Lambda ou Fargate, resultando em custos mais altos e maior sobrecarga de gerenciamento. Por exemplo, executar um servidor web 24/7 em EC2 para uma aplicação que recebe tráfego apenas algumas horas por dia.

2.2. Arquitetar soluções de armazenamento.

Conceitos Fundamentais e Avançados

A AWS oferece uma ampla gama de serviços de armazenamento, cada um projetado para diferentes casos de uso, requisitos de performance, durabilidade e custo. A escolha do serviço de armazenamento adequado é crucial para a performance e a economia de uma solução.

Amazon S3 (Simple Storage Service): Armazenamento de objetos altamente durável, disponível e escalável. Ideal para armazenar qualquer tipo de dado (imagens, vídeos, backups, logs, arquivos estáticos de sites). Oferece diferentes classes de armazenamento para otimização de custos com base na frequência de acesso.
- Classes de Armazenamento: S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA (Infrequent Access), S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive. Cada classe tem um custo e um tempo de recuperação diferentes.
- Pontos de Acesso (Access Points): Simplificam o gerenciamento de acesso a dados em S3 em escala, permitindo criar centenas de pontos de acesso com políticas de acesso distintas para diferentes aplicações ou usuários.
Amazon Elastic File System (EFS): Um sistema de arquivos de rede (NFS) escalável e elástico para instâncias EC2 e on-premises (via Direct Connect ou VPN). Ideal para workloads que precisam de acesso compartilhado a arquivos, como aplicações web, sistemas de gerenciamento de conteúdo e ambientes de desenvolvimento.
Amazon FSx: Oferece sistemas de arquivos totalmente gerenciados para workloads específicas:
- FSx for Lustre: Para workloads de computação de alto desempenho (HPC) que exigem armazenamento de arquivos rápido.
- FSx for Windows File Server: Para workloads que exigem compartilhamentos de arquivos baseados em Windows com suporte a SMB (Server Message Block).
- FSx for NetApp ONTAP: Oferece recursos de gerenciamento de dados do ONTAP com a agilidade e escalabilidade da AWS.
Amazon Elastic Block Store (EBS): Fornece volumes de armazenamento em bloco persistentes para uso com instâncias EC2. É como um disco rígido virtual que você pode anexar a uma instância. Ideal para bancos de dados, sistemas de arquivos e qualquer aplicação que precise de armazenamento de baixa latência e alta performance.
AWS Backup: Um serviço de backup centralizado e gerenciado que facilita o backup de dados de vários serviços da AWS (EBS, RDS, DynamoDB, EFS, FSx, EC2, Storage Gateway) e on-premises.
Amazon Glacier: Uma classe de armazenamento de S3 para arquivamento de dados de longo prazo e baixo custo. Ideal para dados que são acessados raramente, mas que precisam ser retidos por anos ou décadas.
AWS Storage Gateway: Conecta ambientes on-premises com o armazenamento em nuvem da AWS, oferecendo gateways de arquivo, volume e fita para diferentes casos de uso de armazenamento híbrido.
AWS Snow Family: Dispositivos físicos (Snowcone, Snowball, Snowmobile) para transferir grandes volumes de dados para dentro e para fora da AWS, ou para executar computação na borda em ambientes desconectados ou remotos.

Comparações entre Serviços e Quando Usar Cada Um

Característica	Amazon S3	Amazon EFS	Amazon FSx	Amazon EBS
Tipo de Armazenamento	Objeto	Arquivo (NFS)	Arquivo (Lustre, SMB, ONTAP)	Bloco
Casos de Uso	Dados não estruturados, backups, arquivos estáticos	Compartilhamento de arquivos, CMS, dev/test	HPC, Windows file shares, ONTAP features	Bancos de dados, SO de EC2, logs de aplicação
Acesso	HTTP/HTTPS, SDKs, APIs	NFSv4.1	Lustre, SMB, ONTAP	Anexado a uma única instância EC2
Escalabilidade	Praticamente ilimitada	Petabytes, elástico	Petabytes, escalável	Limitado ao tamanho do volume
Performance	Variável (depende da classe)	Variável (depende do modo)	Alta (Lustre), Média (Windows)	Alta (depende do tipo de volume)
Durabilidade	11 noves (99.999999999%)	11 noves (99.999999999%)	Alta (depende do tipo)	Alta (depende do tipo de volume)
Disponibilidade	Alta (99.9% a 99.99%)	Multi-AZ	Multi-AZ (Windows, ONTAP), Single-AZ (Lustre)	Single-AZ (replicado dentro da AZ)

S3 vs. EFS vs. FSx: A principal diferença está no modelo de acesso. S3 é para objetos (acesso via API), EFS e FSx são para arquivos (acesso via sistema de arquivos). A escolha entre EFS e FSx depende do tipo de sistema de arquivos e dos recursos específicos necessários (NFS genérico vs. Lustre/SMB/ONTAP).
S3 vs. Glacier: Glacier é uma classe de armazenamento de S3, otimizada para arquivamento de longo prazo com custos muito baixos, mas com tempos de recuperação mais longos. S3 Standard é para acesso frequente, enquanto as classes IA são para acesso infrequente.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon S3:

Configurações: Crie buckets, defina políticas de bucket, configure políticas de ciclo de vida para transição entre classes de armazenamento, configure versionamento, criptografia (SSE-S3, SSE-KMS, SSE-C).
Limitações: Tamanho máximo de objeto (5 TB), limites de taxa de requisições por prefixo.
Boas Práticas: Use políticas de ciclo de vida para otimizar custos. Habilite o versionamento para proteção contra exclusão acidental. Use Access Points para gerenciar o acesso em escala. Use criptografia por padrão.
Casos de Uso: Data lakes, backups, hospedagem de sites estáticos, armazenamento de logs, distribuição de conteúdo.

Amazon EFS:

Configurações: Crie um sistema de arquivos EFS, defina modos de performance (General Purpose, Max I/O), modos de throughput (Bursting, Provisioned), crie mount targets em suas VPCs.
Limitações: Latência um pouco maior que EBS para acesso de bloco. Custo pode ser mais alto para workloads que não precisam de compartilhamento.
Boas Práticas: Use o modo General Purpose para a maioria das workloads. Use o modo Max I/O para workloads com alta concorrência. Monitore o throughput e o uso de burst credits.
Casos de Uso: Diretórios home de usuários, ambientes de desenvolvimento compartilhados, sistemas de gerenciamento de conteúdo (CMS), workloads de Big Data.

Amazon EBS:

Configurações: Escolha o tipo de volume (gp2/gp3, io1/io2, st1, sc1), tamanho, IOPS/throughput. Crie snapshots para backup. Anexe a instâncias EC2.
Limitações: Anexado a uma única instância EC2 por vez. Performance varia com o tipo de volume.
Boas Práticas: Use gp3 para a maioria das workloads. Use io2 Block Express para workloads de alta performance. Crie snapshots regularmente para recuperação de desastres. Criptografe volumes EBS por padrão.
Casos de Uso: Volumes de boot de instâncias EC2, bancos de dados, logs de aplicação, volumes de dados para aplicações que exigem armazenamento persistente e de baixa latência.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Data Lake no S3: Armazene dados brutos e processados no S3, usando diferentes classes de armazenamento para otimização de custos. Integre com serviços como AWS Glue, Amazon Athena e Amazon Redshift Spectrum para análise.
Armazenamento Compartilhado para Aplicações Web: Use EFS para compartilhar arquivos de conteúdo entre múltiplos servidores web EC2 em um Auto Scaling Group.
Padrões de Segurança: Use políticas de bucket S3, ACLs e políticas de ponto de acesso para controlar o acesso. Use IAM Roles para acesso a serviços de armazenamento. Criptografe dados em repouso (SSE-S3, SSE-KMS) e em trânsito (SSL/TLS). Use o AWS PrivateLink para acesso privado a S3 de dentro da VPC.
Resiliência: S3, EFS e FSx for Windows/ONTAP são projetados para alta durabilidade e disponibilidade multi-AZ. Para EBS, use snapshots para backup e replicação entre AZs para recuperação de desastres.
Governança: Use AWS Config para monitorar a conformidade das configurações de armazenamento. Implemente políticas de ciclo de vida para gerenciar o ciclo de vida dos dados e otimizar custos.

Estratégias de Migração e Modernização

Migração de Dados: Use AWS DataSync para transferir grandes volumes de dados de on-premises para S3, EFS ou FSx. Use o AWS Snow Family para migrações offline de petabytes de dados.
Modernização: Substitua servidores de arquivos on-premises por EFS ou FSx. Migre bancos de dados para RDS ou DynamoDB, que usam EBS e S3 internamente. Refatore aplicações para usar S3 para armazenamento de objetos em vez de sistemas de arquivos locais.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de análise de Big Data gera grandes volumes de dados que precisam ser armazenados de forma econômica e acessados ocasionalmente para relatórios históricos.

Decisão Arquitetural: Armazenar os dados no Amazon S3 com políticas de ciclo de vida para transicionar dados mais antigos para S3 Intelligent-Tiering e, eventualmente, para S3 Glacier Deep Archive. Isso otimiza os custos de armazenamento enquanto mantém os dados acessíveis quando necessário.

Armadilha Comum: Usar S3 Standard para dados que são acessados raramente, resultando em custos de armazenamento desnecessariamente altos. Ou, inversamente, usar Glacier para dados que precisam de recuperação rápida, incorrendo em custos de recuperação elevados e atrasos.

2.3. Arquitetar soluções de banco de dados.

Conceitos Fundamentais e Avançados

A AWS oferece uma ampla variedade de serviços de banco de dados, cobrindo modelos relacionais, NoSQL, data warehousing, grafos, ledger, séries temporais e blockchain. A escolha do banco de dados certo é fundamental para a performance, escalabilidade, resiliência e custo de uma aplicação.

Amazon Relational Database Service (RDS): Um serviço de banco de dados relacional gerenciado que facilita a configuração, operação e escalabilidade de bancos de dados relacionais na nuvem. Suporta vários motores de banco de dados (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB).
Amazon Aurora: Um banco de dados relacional compatível com MySQL e PostgreSQL, construído para a nuvem. Combina a velocidade e a disponibilidade de bancos de dados comerciais de ponta com a simplicidade e a economia de bancos de dados de código aberto. Oferece até 5x o throughput do MySQL padrão e 3x o do PostgreSQL padrão.
Amazon DynamoDB: Um serviço de banco de dados NoSQL de chave-valor e documento totalmente gerenciado que oferece performance de milissegundos de dígito único em qualquer escala. Ideal para aplicações que exigem baixa latência e alta taxa de transferência, como jogos, publicidade digital e IoT.
Amazon DocumentDB (com compatibilidade MongoDB): Um serviço de banco de dados de documentos totalmente gerenciado que suporta workloads MongoDB. Compatível com as APIs do MongoDB, permitindo que você use o código, drivers e ferramentas do MongoDB existentes.
Amazon Neptune: Um serviço de banco de dados de grafo rápido, confiável e totalmente gerenciado. Ideal para construir e executar aplicações que trabalham com conjuntos de dados altamente conectados, como redes sociais, motores de recomendação e detecção de fraudes.
Amazon Redshift: Um serviço de data warehouse rápido e totalmente gerenciado em escala de petabytes. Ideal para análise de grandes volumes de dados estruturados e semi-estruturados, permitindo consultas complexas e relatórios.
Amazon ElastiCache: Um serviço de cache na memória totalmente gerenciado que suporta Redis e Memcached. Usado para acelerar o desempenho de aplicações web e móveis, recuperando informações de caches na memória de alta velocidade em vez de depender de bancos de dados baseados em disco mais lentos.
Amazon Quantum Ledger Database (QLDB): Um banco de dados de ledger totalmente gerenciado que fornece um log de transações transparente, imutável e criptograficamente verificável. Ideal para sistemas que precisam de um registro completo e verificável de todas as alterações de dados, como registros financeiros ou de supply chain.
Amazon Managed Blockchain: Um serviço totalmente gerenciado para criar e gerenciar redes de blockchain escaláveis usando frameworks populares como Hyperledger Fabric e Ethereum.
Amazon Keyspaces (para Apache Cassandra): Um serviço de banco de dados de tabela ampla, serverless, compatível com Apache Cassandra. Ideal para workloads Cassandra que precisam de escalabilidade e gerenciamento simplificados.
Amazon Timestream: Um serviço de banco de dados de séries temporais rápido, escalável e serverless. Ideal para aplicações IoT e operacionais que coletam dados de séries temporais em alta velocidade.
AWS Database Migration Service (DMS): Ajuda a migrar bancos de dados para a AWS de forma rápida e segura. Suporta migrações homogêneas (por exemplo, Oracle para Oracle) e heterogêneas (por exemplo, Oracle para PostgreSQL).
AWS Schema Conversion Tool (SCT): Ajuda a converter o esquema do banco de dados e o código da aplicação de um banco de dados de origem para um banco de dados de destino diferente.

Comparações entre Serviços e Quando Usar Cada Um

Amazon RDS vs. Amazon Aurora vs. Amazon DynamoDB:

Característica	Amazon RDS	Amazon Aurora	Amazon DynamoDB
Tipo de Banco de Dados	Relacional (SQL)	Relacional (SQL) - compatível com MySQL/PostgreSQL	NoSQL (Chave-Valor, Documento)
Escalabilidade	Vertical (maior instância), Leitura (réplicas)	Leitura (até 15 réplicas), Armazenamento automático	Horizontal (praticamente ilimitada)
Performance	Boa, depende do tipo de instância	Alta (até 5x MySQL, 3x PostgreSQL)	Milissegundos de dígito único em qualquer escala
Custo	Por hora/segundo (instância, armazenamento)	Por hora/segundo (instância, armazenamento)	Por throughput provisionado/sob demanda, armazenamento
Casos de Uso	Aplicações web tradicionais, ERPs, CRMs	Aplicações de alta performance, OLTP	Aplicações de alta taxa de transferência, IoT, jogos, microsserviços
Gerenciamento	Gerenciado (SO, patches, backups)	Totalmente gerenciado, auto-reparável	Totalmente gerenciado, serverless

Use RDS quando: Você precisa de um banco de dados relacional tradicional e quer a conveniência de um serviço gerenciado sem se preocupar com a infraestrutura subjacente. Ideal para a maioria das aplicações web e empresariais que se beneficiam de um esquema fixo e transações ACID.
Use Aurora quando: Você precisa de um banco de dados relacional com alta performance, escalabilidade e disponibilidade, superando o RDS padrão. É uma boa escolha para workloads OLTP (Online Transaction Processing) exigentes.
Use DynamoDB quando: Você precisa de um banco de dados NoSQL com performance de milissegundos de dígito único em qualquer escala, sem se preocupar com o provisionamento de servidores. Ideal para aplicações com grandes volumes de dados e padrões de acesso flexíveis, como dados de sessão, perfis de usuário, IoT.

Outras Comparações:

DocumentDB vs. DynamoDB: Ambos são NoSQL. DocumentDB é para workloads de documentos compatíveis com MongoDB, enquanto DynamoDB é mais flexível para chave-valor e documentos, com performance garantida em escala.
Redshift vs. RDS/Aurora: Redshift é um data warehouse para análise (OLAP), enquanto RDS/Aurora são bancos de dados transacionais (OLTP). Não são substitutos, mas complementares.
ElastiCache vs. Bancos de Dados: ElastiCache é um cache na memória para acelerar o acesso a dados frequentemente acessados, reduzindo a carga no banco de dados principal.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon RDS:

Configurações: Escolha o motor, tipo de instância, armazenamento, Multi-AZ, réplicas de leitura, grupos de parâmetros e opções.
Limitações: Escalabilidade vertical limitada pelo tipo de instância. Réplicas de leitura são assíncronas.
Boas Práticas: Use Multi-AZ para alta disponibilidade. Use réplicas de leitura para escalar workloads de leitura. Monitore métricas de performance e otimize consultas.
Casos de Uso: Aplicações web e móveis, sistemas de gerenciamento de conteúdo, CRMs, ERPs.

Amazon Aurora:

Configurações: Escolha o motor (MySQL/PostgreSQL), tipo de instância, configure réplicas de leitura, Aurora Serverless para escalabilidade sob demanda.
Limitações: Compatibilidade com MySQL/PostgreSQL, mas não 100% idêntico. Custos podem ser mais altos que RDS padrão para workloads de baixa utilização.
Boas Práticas: Use o endpoint de leitura para distribuir o tráfego de leitura entre as réplicas. Use Aurora Serverless para workloads intermitentes ou imprevisíveis. Monitore com CloudWatch.
Casos de Uso: Aplicações de alta performance, jogos, SaaS, e-commerce.

Amazon DynamoDB:

Configurações: Defina tabelas, chaves primárias (partição e sort key), atributos, modos de capacidade (provisionado ou sob demanda), índices secundários globais/locais.
Limitações: Não é um banco de dados relacional. Não suporta joins complexos ou transações multi-tabela nativamente (embora existam transações para múltiplos itens/tabelas no mesmo account/region).
Boas Práticas: Projete bem as chaves primárias para distribuir a carga de trabalho. Use o modo sob demanda para workloads imprevisíveis. Use o DynamoDB Accelerator (DAX) para cache na memória. Habilite o DynamoDB Streams para processamento de eventos.
Casos de Uso: Perfis de usuário, dados de sessão, carrinhos de compras, jogos, IoT, microsserviços sem estado.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura Orientada a Dados: Escolha o banco de dados certo para cada workload, combinando diferentes tipos (relacional para transações, NoSQL para dados flexíveis, data warehouse para análise).
Padrões de Segurança: Use IAM Roles para acesso a bancos de dados. Criptografe dados em repouso (KMS) e em trânsito (SSL/TLS). Use Security Groups para controlar o acesso à rede. Implemente o princípio do menor privilégio.
Resiliência: Use Multi-AZ para RDS e Aurora para alta disponibilidade. DynamoDB é inerentemente distribuído e resiliente. Use backups e snapshots regulares.
Governança: Use AWS Config para monitorar a conformidade das configurações de banco de dados. Implemente políticas de tagging para rastreamento de custos e recursos.

Estratégias de Migração e Modernização

Migração de Banco de Dados: Use AWS DMS para migrar bancos de dados existentes para a AWS, com suporte para migrações homogêneas e heterogêneas. Use AWS SCT para converter esquemas.
Modernização: Refatore aplicações para usar bancos de dados serverless como DynamoDB ou Aurora Serverless. Migre de bancos de dados auto-gerenciados para serviços gerenciados como RDS ou Aurora para reduzir a sobrecarga operacional.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce precisa de um banco de dados para armazenar informações de produtos e pedidos. A aplicação espera um alto volume de transações e precisa de alta disponibilidade e escalabilidade.

Decisão Arquitetural: Para informações de produtos e pedidos que exigem um esquema relacional e transações ACID, o Amazon Aurora (compatível com MySQL ou PostgreSQL) com Multi-AZ e réplicas de leitura seria uma excelente escolha devido à sua alta performance e escalabilidade. Para dados de sessão de usuário ou carrinhos de compras (que podem ser mais flexíveis e de alta taxa de transferência), o Amazon DynamoDB seria uma boa opção.

Armadilha Comum: Tentar forçar um banco de dados relacional para um caso de uso NoSQL (ou vice-versa). Por exemplo, usar RDS para armazenar dados de IoT de alta taxa de ingestão, o que pode levar a problemas de performance e escalabilidade. Ou usar DynamoDB para dados que exigem joins complexos e transações multi-tabela, o que pode complicar o desenvolvimento e o gerenciamento.

2.4. Arquitetar soluções de rede.

Conceitos Fundamentais e Avançados

As soluções de rede na AWS são a base para a conectividade de todas as aplicações e serviços. O domínio 2 aprofunda os conceitos de rede, incluindo VPCs, conectividade global e serviços de entrega de conteúdo.

Amazon VPC (Virtual Private Cloud): O serviço fundamental para criar sua rede virtual isolada na AWS. Permite definir sub-redes (públicas e privadas), tabelas de rotas, gateways de internet, gateways NAT e endpoints de VPC. É o alicerce para a segurança e o isolamento da rede.
- Endpoints de VPC (Interface e Gateway): Permitem que você se conecte a serviços da AWS (como S3 e DynamoDB) e serviços de endpoint de VPC alimentados por PrivateLink sem usar um gateway de internet, um dispositivo NAT ou uma conexão VPN. Isso mantém o tráfego dentro da rede da AWS, aumentando a segurança e reduzindo a latência.
AWS Transit Gateway: (Já abordado no Domínio 1) Atua como um hub central para conectar VPCs e redes on-premises, simplificando o roteamento e a conectividade em arquiteturas complexas e multi-contas.
AWS PrivateLink: (Já abordado no Domínio 1) Permite que você exponha serviços em sua VPC para outras VPCs ou para redes on-premises de forma privada e segura, sem expor o tráfego à Internet pública.
VPC Peering: (Já abordado no Domínio 1) Conecta duas VPCs diretamente, permitindo que elas se comuniquem como se estivessem na mesma rede. Ideal para um número limitado de conexões ponto a ponto.
AWS Direct Connect e AWS VPN: (Já abordados no Domínio 1) Soluções para conectividade híbrida entre on-premises e AWS, oferecendo conexões privadas e seguras, respectivamente.
Amazon Route 53: Um serviço de DNS (Domain Name System) web escalável e altamente disponível. Além da resolução de nomes, oferece recursos avançados de roteamento:
- DNS Multi-Região: Permite rotear o tráfego para recursos em diferentes regiões com base em latência, geolocalização, ponderação ou saúde do recurso, crucial para alta disponibilidade e recuperação de desastres.
- Políticas de Roteamento: Incluem roteamento simples, ponderado, baseado em latência, failover, geolocalização, multi-valor de resposta e baseado em proximidade (com Global Accelerator).
Amazon CloudFront: Um serviço de rede de entrega de conteúdo (CDN) rápido que entrega dados, vídeos, aplicações e APIs com segurança globalmente, com baixa latência e altas velocidades de transferência. Ele armazena em cache o conteúdo em edge locations (Pontos de Presença) próximos aos usuários.
- URLs Assinadas e Cookies Assinados: Permitem controlar o acesso ao conteúdo do CloudFront, concedendo acesso temporário a usuários específicos. Útil para conteúdo premium ou privado.
- Geo-restrições: Permitem controlar quais países podem acessar seu conteúdo do CloudFront.
AWS Global Accelerator: Um serviço de rede que melhora a disponibilidade e a performance de suas aplicações para usuários globais. Ele roteia o tráfego para o endpoint de aplicação mais saudável e mais próximo usando a rede global da AWS, otimizando a performance em comparação com a Internet pública.
AWS App Mesh: Um service mesh que fornece visibilidade e controle de rede para suas aplicações baseadas em microsserviços. Ele padroniza como os microsserviços se comunicam, fornecendo recursos como roteamento de tráfego, retries, circuit breaking e métricas.
AWS Cloud Map: Um serviço de descoberta de recursos que permite que suas aplicações descubram e se conectem a serviços de nuvem dinamicamente. Ele mantém um registro de todos os seus recursos de aplicação e seus locais, e os atualiza automaticamente.
VPC Lattice: Um novo serviço que simplifica a conectividade, segurança e observabilidade entre serviços em uma arquitetura de microsserviços. Ele permite que você defina políticas de acesso e roteamento em um nível de serviço, independentemente da infraestrutura de rede subjacente. Facilita a comunicação entre serviços em diferentes VPCs e contas.

Comparações entre Serviços e Quando Usar Cada Um

AWS Transit Gateway vs. AWS PrivateLink vs. VPC Peering:

Característica	VPC Peering	AWS Transit Gateway	AWS PrivateLink
Conectividade	Ponto a ponto (VPC para VPC)	Hub-and-spoke (VPC para VPC, on-premises)	Endpoint privado para serviços
Roteamento Transitivo	Não suportado	Suportado	Não aplicável (acesso a serviço, não rede)
Escalabilidade	Baixa (malha complexa)	Alta (hub central)	Alta (para acesso a serviços)
Complexidade	Baixa para poucas VPCs	Média para muitas VPCs	Média (configuração de endpoints e serviços)
Custo	Baixo para poucas VPCs	Baseado em anexos e tráfego	Baseado em endpoints e tráfego
Casos de Uso	Conectar 2-3 VPCs	Redes corporativas, multi-contas, híbridas	Acesso privado a SaaS, serviços internos

CloudFront vs. Global Accelerator: Ambos melhoram a performance e a disponibilidade, mas em diferentes camadas. CloudFront é um CDN para conteúdo web (camada 7 - HTTP/HTTPS), otimizando a entrega de conteúdo estático e dinâmico. Global Accelerator opera na camada de rede (camada 4 - TCP/UDP), otimizando o roteamento do tráfego para aplicações, independentemente do protocolo. Use CloudFront para conteúdo web e Global Accelerator para aplicações que não são baseadas em HTTP/HTTPS ou que exigem endereços IP estáticos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon VPC:

Configurações: Defina blocos CIDR, crie sub-redes (públicas/privadas), configure tabelas de rotas, gateways de internet, NAT Gateways, Endpoints de VPC. Use Security Groups e NACLs para controle de tráfego.
Limitações: Limites de blocos CIDR, número de VPCs, sub-redes, Security Groups por região/conta.
Boas Práticas: Use um modelo de VPC com sub-redes públicas e privadas. Use NAT Gateways para acesso de saída de sub-redes privadas. Use Endpoints de VPC para acesso seguro a serviços AWS. Monitore Flow Logs para visibilidade do tráfego.
Casos de Uso: Isolamento de ambientes (dev, test, prod), hospedagem de aplicações multi-tier, redes híbridas.

Amazon Route 53:

Configurações: Crie zonas hospedadas, registros DNS (A, CNAME, MX, TXT, etc.), configure políticas de roteamento (simples, ponderado, latência, failover, geolocalização).
Limitações: Limites de zonas hospedadas e registros por zona.
Boas Práticas: Use políticas de roteamento de failover para alta disponibilidade. Use roteamento baseado em latência para otimizar a performance global. Use health checks para monitorar a saúde dos endpoints.
Casos de Uso: Resolução de DNS para domínios, roteamento de tráfego global, failover de aplicações.

Amazon CloudFront:

Configurações: Crie distribuições, defina origens (S3, EC2, Load Balancers), configure comportamentos de cache, SSL/TLS, URLs/Cookies assinados, geo-restrições.
Limitações: Custos de transferência de dados podem ser significativos. Invalidações de cache podem levar tempo.
Boas Práticas: Use para entregar conteúdo estático e dinâmico. Otimize as configurações de cache para melhorar a performance e reduzir custos. Use URLs/Cookies assinados para conteúdo restrito.
Casos de Uso: Aceleração de sites e aplicações web, streaming de vídeo, distribuição de APIs, entrega de conteúdo de software.

AWS Global Accelerator:

Configurações: Crie um acelerador, adicione ouvintes (listeners) e grupos de endpoints (com instâncias EC2, Load Balancers, Elastic IPs). O Global Accelerator fornece dois endereços IP estáticos.
Limitações: Não é um CDN. Não armazena conteúdo em cache.
Boas Práticas: Use para aplicações que exigem alta disponibilidade e performance global, especialmente para tráfego não-HTTP/HTTPS. Use com health checks para rotear para endpoints saudáveis.
Casos de Uso: Jogos online, VoIP, aplicações financeiras, aplicações que exigem endereços IP estáticos globais.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Rede em Estrela (Hub-and-Spoke): Com o Transit Gateway como hub central, conectando VPCs de diferentes ambientes (produção, desenvolvimento, segurança) e redes on-premises.
Padrões de Segurança: Implemente o princípio do menor privilégio para acesso à rede. Use Security Groups e NACLs. Use AWS WAF e Shield para proteção de aplicações web. Monitore o tráfego com VPC Flow Logs e CloudWatch.
Resiliência: Projete redes multi-AZ e multi-região. Use Load Balancers para distribuir o tráfego. Implemente failover de DNS com Route 53.
Governança: Use AWS Organizations para gerenciar contas de rede. Use AWS Config para monitorar a conformidade das configurações de rede. Use AWS Network Manager para gerenciar e monitorar sua rede global.

Estratégias de Migração e Modernização

Migração de Rede: Migre redes on-premises para VPCs usando Direct Connect ou VPN. Consolide redes complexas com VPC Peering em uma arquitetura Transit Gateway.
Modernização: Adote VPC Lattice para simplificar a conectividade e segurança de microsserviços. Use CloudFront e Global Accelerator para otimizar a entrega de aplicações globais. Refatore aplicações para usar Endpoints de VPC para acesso privado a serviços AWS.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa tem uma aplicação web global que precisa entregar conteúdo estático e dinâmico com baixa latência para usuários em todo o mundo, além de uma API backend que precisa de alta performance e disponibilidade.

Decisão Arquitetural: Usar Amazon CloudFront para entregar o conteúdo estático (imagens, CSS, JS) e dinâmico (HTML). Para a API backend, usar AWS Global Accelerator para rotear o tráfego para o endpoint de API mais próximo e saudável, garantindo baixa latência e alta disponibilidade. O CloudFront pode ser configurado para usar o Global Accelerator como origem para a API.

Armadilha Comum: Não otimizar o roteamento de DNS ou a entrega de conteúdo para usuários globais, resultando em alta latência e má experiência do usuário. Confundir o propósito de CloudFront e Global Accelerator e usar um onde o outro seria mais apropriado.

2.5. Arquitetar soluções de mensageria e integração.

Conceitos Fundamentais e Avançados

Serviços de mensageria e integração são cruciais para construir aplicações distribuídas, desacopladas e escaláveis. Eles permitem que diferentes componentes de uma aplicação se comuniquem de forma assíncrona, aumentando a resiliência e a flexibilidade.

Amazon Simple Notification Service (SNS): Um serviço de mensagens pub/sub (publicar/assinar) totalmente gerenciado. Permite enviar mensagens para um grande número de assinantes (aplicações, usuários, outros serviços AWS) de forma assíncrona. Ideal para notificações, fanout de eventos e comunicação entre microsserviços.
Amazon Simple Queue Service (SQS): Um serviço de fila de mensagens totalmente gerenciado que permite desacoplar e escalar microsserviços, sistemas distribuídos e aplicações serverless. As mensagens são armazenadas em uma fila até que um consumidor as processe. Suporta filas padrão (alta taxa de transferência, melhor esforço de ordenação) e filas FIFO (First-In, First-Out - garante ordenação e processamento

exatamente uma vez).

Amazon EventBridge: Um barramento de eventos serverless que facilita a conexão de aplicações usando dados de seus próprios aplicativos, software como serviço (SaaS) e serviços da AWS. Ele permite rotear eventos de várias fontes para destinos como AWS Lambda, Amazon SQS, Amazon SNS e outros. Ideal para arquiteturas orientadas a eventos e integração entre sistemas.
AWS Step Functions: Um serviço de fluxo de trabalho serverless que permite orquestrar funções Lambda e outros serviços AWS para construir aplicações complexas. Ele gerencia o estado, o tratamento de erros e as repetições, tornando a construção de fluxos de trabalho distribuídos mais fácil.
Amazon Kinesis: Uma plataforma para streaming de dados em tempo real. Inclui:
- Kinesis Data Streams: Para coletar e processar grandes fluxos de dados em tempo real.
- Kinesis Data Firehose: Para entregar fluxos de dados para destinos como S3, Redshift, Splunk e outros.
- Kinesis Data Analytics: Para processar e analisar dados de streaming em tempo real usando SQL ou Apache Flink.
Amazon Managed Streaming for Apache Kafka (MSK): Um serviço totalmente gerenciado para Apache Kafka, facilitando a construção e execução de aplicações que usam Apache Kafka para processamento de dados em tempo real.
AWS AppSync: Um serviço de GraphQL totalmente gerenciado que facilita o desenvolvimento de aplicações com dados em tempo real e offline. Ele lida com a conexão segura a fontes de dados, como DynamoDB, Lambda e bancos de dados relacionais.
Amazon API Gateway: Um serviço totalmente gerenciado que facilita a criação, publicação, manutenção, monitoramento e proteção de APIs em qualquer escala. Atua como um

front-door para aplicações, permitindo que os clientes acessem dados, lógica de negócios ou funcionalidades de seus serviços de backend.

AWS IoT Core: Um serviço gerenciado que permite que dispositivos conectados interajam de forma segura e fácil com aplicações em nuvem e outros dispositivos. Ideal para soluções de Internet das Coisas.

Comparações entre Serviços e Quando Usar Cada Um

SNS vs. SQS vs. EventBridge:

Característica	Amazon SNS	Amazon SQS	Amazon EventBridge
Modelo	Publicar/Assinar (Pub/Sub)	Fila de Mensagens	Barramento de Eventos
Entrega	Push (para múltiplos assinantes)	Pull (por um consumidor)	Roteamento de eventos
Casos de Uso	Notificações, fanout, microsserviços	Desacoplamento, processamento assíncrono	Arquiteturas orientadas a eventos, integração de SaaS
Durabilidade	Mensagens entregues para assinantes ativos	Mensagens persistentes na fila	Eventos roteados para destinos
Ordenação	Não garantida (padrão)	Não garantida (padrão), FIFO (garantida)	Não garantida
Retries	Políticas de repetição para endpoints HTTP/S	Configurado no consumidor	Configurado nas regras de destino

Use SNS quando: Você precisa enviar a mesma mensagem para múltiplos assinantes de forma assíncrona. Ideal para notificações (SMS, e-mail, push), fanout de eventos para múltiplos sistemas downstream, ou para acionar várias funções Lambda em paralelo.
Use SQS quando: Você precisa desacoplar componentes de uma aplicação, processar mensagens de forma assíncrona e garantir que cada mensagem seja processada uma vez (com filas FIFO). Ideal para filas de trabalho, processamento em lote, ou para lidar com picos de tráfego.
Use EventBridge quando: Você precisa construir arquiteturas orientadas a eventos, integrar aplicações com serviços AWS ou SaaS, ou rotear eventos de forma inteligente com base em regras. É mais poderoso que SNS para roteamento de eventos complexos e filtragem.

Kinesis Data Streams vs. SQS:

Kinesis Data Streams: Ideal para processamento de dados em tempo real, onde a ordem dos registros é importante e você precisa de múltiplos consumidores para processar o mesmo fluxo de dados. Ex: clickstreams, dados de IoT.
SQS: Ideal para desacoplar componentes e processar mensagens de forma assíncrona, onde cada mensagem é processada por um único consumidor (ou um grupo de consumidores para filas padrão). Ex: filas de tarefas, processamento de pedidos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon SNS:

Configurações: Crie tópicos, adicione assinantes (Lambda, SQS, HTTP/S, e-mail, SMS), defina políticas de acesso. Configure filas de dead-letter (DLQ) para mensagens não entregues.
Limitações: Tamanho máximo da mensagem (256 KB). Não garante a ordem de entrega para tópicos padrão.
Boas Práticas: Use para fanout de eventos. Integre com SQS para durabilidade e processamento assíncrono. Use DLQs para lidar com falhas de entrega.
Casos de Uso: Notificações de sistema, fanout de eventos de S3, acionamento de múltiplos microsserviços, alertas.

Amazon SQS:

Configurações: Crie filas (padrão ou FIFO), configure visibilidade de mensagens, atraso, retenção, políticas de acesso. Configure DLQs.
Limitações: Tamanho máximo da mensagem (256 KB). Filas FIFO têm menor throughput que filas padrão.
Boas Práticas: Use filas FIFO para workloads que exigem ordenação e processamento exatamente uma vez. Use filas padrão para alta taxa de transferência. Monitore o número de mensagens visíveis e invisíveis.
Casos de Uso: Filas de trabalho, processamento de pedidos, desacoplamento de microsserviços, processamento de dados em lote.

Amazon EventBridge:

Configurações: Crie barramentos de eventos, defina regras com padrões de eventos e destinos. Use o Schema Registry para gerenciar esquemas de eventos.
Limitações: Limites no número de regras e destinos por regra.
Boas Práticas: Use para construir arquiteturas orientadas a eventos. Use regras para filtrar e rotear eventos para destinos específicos. Use o Schema Registry para garantir a compatibilidade de eventos.
Casos de Uso: Integração entre serviços AWS, integração com SaaS, auditoria de eventos, automação de fluxos de trabalho.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura Orientada a Eventos: Use EventBridge como o hub central para eventos, com produtores publicando eventos e consumidores reagindo a eles. Isso promove o desacoplamento e a escalabilidade.
Padrões de Segurança: Use IAM Roles para conceder permissões mínimas aos produtores e consumidores de mensagens. Criptografe mensagens em trânsito e em repouso. Use políticas de acesso para controlar quem pode publicar ou consumir mensagens.
Resiliência: Use filas de mensagens (SQS) para absorver picos de tráfego e garantir a entrega de mensagens. Use DLQs para lidar com mensagens que não podem ser processadas. Implemente retries e backoff exponenciais.
Governança: Use AWS CloudTrail para auditar as operações de API em serviços de mensageria. Use AWS Config para monitorar a conformidade das configurações.

Estratégias de Migração e Modernização

Migração: Substitua sistemas de mensageria on-premises por SQS e SNS. Migre sistemas de integração legados para EventBridge para uma abordagem orientada a eventos.
Modernização: Refatore aplicações monolíticas em microsserviços que se comunicam via eventos e filas. Adote Step Functions para orquestrar fluxos de trabalho complexos e de longa duração.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce precisa processar pedidos de forma assíncrona. Após um pedido ser feito, várias ações precisam ser executadas: atualizar o estoque, enviar e-mail de confirmação, notificar o sistema de logística e atualizar o CRM.

Decisão Arquitetural: O serviço de pedidos publica uma mensagem em uma fila SQS. Um consumidor (por exemplo, uma função Lambda) lê a mensagem da fila e orquestra as ações subsequentes usando AWS Step Functions. O Step Functions pode chamar funções Lambda para atualizar o estoque e o CRM, e publicar em um tópico SNS para enviar o e-mail de confirmação e notificar o sistema de logística. Isso garante que o processamento do pedido seja robusto, escalável e tolerante a falhas.

Armadilha Comum: Usar SNS para desacoplar componentes quando SQS seria mais apropriado, resultando em mensagens perdidas se os assinantes não estiverem disponíveis. Ou, inversamente, usar SQS para fanout de eventos, o que exigiria que cada consumidor fizesse polling da fila, em vez de receber a mensagem por push.

Domínio 3: Melhoria Contínua para Soluções Existentes

Este domínio concentra-se na otimização e aprimoramento de arquiteturas existentes para melhorar a performance, resiliência, segurança e eficiência operacional. O foco é garantir que as soluções AWS continuem a atender aos requisitos de negócios em evolução e às melhores práticas da indústria.

Tópicos e Subtópicos:

3.1. Arquitetar soluções para alta disponibilidade e resiliência.

Conceitos Fundamentais e Avançados

Alta disponibilidade e resiliência são pilares críticos de qualquer arquitetura de nuvem robusta. A AWS oferece uma série de serviços e padrões para garantir que as aplicações permaneçam operacionais mesmo diante de falhas.

Estratégias de Recuperação de Desastres (DR): A recuperação de desastres envolve a preparação para a recuperação de um evento que interrompe as operações de negócios. As estratégias de DR são classificadas com base em dois objetivos principais:
- Recovery Time Objective (RTO): O tempo máximo aceitável para restaurar o serviço após um desastre. Um RTO baixo significa que o serviço deve ser restaurado rapidamente.
- Recovery Point Objective (RPO): A quantidade máxima aceitável de perda de dados medida em tempo. Um RPO baixo significa que pouca ou nenhuma perda de dados é tolerada. As estratégias de DR na AWS incluem:
  - Backup e Restauração: O método mais simples e de menor custo. Os dados são copiados para outra região ou conta e restaurados em caso de desastre. RTO e RPO são mais altos.
  - Piloto Leve (Pilot Light): Uma versão mínima da aplicação é mantida em execução em uma região de DR. Em caso de desastre, os recursos são escalados para restaurar a funcionalidade completa. RTO e RPO são menores que backup e restauração.
  - Warm Standby: Uma versão em escala reduzida da aplicação está sempre em execução na região de DR, pronta para assumir a carga. RTO e RPO são ainda menores.
  - Multi-Site Ativo-Ativo (Multi-Region Active-Active): A aplicação é executada simultaneamente em múltiplas regiões, com o tráfego roteado para ambas. Oferece o menor RTO e RPO (próximo de zero), mas é a estratégia mais cara e complexa.
AWS Well-Architected Framework (Pilar de Confiabilidade): Este pilar fornece diretrizes para projetar sistemas que podem se recuperar de falhas e continuar a funcionar conforme o esperado. Abrange tópicos como recuperação de desastres, design para falhas, gerenciamento de mudanças e monitoramento.
Amazon Route 53: Além de ser um serviço DNS, o Route 53 é fundamental para a resiliência, oferecendo:
- Roteamento de Failover: Roteia o tráfego para um recurso alternativo se o recurso primário se tornar não saudável.
- Roteamento Baseado em Latência: Roteia o tráfego para a região da AWS que oferece a menor latência para o usuário.
AWS Global Accelerator: Melhora a disponibilidade e a performance de aplicações para usuários globais, roteando o tráfego para o endpoint mais saudável e mais próximo usando a rede global da AWS.
Elastic Load Balancing (ELB): Distribui o tráfego de entrada entre múltiplas instâncias de destino em múltiplas Zonas de Disponibilidade, aumentando a disponibilidade e a tolerância a falhas.
Amazon EC2 Auto Scaling: Ajusta automaticamente o número de instâncias EC2 em seu grupo de Auto Scaling em resposta a condições definidas, garantindo que a aplicação tenha a capacidade necessária para lidar com a demanda e se recupere de falhas de instâncias.
Amazon CloudFront: Atua como um CDN, armazenando em cache o conteúdo em edge locations próximos aos usuários, o que melhora a performance e a resiliência ao reduzir a carga sobre os servidores de origem.
AWS Shield e AWS WAF: Serviços de segurança que protegem contra ataques DDoS (Shield) e fornecem proteção em nível de aplicação contra exploits web comuns (WAF).
Padrões de Resiliência:
- Circuit Breaker: Impede que uma aplicação tente repetidamente uma operação que provavelmente falhará, protegendo o sistema de sobrecarga e permitindo que ele se recupere.
- Sagas: Um padrão para gerenciar transações distribuídas, garantindo a consistência dos dados em um sistema de microsserviços, mesmo quando as operações falham.

Comparações entre Serviços e Quando Usar Cada Um

As estratégias de DR (Backup e Restauração, Piloto Leve, Warm Standby, Multi-Site Ativo-Ativo) são escolhas que dependem diretamente dos requisitos de RTO e RPO. Quanto menores os RTO e RPO desejados, mais complexa e cara será a estratégia.

Configurações, Limitações, Boas Práticas e Casos de Uso

Estratégias de DR:

Configurações: Envolvem a replicação de dados (via S3 Cross-Region Replication, DynamoDB Global Tables, RDS Read Replicas ou DMS), o provisionamento de infraestrutura na região de DR e a configuração de roteamento de DNS (Route 53) para failover.
Limitações: O custo e a complexidade aumentam significativamente à medida que RTO e RPO diminuem.
Boas Práticas: Defina RTO e RPO claros para cada aplicação. Teste regularmente seu plano de DR. Automatize o processo de failover e recuperação sempre que possível.
Casos de Uso:
- Backup e Restauração: Dados de arquivos, backups de bancos de dados não críticos.
- Piloto Leve/Warm Standby: Aplicações de negócios críticas que podem tolerar alguns minutos ou horas de inatividade.
- Multi-Site Ativo-Ativo: Aplicações de missão crítica que exigem alta disponibilidade contínua (ex: serviços financeiros, e-commerce de alto volume).

Amazon EC2 Auto Scaling:

Configurações: Defina um grupo de Auto Scaling, especifique o tamanho mínimo, desejado e máximo, configure políticas de escalabilidade (simples, baseada em etapas, de rastreamento de destino), e health checks.
Limitações: A escalabilidade leva tempo para que novas instâncias sejam provisionadas e inicializadas.
Boas Práticas: Use métricas de utilização de CPU ou requisições de Load Balancer para escalar. Use warm pools para reduzir o tempo de inicialização de novas instâncias. Monitore o grupo de Auto Scaling com CloudWatch.
Casos de Uso: Aplicações web, microsserviços, qualquer workload que precise de escalabilidade elástica e resiliência a falhas de instâncias.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura Multi-AZ: Implante recursos em pelo menos duas Zonas de Disponibilidade dentro de uma região para proteger contra falhas de AZ. Use Load Balancers e Auto Scaling para distribuir o tráfego.
Arquitetura Multi-Região: Para os requisitos mais rigorosos de RTO/RPO, implante a aplicação em múltiplas regiões. Use serviços como Route 53 e Global Accelerator para roteamento de tráfego e failover.
Padrões de Segurança: Implemente o princípio do menor privilégio. Use Security Groups e NACLs. Criptografe dados em repouso e em trânsito. Use AWS Shield e WAF para proteção de borda.
Resiliência: Projete para falhas. Implemente timeouts, retries e circuit breakers. Use filas e mensageria para desacoplar componentes. Teste a resiliência regularmente com Chaos Engineering.
Governança: Use AWS Config para monitorar a conformidade das configurações de resiliência. Use AWS Resilience Hub para avaliar e gerenciar a resiliência de suas aplicações.

Estratégias de Migração e Modernização

Modernização para Resiliência: Ao modernizar, refatore aplicações para serem stateless e use serviços gerenciados que são inerentemente resilientes (ex: DynamoDB Global Tables, Aurora Multi-Master). Adote padrões de microsserviços para isolar falhas.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de streaming de vídeo de missão crítica precisa de um RTO de segundos e um RPO de zero para seus dados de sessão de usuário.

Decisão Arquitetural: Implementar uma estratégia de DR Multi-Site Ativo-Ativo usando DynamoDB Global Tables para os dados de sessão (que oferece replicação multi-região ativa-ativa com RPO próximo de zero) e Amazon Route 53 com roteamento de failover para direcionar o tráfego para a região saudável.

Armadilha Comum: Não testar o plano de recuperação de desastres regularmente. Um plano de DR não testado é um plano de DR que provavelmente falhará quando mais for necessário. Outra armadilha é superestimar a resiliência de um serviço sem entender suas limitações (ex: acreditar que Multi-AZ para RDS protege contra falhas de região inteira).

3.2. Arquitetar soluções para otimização de performance.

Conceitos Fundamentais e Avançados

A otimização de performance na AWS envolve a seleção e configuração de recursos para garantir que as aplicações respondam rapidamente e processem dados de forma eficiente, ao mesmo tempo em que se equilibra com os custos. O Pilar de Eficiência de Performance do AWS Well-Architected Framework fornece diretrizes para isso.

AWS Well-Architected Framework (Pilar de Eficiência de Performance): Este pilar foca na capacidade de usar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda. Abrange tópicos como seleção de recursos, monitoramento, otimização de rede e armazenamento.
Otimização de Computação:
- Escolha de Instâncias: Selecionar o tipo de instância EC2 correto (família, tamanho) para a workload. Instâncias otimizadas para computação, memória, armazenamento ou rede.
- Otimização de Contêineres: Otimizar imagens de contêiner para serem pequenas e eficientes. Usar Fargate para abstrair o gerenciamento de servidores.
- Lambda Provisioned Concurrency: Pre-inicializa instâncias de funções Lambda para reduzir cold starts, melhorando a latência para aplicações sensíveis ao tempo.
Otimização de Armazenamento:
- Escolha de Classes de S3: Usar a classe de armazenamento S3 apropriada (Standard, IA, Glacier) com base na frequência de acesso para otimizar custos e performance de recuperação.
- Otimização de EBS: Selecionar o tipo de volume EBS correto (gp3, io2 Block Express) e provisionar IOPS/throughput adequados para a workload.
- Otimização de EFS/FSx: Escolher os modos de performance e throughput corretos para EFS, e o tipo de FSx adequado para o caso de uso (Lustre para HPC, Windows para SMB).
Otimização de Banco de Dados:
- Escolha de Tipo de DB: Selecionar o tipo de banco de dados (relacional, NoSQL, etc.) que melhor se adapta aos padrões de acesso e requisitos de escalabilidade da aplicação.
- Otimização de Consultas: Otimizar consultas SQL e NoSQL para reduzir o tempo de execução e o consumo de recursos.
- Caching com ElastiCache: Usar Amazon ElastiCache (Redis ou Memcached) para armazenar em cache dados frequentemente acessados, reduzindo a carga sobre o banco de dados e melhorando a latência.
Otimização de Rede:
- Direct Connect: Para conexões on-premises de alta largura de banda e baixa latência.
- Global Accelerator: Para roteamento de tráfego global otimizado para aplicações não-HTTP/HTTPS.
- CloudFront: Para entrega de conteúdo com baixa latência e alta taxa de transferência via CDN.
Caching: Implementar estratégias de cache em diferentes camadas da arquitetura (CDN com CloudFront, cache de aplicação com ElastiCache, cache de DNS com Route 53).
Content Delivery Networks (CDNs): Redes de servidores distribuídos geograficamente que entregam conteúdo web e multimídia para usuários com base em sua localização, melhorando a velocidade de carregamento e reduzindo a carga sobre os servidores de origem.

Comparações entre Serviços e Quando Usar Cada Um

ElastiCache (Redis vs. Memcached):
- Redis: Mais rico em recursos, suporta estruturas de dados complexas (listas, sets, hashes), persistência de dados, replicação e clustering. Ideal para caching, leaderboards, contadores, filas de mensagens.
- Memcached: Mais simples, focado em caching de objetos. Ideal para caching de dados simples e escalabilidade horizontal.

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Computação (EC2):

Configurações: Monitore a utilização de CPU, memória e rede. Use o AWS Compute Optimizer para recomendações de dimensionamento correto.
Limitações: A super-provisionamento leva a custos desnecessários; o sub-provisionamento leva a problemas de performance.
Boas Práticas: Use o tipo de instância mais adequado para a workload. Use Auto Scaling para ajustar a capacidade dinamicamente. Considere instâncias com processadores otimizados (Graviton2/3) para melhor performance/custo.
Casos de Uso: Aplicações web de alto tráfego, microsserviços, processamento de dados.

Amazon ElastiCache:

Configurações: Escolha o motor (Redis/Memcached), tipo de nó, número de nós, Multi-AZ, grupos de segurança.
Limitações: O cache é volátil (dados podem ser perdidos). Requer lógica de aplicação para gerenciar o cache.
Boas Práticas: Armazene dados frequentemente acessados e que não mudam com frequência. Implemente estratégias de cache-aside ou write-through. Monitore as taxas de cache hit e miss.
Casos de Uso: Caching de resultados de consultas de banco de dados, dados de sessão de usuário, rankings de jogos, feeds de notícias.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Caching em Camadas: Combine CDN (CloudFront) para cache de borda, ElastiCache para cache de aplicação/banco de dados e cache de objetos em S3 para dados estáticos.
Padrões de Segurança: Use IAM Roles para acesso a serviços de cache. Criptografe dados em trânsito e em repouso no cache (Redis suporta criptografia).
Resiliência: Use ElastiCache com Multi-AZ para alta disponibilidade. Implemente lógica de fallback na aplicação caso o cache não esteja disponível.
Governança: Use AWS Config para monitorar a conformidade das configurações de performance. Use AWS Trusted Advisor para recomendações de otimização de performance.

Estratégias de Migração e Modernização

Modernização para Performance: Refatore aplicações para serem stateless e usem cache extensivamente. Migre para serviços serverless e gerenciados que oferecem escalabilidade e performance otimizadas. Adote microsserviços para isolar e otimizar componentes individualmente.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de e-commerce sofre com alta latência nas consultas ao banco de dados durante picos de tráfego, impactando a experiência do usuário.

Decisão Arquitetural: Implementar Amazon ElastiCache (Redis) para armazenar em cache os resultados de consultas frequentemente acessadas (ex: detalhes de produtos, categorias). A aplicação primeiro verifica o cache; se os dados não estiverem lá, consulta o banco de dados e armazena o resultado no cache para futuras requisições.

Armadilha Comum: Caching de dados que mudam com frequência, levando a dados desatualizados. Não invalidar o cache corretamente quando os dados de origem mudam. Não monitorar o cache hit ratio, o que pode indicar que o cache não está sendo eficaz.

3.3. Arquitetar soluções para monitoramento e observabilidade.

Conceitos Fundamentais e Avançados

Monitoramento e observabilidade são essenciais para entender o comportamento das aplicações, identificar problemas, otimizar performance e garantir a segurança. A AWS oferece um conjunto robusto de ferramentas para coletar, analisar e visualizar dados de telemetria.

Amazon CloudWatch: Um serviço de monitoramento e gerenciamento que fornece dados e insights acionáveis para AWS, aplicações híbridas e on-premises. Ele coleta e rastreia métricas, coleta e monitora arquivos de log, e dispara alarmes com base em limites definidos.
- Métricas: Pontos de dados que representam a performance de um recurso ao longo do tempo (ex: utilização de CPU, I/O de disco, requisições de Load Balancer).
- Logs: Registros de eventos de aplicações e serviços (ex: logs de EC2, Lambda, VPC Flow Logs).
- Alarmes: Acionam ações (ex: notificação SNS, Auto Scaling) quando uma métrica excede um limite.
- Dashboards: Visualizações personalizadas de métricas e logs.
AWS X-Ray: Ajuda desenvolvedores a analisar e depurar aplicações distribuídas, como as construídas usando uma arquitetura de microsserviços. Ele fornece uma visão de ponta a ponta das requisições à medida que elas viajam através dos componentes da aplicação, mostrando o desempenho da aplicação, gargalos e erros.
AWS CloudTrail: Registra as chamadas de API da AWS feitas em sua conta, incluindo as feitas por usuários, funções e serviços da AWS. Esses logs de eventos podem ser usados para auditoria de segurança, rastreamento de alterações de recursos e solução de problemas operacionais.
AWS Config: Permite avaliar, auditar e avaliar as configurações de seus recursos da AWS. Ele monitora continuamente as configurações dos recursos e as compara com as melhores práticas ou políticas definidas, alertando sobre não conformidades.
- Conformance Packs: Coleções de regras e ações do AWS Config que podem ser implantadas como uma única entidade para ajudar a auditar e relatar a conformidade de um grupo de recursos.
Amazon Kinesis (para ingestão de logs e métricas): Pode ser usado para coletar grandes volumes de logs e métricas em tempo real de várias fontes para processamento e análise downstream.
AWS Systems Manager (OpsCenter, Explorer): Fornece uma visão centralizada de dados operacionais de seus recursos da AWS e permite automatizar a identificação e remediação de problemas.
AWS Health Dashboard: Fornece uma visão personalizada da saúde dos serviços da AWS e dos eventos que podem afetar seus recursos.
AWS Trusted Advisor: Um serviço que fornece recomendações para otimizar seus recursos da AWS em cinco categorias: otimização de custos, performance, segurança, tolerância a falhas e limites de serviço.
Feature flags com CloudWatch Evidently: Permite que os desenvolvedores lancem novos recursos para um subconjunto de usuários, monitorem seu desempenho e impacto, e desativem ou ativem o recurso rapidamente com base em métricas em tempo real. Isso é parte de uma estratégia de observability-driven development.

Comparações entre Serviços e Quando Usar Cada Um

CloudWatch vs. X-Ray vs. CloudTrail:

Característica	Amazon CloudWatch	AWS X-Ray	AWS CloudTrail
Propósito	Monitoramento de performance e logs	Rastreamento de requisições distribuídas	Auditoria de API calls e governança
Dados Coletados	Métricas, logs, eventos	Traces de requisições, segmentos, subsegmentos	Eventos de API (quem, o quê, quando, onde)
Casos de Uso	Alarmes, dashboards, escalabilidade	Depuração de microsserviços, análise de latência	Auditoria de segurança, conformidade, solução de problemas operacionais
Visão	Saúde e performance de recursos	Fluxo de requisições através de serviços	Histórico de atividades na conta

Use CloudWatch quando: Você precisa monitorar a saúde e a performance de seus recursos e aplicações, coletar logs e configurar alarmes. É a ferramenta central para monitoramento na AWS.
Use X-Ray quando: Você precisa entender o fluxo de requisições através de uma aplicação distribuída, identificar gargalos de performance e depurar erros em microsserviços. Complementa o CloudWatch para observabilidade de aplicações.
Use CloudTrail quando: Você precisa auditar as atividades em sua conta AWS para segurança, conformidade e solução de problemas. Ele registra todas as ações realizadas na conta.

Configurações, Limitações, Boas Práticas e Casos de Uso

Amazon CloudWatch:

Configurações: Crie alarmes com base em métricas, configure dashboards personalizados, envie logs de aplicações para CloudWatch Logs, use CloudWatch Events para automação.
Limitações: Retenção de logs e métricas pode ter custos. Granularidade de métricas padrão (1 minuto).
Boas Práticas: Defina alarmes para métricas críticas. Use logs estruturados (JSON) para facilitar a análise. Crie dashboards para visibilidade rápida. Use CloudWatch Agent para coletar métricas e logs de instâncias EC2 e on-premises.
Casos de Uso: Monitoramento de utilização de recursos, detecção de erros de aplicação, alertas de segurança, escalabilidade automática.

AWS X-Ray:

Configurações: Habilite o X-Ray para seus serviços (Lambda, EC2, ECS), configure o SDK do X-Ray em sua aplicação, use o X-Ray Daemon para enviar dados de trace.
Limitações: Overhead de performance mínimo na aplicação. Requer instrumentação do código.
Boas Práticas: Instrumente todos os componentes da aplicação. Use anotações e metadados para adicionar contexto aos traces. Monitore o mapa de serviço do X-Ray para identificar dependências e gargalos.
Casos de Uso: Depuração de aplicações distribuídas, análise de latência de ponta a ponta, otimização de performance de microsserviços.

AWS Config:

Configurações: Habilite o AWS Config para os tipos de recursos desejados, crie regras gerenciadas ou personalizadas, configure conformance packs.
Limitações: Custos baseados no número de configurações gravadas e regras avaliadas.
Boas Práticas: Use regras para impor padrões de segurança e conformidade. Use conformance packs para auditorias de conformidade em larga escala. Integre com AWS Security Hub para agregação de descobertas de segurança.
Casos de Uso: Auditoria de conformidade, monitoramento de alterações de configuração, detecção de desvios de segurança.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Observabilidade Centralizada: Agregue logs e métricas de todas as contas e regiões em uma conta de log centralizada. Use CloudWatch, X-Ray e CloudTrail para uma visão unificada.
Padrões de Segurança: Use CloudTrail para auditar todas as ações na conta. Use AWS Config para monitorar a conformidade de segurança. Integre com Security Hub para uma visão consolidada da postura de segurança.
Resiliência: Use métricas e alarmes do CloudWatch para detectar problemas e acionar ações de recuperação automática (ex: Auto Scaling, Lambda).
Governança: Use AWS Config para garantir que os recursos estejam configurados de acordo com as políticas da organização. Use CloudTrail para rastrear quem fez o quê e quando.

Estratégias de Migração e Modernização

Modernização para Observabilidade: Ao modernizar, adote uma abordagem de observability-driven development. Instrumente aplicações com X-Ray. Use logs estruturados. Implemente feature flags com CloudWatch Evidently para lançamentos controlados e monitoramento de impacto.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação de microsserviços está apresentando alta latência e erros intermitentes, mas é difícil identificar a causa raiz devido à complexidade da arquitetura distribuída.

Decisão Arquitetural: Implementar AWS X-Ray para rastrear as requisições através de todos os microsserviços. O X-Ray fornecerá um mapa de serviço visual, mostrando as dependências, latências em cada etapa e quaisquer erros, permitindo identificar rapidamente o serviço ou componente que está causando o problema.

Armadilha Comum: Coletar muitos dados de monitoramento sem ter um plano para analisá-los ou agir sobre eles, resultando em

ruído e dificultando a identificação de problemas reais. Outra armadilha é não configurar alarmes adequados, o que significa que os problemas só são descobertos quando já estão impactando os usuários.

3.4. Arquitetar soluções para segurança contínua.

Conceitos Fundamentais e Avançados

A segurança na AWS é uma responsabilidade compartilhada entre a AWS e o cliente. A AWS é responsável pela segurança da nuvem, enquanto o cliente é responsável pela segurança na nuvem. Este domínio foca em como arquitetar soluções para manter uma postura de segurança robusta e contínua, utilizando os serviços de segurança da AWS.

AWS Security Hub: Fornece uma visão abrangente de alto nível da sua postura de segurança na AWS. Ele agrega, organiza e prioriza seus alertas de segurança (ou descobertas) de vários serviços da AWS (como GuardDuty, Inspector, Macie) e de produtos de parceiros da AWS. Permite que você execute verificações de segurança automatizadas em relação aos padrões da indústria e às melhores práticas.
Amazon GuardDuty: Um serviço de detecção de ameaças que monitora continuamente atividades maliciosas e comportamentos não autorizados para proteger suas contas e workloads da AWS. Ele usa machine learning, detecção de anomalias e inteligência de ameaças para identificar ameaças como criptomineração, acesso não autorizado a dados e ataques de negação de serviço.
Amazon Detective: Um serviço que facilita a análise, investigação e identificação da causa raiz de descobertas de segurança ou atividades suspeitas. Ele coleta automaticamente dados de log de seus recursos da AWS e usa machine learning, análise estatística e teoria dos grafos para construir um modelo unificado de suas atividades, tornando mais fácil conduzir investigações de segurança.
AWS Inspector: Um serviço de avaliação de vulnerabilidades automatizado que ajuda a melhorar a segurança e a conformidade de aplicações implantadas na AWS. Ele descobre automaticamente e avalia continuamente instâncias EC2, imagens de contêiner no Amazon ECR e funções Lambda em busca de vulnerabilidades e desvios de melhores práticas.
AWS WAF (Web Application Firewall): Ajuda a proteger suas aplicações web ou APIs contra exploits web comuns que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos excessivos. Permite criar regras personalizadas para bloquear ou permitir tráfego com base em condições que você especifica.
AWS Shield: Um serviço de proteção contra ataques de negação de serviço distribuída (DDoS) gerenciado que protege aplicações em execução na AWS. Oferece dois níveis: Standard (proteção automática para todos os clientes AWS) e Advanced (proteção aprimorada para aplicações críticas, com detecção e mitigação mais sofisticadas).
AWS Firewall Manager: Um serviço de gerenciamento de segurança que permite configurar e gerenciar centralmente regras de firewall em suas contas e aplicações na AWS Organizations. Simplifica a implantação e a auditoria de regras de AWS WAF, AWS Shield Advanced, Security Groups, AWS Network Firewall e Route 53 Resolver DNS Firewall.
AWS Certificate Manager (ACM): Facilita o provisionamento, gerenciamento e implantação de certificados SSL/TLS para uso com serviços AWS (como ELB, CloudFront, API Gateway). Ajuda a proteger a comunicação de rede e estabelecer a identidade de sites e aplicações.
AWS Secrets Manager: Ajuda a proteger o acesso às suas aplicações, serviços e recursos de TI. Permite que você gire, gerencie e recupere credenciais de banco de dados, chaves de API e outros segredos durante seu ciclo de vida. Reduz a necessidade de codificar segredos em texto simples.
AWS Systems Manager Parameter Store: Fornece armazenamento seguro e hierárquico para dados de configuração e gerenciamento de segredos. Pode ser usado para armazenar senhas, strings de conexão de banco de dados, códigos de licença e outros valores que precisam ser acessados por suas aplicações.
AWS Single Sign-On (AWS SSO) / AWS IAM Identity Center: Um serviço de nuvem que facilita o gerenciamento centralizado do acesso a várias contas AWS e aplicações de negócios. Permite que os usuários façam login uma vez para acessar todos os seus recursos e aplicações atribuídos.
Princípio do Menor Privilégio: Uma prática de segurança fundamental que afirma que cada usuário, programa ou processo deve ter apenas as permissões mínimas necessárias para executar sua função. Na AWS, isso é implementado através de políticas de IAM granulares.
Automação de Segurança: Utilizar serviços como AWS Security Hub e AWS Config Rules para automatizar a detecção de não conformidades de segurança e, em alguns casos, a remediação.

Comparações entre Serviços e Quando Usar Cada Um

AWS Security Hub vs. Amazon GuardDuty vs. Amazon Detective vs. AWS Inspector:

Serviço	Propósito Principal	Tipo de Análise	Casos de Uso
Security Hub	Visão consolidada da postura de segurança, conformidade	Agregação e priorização de descobertas, verificações de padrões	Gerenciamento centralizado de segurança, auditoria de conformidade, relatórios
GuardDuty	Detecção de ameaças e atividades maliciosas	Machine learning, detecção de anomalias, inteligência de ameaças	Identificação de comprometimento de contas, acesso não autorizado, criptomineração
Detective	Investigação e análise da causa raiz de incidentes	Análise de grafos, machine learning, dados de log	Investigação forense, identificação de atividades suspeitas, análise de comportamento
Inspector	Avaliação de vulnerabilidades em workloads	Análise de vulnerabilidades em EC2, contêineres, Lambda	Identificação de CVEs, desvios de melhores práticas de segurança em aplicações

Esses serviços são complementares e devem ser usados em conjunto para uma postura de segurança abrangente. O Security Hub atua como um orquestrador e agregador, enquanto GuardDuty, Detective e Inspector fornecem insights específicos sobre ameaças, investigações e vulnerabilidades, respectivamente.

AWS WAF vs. AWS Shield:

AWS WAF: Protege aplicações web contra ataques em nível de aplicação (Camada 7), como injeção de SQL, cross-site scripting (XSS). Você define as regras para permitir ou bloquear o tráfego.
AWS Shield: Protege contra ataques DDoS (Distributed Denial of Service) em níveis de rede (Camada 3) e transporte (Camada 4), e também em nível de aplicação (Camada 7) com o Shield Advanced. É uma proteção mais ampla contra ataques de negação de serviço.

Configurações, Limitações, Boas Práticas e Casos de Uso

AWS Security Hub:

Configurações: Habilite o Security Hub, integre com outros serviços AWS (GuardDuty, Config, Macie), configure padrões de segurança (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark).
Limitações: Requer a habilitação de outros serviços de segurança para coletar descobertas. Não é uma ferramenta de remediação direta.
Boas Práticas: Use o Security Hub como seu painel central de segurança. Automatize a resposta a descobertas usando EventBridge e Lambda. Revise regularmente as descobertas e priorize a remediação.
Casos de Uso: Gerenciamento centralizado de segurança, auditoria de conformidade, resposta a incidentes.

Amazon GuardDuty:

Configurações: Habilite o GuardDuty em todas as regiões. Configure notificações para descobertas de alta severidade.
Limitações: Não bloqueia o tráfego. Apenas detecta ameaças.
Boas Práticas: Habilite o GuardDuty em todas as contas e regiões. Integre as descobertas com o Security Hub e sistemas de SIEM. Use para identificar atividades suspeitas em tempo real.
Casos de Uso: Detecção de comprometimento de credenciais, acesso não autorizado a instâncias, uso de portas incomuns, criptomineração.

AWS KMS (Key Management Service):

Configurações: Crie chaves KMS (chaves de cliente gerenciadas - CMKs), defina políticas de chave, configure rotação de chaves. Use chaves multi-região para replicação de chaves entre regiões.
Limitações: Custos por chave e por requisição de API. Limites de taxa de requisições.
Boas Práticas: Use KMS para criptografar dados em repouso em serviços AWS (S3, EBS, RDS, Lambda). Use chaves separadas para diferentes aplicações ou ambientes. Implemente o princípio do menor privilégio para acesso a chaves.
Casos de Uso: Criptografia de dados em repouso, gerenciamento de chaves de criptografia, assinaturas digitais.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura de Segurança em Camadas (Defense in Depth): Implemente segurança em todas as camadas da arquitetura, desde a rede (VPC, Security Groups, NACLs, WAF, Shield) até a aplicação (IAM, Secrets Manager, KMS) e os dados (criptografia).
Padrões de Segurança: Implemente o princípio do menor privilégio em todas as políticas de IAM. Use roles cross-account para acesso seguro entre contas. Automatize a detecção e resposta a incidentes de segurança.
Resiliência: Use serviços de segurança gerenciados pela AWS que são inerentemente resilientes (ex: Shield, WAF). Projete para que as falhas de segurança não levem a uma interrupção completa do serviço.
Governança: Use AWS Organizations e SCPs para impor políticas de segurança em toda a organização. Use AWS Config e Conformance Packs para monitorar a conformidade de segurança. Realize auditorias de segurança regulares.

Estratégias de Migração e Modernização

Modernização para Segurança: Ao modernizar, adote uma abordagem de segurança shift-left, integrando a segurança no ciclo de vida de desenvolvimento. Use ferramentas de segurança automatizadas. Migre de gerenciamento de segredos manual para AWS Secrets Manager. Adote ABAC para gerenciamento de permissões escalável.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa precisa garantir que nenhuma instância EC2 seja lançada sem criptografia de volume EBS em sua conta de produção, e que todas as atividades suspeitas sejam detectadas e investigadas.

Decisão Arquitetural: Usar AWS Config para criar uma regra que detecta instâncias EC2 com volumes EBS não criptografados e, opcionalmente, uma função Lambda para remediar automaticamente. Habilitar Amazon GuardDuty para detecção de ameaças e Amazon Detective para investigação de incidentes. As descobertas de GuardDuty e Config seriam agregadas no AWS Security Hub para uma visão centralizada.

Armadilha Comum: Conceder permissões excessivas (privilégio elevado) a usuários ou funções, violando o princípio do menor privilégio. Não revisar regularmente as políticas de IAM e as configurações de segurança. Confiar apenas em uma única camada de segurança, em vez de implementar uma defesa em profundidade.

Domínio 4: Otimização de Custos e Performance

Este domínio foca na capacidade de projetar soluções que sejam eficientes em termos de custo e performance. Isso envolve a seleção de serviços e recursos apropriados, a implementação de estratégias de otimização e o monitoramento contínuo para garantir que os gastos sejam controlados e que a performance atenda aos requisitos.

Tópicos e Subtópicos:

4.1. Arquitetar soluções para otimização de custos.

Conceitos Fundamentais e Avançados

A otimização de custos na AWS é um processo contínuo que visa maximizar o valor dos investimentos na nuvem. O Pilar de Otimização de Custos do AWS Well-Architected Framework fornece diretrizes para alcançar esse objetivo.

AWS Well-Architected Framework (Pilar de Otimização de Custos): Este pilar foca na capacidade de executar sistemas para entregar valor de negócio ao menor preço. Abrange tópicos como adoção de um modelo de consumo, medição da eficiência geral, interrupção de gastos com trabalho indiferenciado e análise e atribuição de gastos.
Modelos de Preços da AWS:
- On-Demand: Pague por capacidade de computação por hora ou segundo, sem compromisso de longo prazo. Ideal para workloads imprevisíveis ou de curta duração.
- Reserved Instances (RIs): Compromisso de uso de instâncias EC2, RDS, Redshift, ElastiCache por 1 ou 3 anos em troca de um desconto significativo (até 75% em comparação com On-Demand). Podem ser Standard (menos flexíveis) ou Convertible (mais flexíveis).
- Savings Plans: Um modelo de precificação flexível que oferece preços mais baixos em troca de um compromisso de uso consistente (medido em USD/hora) por um período de 1 ou 3 anos. Abrangem EC2, Fargate e Lambda. Oferecem mais flexibilidade que RIs.
- Spot Instances: Permitem que você solicite capacidade EC2 não utilizada da AWS com grandes descontos (até 90% em comparação com On-Demand). Ideal para workloads tolerantes a interrupções, como processamento em lote, renderização ou testes.
Otimização de Recursos:
- Dimensionamento Correto (Rightsizing): Ajustar o tamanho dos recursos (instâncias EC2, volumes EBS, etc.) para corresponder à demanda da workload, evitando o super-provisionamento.
- Elasticidade: Usar Auto Scaling para escalar recursos para cima e para baixo automaticamente com base na demanda, garantindo que você pague apenas pela capacidade que realmente usa.
- Desligamento de Recursos Ociosos: Identificar e desligar recursos que não estão sendo utilizados (ex: instâncias de desenvolvimento fora do horário comercial).
Gerenciamento de Custos e Visibilidade:
- AWS Cost Explorer: Uma ferramenta para visualizar, entender e gerenciar seus custos e uso da AWS ao longo do tempo. Permite analisar tendências, identificar áreas de alto custo e prever gastos futuros.
- AWS Budgets: Permite definir orçamentos personalizados que o alertam quando seus custos ou uso excedem (ou estão previstos para exceder) seus limites orçamentários.
- AWS Cost and Usage Report (CUR): Fornece um conjunto abrangente de dados sobre seus custos e uso da AWS, permitindo análises detalhadas e integração com ferramentas de BI.
- AWS Compute Optimizer: Um serviço que usa machine learning para analisar a configuração e as métricas de utilização de seus recursos de computação da AWS (EC2, Auto Scaling Groups, Lambda, EBS, Fargate) e recomenda os recursos ideais para reduzir custos e melhorar a performance.
- AWS Trusted Advisor: Oferece recomendações para otimização de custos, performance, segurança, tolerância a falhas e limites de serviço.
Estratégias Multi-Conta para Otimização de Custos: Usar AWS Organizations para consolidação de faturamento e aplicação de políticas de custos em toda a organização.

Comparações entre Serviços e Quando Usar Cada Um

Reserved Instances (RIs) vs. Savings Plans:

Característica	Reserved Instances (RIs)	Savings Plans
Compromisso	Uso de uma configuração de instância específica (tipo, região, SO)	Gasto consistente (USD/hora) por um período
Flexibilidade	Menor (específico para instância/região)	Maior (aplica-se a EC2, Fargate, Lambda)
Tipos	Standard (menos flexível, maior desconto), Convertible (mais flexível, menor desconto)	Compute Savings Plans, EC2 Instance Savings Plans
Aplicabilidade	EC2, RDS, Redshift, ElastiCache, DynamoDB	EC2, Fargate, Lambda
Recomendação AWS	Savings Plans são geralmente preferidos devido à flexibilidade

Use Savings Plans quando: Você tem um uso consistente de computação (EC2, Fargate, Lambda) e quer o maior desconto com flexibilidade para mudar tipos de instância ou regiões.
Use Reserved Instances quando: Você tem um uso muito estável e previsível de um tipo de instância específico (especialmente para RDS, Redshift, ElastiCache, onde Savings Plans não se aplicam).

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Custos:

Configurações: Habilite o AWS Cost Explorer e o AWS Budgets. Configure o AWS Compute Optimizer. Use políticas de ciclo de vida para S3. Configure Auto Scaling para escalar para baixo.
Limitações: A otimização de custos é um processo contínuo e requer monitoramento e ajustes regulares. Nem todas as workloads são adequadas para Spot Instances.
Boas Práticas: Comece com o dimensionamento correto. Use o modelo de consumo (pague pelo que usa). Aproveite os descontos por volume. Use instâncias Spot para workloads tolerantes a falhas. Use Savings Plans ou RIs para workloads de base. Monitore e analise os custos regularmente.
Casos de Uso: Redução de custos em ambientes de desenvolvimento/teste, otimização de workloads de produção, planejamento orçamentário.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura Serverless: Frequentemente a mais eficiente em termos de custo, pois você paga apenas pelo uso real, sem provisionamento de servidores.
Padrões de Segurança: Implemente o princípio do menor privilégio para evitar o provisionamento excessivo de recursos. Monitore o uso de recursos para identificar anomalias que possam indicar atividades maliciosas.
Resiliência: A elasticidade (Auto Scaling) que otimiza custos também contribui para a resiliência, garantindo que a capacidade seja ajustada à demanda.
Governança: Use tagging para atribuição de custos. Implemente políticas de orçamento. Use AWS Organizations para gerenciar custos em várias contas.

Estratégias de Migração e Modernização

Migração para Otimização de Custos: Ao migrar, considere refatorar aplicações para usar serviços gerenciados e serverless que oferecem um modelo de custo mais granular e otimizado. Use o AWS Migration Hub para rastrear e otimizar o processo de migração.
Modernização para Otimização de Custos: Adote microsserviços e conteinerização para otimizar o uso de recursos. Use serviços serverless sempre que possível. Implemente práticas de FinOps para gerenciar e otimizar continuamente os custos da nuvem.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma empresa tem uma grande frota de instâncias EC2 para processamento de dados em lote que pode ser interrompido e reiniciado. Eles querem reduzir os custos de computação.

Decisão Arquitetural: Utilizar Spot Instances para a frota de processamento em lote. Isso pode reduzir os custos de computação em até 90% em comparação com as instâncias On-Demand. Para gerenciar a frota, pode-se usar o EC2 Fleet ou Auto Scaling Groups com uma estratégia de mixed instances que priorize Spot.

Armadilha Comum: Não considerar o custo total de propriedade (TCO) ao migrar para a nuvem, focando apenas nos custos de infraestrutura e ignorando os custos operacionais, de licenciamento ou de migração. Outra armadilha é comprar RIs ou Savings Plans sem uma análise cuidadosa do uso futuro, resultando em capacidade não utilizada e desperdício de dinheiro.

4.2. Arquitetar soluções para otimização de performance.

Conceitos Fundamentais e Avançados

A otimização de performance já foi abordada em detalhes no Domínio 3 (Seção 3.2). No contexto do Domínio 4, o foco é a intersecção entre performance e custo, buscando o equilíbrio ideal para entregar valor de negócio.

AWS Well-Architected Framework (Pilar de Eficiência de Performance): Relembrando, este pilar foca na capacidade de usar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda. A otimização de performance muitas vezes leva à otimização de custos, pois recursos mais eficientes podem significar menos recursos necessários.
Serviços e Estratégias Chave (revisão e aprofundamento com foco em custo):
- Dimensionamento Correto (Rightsizing): Usar o AWS Compute Optimizer para identificar e redimensionar recursos (EC2, EBS, Lambda, Fargate) para o tamanho ideal, o que otimiza tanto a performance quanto o custo.
- Caching: Implementar estratégias de cache (CloudFront, ElastiCache) para reduzir a latência e a carga sobre os serviços de backend, o que pode levar a uma necessidade menor de recursos computacionais e, consequentemente, a custos mais baixos.
- Elasticidade e Escalabilidade: Usar Auto Scaling e serviços serverless (Lambda, Fargate, DynamoDB) que escalam automaticamente com a demanda. Isso garante que você tenha a performance necessária nos picos, mas não pague por capacidade ociosa nos períodos de baixa demanda.
- Otimização de Banco de Dados: Escolher o tipo de banco de dados correto para a workload (relacional, NoSQL, etc.) e otimizar consultas. O uso de DynamoDB com seu modelo de capacidade sob demanda, por exemplo, pode ser mais eficiente em custo para workloads com picos de tráfego do que um banco de dados relacional provisionado para o pico.
- Otimização de Rede: Utilizar serviços como CloudFront e Global Accelerator para melhorar a performance de entrega de conteúdo e roteamento de tráfego, o que pode reduzir a necessidade de recursos de backend e, portanto, custos.
- Armazenamento Inteligente: Usar classes de armazenamento S3 como Intelligent-Tiering, que movem automaticamente os dados para as classes de acesso infrequente ou arquivamento com base nos padrões de acesso, otimizando custos sem comprometer a performance de acesso quando necessário.

Comparações entre Serviços e Quando Usar Cada Um

Compute Optimizer vs. Análise Manual: O Compute Optimizer automatiza a análise de performance e custo, fornecendo recomendações baseadas em machine learning, o que é mais eficiente e preciso do que a análise manual, especialmente em ambientes grandes e dinâmicos.

Configurações, Limitações, Boas Práticas e Casos de Uso

Otimização de Performance e Custo:

Configurações: Habilite o AWS Compute Optimizer. Monitore métricas de performance e custo no CloudWatch e Cost Explorer. Configure políticas de ciclo de vida para S3 Intelligent-Tiering.
Limitações: A otimização é um trade-off. Otimizar demais o custo pode impactar a performance, e vice-versa. É crucial encontrar o equilíbrio certo para os requisitos de negócio.
Boas Práticas: Adote uma cultura de FinOps. Revise regularmente as recomendações do Compute Optimizer. Teste as otimizações em ambientes de não produção antes de aplicar em produção. Automatize o desligamento de recursos não utilizados.
Casos de Uso: Redução de custos de infraestrutura, melhoria da experiência do usuário, garantia de que as aplicações atendam aos SLAs de performance.

Modelos de Arquitetura Recomendados, Padrões de Segurança, Resiliência e Governança

Arquitetura Elástica e Serverless: Permite que a capacidade se ajuste à demanda, otimizando tanto a performance (capacidade suficiente nos picos) quanto o custo (não paga por capacidade ociosa).
Padrões de Segurança: A otimização de recursos (rightsizng) também contribui para a segurança, pois menos recursos expostos significam uma superfície de ataque menor.
Resiliência: A elasticidade é um componente chave da resiliência. A capacidade de escalar rapidamente para cima e para baixo ajuda a manter a performance e a disponibilidade sob carga variável.
Governança: Use tags para rastrear o uso e o custo dos recursos. Implemente políticas de gerenciamento de recursos para garantir que os recursos sejam otimizados continuamente.

Estratégias de Migração e Modernização

Modernização para Performance e Custo: Refatorar aplicações para usar serviços serverless e gerenciados que oferecem escalabilidade automática e um modelo de custo baseado no consumo. Isso geralmente resulta em melhor performance e custos mais baixos em comparação com a execução de workloads em VMs auto-gerenciadas.

Exemplos de Cenários Práticos que Caem na Prova, Decisões Arquiteturais e Armadilhas Comuns

Cenário: Uma aplicação web de e-commerce tem um tráfego variável ao longo do dia, com picos significativos durante promoções. A empresa quer garantir a performance durante os picos e otimizar os custos nos períodos de baixa demanda.

Decisão Arquitetural: Utilizar Amazon EC2 Auto Scaling para o backend da aplicação, configurado com políticas de escalabilidade baseadas na utilização da CPU ou no número de requisições do Load Balancer. Para o banco de dados, considerar Amazon Aurora Serverless ou DynamoDB On-Demand, que escalam automaticamente a capacidade e cobram apenas pelo uso real, eliminando a necessidade de provisionar para o pico.

Armadilha Comum: Não implementar Auto Scaling ou usar um modelo de provisionamento fixo para workloads com demanda variável, resultando em super-provisionamento (custo alto) ou sub-provisionamento (baixa performance). Ignorar as recomendações do Compute Optimizer ou não agir sobre elas.

Tabelas Comparativas e Resumos

Esta seção consolida informações importantes em tabelas para facilitar a consulta rápida e a tomada de decisões arquiteturais.

Estratégias de Recuperação de Desastres (DR)

Estratégia	RTO (Tempo de Recuperação)	RPO (Perda de Dados)	Custo	Complexidade	Caso de Uso
Backup e Restauração	Horas a dias	Horas	Baixo	Baixa	Dados de arquivo, backups não críticos
Piloto Leve (Pilot Light)	Dezenas de minutos a horas	Minutos	Baixo-Médio	Média	Aplicações de negócios críticas com alguma tolerância
Warm Standby	Minutos a dezenas de minutos	Segundos a minutos	Médio	Média-Alta	Aplicações de negócios importantes com baixa tolerância
Multi-Site Ativo-Ativo	Segundos (ou zero)	Zero (ou quase zero)	Alto	Alta	Aplicações de missão crítica com tolerância zero

Reserved Instances (RIs) vs. Savings Plans

Característica	Reserved Instances (RIs)	Savings Plans
Compromisso	Uso de uma configuração de instância específica (tipo, região, SO)	Gasto consistente (USD/hora) por um período
Flexibilidade	Menor (específico para instância/região)	Maior (aplica-se a EC2, Fargate, Lambda em diferentes regiões/tipos)
Tipos	Standard (menos flexível, maior desconto), Convertible (mais flexível)	Compute Savings Plans, EC2 Instance Savings Plans, SageMaker Savings Plans
Aplicabilidade	EC2, RDS, Redshift, ElastiCache, DynamoDB	EC2, Fargate, Lambda, SageMaker
Recomendação AWS	Savings Plans são geralmente preferidos devido à maior flexibilidade para computação. RIs ainda são relevantes para RDS, Redshift, etc.

Gatilhos Comuns de Auto Scaling

Métrica/Gatilho	Descrição	Caso de Uso Comum
Utilização de CPU	Escala com base na utilização média da CPU do grupo de Auto Scaling.	Aplicações web, processamento de CPU intensivo
Contagem de Requisições por Alvo	Escala com base no número de requisições por instância no Load Balancer.	Aplicações web, APIs
Tráfego de Rede (Entrada/Saída)	Escala com base na quantidade de tráfego de rede por instância.	Aplicações de streaming, transferência de dados
Tamanho da Fila SQS	Escala com base no número de mensagens em uma fila SQS.	Processamento de trabalho assíncrono, workloads em lote
Métricas Personalizadas	Escala com base em qualquer métrica personalizada do CloudWatch.	Workloads com métricas de negócio específicas (ex: usuários ativos)
Escalonamento Agendado	Escala em horários específicos do dia ou da semana.	Aplicações com padrões de tráfego previsíveis (ex: horário comercial)

Característica	Amazon SNS	Amazon SQS	Amazon EventBridge
Modelo	Publicar/Assinar (Pub/Sub)	Fila de Mensagens	Barramento de Eventos
Entrega	Push (para múltiplos assinantes)	Pull (por um consumidor)	Roteamento de eventos para múltiplos destinos
Casos de Uso	Notificações, fanout, microsserviços	Desacoplamento, processamento assíncrono	Arquiteturas orientadas a eventos, integração de SaaS
Durabilidade	Mensagens entregues para assinantes ativos	Mensagens persistentes na fila	Eventos roteados para destinos
Filtragem	Simples (baseada em atributos)	Não (consumidor processa todas as mensagens)	Avançada (baseada no conteúdo do evento)

Detalhamento de Tópicos Obrigatórios

Esta seção aprofunda os tópicos mais críticos e frequentemente cobrados no exame, consolidando o conhecimento dos domínios anteriores.

1. Estratégias Multi-Account e AWS Organizations

AWS Organizations: Permite gerenciar centralmente várias contas AWS. Facilita a aplicação de políticas, o faturamento consolidado e o gerenciamento de segurança.
Landing Zone (via AWS Control Tower): Uma arquitetura de referência para configurar um ambiente multi-conta seguro e escalável. O Control Tower automatiza a criação da Landing Zone, estabelecendo uma linha de base com contas para log, auditoria e segurança, e aplicando guardrails (baseados em SCPs) para governança.
Unidades Organizacionais (OUs): Permitem agrupar contas para aplicar políticas de forma hierárquica. Uma estrutura comum é ter OUs para Infraestrutura, Segurança, Workloads (separados por Prod, Dev, Test), etc.
Service Control Policies (SCPs): Políticas de controle de serviço que definem as permissões máximas para as contas em uma OU. Elas não concedem permissões, mas atuam como um filtro, restringindo o que os administradores de contas podem delegar aos usuários e roles. Por exemplo, um SCP pode negar o acesso a regiões específicas ou impedir a desativação de serviços de segurança como CloudTrail e GuardDuty.

2. Networking Avançado

Transit Gateway: Atua como um hub de rede central para conectar VPCs e redes on-premises. Simplifica a arquitetura de rede, elimina a necessidade de VPC Peering complexo e permite o roteamento centralizado.
PrivateLink: Fornece conectividade privada entre VPCs, serviços AWS e suas redes on-premises sem expor o tráfego à internet pública. Cria um endpoint de interface em sua VPC que se conecta a um serviço de endpoint.
Direct Connect: Uma conexão de rede dedicada e privada entre seu data center e a AWS. Oferece largura de banda consistente e baixa latência. O Direct Connect Gateway permite conectar a múltiplas VPCs em diferentes regiões com uma única conexão.
DNS Multi-Região com Route 53: Essencial para alta disponibilidade e recuperação de desastres. Use políticas de roteamento como Failover (para DR ativo-passivo), Latency-based (para performance global) e Geolocation (para conformidade de dados) para direcionar o tráfego para a região mais apropriada.

3. IAM Avançado

Permission Boundaries: Uma política de IAM gerenciada que define as permissões máximas que uma política de identidade pode conceder a uma entidade (usuário ou role). Útil para delegar a criação de roles a desenvolvedores, garantindo que eles não possam criar roles com mais permissões do que o limite definido.
Attribute-Based Access Control (ABAC): Uma estratégia de autorização que define permissões com base em atributos (tags) anexados a usuários e recursos. É mais escalável que o RBAC (Role-Based Access Control) em ambientes com muitos recursos e políticas, pois você pode criar uma única política que se aplica a todos os recursos com uma determinada tag.
Roles Cross-Account: Permitem que usuários ou serviços em uma conta (a conta confiável) assumam uma role em outra conta (a conta que confia) para acessar recursos. É a maneira padrão e segura de conceder acesso entre contas.
IAM Roles Anywhere: Permite que workloads que rodam fora da AWS (como em seus data centers on-premises) usem certificados X.509 para obter credenciais de segurança temporárias e acessar recursos da AWS. Estende a segurança do IAM para fora da nuvem.

4. Observabilidade e Segurança Contínua

CloudWatch: O serviço central para monitoramento de métricas e logs. Use CloudWatch Logs Insights para análises de log poderosas e CloudWatch Alarms para automação e alertas.
CloudTrail: Audita todas as chamadas de API. Essencial para segurança e conformidade. Envie os logs para o S3 para retenção a longo prazo e para o CloudWatch Logs para análise em tempo real.
AWS Config: Monitora a conformidade das configurações dos recursos. Use Conformance Packs para implantar um conjunto de regras de conformidade em sua organização.
Security Hub: Agrega descobertas de segurança de GuardDuty, Inspector, Macie e outros serviços, fornecendo uma visão unificada da sua postura de segurança.
GuardDuty: Detecção de ameaças baseada em machine learning. Monitora logs de CloudTrail, VPC Flow Logs e DNS para identificar atividades maliciosas.
KMS Multi-Region Keys: Chaves KMS que podem ser replicadas para múltiplas regiões. Simplificam o gerenciamento de criptografia para dados que são replicados entre regiões, garantindo que você possa descriptografar os dados na região de DR.

5. Migração e Modernização (7Rs)

As 7 estratégias comuns de migração e modernização:

Retire (Aposentar): Descomissionar aplicações que não são mais necessárias.
Retain (Reter): Manter aplicações on-premises que não estão prontas para migrar.
Rehost (Lift-and-Shift): Migrar aplicações para a nuvem sem modificações. Rápido, mas com menos benefícios da nuvem. (Ex: usar Application Migration Service - MGN).
Replatform (Lift-and-Tinker): Migrar com algumas otimizações, como mover um banco de dados para RDS.
Repurchase (Comprar Novamente): Mover para um produto diferente, geralmente uma solução SaaS.
Refactor/Re-architect (Refatorar/Rearquitetar): Modificar a aplicação para aproveitar os recursos nativos da nuvem (ex: microsserviços, serverless). Maior benefício, mas maior esforço.
Relocate (Realocar): Mover infraestrutura de um ambiente de nuvem para outro (ex: VMware Cloud on AWS).

AWS Migration Acceleration Program (MAP): Um programa que fornece consultoria, ferramentas e créditos de serviço para acelerar a migração para a AWS.

6. Novidades Relevantes

VPC Lattice: Simplifica a conectividade, segurança e observabilidade entre serviços em diferentes VPCs e contas, sem a complexidade de gerenciar Transit Gateways ou VPC Peering para cada serviço.
CloudFront Signed URLs/Cookies: Mecanismos para controlar o acesso a conteúdo privado no CloudFront. URLs assinadas são para acesso a arquivos individuais, enquanto cookies assinados podem conceder acesso a múltiplos arquivos.
CloudWatch Evidently: Permite realizar experimentos e lançamentos de features (feature flags) para testar novas funcionalidades com um subconjunto de usuários e medir o impacto na performance e no negócio.

Cenários Práticos e Questões de Exemplo

Cenário 1: Otimização de Custos para Workload de Análise

Situação: Uma empresa executa um cluster de análise de dados no Amazon EMR todas as noites. O trabalho leva cerca de 4 horas para ser concluído e pode ser reiniciado em caso de falha. O custo do cluster é alto.
Decisão Arquitetural: Usar Spot Instances para os nós de tarefa (task nodes) do cluster EMR. Como os nós de tarefa não armazenam dados, a interrupção de uma instância Spot pode ser tolerada. Isso pode reduzir significativamente os custos de computação. Para os nós principais (master e core nodes), usar instâncias On-Demand ou Reserved Instances para garantir a estabilidade do cluster.

Cenário 2: Segurança de Acesso a Dados em Múltiplas Contas

Situação: Uma aplicação em uma VPC na Conta A precisa acessar um bucket S3 na Conta B de forma segura, sem expor o tráfego à internet.
Decisão Arquitetural: Criar um VPC Gateway Endpoint para o S3 na VPC da Conta A. Na Conta B, criar uma política de bucket S3 que permita o acesso a partir do VPC Endpoint da Conta A. Isso garante que o tráfego entre a VPC e o S3 permaneça na rede da AWS.

Cenário 3: Alta Disponibilidade para Aplicação Web Global

Situação: Uma aplicação web com usuários em todo o mundo precisa de baixa latência e alta disponibilidade. A aplicação tem um backend de API e conteúdo estático.
Decisão Arquitetural: Usar Amazon CloudFront para entregar o conteúdo estático e dinâmico. Configurar o CloudFront com múltiplas origens em diferentes regiões. Usar Amazon Route 53 com uma política de roteamento baseada em latência para direcionar os usuários para a região mais próxima. Implementar health checks do Route 53 para failover automático em caso de falha de uma região.

Cenário 4: Governança de Segurança em Larga Escala

Situação: Uma empresa com dezenas de contas AWS quer garantir que ninguém possa desativar o AWS CloudTrail ou criar chaves de acesso IAM para o usuário root.
Decisão Arquitetural: Usar AWS Organizations para gerenciar todas as contas. Criar uma Service Control Policy (SCP) e anexá-la à raiz da organização ou a uma OU específica. A SCP deve conter uma declaração de Deny explícita para as ações cloudtrail:StopLogging, cloudtrail:DeleteTrail e iam:CreateAccessKey quando o principal for o usuário root. Isso impõe a política em todas as contas afetadas, mesmo para os administradores dessas contas.

Estudando C Sharp a partir do Python

Sat, 08 Mar 2025 00:00:00 +0000

Nesta postagem, vou analisar a implementação da sequência de Fibonacci em Python e C#, destacando as principais diferenças de sintaxe e conceitos de programação. Também vou explorar alguns princípios essenciais do C# para facilitar a transição para desenvolvedores Python. Tenho uma amiga que é apaixonada pelo .NET. Sempre que mostro a ela um trecho de código em Python, ela torce o nariz e diz: “Por que usar Python? O .NET é muito melhor!” Então, em homenagem a ela, resolvi converter esse código Python para C# e estudar as diferenças. Utilizei IA para gerar o código em C# e comentar o código, para me ajudar a entender. Achei esta abordagem fantástica para aprendizado, e pretendo me aprofundar em C# paralelamente utilizando esta forma de estudo.

Código em Python:

Código-fontepython


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


import time

cache = {0:0, 1:1}
calls = 0
cache_hits = 0

def fib(n: int) -> int:
 global calls, cache_hits
 if n in cache:
 cache_hits += 1
 return cache[n]
 else:
 calls += 1
 cache[n] = fib(n-1) + fib(n-2)
 return cache[n]

if __name__ == '__main__':
 n = 500

 start_time = time.perf_counter()
 result = fib(n)
 end_time = time.perf_counter()

 elapsed_time_ms = (end_time - start_time) * 1000

 print(f'{result}')
 print(f'{calls} chamadas de função e {cache_hits} acertos de cache.')
 print(f"Tempo decorrido: {elapsed_time_ms:.4f} ms")

Tradução para C#:

Abaixo o equivalente em C#:

Código-fontecsharp


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


using System;
using System.Collections.Generic;
using System.Diagnostics;

public class Fibonacci
{
 private static Dictionary<int, long> cache = new Dictionary<int, long> { { 0, 0 }, { 1, 1 } };
 private static long calls = 0;
 private static long cacheHits = 0;

 public static long Fib(int n)
 {
 if (cache.ContainsKey(n))
 {
 cacheHits++;
 return cache[n];
 }
 else
 {
 calls++;
 cache[n] = Fib(n - 1) + Fib(n - 2);
 return cache[n];
 }
 }

 public static void Main(string[] args)
 {
 int n = 500;

 Stopwatch stopwatch = new Stopwatch();
 stopwatch.Start();

 long result = Fib(n);

 stopwatch.Stop();
 double elapsedTimeMs = stopwatch.Elapsed.TotalMilliseconds;

 Console.WriteLine(result);
 Console.WriteLine($"{calls} chamadas de função e {cacheHits} acertos de cache.");
 Console.WriteLine($"Tempo decorrido: {elapsedTimeMs:F4} ms");
 }
}

Conceitos Chave para Desenvolvedores Python Transicionando para C#

Esta seção destaca os conceitos principais encontrados ao migrar do Python para o C#, com foco nas áreas onde as diferenças são mais pronunciadas.

Tipagem Estática: Ao contrário da tipagem dinâmica do Python, o C# exige declarações de tipo explícitas (por exemplo, int idade = 30;). Isso impõe a segurança de tipo em tempo de compilação, detectando possíveis erros antecipadamente. É necessário familiarizar-se com os tipos de dados comuns do C#, como int, double, string, bool, char e long (usado para valores inteiros maiores).
Paradigma de Programação Orientada a Objetos (POO): O C# é fundamentalmente orientado a objetos. O código é organizado em torno de classes, que servem como modelos para criar objetos. Os principais conceitos de POO a serem dominados incluem:
- Classes e Objetos: Definir classes com propriedades (dados) e métodos (comportamento).
- Encapsulamento: Proteger os dados dentro de uma classe e controlar o acesso usando modificadores de acesso (public, private, protected).
- Herança: Criar novas classes com base em classes existentes, herdando suas características.
- Polimorfismo: Permitir que objetos de diferentes classes respondam à mesma chamada de método de sua própria maneira.
Namespaces: Organização do Código: Namespaces são como módulos Python, mas turbinados. Eles fornecem uma maneira hierárquica de organizar o código, evitando conflitos de nomenclatura e agrupando classes relacionadas. Usa-se a palavra-chave using para importar namespaces e acessar seu conteúdo (por exemplo, using System;).
Métodos: Funções Vinculadas à Classe: Métodos são funções que pertencem a uma classe. Eles definem as ações que um objeto pode executar. Prestar atenção às assinaturas dos métodos, incluindo tipos de retorno, parâmetros e modificadores de acesso. A palavra-chave static permite definir métodos que pertencem à própria classe, em vez de a uma instância.
Fluxo de Controle com Chaves: O C# usa chaves {} para definir blocos de código para instruções de fluxo de controle como if, else, for, while e switch. Esta é uma diferença sintática fundamental da abordagem baseada em indentação do Python.
Coleções: Estruturas de Dados: O C# oferece um rico conjunto de classes de coleção para armazenar e gerenciar dados, incluindo arrays, listas (List<T>) e dicionários (Dictionary<TKey, TValue>).
O Ecossistema .NET: O código C# é executado no runtime .NET. Compreender o básico do framework .NET, incluindo o Common Language Runtime (CLR) e a Base Class Library (BCL), fornece uma compreensão mais profunda de como o código C# é executado.

Lições Aprendidas: Principais Conclusões para Pythonistas

Após converter a sequência de Fibonacci e explorar esses conceitos básicos, aqui estão as lições mais significativas aprendidas:

Abrace a Tipagem Estática: Embora possa parecer verboso no início, a tipagem estática leva a um código mais robusto e fácil de manter.
POO é Fundamental: O C# é uma linguagem orientada a objetos de ponta a ponta.
Aproveite o Framework .NET: O framework .NET fornece uma riqueza de classes e métodos pré-construídos que podem acelerar significativamente o desenvolvimento.
A Sintaxe Importa: Prestar atenção à sintaxe, especialmente ao uso de chaves para blocos de código. Pequenos erros sintáticos podem impedir que o código seja compilado.
IA como Acelerador de Aprendizagem: Usar ferramentas de IA para gerar código e explicar conceitos é maneira poderosa de aprender C#. Concentrar-se em entender o porquê por trás do código, em vez de apenas o como, é a diferença entre aprender de fato e deixar a IA fazer por você apenas.

Considerações Finais

Converter código Python para C# pode parecer intimidador no início, mas ao entender os conceitos principais e as diferenças de sintaxe, a transição se torna muito mais suave. Este exercício com a sequência de Fibonacci destaca a importância da tipagem estática, da programação orientada a objetos e da estrutura que os namespaces fornecem em C#. O que tornou essa experiência de aprendizado verdadeiramente poderosa foi o uso de IA para gerar o código C# inicial e fornecer explicações. Essa abordagem me permitiu focar em entender o porquê por trás do código, em vez de me perder em erros de sintaxe. Enquanto o Python oferece flexibilidade e prototipagem rápida, o C# traz robustez e desempenho, especialmente benéficos para aplicações maiores. É uma questão de saber qual linguagem utilizar em cada situação. Na minha opinião, o Python resolve a maioria dos problemas que não exijam desempenho e para tarefas rápidas. E, crucialmente, ao usar a IA como uma companheira de aprendizado, podemos acelerar o processo de dominar novas linguagens e paradigmas, tornando tarefas complexas como tradução entre linguagens e compreensão de conceitos significativamente mais acessíveis.

Busca em Largura (BFS) e Busca em Profundidade (DFS): Um Estudo Detalhado

Wed, 05 Mar 2025 00:00:00 +0000

Busca em Largura (BFS)

A Busca em Largura (BFS, do inglês Breadth-First Search) é um algoritmo fundamental de busca e travessia de grafos. Ele explora sistematicamente um grafo nível por nível, começando de um nó inicial designado. Imagine explorar um labirinto: o BFS exploraria todos os caminhos a um passo da entrada, depois todos os caminhos a dois passos, e assim por diante, garantindo que o caminho mais curto seja encontrado primeiro.

Como o BFS Funciona

Inicialização:
- Comece com uma estrutura de dados fila (queue), tipicamente implementada usando collections.deque em Python para operações FIFO (First-In, First-Out, Primeiro a Entrar, Primeiro a Sair) eficientes. A fila inicialmente contém apenas o nó inicial.
- Mantenha um conjunto (set) ou lista visitados para controlar os nós que já foram explorados, evitando ciclos.
- Opcionalmente, um dicionário pai (parent) é usado para armazenar o predecessor de cada nó visitado, permitindo a reconstrução do caminho mais tarde.
Iteração:
- Enquanto a fila não estiver vazia:
  - Remova um nó da frente da fila (dequeue). Este é o nó sendo explorado atualmente.
  - Para cada vizinho do nó atual:
    - Se o vizinho não foi visitado:
      - Marque o vizinho como visitado.
      - Adicione o vizinho ao final da fila (enqueue).
      - Registre o nó atual como o pai do vizinho (se a reconstrução do caminho for necessária).
Terminação:
- O algoritmo termina quando a fila está vazia, indicando que todos os nós alcançáveis a partir do nó inicial foram explorados.
- Se um nó alvo for especificado, a busca pode terminar assim que o nó alvo for removido da fila. O dicionário pai pode então ser usado para reconstruir o caminho mais curto do nó inicial ao nó alvo.

Prós do BFS

Completude: O BFS é completo, o que significa que se um caminho existe entre o nó inicial e o nó alvo, o BFS irá encontrá-lo.
Optimalidade: O BFS garante encontrar o caminho mais curto (em termos do número de arestas) entre o nó inicial e o nó alvo em um grafo não ponderado.
Simplicidade: O algoritmo é relativamente simples de entender e implementar.

Contras do BFS

Consumo de Memória: O BFS pode consumir uma quantidade significativa de memória, especialmente para grafos grandes. Isso ocorre porque ele armazena todos os nós no nível atual na fila. No pior cenário, onde todo o grafo precisa ser percorrido, a fila pode crescer e conter uma grande fração do número total de nós.
Não Adequado para Grafos Ponderados: O BFS é projetado para grafos não ponderados. Ele encontra o caminho mais curto com base no número de arestas, não no peso total das arestas. Para grafos ponderados, algoritmos como o algoritmo de Dijkstra são mais apropriados.

Onde o BFS se Destaca

Encontrar Caminhos Mais Curtos (Grafos Não Ponderados): Sua principal força é encontrar o caminho mais curto em grafos onde todas as arestas têm o mesmo peso (ou nenhum peso).
Teste de Conectividade: Determinar se dois nós estão conectados em um grafo.
Web Crawlers (Robôs de Busca): O BFS pode ser usado para rastrear páginas da web, explorando links nível por nível.
Análise de Redes Sociais: Encontrar a cadeia mais curta de conexões entre duas pessoas em uma rede social.
Navegação GPS: Em cenários onde minimizar o número de “saltos” (hops) é mais importante do que a distância total (por exemplo, minimizar o número de transferências no transporte público).

Onde o BFS Falha

Grafos Ponderados: Conforme mencionado anteriormente, o BFS não é adequado para encontrar o caminho mais curto em grafos onde as arestas têm pesos diferentes.
Grafos Muito Grandes: Os requisitos de memória do BFS podem se tornar proibitivos para grafos muito grandes.
Grafos com Altos Fatores de Ramificação (Branching Factors): Grafos onde cada nó tem muitos vizinhos podem levar a uma fila grande e alto consumo de memória.

Casos de Uso Comuns

Pathfinding em Jogos (Busca de Caminho): Encontrar o caminho mais curto para um personagem se mover em um ambiente de jogo (onde todos os movimentos têm o mesmo custo).
Roteamento de Rede: Descobrir a topologia da rede e encontrar os caminhos mais curtos entre dispositivos.
Coleta de Lixo (Garbage Collection): Rastrear objetos alcançáveis na memória para identificar aqueles que podem ser desalocados com segurança.
Redes Peer-to-Peer: Encontrar os pares mais próximos em uma rede peer-to-peer.

Busca em Profundidade (DFS)

A Busca em Profundidade (DFS, do inglês Depth-First Search) é outro algoritmo fundamental de busca e travessia de grafos. Em vez de explorar um grafo nível por nível como o BFS, o DFS explora o mais profundamente possível ao longo de cada ramo antes de retroceder (backtracking). O DFS escolherá um caminho e o seguirá até o final, então retrocederá ao último ponto de ramificação e tentará um caminho diferente.

Como o DFS Funciona

Inicialização:
- Comece com uma estrutura de dados pilha (stack), tipicamente implementada usando uma lista em Python. A pilha inicialmente contém apenas o nó inicial.
- Mantenha um conjunto (set) ou lista visitados para controlar os nós que já foram explorados, evitando ciclos.
- Opcionalmente, um dicionário pai (parent) é usado para armazenar o predecessor de cada nó visitado, permitindo a reconstrução do caminho mais tarde.
Iteração:
- Enquanto a pilha não estiver vazia:
  - Remova um nó do topo da pilha (pop). Este é o nó sendo explorado atualmente.
  - Se o nó não foi visitado:
    - Marque o nó como visitado.
    - Para cada vizinho do nó atual:
      - Se o vizinho não foi visitado:
        
        Adicione o vizinho ao topo da pilha (push).
        
        Registre o nó atual como o pai do vizinho (se a reconstrução do caminho for necessária).
Terminação:
- O algoritmo termina quando a pilha está vazia, indicando que todos os nós alcançáveis a partir do nó inicial foram explorados.
- Se um nó alvo for especificado, a busca pode terminar assim que o nó alvo for removido da pilha e for encontrado. O dicionário pai pode então ser usado para reconstruir um caminho (não necessariamente o mais curto) do nó inicial ao nó alvo.

Prós do DFS

Eficiência de Memória: O DFS geralmente requer menos memória do que o BFS, especialmente para grafos profundos. Ele só precisa armazenar os nós no caminho atual sendo explorado, em vez de todos os nós no nível atual (como o BFS faz).
Implementação Simples: O DFS pode ser implementado recursivamente, tornando o código muito conciso (embora a versão iterativa, usando uma pilha, também seja direta).
Bom para Encontrar Qualquer Caminho: Se você só precisa encontrar um caminho entre dois nós (não necessariamente o mais curto), o DFS pode ser mais rápido do que o BFS.

Contras do DFS

Não Garante Encontrar o Caminho Mais Curto: O DFS não garante encontrar o caminho mais curto. Ele encontra um caminho, mas esse caminho pode ser muito mais longo do que o caminho mais curto.
Pode Ficar Preso em Loops Infinitos: Se o grafo contém ciclos e o conjunto visitados não for usado corretamente, o DFS pode ficar preso em um loop infinito, explorando os mesmos nós repetidamente.
Pode Explorar Caminhos Irrelevantes: O DFS pode explorar caminhos que estão longe do nó alvo antes de encontrar o alvo.

Onde o DFS se Destaca

Detecção de Ciclos: O DFS é adequado para detectar ciclos em um grafo. Se, durante a travessia, você encontrar um nó que já foi visitado (e ainda está na pilha), isso indica a presença de um ciclo.
Ordenação Topológica: O DFS é usado em algoritmos para ordenação topológica de grafos acíclicos dirigidos (DAGs).
Verificação da Existência de Caminho: Determinar se um caminho existe entre dois nós, mesmo que o caminho mais curto não seja necessário.
Resolvendo Quebra-Cabeças: O DFS pode ser usado para explorar possíveis soluções em quebra-cabeças e jogos (por exemplo, resolver um labirinto, encontrar uma solução para um quebra-cabeça Sudoku).

Onde o DFS Falha

Encontrar Caminhos Mais Curtos: Quando o caminho mais curto é necessário, o BFS ou outros algoritmos como o algoritmo de Dijkstra são melhores opções.
Grafos com Caminhos Longos: Em grafos com caminhos muito longos, o DFS pode levar muito tempo para encontrar o nó alvo ou explorar todo o grafo.
Grafos Infinitos: O DFS pode se perder em grafos infinitos se não houver uma condição de terminação clara.

Casos de Uso Comuns

Detecção de Ciclos: Conforme mencionado anteriormente, o DFS é comumente usado para detectar ciclos em grafos.
Ordenação Topológica: Ordenar tarefas em um projeto com base em dependências.
Resolvendo Labirintos: Encontrar um caminho da entrada para a saída.
Algoritmos de Backtracking: Resolver problemas onde você precisa explorar diferentes possibilidades e retroceder quando um beco sem saída é atingido (por exemplo, resolver problemas de satisfação de restrições).
IA de Jogos: Implementar IA para jogos onde a IA precisa explorar possíveis movimentos e avaliar suas consequências.

Adicionei abaixo dois exemplos, um para BFS e outro para DFS. O grafo usado foi o da imagem abaixo:

Este é o resultado de ambos, onde podemos notar a diferença:

bfs.py:

Código-fontebash


1
2
3


Sequência de nós visitados: ['A', 'B', 'G', 'C', 'D', 'E', 'H', 'J', 'F', 'I']
Visitados um total de 10 nós.
Caminho encontrado de A para F: ['A', 'B', 'E', 'F']

Ordem de Visitação:

Nível 0: [‘A’]
Nível 1: [‘B’, ‘G’]
Nível 2: [‘C’, ‘D’, ‘E’, ‘H’, ‘J’]
Nível 3: [‘F’, ‘I’]

Ele visita todos os nós no nível atual antes de ir para o próximo nível.

dfs.py:

Código-fontebash


1
2
3


Sequência de nós visitados: ['A', 'G', 'J', 'H', 'I', 'B', 'E', 'F']
Visitados um total de 8 nós.
Caminho encontrado de A para F: ['A', 'B', 'E', 'F']

Ordem de Visitação:

‘A’: Nó inicial, removido primeiro.
‘G’: De ‘A’, vizinhos são [‘B’, ‘G’]. Adicionado à pilha como [‘B’, ‘G’], então ‘G’ é removido em seguida (LIFO).
‘J’: De ‘G’, vizinhos são [‘H’, ‘J’]. Adicionado como [‘B’, ‘H’, ‘J’], ‘J’ removido.
‘H’: De ‘J’, nenhum novo vizinho. Pilha agora [‘B’, ‘H’], ‘H’ removido.
‘I’: De ‘H’, vizinho ‘I’ adicionado, removido em seguida.
‘B’: Pilha agora [‘B’], removido após a subárvore de ‘G’ ser esgotada.
‘E’: De ‘B’, vizinhos [‘C’, ‘D’, ‘E’]. Adicionado como [‘C’, ‘D’, ‘E’], ‘E’ removido.
‘F’: De ‘E’, vizinhos [‘F’, ‘I’]. ‘I’ já visitado, então ‘F’ adicionado e removido. Alvo encontrado, para.

Ele vai fundo no ramo de ‘G’ (‘G’ → ‘J’ → ‘H’ → ‘I’) antes de retroceder para ‘B’ e então ‘E’ → ‘F’.

Exemplo de BFS (Clique para Mostrar/Esconder)

Código-fontepython


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


from collections import deque

def breadth_first_search(graph, start_node, target_node=None):
 visited_set, visited_order, queue, parent = {start_node}, [start_node], deque([start_node]), {}
 while queue:
 node = queue.popleft()
 if target_node == node:
 path = [node]
 while node != start_node: node = parent[node]; path += [node]
 return visited_order, path[::-1]
 for neighbor in graph.get(node, []):
 if neighbor not in visited_set:
 visited_set.add(neighbor)
 visited_order += [neighbor]
 queue += [neighbor]
 parent[neighbor] = node
 return visited_order, None

if __name__ == '__main__':
 graph = {
 'A': ['B', 'G'],
 'B': ['C', 'D', 'E'],
 'C': [],
 'D': [],
 'E': ['F', 'I'],
 'F': [],
 'G': ['H', 'J'],
 'H': ['I'],
 'I': [],
 'J': [],
 }

 start_node = 'A'
 target_node = 'F'
 visited, path = breadth_first_search(graph, start_node, target_node)

 print(f"Sequência de nós visitados: {visited}")
 print(f"Visitados um total de {len(visited)} nós.")
 if path:
 print(f"Caminho encontrado de {start_node} para {target_node}: {path}")
 elif not target_node:
 print(f"Alvo não foi especificado.")
 else:
 print(f"Nenhum caminho encontrado de {start_node} para {target_node}.")

Exemplo de DFS (Clique para Mostrar/Esconder)

Código-fontepython


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


def depth_first_search(graph, start_node, target_node=None):
 visited, stack, parent = [], [start_node], {}
 if start_node not in graph: return visited, None
 while stack:
 node = stack.pop()
 if node not in visited:
 visited += [node]
 if target_node == node:
 path = []
 current = node
 while current in parent or current == start_node:
 path += [current]
 if current == start_node: break
 current = parent[current]
 return visited, path[::-1]
 for neighbor in graph.get(node, []):
 if neighbor not in visited:
 stack += [neighbor]
 parent[neighbor] = node
 return visited, None

if __name__ == '__main__':
 graph = {
 'A': ['B', 'G'],
 'B': ['C', 'D', 'E'],
 'C': [],
 'D': [],
 'E': ['F', 'I'],
 'F': [],
 'G': ['H', 'J'],
 'H': ['I'],
 'I': [],
 'J': [],
 }

 start_node = 'A'
 target_node = 'F'
 visited, path = depth_first_search(graph, start_node, target_node)

 print(f"Sequência de nós visitados: {visited}")
 print(f"Visitados um total de {len(visited)} nós.")
 if path:
 print(f"Caminho encontrado de {start_node} para {target_node}: {path}")
 elif not target_node:
 print(f"Alvo não foi especificado.")
 else:
 print(f"Nenhum caminho encontrado de {start_node} para {target_node}.")

Construindo um Cluster Kubernetes com Kubespray: Uma Jornada Pessoal

Sat, 09 Nov 2024 00:00:00 +0000

Construindo um Cluster Kubernetes com Kubespray e Stack de Monitoramento: Uma Jornada Pessoal

Este post detalha minha experiência configurando um cluster Kubernetes em 7 nós bare-metal usando Kubespray, seguido pela implantação de um stack de monitoramento abrangente composto por Rook, Mimir, Grafana e Loki, que serão descritos em posts separados. Esta configuração fornece recursos robustos de armazenamento, métricas e logs para nosso uso interno.

Kubespray: O Orquestrador

Kubespray é uma ferramenta poderosa baseada em Ansible para implantar e gerenciar clusters Kubernetes. Ele automatiza o processo complexo de configurar um plano de controle Kubernetes e nós de trabalho, lidando com tarefas como instalar componentes Kubernetes, configurar rede e gerenciar etcd. Ele permite personalização flexível por meio de arquivos de inventário e variáveis de grupo. Escolhi a versão 2.26.0 para esta implantação na época.

Pré-requisitos

Como usei servidores bare metal que ficaram disponíveis de outro projeto, instalei previamente o sistema operacional e configurei tudo, desde pacotes até rede e autenticação.

Configuração Passo a Passo

1. Clonagem do Git e Imagem Docker:

Primeiro, clonamos o repositório Kubespray e puxamos a imagem Docker necessária:

Código-fontebash


1
2
3
4
5
6


# Clona o repositório Kubespray
git clone https://github.com/kubernetes-sigs/kubespray.git
git checkout v2.26.0

# Puxa a imagem Docker do Kubespray
docker pull quay.io/kubespray/kubespray:v2.26.0

Isso garante que tenhamos a versão mais recente (ou a versão específica que precisamos) do Kubespray. A imagem Docker contém todos os componentes Ansible necessários e evita possíveis conflitos com instalações locais. Nunca use a versão mais recente commitada no repositório, sempre use uma versão estável.

2. Configuração do Inventário:

O coração da configuração do Kubespray reside em seus arquivos de inventário. Eles definem os nós em seu cluster, suas funções e informações de rede relevantes. Meu arquivo de inventário (inventory/k8s-logs/hosts.yml) se parece com isto:

Código-fonteyaml


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


all:
 hosts:
 # Nós de Trabalho
 logsrv1234:
 ansible_host: 10.0.0.245 # IP de conexão Ansible
 ip: 10.1.0.45 # Endereço IP interno
 access_ip: 10.1.0.45 # IP para acesso externo (se necessário)
 node_labels:
 node-role.kubernetes.io/node: "" # Rótulo indicando que é um nó de trabalho

 # ... (entradas semelhantes para outros nós de trabalho logsrv1233 - logsrv1228) ...

 # Nó de Ingress
 ingress-1:
 ansible_host: 10.0.0.241
 ip: 10.1.0.41
 access_ip: 10.1.0.41
 node_labels:
 node-role.kubernetes.io/node: "" # Nó de Ingress também precisa de função de nó

 # Nós Master
 master-1:
 ansible_host: 10.0.0.242
 ip: 10.1.0.42
 access_ip: 10.1.0.42
 node_labels:
 node-role.kubernetes.io/master: "" # Rótulo designando um nó master

 # ... (entradas semelhantes para master-2 e master-3) ...

 children:
 # Agrupando hosts com base em suas funções para gerenciamento simplificado
 kube_control_plane:
 hosts:
 master-1:
 master-2:
 master-3:
 kube_node:
 hosts:
 logsrv1234:
 logsrv1233:
 # ... outros nós de trabalho e ingress ...
 etcd:
 hosts:
 master-1:
 master-2:
 master-3:
 k8s_cluster:
 children:
 kube_control_plane:
 kube_node:
 calico_rr:
 hosts: {} # Configuração do Calico (vazia por enquanto)

Isso define meticulosamente cada nó, seus endereços IP (ansible_host para conexão Ansible, ip para comunicação interna do cluster e access_ip para acesso externo) e sua função dentro do cluster Kubernetes usando rótulos de nó. A seção children agrupa os hosts para facilitar o gerenciamento nos playbooks do Ansible.

3. Variáveis de Grupo:

O diretório group_vars contém arquivos YAML que definem variáveis globais e específicas do grupo para a implantação do Kubespray. O arquivo all.yml define configurações gerais:

Código-fonteyaml


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


---
bin_dir: /usr/local/bin
loadbalancer_apiserver_port: 6443
loadbalancer_apiserver_healthcheck_port: 8081
upstream_dns_servers:
 - 10.0.0.15
 - 10.0.0.16
http_proxy: "http://proxy.internal:3128" # ambiente sem acesso direto à internet
https_proxy: "http://proxy.internal:3128" # ambiente sem acesso direto à internet
no_proxy: "10.0.0.0/8,localhost,127.0.0.0/8,172.16.0.0/16,*.internal" # ambiente sem acesso direto à internet
no_proxy_exclude_workers: false
kube_webhook_token_auth: false
kube_webhook_token_auth_url_skip_tls_verify: false
ntp_enabled: false
ntp_manage_config: false
ntp_servers:
 - "0.pool.ntp.org iburst"
 - "1.pool.ntp.org iburst"
 - "2.pool.ntp.org iburst"
 - "3.pool.ntp.org iburst"
unsafe_show_logs: false
allow_unsupported_distribution_setup: false

E k8s-cluster.yml configura as configurações específicas do Kubernetes:

Código-fonteyaml


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79


---
kube_version: v1.30.4  # Versão do Kubernetes
kube_network_plugin: calico # Plugin CNI a ser usado
kube_config_dir: /etc/kubernetes
kube_script_dir: "{{ bin_dir }}/kubernetes-scripts"
kube_manifest_dir: "{{ kube_config_dir }}/manifests"
kube_cert_dir: "{{ kube_config_dir }}/ssl"
kube_token_dir: "{{ kube_config_dir }}/tokens"
kube_api_anonymous_auth: true
local_release_dir: "/tmp/releases"
retry_stagger: 5
kube_owner: kube
kube_cert_group: kube-cert
kube_log_level: 2
credentials_dir: "{{ inventory_dir }}/credentials"
kube_network_plugin_multus: false
kube_service_addresses: 10.36.192.0/18
kube_pods_subnet: 172.16.0.0/16
kube_network_node_prefix: 24
enable_dual_stack_networks: false
kube_service_addresses_ipv6: fd85:ee78:d8a6:8607::1000/116
kube_pods_subnet_ipv6: fd85:ee78:d8a6:8607::1:0000/112
kube_network_node_prefix_ipv6: 120
kube_apiserver_ip: "{{ kube_service_addresses | ipaddr('net') | ipaddr(1) | ipaddr('address') }}"
kube_apiserver_port: 6443
kube_proxy_mode: ipvs
kube_proxy_strict_arp: true
kube_proxy_nodeport_addresses: >-
 {%- if kube_proxy_nodeport_addresses_cidr is defined -%}
 [{{ kube_proxy_nodeport_addresses_cidr }}]
 {%- else -%}
 []
 {%- endif -%} 
kube_encrypt_secret_data: false
cluster_name: k8s-logs
ndots: 2
dns_mode: coredns
enable_nodelocaldns: true
enable_nodelocaldns_secondary: false
nodelocaldns_ip: 169.254.25.10
nodelocaldns_health_port: 9254
nodelocaldns_second_health_port: 9256
nodelocaldns_bind_metrics_host_ip: false
nodelocaldns_secondary_skew_seconds: 5
enable_coredns_k8s_external: false
coredns_k8s_external_zone: k8s_external.local
enable_coredns_k8s_endpoint_pod_names: false
resolvconf_mode: host_resolvconf
deploy_netchecker: false
skydns_server: "{{ kube_service_addresses | ipaddr('net') | ipaddr(3) | ipaddr('address') }}"
skydns_server_secondary: "{{ kube_service_addresses | ipaddr('net') | ipaddr(4) | ipaddr('address') }}"
dns_domain: "{{ cluster_name }}"
container_manager: containerd
kata_containers_enabled: false
kubeadm_certificate_key: "{{ lookup('password', credentials_dir + '/kubeadm_certificate_key.creds length=64 chars=hexdigits') | lower }}"
k8s_image_pull_policy: IfNotPresent
kubernetes_audit: false
default_kubelet_config_dir: "{{ kube_config_dir }}/dynamic_kubelet_dir"
podsecuritypolicy_enabled: false
volume_cross_zone_attachment: false
persistent_volumes_enabled: false
event_ttl_duration: "1h0m0s"
auto_renew_certificates: false
kubeadm_patches:
 enabled: false
 source_dir: "{{ inventory_dir }}/patches"
 dest_dir: "{{ kube_config_dir }}/patches"
containerd_limit_open_file_num: 1048576
kube_proxy_metrics_bind_address: 0.0.0.0:10249
kube_vip_enabled: true
kube_vip_controlplane_enabled: true
kube_vip_address: 10.46.0.40
apiserver_loadbalancer_domain_name: master-k8s-logs.local
loadbalancer_apiserver:
 address: 10.0.0.40
 port: 6443
kube_vip_interface: ens224
kube_vip_services_enabled: false
kube_vip_arp_enabled: true

Essas variáveis definem parâmetros cruciais como a versão do Kubernetes, configuração de rede, configurações de proxy e muito mais. Os comentários dentro dos arquivos YAML oferecem mais detalhes sobre o propósito dessas variáveis.

4. Geração de Chave SSH:

Em seguida, um par de chaves SSH é gerado para autenticação sem senha nos nós bare metal:

Código-fontebash

1

ssh-keygen -t rsa -f id_rsa_kubespray

Esta chave será usada pelo Ansible para se conectar e gerenciar os nós do cluster sem exigir a entrada manual de senha. Lembre-se de copiar a chave pública para o arquivo authorized_keys de todos os nós.

5. Executando o Kubespray dentro de um Contêiner Docker:

Para executar o Kubespray, usamos um contêiner Docker para isolar o ambiente:

Código-fontebash


1
2
3
4


docker run --rm -it \
 --mount type=bind,source="$(pwd)"/inventory/k8s-logs,dst=/inventory \
 --mount type=bind,source="${HOME}"/cluster-logs/kubespray/id_rsa_kubespray,dst=/root/.ssh/id_rsa \
 quay.io/kubespray/kubespray:v2.26.0 bash

Este comando executa a imagem Kubespray, montando o diretório de inventário e a chave privada SSH no contêiner. A flag --rm remove o contêiner após a execução. O comando bash inicia um shell bash dentro do contêiner.

6. Executando o Playbook:

Uma vez dentro do contêiner, o playbook principal do Kubespray é executado:

Código-fontebash

1

ansible-playbook -i inventory/hosts.yml cluster.yml -b

-i inventory/hosts.yml especifica o arquivo de inventário, cluster.yml é o playbook principal e -b habilita a execução become (sudo). Este comando inicia a implantação automatizada de todo o cluster Kubernetes.

7. Obtendo o kubeconfig:

Após a execução bem-sucedida do playbook, o arquivo Kubernetes admin.conf está localizado em /etc/kubernetes/admin.conf em qualquer nó master. Este arquivo é copiado e usado para autenticar com o cluster usando kubectl.

8. Ajustes do kubectl:

Para acesso de fora da rede local (por exemplo, via VPN), o arquivo kubeconfig pode precisar de ajustes para usar endereços IP em vez de FQDNs para uma conexão adequada.

9. Implantação de Rook, Mimir, Grafana e Loki (Não detalhado aqui):

Após a configuração do cluster Kubernetes, instalei o Rook para armazenamento persistente, o Mimir para armazenamento de métricas de longo prazo, o Grafana para visualizar as métricas e o Loki para agregação de logs. Essas etapas estão além do escopo deste post, mas foram cruciais para criar nosso stack de monitoramento. Descreverei cada instalação em posts dedicados.

Todo este processo fornece uma base sólida para um cluster Kubernetes robusto e escalável. O uso do Kubespray simplificou significativamente a implantação, e o stack de monitoramento garante que possamos gerenciar e solucionar problemas de nossa infraestrutura de forma eficaz. As configurações detalhadas de inventário e variáveis de grupo fornecem um modelo sólido para futuras implantações de cluster.

Primeiros Passos com Pipelines Declarativos no Jenkins

Mon, 18 Oct 2021 00:00:00 +0000

Depois de horas e horas de treinamento, vídeos, documentação e tutoriais, era hora de colocar em prática os conceitos que aprendi sobre Jenkins, uma das ferramentas de automação mais usadas para CI/CD.

É sabido que existem muitas outras soluções mais modernas hoje em dia, como GitHub Actions ou Gitlab CI, por exemplo, que é uma abordagem comum, já que você pode aproveitar o SCM (Source Code Management, ou Gerenciamento de Código Fonte) diretamente para automatizar suas tarefas, em vez de depender de uma ferramenta externa. No entanto, o Jenkins ainda é amplamente adotado e você pode executar muitas tarefas de automação sem muito esforço usando-o. Tudo vai depender da situação, do projeto atual e da equipe. Tradicionalmente, os jobs do Jenkins eram criados usando a interface do usuário do Jenkins e eram chamados de jobs FreeStyle. No Jenkins 2.0, uma nova forma foi introduzida usando uma técnica chamada pipeline como código, onde os jobs são criados usando um arquivo de script contendo os passos a serem executados. Esse arquivo de script é chamado de Jenkinsfile. Isso é apenas uma pincelada sobre os pipelines do Jenkins, há muito mais profundidade nisso e você sempre pode se aprofundar usando a documentação oficial em https://www.jenkins.io/doc/book/pipeline/.

Antes de começarmos a entrar nas coisas sérias, deixe-me apenas mencionar uma referência que inevitavelmente me veio à mente quando li pela primeira vez o nome “Jenkins”, que tenho certeza de que a maioria dos gamers do início dos anos 2000 vão se lembrar:

1. O que é um Pipeline de CI/CD?

Um pipeline de CI/CD é geralmente descrito como os processos e estágios de automação na entrega de software. Geralmente, existe uma ferramenta específica usada para realizar isso, que se orquestra com o SCM e as outras ferramentas. Ele pode ser usado para construir código, executar testes unitários, testes de fumaça (smoke tests), chamar ferramentas externas como SonarQube, Anchore, Trivy, construir imagens Docker e implantar em ambientes como Kubernetes ou onde quer que a aplicação seja entregue. Ao realizar operações e testes padronizados, um pipeline de CI/CD pode ajudar a reduzir erros manuais, fornecer feedback aos desenvolvedores e permitir iterações rápidas.

2. O que é um Jenkinsfile?

Um Jenkinsfile é apenas um arquivo de texto, geralmente commitado juntamente com o código fonte do projeto em um SCM. Idealmente, cada aplicação terá seu Jenkinsfile. Um Jenkinsfile pode ser escrito de duas maneiras - “sintaxe de pipeline com script” ou “sintaxe de pipeline declarativa”.

3. O que é um Pipeline Scripted do Jenkins?

Pipelines com script são executados no Jenkins master com a ajuda de um executor leve. Ele usa muito poucos recursos para traduzir o pipeline em comandos atômicos. Tanto a sintaxe declarativa quanto a sintaxe com script são diferentes uma da outra e são definidas de forma diferente. Pipelines com script são escritos em Groovy.

Requer conhecimento da linguagem Groovy;
O Jenkinsfile começa com a palavra ’node';
Capacidades avançadas;
Motor Groovy;
Pode conter construções de programação padrão, como bloco if-else, bloco try-catch, etc.

Um exemplo de um Pipeline Scripted:

Código-fontegroovy


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


node {
 stage('Build') {
 if (env.BRANCH_NAME == 'master') {
 echo "Estou na branch master, construindo a aplicação"
 bat "msbuild ${C:\\Jenkins\\my_project\\workspace\\test\\my_project.sln}"
 } else {
 echo 'Em direção ao centro do Computador Nuvem.'
 }
 }
 stage('Selenium') {
 echo 'Executando Testes de Fumaça do Selenium'
 dir(bachelol) { //muda o caminho para “bachelol”
 bat "mvn clean test -Dsuite=SMOKE_TEST -Denvironment=QA"
 }
 }
}

4. O que é um Pipeline Declarativo do Jenkins?

O Pipeline Declarativo é relativamente novo e fornece uma sintaxe simplificada e opinativa sobre os subsistemas do Pipeline. Sua sintaxe oferece uma maneira fácil de criar pipelines. Ele contém uma hierarquia predefinida e oferece a capacidade de controlar todos os aspectos da execução de um pipeline de maneira simples e direta.

A adição mais recente na técnica de criação de job pipeline do Jenkins;
Precisa usar as construções predefinidas para criar pipelines; Portanto, não é tão flexível quanto um pipeline com script;
O Jenkinsfile começa com a palavra ‘pipeline’ e existe uma estrutura predefinida;
Normalmente, a maneira preferida de começar, pois oferecem um rico conjunto de recursos, vêm com uma curva de aprendizado menor e não exigem o aprendizado prévio de uma linguagem de programação como Groovy apenas para escrever código de pipeline;
Também podemos validar a sintaxe do código do pipeline declarativo antes de executar o job. Ajuda a evitar muitos problemas de tempo de execução com o script de build.

5. Por que executar o Jenkins no Docker?

Apesar das vantagens inerentes (e ressalvas) de executar qualquer coisa no Docker, os principais motivos que pude pensar são:

Capacidade de manter a configuração do servidor sob controle de versão;
Executar várias cópias do servidor em qualquer lugar;
Integrar com Kubernetes e outras plataformas de orquestração;
A imagem oficial do Docker do Jenkins é amplamente adotada e mantida;
Implementação simples = administração simples.

O principal (Desvantagem|Ressalva|Problema|Questão|Falha) é quando você também deseja usar agentes com o docker. Para fazer isso, você precisará de alguma implementação do Docker in Docker. Existem algumas maneiras de fazer isso, mas as duas maneiras mais fáceis são conectar o contêiner Jenkins diretamente ao socket Docker do host usando -v /var/run/docker.sock:/var/run/docker.sock e alterar as permissões, ou habilitar o TCP no lado do servidor Docker. Se você puder executar seu servidor Jenkins no Kubernetes, poderá habilitá-lo para iniciar novos pods de agente dentro do cluster, o que oferece ainda mais flexibilidade. Vou tentar isso no futuro, já que estou sem créditos na AWS e meu cluster de desenvolvimento está atrás de um proxy, o que é uma dor de cabeça para lidar.

6. Construindo uma Imagem do Jenkins

O Dockerfile abaixo cria uma imagem baseada no Jenkins LTS mais recente do Dockerhub e pré-instala os plugins necessários:

Código-fontedockerfile


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


FROM jenkins/jenkins:lts

# Ignorar o assistente de configuração
ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false"

# Definir o grupo docker
ARG DOCKER_GID=998

# Obter plugins
RUN /usr/local/bin/install-plugins.sh \
 workflow-multibranch:latest \
 pipeline-model-definition:latest \
 pipeline-stage-view:latest \
 git:latest \
 credentials:latest \
 slack:latest

# Instalar Docker & docker-compose
USER root

RUN apt-get update && \
 apt-get -y install apt-transport-https \
 ca-certificates \
 curl \
 gnupg2 \
 software-properties-common && \
 curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg > /tmp/dkey; apt-key add /tmp/dkey && \
 add-apt-repository \
 "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \
 $(lsb_release -cs) \
 stable" && \
 apt-get update && \
 groupadd -g ${DOCKER_GID} docker && \
 apt-get -y install docker-ce docker-ce-cli containerd.io

RUN curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose

RUN usermod -aG docker jenkins

USER jenkins

Eu me referi à documentação oficial: https://docs.docker.com/compose/install/ https://docs.docker.com/engine/install/ubuntu/

Para subir uma instância do Jenkins na minha máquina local, usei um arquivo docker-compose.yml e coloquei tudo na mesma pasta. O serviço jenkins aponta para um dockerfile no mesmo caminho e o contêiner estará acessível em localhost:9080. Mapeei o docker.sock para o contêiner e combinei o docker GID com o host, e também criei e mapeei uma pasta jenkins_home localmente para persistir os dados:

Código-fonteyaml


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


version: "3.8"
services:
 jenkins:
 build:
 context: .
 dockerfile: Dockerfile
 ports:
 - "127.0.0.1:9080:8080"
 volumes:
 - ./jenkins_home:/var/jenkins_home
 - /var/run/docker.sock:/var/run/docker.sock
 restart: unless-stopped

Agora que temos uma instância do Jenkins em execução com os plugins instalados e com acesso ao dockerd do host, vamos começar a usá-lo para automatizar um build.

7. A Aplicação de Exemplo Spring PetClinic

Para testar tudo, baixei a “Spring PetClinic Sample Application” (pode ser encontrada aqui: https://github.com/spring-projects/spring-petclinic), que é escrita em Java usando Spring Boot e construída com Maven. Se você clonar o repositório oficial, você terá um Maven Wrapper incluído que pode ser usado para construir a aplicação. Então, antes de tentar automatizar qualquer coisa com Jenkins, vamos primeiro construir, testar e executar a aplicação manualmente:

Código-fontebash


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Clonar o repo
git clone https://github.com/spring-projects/spring-petclinic.git

# Entrar no diretório
cd spring-petclinic

# Construir a aplicação
./mvnw package

# Executar a aplicação
java -jar target/*.jar

Na primeira vez que executei o comando mvnw package, demorou um pouco para terminar, pois baixou todas as dependências. Depois disso, as execuções subsequentes levaram cerca de um minuto para terminar. Isso é praticamente tudo que temos que fazer para testar se ele constrói e executa corretamente, eu apenas segui as instruções do repositório sem mudar nada. Se ele executar, sabemos que o código deve funcionar dentro do pipeline também. As mudanças virão quando usarmos o Maven do Jenkins e tentarmos executar os testes JUnit.

Saída do build:

Código-fonteTexto simples


 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[INFO] Construindo jar: ./github/spring-petclinic/target/spring-petclinic-2.5.0-SNAPSHOT.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:2.5.4:repackage (repackage) @ spring-petclinic ---
[INFO] Substituindo o artefato principal pelo arquivo repaginado
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Tempo total: 01:15 min
[INFO] Finalizado em: 2021-10-19T11:35:43-03:00
[INFO] ------------------------------------------------------------------------

Saída de java -jar target/*.jar:

Código-fonteTexto simples


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


java -jar target/*.jar


 |\ _,,,--,,_
 /,`.-'`' ._ \-;;,_
 _______ __|,4- ) )_ .;.(__`'-'__ ___ __ _ ___ _______
 | | '---''(_/._)-'(_\_) | | | | | | | | |
 | _ | ___|_ _| | | | | |_| | | | __ _ _
 | |_| | |___ | | | | | | | | | | \ \ \ \
 | ___| ___| | | | _| |___| | _ | | _| \ \ \ \
 | | | |___ | | | |_| | | | | | | |_ ) ) ) )
 |___| |_______| |___| |_______|_______|___|_| |__|___|_______| / / / /
 ==================================================================/_/_/_/

:: Built with Spring Boot :: 2.5.4


2021-10-19 11:38:31.201 INFO 39806 --- [ main] o.s.s.petclinic.PetClinicApplication : Starting PetClinicApplication v2.5.0-SNAPSHOT using Java 11.0.11 on my-machine with PID 39806 (./github/spring-petclinic/target/spring-petclinic-2.5.0-SNAPSHOT.jar started by biofa in ./github/spring-petclinic)
2021-10-19 11:38:31.204 INFO 39806 --- [ main] o.s.s.petclinic.PetClinicApplication : No active profile set, falling back to default profiles: default
2021-10-19 11:38:32.230 INFO 39806 --- [ main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
2021-10-19 11:38:32.288 INFO 39806 --- [ main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 50 ms. Found 4 JPA repository interfaces.
2021-10-19 11:38:33.020 INFO 39806 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
2021-10-19 11:38:33.036 INFO 39806 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2021-10-19 11:38:33.037 INFO 39806 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.52]
2021-10-19 11:38:33.128 INFO 39806 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2021-10-19 11:38:33.128 INFO 39806 --- [ main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1865 ms
2021-10-19 11:38:33.377 INFO 39806 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Starting...
2021-10-19 11:38:33.590 INFO 39806 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Start completed.
2021-10-19 11:38:33.919 INFO 39806 --- [ main] org.ehcache.core.EhcacheManager : Cache 'vets' created in EhcacheManager.
2021-10-19 11:38:33.934 INFO 39806 --- [ main] org.ehcache.jsr107.Eh107CacheManager : Registering Ehcache MBean javax.cache:type=CacheStatistics,CacheManager=urn.X-ehcache.jsr107-default-config,Cache=vets
2021-10-19 11:38:33.941 INFO 39806 --- [ main] org.ehcache.jsr107.Eh107CacheManager : Registering Ehcache MBean javax.cache:type=CacheStatistics,CacheManager=urn.X-ehcache.jsr107-default-config,Cache=vets
2021-10-19 11:38:34.021 INFO 39806 --- [ main] o.hibernate.jpa.internal.util.LogHelper : HHH000204: Processing PersistenceUnitInfo [name: default]
2021-10-19 11:38:34.081 INFO 39806 --- [ main] org.hibernate.Version : HHH000412: Hibernate ORM core version 5.4.32.Final
2021-10-19 11:38:34.204 INFO 39806 --- [ main] o.hibernate.annotations.common.Version : HCANN000001: Hibernate Commons Annotations {5.1.2.Final}
2021-10-19 11:38:34.332 INFO 39806 --- [ main] org.hibernate.dialect.Dialect : HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
2021-10-19 11:38:34.955 INFO 39806 --- [ main] o.h.e.t.j.p.i.JtaPlatformInitiator : HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.NoJtaPlatform]
2021-10-19 11:38:34.962 INFO 39806 --- [ main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2021-10-19 11:38:36.371 INFO 39806 --- [ main] o.s.b.a.e.web.EndpointLinksResolver : Exposing 13 endpoint(s) beneath base path '/actuator'
2021-10-19 11:38:36.441 INFO 39806 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
2021-10-19 11:38:36.453 INFO 39806 --- [ main] o.s.s.petclinic.PetClinicApplication : Started PetClinicApplication in 5.753 seconds (JVM running for 6.136)

8. Usando Maven no Jenkins

Existem algumas maneiras diferentes de usar o Maven com o Jenkins. Existe um plugin Maven para Jenkins, e podemos instalar o Maven no servidor Jenkins e configurá-lo em “Global Tool Configuration”. Como queremos usar contêineres docker como executores ou agentes, essa não seria uma opção. Também poderíamos usar o wrapper que vem com o projeto, mas uma rota melhor e simples seria usar a imagem oficial do Maven docker, e dessa forma podemos ter um agente sempre atualizado e completamente separado do Maven do nosso servidor Jenkins. Essa abordagem facilita o gerenciamento do ambiente e também permite que um único servidor Jenkins trabalhe com diferentes tipos de builds com uma única instalação, sem ter que incorporar todas as ferramentas usadas no servidor.

Eu construí um pipeline com seis estágios: Init, Build, Test e Build Image, Publish Image e Prod. Alguns dos principais aspectos são:

Ele monta o diretório m2, que é usado pelo maven, localmente para ter cache entre os builds, e também o settings.xml para permitir a configuração de parâmetros personalizados para o Maven;
A Imagem Docker Maven 3.8.3 com AdoptOpenJDK 11 é usada como um agente apenas para os estágios que a requerem;
As credenciais do Dockerhub foram adicionadas anteriormente no Jenkins.

Código-fontegroovy


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86


pipeline {
 agent none
 environment {
 DEPLOY_TO = 'staging'
 imageName = "fabioctba/spring-petclinic"
 registryCredential = 'dockerhub'
 dockerImage = ''
 }
 stages {
 stage('Init'){
 agent any
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Starting"
 sh 'git --version'
 echo "Implantando para ${DEPLOY_TO}"
 }
 }
 stage('Build') {
 agent {
 docker {
 image 'maven:3.8.3-adoptopenjdk-11'
 args '-v m2:/root/.m2 -v settings.xml:/root/.m2/settings.xml'
 }
 }
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Building"
 sh 'mvn -B -DskipTests clean package'

 }
 }
 stage('Test') {
 agent {
 docker {
 image 'maven:3.8.3-adoptopenjdk-11'
 args '-v m2:/root/.m2 -v settings.xml:/root/.m2/settings.xml'
 }
 }
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Running Tests"
 sh 'mvn test'
 }
 post {
 always {
 archiveArtifacts artifacts: 'target/*.jar'
 junit 'target/surefire-reports/*.xml'
 }
 }
 }
 stage('Build Image') {
 agent any
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Building Image"

 script {
 dockerImage = docker.build imageName
 }
 }
 }
 stage('Publish Image') {
 agent any
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Building Image"

 script {
 docker.withRegistry( '', registryCredential ) {
 dockerImage.push("$BUILD_NUMBER")
 dockerImage.push('latest')
 }
 }
 }
 }
 stage('Prod') {
 agent any
 when {
 allOf {
 branch 'master';
 environment name: 'DEPLOY_TO', value: 'production'
 }
 }
 steps {
 slackSend channel: '#jenkins', message: "${env.BUILD_ID} on ${env.JENKINS_URL} - Running Production stage"
 echo 'Algum passo extra quando no release de produção'
 }
 }
 }
}

Eu usei o Plugin Slack para integrar com o Jenkins, seguindo esta documentação. Usei apenas duas variáveis apenas para ilustrar o que pode ser enviado como mensagem, mas uma lista completa de variáveis de ambiente pode ser encontrada diretamente no Jenkins acessando http://localhost:9080/env-vars.html. Claro, você tem que mudar localhost:9080 para o endereço do seu servidor.

O estágio Init imprime as versões das principais ferramentas utilizadas, úteis para depurar problemas;

O estágio Build executa mvn package, que cria os arquivos jar;

O estágio Test executa os testes unitários. O Spring Pet Clinic tem um total de 40 testes configurados, e isso dependeria de como a equipe de desenvolvimento criou seus testes;

O estágio Build Image cria uma imagem Docker;

O estágio Publish Image publica a imagem no Dockerhub;

O estágio Prod não faz nada, é apenas um exemplo de um passo condicional que pode ser executado dependendo de uma variável.

Observe que não há um estágio para clonar o repositório no início; esse estágio é implícito quando você configura o Jenkins para puxar o pipeline do SCM, que é o plano aqui.

Aqui está o Dockerfile que eu usei para publicar a aplicação:

Código-fontedockerfile


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


FROM openjdk:11-jre-slim

RUN groupadd --gid 1000 java \
 && useradd --uid 1000 --gid java --shell /bin/bash --create-home java

USER java

VOLUME /tmp

WORKDIR /app

COPY --chown=java:java ./target/*.jar /app/

CMD ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app/*.jar"]

Esse é um pipeline funcional, e eu queria incluir a maioria dos conceitos que vi nos cursos. Existem outros recursos que gostaria de experimentar no futuro, como bibliotecas compartilhadas e pipelines multi-branch, mas isso pode entrar em outro post.

9. Cursos que eu fiz ou recomendo:

a. Jenkins, Do Zero ao Herói: Torne-se um Mestre DevOps Jenkins

Udemy, por Ricardo Andre Gonzalez Gomez, 2018 https://www.udemy.com/course/jenkins-from-zero-to-hero/

Eu achei este curso um pouco desatualizado e parece que o autor parou de mantê-lo em 2020. No entanto, se você nunca usou o Jenkins antes e quer um curso barato para começar, eu recomendo fortemente este. Também é bem recomendado em muitas outras fontes e tem uma alta taxa na Udemy. Ricardo se concentra muito em Docker, então pode ser mais adequado para alguém sem nenhuma experiência em Docker também.

b. Integração Contínua com Jenkins

Pluralsight, por diferentes autores, atualizado constantemente https://app.pluralsight.com/paths/skill/continuous-integration-with-jenkins

A Pluralsight tem um total de 8 cursos, cada um com cerca de 2 horas de duração, o que torna o Skill Path do Jenkins. Fiz quatro deles durante a última Pluralsight Free Week e, como outros cursos que fiz na Pluralsight, a qualidade foi muito superior. Infelizmente, a Pluralsight custa uma grande quantia de dinheiro, então geralmente fico de olho em suas semanas gratuitas e fins de semana gratuitos periodicamente. O bom é que você pode baixar o material do curso e a maioria dos autores tem repositórios no GitHub onde você pode verificar o código mais tarde.

10. Referências

https://stackoverflow.com/questions/44440164/what-are-the-advantages-of-running-jenkins-in-a-docker-container

https://www.cinqict.nl/blog/building-a-jenkins-development-docker-image

https://tomgregory.com/building-a-spring-boot-application-in-jenkins/

Se você leu até o final, gostaria de ouvir seus comentários, e espero que isso o tenha ajudado de alguma forma.

.
.
.
.

E desculpe pelo post longo... aqui está uma batata.

Fonte: @truth.potato