DevOps Madness — IaC × AI agents

IaC Modernization & How to Future-Proof Your Infrastructure

Tue, 21 Jul 2026 00:00:00 GMT

Summary: “Modernize” usually arrives as a mandate with no sequence attached, and this piece gives the sequence: nine steps from inventory to agentic AI. Import what exists and enforce code-first changes before tooling decisions, break up monolithic state and add policy gates before automating delivery. Bring AI in last, once guardrails exist, and plan for a multi-tool reality built on open standards.

Who should read it: teams with an aging Terraform estate, and platform leads deciding where AI fits into infrastructure work.

Read the full article on Spacelift →

Claude Code for Infrastructure as Code: A Practical Guide

Tue, 30 Jun 2026 00:00:00 GMT

Summary: This is the piece closest to what this site is about. IaC is a good match for coding agents because plans give you a review gate before anything applies. Start with the boring work (module upgrades, refactors, drift explanations, docs), give the agent plan-only permissions, and let it earn trust per repo through conventions and context files, the same way a new team member would.

Who should read it: platform engineers who want to try an agent against a Terraform estate without gambling production on it.

Read the full article on Spacelift →

How to Build a Well-Architected AWS Landing Zone

Fri, 26 Jun 2026 00:00:00 GMT

Summary: The landing zone is the highest-leverage early decision in AWS, since accounts, identity, networking and guardrails all inherit it. The guide compares the build routes honestly (Control Tower, Landing Zone Accelerator, account factory, fully custom), each trading flexibility against maintenance differently. OU design and account vending hurt most to change later, so spend your thinking there first and manage the landing zone itself with IaC from day one.

Who should read it: anyone standing up multi-account AWS from scratch, or re-platforming an organisation that grew one account at a time.

Read the full article on Gruntwork →

Cloud Migration Security Guide: Risks & Checklist

Tue, 09 Jun 2026 00:00:00 GMT

Summary: Migrations create a window where data lives in two places, identities double, and temporary access hardens into permanent access. This guide maps the risks to each migration phase and ends in a runnable checklist. Know who owns what during the move, expire migration access by design, and re-verify encryption, logging and identity in the new home.

Who should read it: teams planning a lift to the cloud, and security folks handed a migration halfway through.

Read the full article on Spacelift →

AI Coding Assistants and Infrastructure as Code: Velocity Without Losing Control

Fri, 08 May 2026 00:00:00 GMT

Summary: This is the closest thing to a manifesto for what this site covers: agents make IaC work fast, and speed against production infrastructure is only welcome with brakes. The piece builds six layered controls for Claude Code, from least-privilege credentials and permission rules through CLAUDE.md conventions to hooks and sandboxing. Each layer catches what the previous one missed, and the last two cover the tail risks where agent incidents actually live.

Who should read it: platform teams adopting coding agents against Terraform estates, and anyone whose security review asked how the agent is contained.

Read the full article on Gruntwork →

DevOps Practices in Government and the Public Sector

Wed, 22 Apr 2026 00:00:00 GMT

Summary: Most DevOps writing assumes a startup’s freedom, while public-sector teams work under procurement rules, audit trails and security baselines. Here the ordering is reversed: security and compliance gates come first, and the pipeline is built to satisfy them by default, with auditability and data residency as hard tooling requirements. Modernization succeeds through small proofs inside the rules, rarely through big-bang transformation.

Who should read it: engineers and leads in government or regulated industries, and vendors trying to understand their constraints.

Read the full article on Spacelift →

What is Multi-Cloud Security? Challenges & Best Practices

Fri, 17 Apr 2026 00:00:00 GMT

Summary: Multi-cloud usually arrives by acquisition or by accident, and security inherits the mess of three IAM dialects and three logging stories. Centralize identity first, then normalize logging and detection into one place, since nobody triages three consoles during an incident. Policy as code and IaC are the only realistic path to consistent baselines across providers.

Who should read it: security and platform teams inheriting a second cloud, and architects being asked to plan for one.

Read the full article on Spacelift →

Infrastructure as Code with Ansible: Tutorial

Thu, 05 Mar 2026 00:00:00 GMT

Summary: Ansible was built for configuration management and gets regularly pressed into provisioning, and this tutorial takes that usage seriously with real AWS resources. It can provision, but it tracks no state, so idempotency comes from modules checking reality on every run. The strongest pattern pairs it with Terraform: one provisions, the other configures.

Who should read it: Ansible shops weighing whether they need Terraform, and IaC users curious what the playbook side offers.

Read the full article on Spacelift →

Migrate Amazon EC2 to ECS Express Mode using Kiro CLI and MCP servers

Thu, 26 Feb 2026 00:00:00 GMT

Summary: Migrations are exactly the toil agents should absorb. This walkthrough uses Kiro CLI with MCP servers to move an EC2 workload onto ECS Express Mode, with the agent doing discovery and generation while you review the steps. MCP servers give the agent real context about your environment, which separates a guided migration from generated guesswork.

Who should read it: teams still running container-shaped workloads on EC2, and anyone curious what agentic migration looks like in practice.

Read the full article on AWS →

From Terraform to OpenTofu: A Migration Guide

Mon, 19 Jan 2026 00:00:00 GMT

Summary: The licence change forced a decision on every platform team, and OpenTofu is close to a drop-in replacement from some Terraform versions and a diverging fork from others. Match the migration path to your starting version; from 1.9.x there is a defined, reversible sequence. Check provider and module compatibility first, and decide the rollback plan before you migrate.

Who should read it: platform teams still on Terraform and weighing a move, especially with a large multi-team estate where a botched cutover is expensive.

Read the full article on StackGuardian →

Deploying Agentic AI Solutions with Infrastructure as Code

Fri, 09 Jan 2026 00:00:00 GMT

Summary: Agents are usually shown as laptop demos; this piece treats one as a production service and codifies the whole deployment with Terraform on Bedrock AgentCore. Agent infrastructure deserves the same IaC discipline as the rest of the estate, with AgentCore covering runtime, memory and identity. Least privilege matters more for agents than for humans, since they act faster and never get tired.

Who should read it: teams moving a first agent from prototype to production on AWS.

Read the full article on Spacelift →

IaC Testing for DevOps: Types, Tools & Examples

Wed, 10 Dec 2025 00:00:00 GMT

Summary: Application code gets tests by default while infrastructure code mostly gets a plan and a prayer. This guide lays out the IaC testing layers and what each catches: static analysis is nearly free and catches a surprising share, real confidence needs integration tests against real resources, and policy as code scales better than review comments.

Who should read it: teams whose only IaC gate is a human reading a plan, and anyone building out a platform pipeline.

Read the full article on Spacelift →

Strengthen AWS Security Posture with Robust Infrastructure as Code Strategy

Mon, 10 Nov 2025 00:00:00 GMT

Summary: This APN piece frames security posture as an IaC problem: when accounts, controls and baselines are code, security is enforced at provision time instead of discovered at audit time. Control Tower controls plus baseline-equipped account vending mean new accounts start compliant. Drift detection doubles as a security control, since an unexplained change to security infrastructure is a finding, whatever caused it.

Who should read it: security engineers who keep finding the same misconfigurations, and platform teams codifying an AWS estate.

Read the full article on AWS →

Building Golden Paths: Standardizing Cloud Deployments

Wed, 22 Oct 2025 00:00:00 GMT

Summary: Most standardization attempts die as pdf guidelines nobody opens; golden paths work because the standard way is also the easiest way. A golden path is a product, and adoption is its only real metric, since mandates create workarounds and good defaults create users. The predictable pitfalls: paths too rigid for real needs, and paths built once with no feedback loop.

Who should read it: platform teams tired of writing standards documents, and leads deciding between governance and enablement.

Read the full article on StackGuardian →

How to Migrate From On-premise to AWS Cloud

Fri, 03 Oct 2025 00:00:00 GMT

Summary: Migrations fail on sequencing more than on technology. The seven Rs are a triage tool, and most estates end up mixed: rehost the bulk, refactor the few that earn it, retire more than expected. Assessment is the phase teams shortchange, and the operating model change deserves planning alongside the technical move.

Who should read it: teams with a migration mandate and a datacenter lease ending, and engineers translating strategy slides into a plan.

Read the full article on Spacelift →

AWS CloudFormation Drift Detection & Remediation Guide

Tue, 23 Sep 2025 00:00:00 GMT

Summary: CloudFormation ships drift detection, and this guide covers using it honestly: detection is on demand and has documented blind spots worth knowing before trusting a green result. Remediation is rarely just re-apply, since import or careful template updates preserve the fix someone made for a reason. Prevention is organizational: lock down console writes and make the pipeline the only door.

Who should read it: CloudFormation operators, and anyone auditing an estate where the console has had visitors.

Read the full article on Spacelift →

Kubernetes right-sizing with metrics-driven GitOps automation

Thu, 11 Sep 2025 00:00:00 GMT

Summary: Resource requests are guesses that never get revised, and clusters pay for the padding forever. This walkthrough builds the loop that fixes it: metrics feed recommendations, which arrive as reviewed GitOps pull requests with a full audit trail. Mind the metrics window, since recommendations from a quiet week will starve the busy one.

Who should read it: EKS operators with overprovisioned clusters, and FinOps-minded platform folks who want savings with review gates.

Read the full article on AWS →

Building a developer portal with Port on AWS to Boost Engineering Efficiency

Tue, 05 Aug 2025 00:00:00 GMT

Summary: Developer portals get discussed in the abstract far more than they get built, and this APN piece takes the concrete route to a working one on AWS with Port. The portal earns its keep as a single entry point: service catalog, scorecards and self-service actions in one place. Integration speed beats feature breadth at the start, and adoption is the metric.

Who should read it: platform teams evaluating the build-or-buy portal question, and engineering leads chasing onboarding time.

Read the full article on AWS →

What Is MCP? Model Context Protocol Explained Simply

Mon, 04 Aug 2025 00:00:00 GMT

Summary: MCP became the default way to give agents tools, and the mental model is small: hosts, clients and servers exposing tools, resources and prompts. It complements APIs by standardizing how a model discovers and calls capabilities. A working server takes an afternoon, so build one before forming an opinion about the protocol.

Who should read it: engineers wiring agents to real systems, and anyone who keeps hearing MCP in meetings and wants the plain version.

Read the full article on Spacelift →

What is Observability? Metrics, Logs & Traces Overview

Fri, 04 Jul 2025 00:00:00 GMT

Summary: Metrics tell you something is wrong, traces tell you where, logs tell you why, so design collection around the questions. OpenTelemetry is the sane default now: one instrumentation layer, vendor choice deferred. Cardinality and retention are where observability bills explode, so decide both deliberately.

Who should read it: teams standing up observability from scratch, and anyone consolidating three agents into one pipeline.

Read the full article on Spacelift →

DevOps Release Management: Stages & Best Practices

Thu, 26 Jun 2025 00:00:00 GMT

Summary: Release management survives in DevOps as automation plus clear stages: plan, build, test, deploy, verify, roll back. Rollback deserves as much rehearsal as deployment, since an untested rollback plan is a hope, and hope pages you at night. Progressive delivery turns releases into experiments with small blast radii.

Who should read it: teams formalizing how software ships, and release managers translating their role into a DevOps organization.

Read the full article on Spacelift →

How AI can Impact Platform Engineering Implementations

Tue, 17 Jun 2025 00:00:00 GMT

Summary: A map of where AI concretely lands in platform work: automation, self-service, reliability prediction, security and cost. The near-term wins are unglamorous (better self-service interfaces, drift explanations, policy suggestions) and the predictive work needs data your platform may not collect yet. AI extends a working platform and rescues no broken one.

Who should read it: platform leads writing next year’s roadmap, and engineers separating the plausible from the pitch deck.

Read the full article on StackGuardian →

Top 19 AWS Monitoring Tools & 8 Best Practices for 2026

Thu, 15 May 2025 00:00:00 GMT

Summary: A map of the crowded AWS monitoring aisle, native stack on one side and specialized tools on the other. Start with CloudWatch, X-Ray and friends, which cover more than teams assume at predictable cost, and let third-party tools earn their place on cross-cloud visibility or correlation. The practices carry the weight: alert on symptoms, tag for cost attribution, review dashboards someone actually opens.

Who should read it: teams choosing or consolidating monitoring on AWS, especially anyone paying for three tools that overlap.

Read the full article on Spacelift →

Implementing Cloud Security Best Practices with StackGuardian

Tue, 29 Apr 2025 00:00:00 GMT

Summary: Everyone can list cloud security best practices, and implementation is where they go to die, usually as review comments and wiki pages. Policy as code closes the gap, moving security review from opinions in pull requests to rules that fail pipelines consistently. Start with the practices that automate cleanly: encryption defaults, tagging, identity boundaries and drift.

Who should read it: security and platform folks who own cloud baselines, and teams whose security process is still a checklist.

Read the full article on StackGuardian →

The Illusion of Infrastructure Automation Maturity

Tue, 15 Apr 2025 00:00:00 GMT

Summary: Most teams rate their automation maturity by what exists rather than by what they trust, and a pipeline nobody dares run on Friday is not maturity. The pitfalls are quiet: manual steps around the pipeline, state only one person understands, drift nobody measures. Closing the gap starts with measuring outcomes instead of counting tools.

Who should read it: platform leads who suspect their automation story sounds better in slides than it feels on call.

Read the full article on Spacelift →

EKS Auto Mode: Simplify Kubernetes Operations

Wed, 09 Apr 2025 00:00:00 GMT

Summary: This one pairs with my AWS Summit Amsterdam talk on the same topic. Auto Mode moves node management, autoscaling and core add-ons onto the AWS side of the line, with the Karpenter-based node story as the substance behind the name. The trade is control for operations, and the management premium on top of EC2 should be judged against the engineering time it replaces.

Who should read it: teams running EKS with a thin platform crew, and anyone evaluating how much cluster operations they still want to own.

Read the full article on Spacelift →

Harnessing AI to Revolutionize Test Coverage Analysis

Sun, 30 Mar 2025 00:00:00 GMT

Summary: Coverage numbers are the most gamed metric in software: a high percentage says lines ran, and nothing about whether anything was verified. AI genuinely helps at gap analysis and drafting tests for uncovered paths, which turns coverage reports into work items. The risk is generated tests that assert the bug, so review remains the job.

Who should read it: developers who inherited a coverage target, and QA engineers evaluating AI tooling past the demo.

Read the full article on Qodo →

How AI Code Assistants Are Revolutionizing Test-Driven Development

Thu, 20 Mar 2025 00:00:00 GMT

Summary: Generative AI writes plausible code, and plausible is the problem. TDD turns out to be a natural harness: tests written first give the assistant a checkable target, and the red-green cycle catches confident nonsense the same way it catches human mistakes. The tests themselves still need review, and the loop rewards small steps over big prompts.

Who should read it: developers using assistants daily who want more than autocomplete, and TDD practitioners curious what changes.

Read the full article on Qodo →

10 Tips for Selecting the Perfect AI Code Assistant for Your Development Needs

Mon, 17 Mar 2025 00:00:00 GMT

Summary: Teams pick AI assistants the way they pick lunch: whatever is closest. Context handling separates the tools more than model choice does, and integration fit beats raw capability, since the best suggestions in the wrong place go unused. Read the security and privacy terms properly; where code travels and what trains on it are contract questions.

Who should read it: engineering leads running a tool evaluation, and developers making the case for a specific assistant.

Read the full article on Qodo →

Ansible vs. Jenkins - Key Differences and Comparison

Thu, 06 Mar 2025 00:00:00 GMT

Summary: Jenkins orchestrates pipelines, Ansible changes host state, and the overlap is limited to triggering tasks. The common pattern uses Jenkins to decide when and Ansible to define what: pipeline stages calling playbooks. If you are choosing one, you are probably asking the wrong question, since most stacks that need one eventually need both.

Who should read it: engineers untangling CI/CD responsibilities, and anyone whose team debates this in tooling meetings.

Read the full article on Spacelift →

Observability vs Monitoring: Key Differences Explained

Thu, 13 Feb 2025 00:00:00 GMT

Summary: Monitoring watches for known failure modes, observability lets you interrogate unknown ones, and the distinction decides what you build and what you buy. The two complement each other: dashboards and alerts on top, rich telemetry underneath for the incidents that fit no dashboard. Get monitoring right first, then invest in the high-cardinality telemetry that makes systems explorable.

Who should read it: anyone writing an observability strategy, and engineers who suspect their dashboards only cover the failures already seen.

Read the full article on Spacelift →

Empower your Dev Teams: The Value of Self-Service Infrastructure

Fri, 31 Jan 2025 00:00:00 GMT

Summary: Ticket queues are how infrastructure teams become bottlenecks with good intentions, and self-service is the exit. Guardrails are the enabler: it works when the safe path is predefined rather than when everyone gets admin. Start with the most requested resources, since one well-built template kills more tickets than a portal full of half-built ones.

Who should read it: infrastructure leads measuring their week in tickets, and platform engineers designing their first vending flow.

Read the full article on StackGuardian →

16 DevOps Metrics You Should Be Tracking [DORA & Other]

Wed, 15 Jan 2025 00:00:00 GMT

Summary: The DORA four (deployment frequency, lead time, change failure rate, time to restore) tell most of the delivery story, with a dozen supporting metrics around them. Every metric needs an owner and a decision it informs, since orphan metrics rot into wallpaper. Watch trends over absolutes, and never wire metrics to individual performance unless you want them gamed.

Who should read it: engineering leads building a measurement practice, and teams whose current metric is vibes.

Read the full article on Spacelift →

AWS AI Practitioner Certification Cheat Sheet

Mon, 06 Jan 2025 00:00:00 GMT

AWS AI Practitioner Certification exam study notes, exam pointers, and cheat sheet.

Photo by Google DeepMind on Unsplash

This material was gathered during my preparation for the AWS AI Practitioner Certification Exam (here’s my badge). I created and curated this cheatsheet with useful information that will be handy to review before taking the exam.

Note that to pass this exam is crucial to get a good overall understanding of the basic AI concepts and AWS AI-focused services. Use these notes as complementary material and not complete study material for the exam.

AWS frequently changes information, configuration, and options of different services, so some of the content might become outdated at some point. Make sure to cross-check and validate the information you are getting from online sources with the official AWS Documentation and FAQs before your exam.

OK, enough with the disclaimers, let’s get to it.

SageMaker

Automatic model tuning can be performed using SageMaker Automatic Model Tuning (AMT). It can automatically choose hyper parameter ranges, search strategy, maximum runtime of a tuning job, early stopping type for training jobs, number of times to retry a training job, and model convergence flag to stop a tuning job, based on the objective metric you provide.

SageMaker Inference

Asynchronous — process smaller payloads without requiring real-time responses by queuing the requests and handling them in the background. This method is cost-effective and efficient when some delay is acceptable, as it frees up resources and optimizes compute usage. Asynchronous inference is ideal for scenarios where the payload size is less than 1 GB and immediate results are not critical.
Batch — generally used for processing large datasets all at once. it is typically more efficient for handling larger payloads (several gigabytes or more). For smaller payloads of less than 1 GB, batch inference might be overkill and less cost-efficient compared to asynchronous inference.
Real-time — optimized for scenarios where low latency is essential, and responses are needed immediately
Serverless — good choice for workloads with unpredictable traffic or sporadic requests, as it scales automatically based on demand

SageMaker Clarify

Focused on detecting bias in data and explaining model predictions to ensure transparency and fairness.

SageMaker GroundTruth

Labeling data with a human-in-the-loop
GroundTruth Plus provides a fully managed data labeling service that helps deliver high-quality annotations. Combination of human labelers and machine learning-assisted labeling to ensure accuracy and consistency in the labels.

SageMaker Canvas

No-code interface to create ML models

SageMaker Data Wrangler

Reduces the time it takes to aggregate and prepare tabular and image data for ML from weeks to minutes from a single visual interface.
Data Wrangler supports several balancing operators as part of the Balance data transform to fix bias by balancing the dataset.

SageMaker Feature Store

Fully managed, purpose-built repository to store, share, and manage features for machine learning (ML) models. Features are inputs to ML models used during training and inference.

SageMaker JumpStart

Amazon SageMaker JumpStart is a machine learning (ML) hub that can help you accelerate your ML journey. With SageMaker JumpStart, you can evaluate, compare, and select Foundation Models (FMs) quickly based on pre-defined quality and responsibility metrics to perform tasks like article summarization and image generation. Pretrained models are fully customizable for your use case with your data, and you can easily deploy them into production with the user interface or SDK.

SageMaker Model Dashboard

Aggregates and displays data from Amazon SageMaker Model Cards, SageMaker Model Monitor and SageMaker Endpoint services. It’s a centralized repository of all models created in your account. The models are generally the outputs of SageMaker training jobs, but you can also import models trained elsewhere and host them on SageMaker.

SageMaker Model Cards

Document critical details about your machine learning (ML) models in a single place for streamlined governance and reporting. Model cards can help you to capture key information about your models throughout their lifecycle and implement responsible AI practices.
Catalog details such as the intended use and risk rating of a model, training details and metrics, evaluation results and observations, and additional call-outs such as considerations, recommendations, and custom information
Describes how a model should be used in production, the scenarios in which is appropriate to use a model, and additional considerations such as the type of data to use with the model or any assumptions made during development.

SageMaker Model Monitor

Designed to track the performance of machine learning models in production by monitoring data drift, bias, and other deviations. primarily focused on post-deployment model monitoring

Governance in SageMaker

SageMaker provides purpose-built ML governance tools across the ML lifecycle. With Amazon SageMaker Role Manager, administrators can define minimum permissions in minutes. Amazon SageMaker Model Cards make it easier to capture, retrieve, and share essential model information from conception to deployment, and Amazon SageMaker Model Dashboard keeps you informed on production model behavior, all in one place.

Amazon Augmented AI

Get human review of low-confidence predictions or random prediction samples. Brings human review of ML predictions to all developers by removing the heavy lifting associated with building human review systems or managing large numbers of human reviewers.

Bedrock

For testing and deploy customized models for Amazon Bedrock (via fine-tuning or continued pre-training), it is mandatory to use Provisioned Throughput.

Knowledge bases

Managed opensearch serverless vector store
Retrieval-Augmented Generation (RAG) use cases. When a customer query comes in, the RAG framework first retrieves the most relevant pieces of information from this knowledge base and then uses an LLM to generate a coherent response based on the retrieved context.

Agents

Agents are software components or entities designed to autonomously or semi-autonomously perform specific actions or tasks based on predefined rules or algorithms.

Guardrails

Detects sensitive information such as personally identifiable information (PIIs) in input prompts or model responses. You can also configure sensitive information specific to your use case or organization by defining it with regular expressions (regex).

Amazon Rekognition

image and video analysis service that makes it easy to add advanced computer vision capabilities to your applications.
Deep learning, image recognition service, detect objects within an image.
Offers pre-trained and customizable computer vision (CV) capabilities to extract information and insights from your images and videos
detect text within images. Rekognition specializes in identifying text located spatially within an image, for instance, words displayed on street signs, t-shirts, or license plates.

Amazon Comprehend

Get insights about the content of docs
Detect key phrases, language, sentiment, entities in text, intelligent document processing use cases.
Search social feeds for mentions

Amazon Textract

(ML) service that automatically extracts text, handwriting, and data from scanned documents
It goes beyond simple optical character recognition (OCR) to identify, understand, and extract data from forms and tables.

Amazon Transcribe

Convert audio input (speech) to text. Using Automatic Speech Recognition (ASR) technology, customers can choose to use Amazon Transcribe for a variety of business applications, including transcription of voice-based customer service calls, generation of subtitles on audio/video content, and conduct (text-based) content analysis on audio/video content.
Amazon Transcribe Medical is an automatic speech recognition (ASR) service that makes it easy for you to add medical speech-to-text capabilities to your voice-enabled applications.

Amazon Translate

Text translation service that uses advanced machine learning technologies to provide high-quality translation on demand

Amazon Polly

Uses deep learning technologies to synthesize natural-sounding human speech, so you can convert articles to speech.

Amazon Personalize

Fully managed machine learning (ML) service that uses your data to generate product and content recommendations for your users. You provide data about your end-users (e.g., age, location, device type), items in your catalog (e.g., genre, price), and interactions between users and items (e.g., clicks, purchases). Personalize uses this data to train custom, private models that generate recommendations that can be surfaced via an API.

Amazon Forecast

Fully managed service that uses statistical and machine learning algorithms to deliver highly accurate time-series forecasts.

Amazon Kendra

A highly accurate and easy-to-use enterprise search service that’s powered by machine learning (ML).

AWS Artifact

Provide access to a wide range of AWS compliance reports. AWS Artifact allows users to configure settings to receive notifications when new compliance documents or reports are available.

Amazon Lex — AI Chat Builder

Allows users to interact with any application using natural language voice or chat. Use Amazon Lex to build and deploy conversational AI interfaces for any application. Offers pre-built bots to offer personalized experiences for mobile subscriber activities.

AWS DeepRacer

The AWS DeepRacer vehicle is a Wi-Fi-enabled, physical vehicle that can drive itself on a physical track by using a reinforcement learning model. Uses Reinforcement Learning

Trainium Instance types

Designed with energy efficiency in mind, providing optimal performance per watt for machine learning workloads. They offer the best performance at the lowest power consumption, reducing the carbon footprint of training large-scale models.

Security, Compliance, and Governance for AI Solutions

Each AZ one or more data centers
Each AWS Region consists of minimum 3 AZs
For controlling risks instruct the model to stick to the prompt by adding explicit instructions to ignore any unrelated or potentially malicious content

Metrics, Scores, Parameters, Inputs, Tools

Model Pameters

Values that define a model and its behavior in interpreting input and generating responses. Model parameters are controlled and updated by providers. You can also update model parameters to create a new model through the process of model customization. In other words, Model parameters are the internal variables of the model that are learned and adjusted during the training process. These parameters directly influence the output of the model for a given input. Examples include the weights and biases in a neural network.

Hyperparameters

Values that can be adjusted for model customization to control the training process and, consequently, the output custom model. They are external configurations set before the training process begins. They control the training process and the structure of the model but are not adjusted by the training algorithm itself. Examples include the learning rate, the number of layers in a neural network, etc.

Temperature

Temperature is a value between 0 and 1, and it regulates the creativity of the model’s responses. Higher Temperature to get more creative responses**.** Use a lower temperature if you want more deterministic responses.

Top-P

Represents the percentage of most likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs. Choose a higher value to increase the size of the pool and allow the model to consider less likely outputs.

Top-K

Top K represents the number of most likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs. Choose a higher value to increase the size of the pool and allow the model to consider less likely outputs.

BLEU (Bilingual Evaluation Understudy) score, a metric specifically designed to evaluate the quality of text that has been machine-translated by comparing it with one or more reference translations. Most widely used metrics for evaluating machine translation quality.

ROUGE (Recall-Oriented Understudy for Gisting Evaluation is a metric used mainly for evaluating the quality of automatic text summarization

Accuracy is a broad metric typically used to evaluate classification tasks where the model’s output is compared against the correct label.

Precision, Recall, and F1-Score are standard performance metrics used to evaluate the effectiveness of a classification system
Precision: Measures the accuracy of the positive predictions, calculated as the ratio of true positives to the sum of true positives and false positives.
Recall (Sensitivity): Measures the ability of the classifier to identify all positive instances, calculated as the ratio of true positives to the sum of true positives and false negatives.
F1-Score: The harmonic mean of Precision and Recall, providing a single metric that balances both concerns. When dealing with imbalanced datasets in binary classification

BERT score is a more advanced metric that uses contextual embeddings to assess the semantic similarity between translated and reference texts. It’s designed to capture the contextual meaning of words by looking at both the words that come before and after them

Shapley values are a local interpretability method that explains individual predictions by assigning each feature a contribution score based on its marginal effect on the prediction. This method is useful for understanding the impact of each feature on a specific instance’s prediction.

Partial Dependence Plots (PDP), on the other hand, provide a global view of the model’s behavior by illustrating how the predicted outcome changes as a single feature is varied across its range, holding all other features constant. PDPs help understand the overall relationship between a feature and the model output across the entire dataset.

Confusion matrix is a tool specifically designed to evaluate the performance of classification models by displaying the number of true positives, true negatives, false positives, and false negatives. This matrix provides a detailed breakdown of the model’s performance across all classes, making it the most suitable choice for evaluating a classification model’s accuracy and identifying potential areas for improvement.

Bias is an error introduced by approximating a real-world problem (which may be complex) by a simpler model. High bias can cause the model to miss relevant relations between features and target outputs (underfitting)

Variance is an error introduced by the model’s sensitivity to small fluctuations in the training data. High variance can cause the model to mimic the random noise in the training data rather than the intended outputs (overfitting).

Fundamentals of AI and ML

Generative models learn the underlying patterns of data to create new, similar data, while discriminative models learn to distinguish between different classes of data. Generative models, such as GPT-3, can generate new content, whereas discriminative models are used for classification tasks.

Maintaining data lineage involves tracking the flow, transformations, and origins of data throughout its lifecycle. This is crucial for ensuring data privacy, security, and compliance with regulatory standards.

When the number of samples in the majority class (bigger) is considerably larger than the number of samples in the minority (smaller) class, the dataset is considered imbalanced.

Labeled data is data that comes with predefined labels or annotations. E.g. images labeled with the objects they contain. This type of data is crucial for supervised learning, where the model learns to predict the output from the input data.

In supervised learning, you define both the input and the expected associated output. Supervised learning algorithms learn patterns and relationships between the input and output pairs. Then, they predict outcomes based on new input data. Examples: Linear regression, logistic regression, decision tree, neural network, classification

Unlabeled data is data that does not come with any labels, annotations, or explicit instructions about what it represents. This type of data is often used in unsupervised learning, where the model attempts to find patterns or structures in the data without predefined labels. Examples: Clustering: Grouping similar data points

Unsupervised learning algorithms receive inputs with no specified outputs during the training process. They find hidden patterns and relationships within the data using statistical means. For instance, you could provide a set of documents, and the algorithm may group them into categories it identifies based on the words in the text. You do not get any specific outcomes; they fall within a range. Examples: clustering (K-Means), association rule learning, dimensionality reduction, probability density

Semi-supervised learning is when you apply both supervised and unsupervised learning techniques to a common problem. This technique relies on using a small amount of labeled data and a large amount of unlabeled data to train systems. First, the labeled data is used to partially train the machine learning algorithm. After that, the partially trained algorithm labels the unlabeled data. This process is called pseudo-labeling. The model is then re-trained on the resulting data mix without being explicitly programmed. Examples, fraud detection, sentiment analysis, document classification.

Reinforcement learning mimics the trial-and-error learning process that humans use to achieve their goals. Software actions that work towards your goal are reinforced, while actions that detract from the goal are ignored. Excels in complex environments and requires less human interaction. RL has a predetermined end goal. While it takes an exploratory approach, the explorations are continuously validated and improved to increase the probability of reaching the end goal. It can teach itself to reach very specific outcomes.

Overfitting occurs when the model is overly complex and captures noise or random fluctuations in the training data rather than the underlying patterns.

By fine-tuning hyperparameters, such as increasing regularization or early stopping or adjusting dropout rates, the model can avoid overfitting to the training data and better generalize to new, unseen data in production. This approach helps improve the model’s performance across various data distributions.

To prevent over-fitting, techniques such as cross-validation, regularization, and pruning are employed. Cross-validation helps ensure the model generalizes well to unseen data by dividing the data into multiple training and validation sets. Regularization techniques, such as L1 and L2 regularization, penalize complex models to reduce overfitting. Pruning simplifies decision trees by removing branches that have little importance.

Increasing the number of epochs allows the model to learn from the training data for a longer period, potentially capturing more complex patterns and relationships, which can improve accuracy. Multiple epochs are run until the accuracy of the model reaches an acceptable level, or when the error rate drops below an acceptable level.

Transfer learning allows a model to utilize the knowledge learned from one task or dataset to improve its performanceon a new, but related task.

Incremental training is useful for updating a model with new data continuously. it focuses on enhancing a single model’s performance with its own data. It’s designed to help models adapt to new data over time without forgetting previously learned knowledge

Deep Learning, model training involves feeding large datasets into the neural network and adjusting the weights and biases through multiple iterations.

Computer vision focuses on interpreting and understanding the content of images to make decisions, such as object detection, facial recognition, and scene understanding

Generative Adversarial Networks (GANs) work by training two neural networks in a competitive manner. The first network, known as the generator, generates fake data samples by adding random noise. The second network, called the discriminator, tries to distinguish between real data and the fake data produced by the generator. They are specifically designed for generating synthetic data that is statistically similar to real data

Convolutional Neural Network (CNN) are designed for tasks such as image and video recognition, object detection, and similar applications involving grid-like data (such as pixels in an image)

Recurrent Neural Networks (RNNs) are typically used for sequence data, such as time series or natural language processing tasks (video analysis)

WaveNet is tailored for audio data generation, specifically for tasks such as speech synthesis and audio signal processing.

Support Vector Machines (SVMs) are used for classification and regression

Exploratory Data Analysis (EDA) phase, which involves examining the data through statistical summaries and visualizations to identify patterns, detect anomalies, and form hypotheses.

Foundation Models provide a broad base with generalized capabilities that can be applied to various tasks such as natural language processing (NLP), question answering, and image classification.

Large Language Models are specifically designed for tasks involving the understanding and generation of human language, making them more specialized

Bias versus variance trade-off is about finding a balance between bias (error due to overly simplistic assumptions in the model, leading to underfitting) and variance (error due to the model being too sensitive to small fluctuations in the training data, leading to overfitting)

Interpretability is about understand the internal mechanisms of machine learning model

Explainability focuses on providing understandable reasons for model predictions and behaviors to stakeholders

Data used for ML is split into datasets: 1) training set to train the model, 2) validation set to periodically measure model performance as training is happening and also tune any hyperparameters of the model. However, validation datasets are optional. 3) test set is used on the final trained model to assess its performance on unseen data. This helps determine how well the model generalizes.

Fundamentals of Generative AI

Models for generating images: Stable Diffusion
Diffusion models create new data by iteratively making controlled random changes to an initial data sample.

ChatGPT or Chat Generative Pretrained Transformer is an example of a Transformer model. Transformer-based models use a self-attention mechanism. They weigh the importance of different parts of an input sequence when processing each element in the sequence.

Tokens are fundamental units of text that the AI model processes.

context window defines how much text (measured in tokens) the AI model can process at one time to generate a coherent output.

Embeddings are a way of representing tokens (words, sub-words, or phrases) as numerical vectors to capture their semantic relationships in a high-dimensional space

Transformer models are a type of neural network architecture designed to handle sequential data, such as language, in an efficient and scalable way. They rely on a mechanism called self-attention to process input data, allowing them to understand and generate language effectively

Negative prompting refers to guiding a generative AI model to avoid certain outputs or behaviors when generating content.

Foundation models use self-supervised learning to create labels from input data. This means no one has instructed or trained the model with labeled training data sets. Self-supervised learning is a machine learning approach that applies unsupervised learning methods to tasks usually requiring supervised learning. Instead of using labeled datasets for guidance, self-supervised models create implicit labels from unstructured data.

Few-shots prompting involves providing the model with examples that include both the user-input and the correct user intent.

Chain-of-thought prompting is a technique that breaks down a complex question into smaller, logical parts that mimic a train of thought.

Zero-shot prompting is a technique used in generative AI where the model is asked to perform a task or generate content without having seen any examples of that specific task during training.

Dynamic prompt engineering involves modifying the input prompts to the Large Language Model (LLM) to customize the chatbot’s responses based on a user characteristic or answer

A multimodal model can accept a mix of input types such as audio/text and create a mix of output types such as video/image

A multi-modal embedding model enables the integration of multiple types of data, such as text and images, into a unified representation. This allows for effective processing and understanding queries containing both text and visual content by aligning them in a shared embedding space, facilitating more accurate and context-aware responses.

Small Language Model (SLM) optimized for deployment on edge devices is specifically designed to be lightweight, efficient, and capable of running on devices with limited computational resources.

Prompt Injection refers to influencing the outputs by embedding specific instructions within the prompts themselves.

Exposure refers to the risk of exposing sensitive or confidential information to a model during training or inference. The model can then reveal this sensitive data from their training corpus, leading to potential data leaks or privacy violations.

Hijacking involves manipulating an AI system to serve malicious purposes or to misbehave in unintended ways.

Jailbreaking refers to bypassing the built-in restrictions and safety measures of AI systems to unlock restricted functionalities or generate prohibited content.

Model Customization

You can use continued pre-training or fine-tuning for model customization in Amazon Bedrock.

Continued pre-training

Uses unlabeled data to pre-train a model. The Continued Pre-training process will tweak the model parameters to accommodate the input data and improve its domain knowledge. It’s another appropriate strategy for making a Foundation Model an expert in a specific domain.

Fine-tuning

You provide labeled data to train a model to improve performance on specific tasks. By providing a training dataset of labeled examples, the model learns to associate what types of outputs should be generated for certain types of inputs. The model parameters are adjusted in the process and the model’s performance is improved for the tasks represented by the training dataset. Fine-tuning is a FM is a supervised learning process.

Using ControlMonkey's Terraform Platform to Govern Large-scale AWS Environments

Fri, 03 Jan 2025 00:00:00 GMT

Summary: Reactive governance loses by arithmetic: new resources appear faster than audits close findings. This APN piece argues for the proactive version, a Terraform platform where policy, drift and coverage are managed centrally, grounded in a real customer case. Coverage is the leading metric, since the share of the estate under IaC decides how much governance is even possible.

Who should read it: platform owners of estates measured in hundreds of accounts, and anyone writing a governance strategy for one.

Read the full article on AWS →

Karpenter vs. Cluster Autoscaler - Kubernetes Scaling Tools

Wed, 11 Dec 2024 00:00:00 GMT

Summary: Node scaling decides both your bill and your pending pod queue. Cluster Autoscaler scales node groups you defined in advance and stays the portable, battle-tested option; Karpenter provisions instances directly from pod requirements, which improves packing and spot usage. Test consolidation behavior before production traffic meets it.

Who should read it: EKS operators tired of tuning node groups, and platform teams doing cost work on Kubernetes compute.

Read the full article on Spacelift →

What is Configuration Drift? Tools, Causes & Risks

Thu, 31 Oct 2024 00:00:00 GMT

Summary: Drift is the gap between what your code says and what actually runs, accumulating through reasonable actions like hotfixes and console edits. The risk compounds silently: the next apply either reverts someone’s fix or fails on state it does not expect. Detection is cheap now, and continuous drift checks belong next to your other scheduled jobs.

Who should read it: anyone operating IaC alongside humans with console access, which is everyone.

Read the full article on Spacelift →

How to Use Blocks in Ansible Playbooks

Fri, 25 Oct 2024 00:00:00 GMT

Summary: Blocks are the structure feature people discover late. A when on a block beats copying the same when across ten tasks, and the same goes for become and tags. Rescue turns a failed task into a handled path, and always runs regardless of outcome, which is where cleanup belongs.

Who should read it: playbook authors whose error strategy is currently ignore_errors, and anyone tidying repetitive task lists.

Read the full article on Spacelift →

What is an AWS CloudFormation Template? [Examples]

Wed, 16 Oct 2024 00:00:00 GMT

Summary: CloudFormation is still the native IaC path on AWS, and templates are its whole interface. A few sections do the work (parameters, resources, outputs), with intrinsic functions keeping templates portable across accounts and regions. Change sets are the plan step; never update a production stack without reading one.

Who should read it: AWS engineers starting with CloudFormation, and Terraform users who need to read the native format when they meet it.

Read the full article on Spacelift →

Enterprise DevOps - Adoption Strategies & Best Practices

Wed, 02 Oct 2024 00:00:00 GMT

Summary: DevOps advice written for startups meets a different reality at ten thousand employees: compliance, legacy estates, and change that must survive politics. Start with pilot teams and real workloads, then scale patterns rather than mandates, with platform teams as the delivery mechanism. Expect the legacy estate to set your pace more than the greenfield does.

Who should read it: engineering leadership in large organizations, and practitioners translating startup patterns into enterprise reality.

Read the full article on Spacelift →

DevOps Maturity Model: Levels, Metrics & Benefits

Wed, 25 Sep 2024 00:00:00 GMT

Summary: Maturity models get abused as vendor scorecards, but used honestly they answer where you are and what should improve next. Locate yourself per area, since teams are rarely one level everywhere, and anchor the assessment in metrics like the DORA set. Skipping levels through tool purchases is the classic failure.

Who should read it: leads planning a DevOps investment case, and anyone handed a maturity assessment by a consultancy.

Read the full article on Spacelift →

What is an Internal Developer Platform (IDP)?

Mon, 26 Aug 2024 00:00:00 GMT

Summary: IDPs are platform engineering made concrete: golden paths, self-service and paved infrastructure behind one interface. The IDP is a product with users, and it lives or dies on developer experience rather than feature count. Most working ones compose existing tools behind a thin, opinionated layer that balances self-service with guardrails.

Who should read it: platform teams defining their scope, and engineering leaders deciding whether the investment fits their size.

Read the full article on Spacelift →

Ansible with GitHub Actions: Automating Playbook Runs

Tue, 13 Aug 2024 00:00:00 GMT

Summary: Playbooks run from laptops have the same problems as Terraform applied from laptops: no history, no review, no consistency. Trigger playbooks from pull requests and merges and the git history becomes your change log. Put SSH keys and vault passwords in encrypted secrets, plan runner network reach early, and gate with syntax checks and dry runs before the pipeline touches production hosts.

Who should read it: Ansible users on GitHub who still run playbooks by hand, and platform folks standardizing how config changes ship.

Read the full article on Spacelift →

Configuration Management with Ansible

Fri, 12 Jul 2024 00:00:00 GMT

Summary: Configuration management is the job Ansible was built for, and the comparison with Chef, Puppet and Salt still decides tool choices. Agentless over SSH means nothing to install on targets, and push-based execution gives you control of when changes land at the cost of continuous enforcement. The readable YAML surface matters more than expressiveness.

Who should read it: teams picking a configuration management tool, and Ansible users who want the architectural context behind the commands.

Read the full article on Spacelift →

Using Ansible to Automate AWS [Tutorial]

Wed, 19 Jun 2024 00:00:00 GMT

Summary: A static inventory file dies the first time an autoscaling group scales, and dynamic inventory is what makes Ansible viable against AWS. Tag your instances well and the inventory writes itself. The amazon.aws collection covers provisioning glue too, and credentials belong in roles and profiles, never in playbooks.

Who should read it: teams running Ansible against EC2 fleets, and anyone whose inventory file has ever listed a terminated instance.

Read the full article on Spacelift →

The Value of Upskilling Your SMB's Employees in Generative AI

Fri, 31 May 2024 00:00:00 GMT

Summary: This one is for the business side: small and mid-size companies cannot hire their way into AI capability, and mostly do not need to. Existing employees with domain knowledge plus AI skills beat new hires with AI skills and no context. A real customer example shows the pattern, and the AWS learning paths make it practical.

Who should read it: SMB leaders deciding where AI budget goes, and engineers building the internal case for learning time.

Read the full article on AWS →

7 Ansible Use Cases - Management & Automation Examples

Wed, 01 May 2024 00:00:00 GMT

Summary: Seven jobs Ansible does well, with examples, so teams can match the tool to actual work instead of adopting it on reputation. Configuration management and repetitive operational tasks remain the core, with security baselines and patching as the underrated uses. The weak spots matter as much: no state, limited orchestration logic, and speed at very large fleets.

Who should read it: engineers deciding whether Ansible belongs in their stack, and teams using it for one job unaware of the other six.

Read the full article on Spacelift →

How to Import and Manage AWS Networking with Terraform and ControlMonkey

Thu, 18 Apr 2024 00:00:00 GMT

Summary: Hand-built VPCs, routes and peering are the scariest part of any estate to codify, because mistakes cut connectivity. This APN piece walks a real import with ControlMonkey generating code and state together, which removes the tedious half of the job. The import is the start; the value arrives when every later networking change goes through a plan.

Who should read it: teams with hand-built AWS networking they are afraid to touch, which is a large club.

Read the full article on AWS →

What is Amazon Bedrock? AWS Generative AI Tool Overview

Mon, 25 Mar 2024 00:00:00 GMT

Summary: Bedrock is the AWS answer for teams that want foundation models behind an AWS API with AWS billing and IAM. The value is operational: one API across model providers, IAM for access, no infrastructure to run. Know whether you need on-demand tokens or provisioned throughput before the bill teaches you, and start in the playground before moving to the API.

Who should read it: AWS teams evaluating a managed route into generative AI before committing to any one model vendor.

Read the full article on Spacelift →

AWS Certified DevOps Engineer - Professional [Cheat Sheet]

Tue, 13 Feb 2024 00:00:00 GMT

Summary: Per-service study notes for the DOP exam, continuing the cheat sheet series from the Solutions Architect exams. CodePipeline, CodeDeploy and their rollback behaviors carry a large share of questions, with Config, CloudTrail and Systems Manager close behind in compliance-flavored scenarios. The notes collect the service limits and integration edges the exam actually probes.

Who should read it: engineers preparing for the DOP exam, alongside the SAA and SAP cheat sheets already on this site.

Read the full article on Spacelift →

How to Use Amazon CodeWhisperer (AI Code Generator)

Fri, 12 Jan 2024 00:00:00 GMT

Summary: Written when AI pair programmers were new, with a Terraform demo as the useful part: infrastructure code is repetitive enough that completion tools show their value quickly, and their limits just as quickly. Suggestions are strongest on boilerplate, architecture still belongs to you, and the bundled security scanning catches real issues.

Who should read it: engineers curious how AWS’s completion tool handles IaC, and anyone comparing the first generation of coding assistants.

Read the full article on Spacelift →

How to Build an AWS Multi-Account Strategy

Wed, 22 Nov 2023 00:00:00 GMT

Summary: Accounts are the strongest isolation boundary AWS gives you, partitioning blast radius, billing and quotas at once. Organizations, OUs and SCPs form the skeleton, with Control Tower and vending automation on top. Design the OU structure for policy inheritance rather than for the org chart.

Who should read it: teams feeling the walls of one account, and architects planning a landing zone who want the reasoning behind it.

Read the full article on Spacelift →

Getting Started With Amazon EKS Blueprints for Terraform

Fri, 20 Oct 2023 00:00:00 GMT

Summary: A bare EKS cluster is nowhere near production ready, and EKS Blueprints packages the missing layer of add-ons, IAM wiring and team access as Terraform. The add-on model is the real value, since bootstrapping controllers by hand is where DIY clusters rot. Treat it as a starting point you own afterwards, and understand what it generates before you depend on it.

Who should read it: platform teams standing up EKS with Terraform who would rather compose than reinvent.

Read the full article on Spacelift →

Using Ansible Shell Module to Execute Remote Commands

Tue, 08 Aug 2023 00:00:00 GMT

Summary: Shell is the escape hatch everyone uses and few use carefully. Prefer command over shell unless you need shell features, and prefer a dedicated module over both whenever one exists, since shell tasks are where idempotency goes to die. When shell is unavoidable, pair it with creates, removes or changed_when so reruns stay honest.

Who should read it: Ansible users with playbooks full of shell tasks, and reviewers deciding which of them deserve to stay.

Read the full article on Spacelift →

What is a Service Mesh? Key Features, Benefits & Examples

Mon, 26 Jun 2023 00:00:00 GMT

Summary: Service meshes deliver mTLS, traffic control and telemetry without touching application code, at the price of running a mesh. The sidecar model is the core idea: proxies own the network so services do not have to. Below a certain service count the mesh costs more than it gives, and ingress plus libraries covers more cases than vendors admit.

Who should read it: teams at the microservices scale where network concerns repeat per service, and anyone evaluating Istio and friends.

Read the full article on Spacelift →

AWS Solutions Architect Professional Cheat Sheet

Sun, 11 Jun 2023 00:00:00 GMT

This material was gathered during my preparation for the AWS Solutions Architect Professional Exam. I created and curated this cheatsheet with useful information that will be handy to review before taking the exam.

This article’s objective is to gather different notes, topics and details that I struggled with, and hopefully will help more people get their own badge.

Use these notes as complementary material and not complete study material for the exam. Check out the official AWS SA Pro study guide for comprehensive information.

AWS frequently changes information, configuration, and options of different services so some of the content might become outdated at some point. Make sure to cross-check and validate the information you are getting from online sources with the official AWS Documentation and FAQs before your exam.

OK enough with the disclaimers, let’s get to it.

Multi Account Strategy

Control Tower

Setup and govern a secure multi-account AWS environment by orchestrating multiple AWS services(Organizations, Service Catalog, IAM) on your behalf while maintaining the security and compliance needs of your applications.
Deploy data residency controls and deny data usage outside of specific regions.
Create a landing zone, a well-architected, multi-account AWS environment based on security and compliance best practices.
After the landing zone setup, you can configure IAM Identity Center with a supported directory such as AWS Managed Microsoft AD.
The account factory automates provisioning of new accounts in your organization, preconfigured to meet your needs.
Guardrails are pre-packaged governance rules for security, operations, and compliance that you can select and apply enterprise-wide or to specific groups of accounts. (SCP, CloudFormation, Config, Dashboard) Mandatory, Preventive, Detective, or Optional.
Dashboard gives you continuous visibility into your AWS environment.
Integrates with 3rd party tools to enhance capabilties.
To migrate accounts to an organization, from the management account, create invitations to other accounts and wait them to accept invitations.
There is no additional charge to use AWS Control Tower. However, when you set up AWS Control Tower, you will begin to incur costs for AWS services configured to set up your landing zone and mandatory guardrails.

AWS Organizations

Group accounts into OUs and control access to multiple accounts with IAM Identity Center(previously SSO) and permissions.

Service control policies(SCPs) to impose maximum permissions across OUs or accounts(even the root user of the account is restricted).
Share resources across accounts with RAM.
Activate Cloudtrail across accounts for audit/compliance purposes.
AWS Control Tower offers an abstracted, automated, and prescriptive experience on top of AWS Organizations.
All features mode: prefered way, includes consolidated billing, enabling all features is the default for new orgs, allows advanced account management capabilities.
Consolidated Billing features: basic management tools, cannot leverage SCPs.
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can’t perform that action.
SCPs do not affect any service-linked role.
AWS strongly recommends that you don’t attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don’t inadvertently lock users out of key services.
It can work with CloudWatch Events to raise events when administrator-specified actions occur in an organization. For example, because of the sensitivity of such actions, raise a notification for new accounts creation.
When an invited account joins your organization, you do not automatically have full administrator controlover the account, unlike created accounts. If you want the master account to have full administrative control over an invited member account, you must create the OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.

Resource Access Manager(AWS RAM)

Enables you to share specified AWS resources that you own with other AWS accounts.
To enable trusted access with AWS Organizations: From the AWS RAM CLI, use the enable-sharing-with-aws-organizations command.

Cross Account Access

To access S3 bucket in another account: a) Define an IAM role that allows cross account access with account number of the other account. b) Assign the user on the other account with a policy to be able to assume the role. c) Then the user assumes role. d) The bucket policy must allow this role access.
To assume role in another account, you can’t switch to a role if you are connected as the root user.
For some AWS services, you can grant cross-account access to your resources. To do this, you attach a policy directly to the resource that you want to share, instead of using a role as a proxy. The resource that you want to share must support resource-based policies. Unlike a user-based policy, a resource-based policy specifies who (in the form of a list of AWS account ID numbers) can access that resource.
With a resource that is accessed through a resource-based policy, the user still works in the trusted account and does not have to give up his or her user permissions in place of the role permissions. In other words, the user continues to have access to resources in the trusted account at the same time as he or she has access to the resource in the trusting account. This is useful for tasks such as copying information to or from the shared resource in the other account.
At times, you need to give a third-party access to your AWS resources (delegate access). One important aspect of this scenario is the External ID, optional information that you can use in an IAM role trust policy to designate who can assume the role.

Tagging

Use to organize resources. Helps with billing to break down costs, automation, and acces control.
Tag Categories (technical tags, business tags, tags for automation, security tags).
Best practices: standardized, case-sensitive, consistent across resources, leverage tools(resource groups).

Disaster Recovery

Disaster Recovery Strategies

Pilot Light → DBs ready and data replication, create other resources when it’s time(VMs).
Warm Standby → DBs ready and data replication, other resources operational but scaled down.
The difference between Pilot Light and Warm Standby can sometimes be difficult to understand. Both include an environment in your DR Region with copies of your primary region assets. The distinction is that Pilot Light cannot process requests without additional action taken first, while Warm Standby can handle traffic (at reduced capacity levels) immediately.

Elastic Disaster Recovery

Minimizes downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications using affordable storage, minimal compute, and point-in-time recovery.
Use cases: a) On-premises to AWS b) Cloud to AWS c) AWS Region to AWS Region

Identity and Access Management

AWS IAM Identity Center

Supports only SAML 2.0–based applications so an OpenID Connect-compatible solution will not work.

Simple AD

Subset of Microsoft AD.

Managed Microsoft AD

Configure a trust relationship between AWS Managed Microsoft AD in the AWS Cloud and your existing on-premises Microsoft Active Directory, providing users and groups with access to resources in either domain, using single sign-on (SSO).

Microsoft AD connector

In case you want to connect to on premises AD.

Identity Federation

Identity federation with SAML 2.0 enables federated single sign-on (SSO). You can use a third-party SAML IdP to establish SSO access to the console or you can create a custom IdP to enable console access for your external users.

Before you can use SAML 2.0-based federation, you must configure your organization’s IdP and your AWS account to trust each other. Inside your organization, you must have an IdP that supports SAML 2.0, like Microsoft Active Directory Federation Service (AD FS, part of Windows Server). In your organization’s IdP, you define assertions that map users or groups in your organization to the IAM roles.
When you create the trust policy for the role, you specify the SAML provider that you created earlier as the Principal.
Flow: LDAP → STS → AWS access.
Web Identity Federation with AssumeRoleWithWebIdentity API → STS → AWS resources.

Create SAML Identity provider in IAM

Get the SAML metadata document from IdP.
Create SAML IAM identity provider.
Configure SAML IdP with relying party trust.
In IdP, configure SAML Assertions for the authentication response.

Cognito

Authorization, authentication sign-up and sign-in features, user management for mobile and web.
Scales to millions of users.
User pools: sign in, sign up, can use other providers(Google, FB, Amazon), MFA
Login via social identity providers, such as Apple, Facebook, Google, and Amazon and enterprise identity providers via SAML and OIDC.
Identity pools: Create unique identities and assign permissions for users, obtain temporary AWS credentials with permissions you define to directly access other AWS services or to access resources through Amazon API Gateway.
For unauthenticated users, enable unauthenticated access in Cognito Identity Pool. Guest users can request an identity ID via the GetId API.
In Cognito User Pool, you can configure users in groups to manage the permissions better. Each group can be linked with an IAM Role.
If you don’t use Amazon Cognito, then you choose to write a custom code or app that interacts with a web IdP (Login with Amazon, Facebook, Google, or any other OIDC-compatible IdP) and then call the AssumeRoleWithWebIdentity API to trade the authentication token you get from those IdPs for AWS temporary security credentials.
Pricing based on your monthly active users.

IAM Roles

Trust relationship: Defines which service/user can assume the role.
AssumeRole action via STS, configurable min 15mins, max 12hours.
IAM roles can have a policy attached to define services that can be accessed by the role’s temporary creds.
When you assume a role, you give up your original permissions and take the permissions of the assigned role.

Service role

A service role is an AWS Identity and Access Management (IAM) that grants permissions to an AWS service so that the service can access AWS resources.

Networking

VPC

A transit VPC is a common strategy for connecting multiple, geographically disperse VPCs and remote networks in order to create a global network transit center. Transit VPC uses customer-managed Amazon Elastic Compute Cloud (Amazon EC2) VPN instances in a dedicated transit VPC with an Internet gateway. This design requires the customer to deploy, configure, and manage EC2-based VPN appliances, which will result in additional EC2 instances, and potentially third-party product and licensing charges. Enables more complex routing rules, such as network address translation between overlapping network ranges, or to add additional network- level packet filtering or inspection.

When deploying distributed architectures, a popular approach is to build a shared services VPC, which provides access to services required by workloads in each of the VPCs. This might include directory services or VPC endpoints. Sharing resources from a central location instead of building them in each VPC may reduce administrative overhead and cost.
VPC sharing (part of Resource Access Manager) allows multiple AWS accounts to create their application resources in the same VPC(shared by the VPC owner). The account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization.

You can’t have a VPC with only a public subnet and AWS Site-to-Site VPN.
AWS reserves 5 Ip addresses in each subnet. The first 4 and the last one
To add IPv6 to VPC: a) Associate IPv6 CIDR block. b) Create Egress-only Internet Gateway for private subnets. c) Assign IPv6 addresses to EC2 instances from the IPv6 address range
Possible to expand existing VPC by adding a secondary IPv4 range.
Fixed MAC address for EC2 → use case for ENI.
Once you create DHCP options, you cant modify them.
Use Traffic Mirroring to copy network traffic from an elastic network interface of type interface. You can then send the traffic to out-of-band security and monitoring appliances for content inspection, threat monitoring, network tourbleshooting.

AWS uses the longest prefix matching to determine where traffic should be routed.
Access to interface endpoint: configured through AWS VPN connections or Direct Connect connections, through intra-region VPC peering connections and through inter-region VPC peering connections from any type of instance. You can add endpoint policies to interface endpoints that define which principal can perform which actions on which resources. An endpoint policy does not override or replace IAM user policies or service-specific policies. It is a separate policy for controlling access from the endpoint to the specified service.
An interface endpoint, except for an Amazon S3 interface endpoint, has a corresponding private Domain Name System (DNS) hostname.
You can limit outbound web connections from your VPC to the internet, using a web proxy (such as a squid server) with custom domain whitelists or DNS content filtering services.

NACL

A common use-case is to allow ephemeral ports in NACLs to handle response traffic.

Transit Gateway

Acts as a Regional virtual router for traffic flowing between your virtual private clouds (VPCs) and on-premises networks.

TGW supports multicast.

NAT Instance

When there is a connection time out, a NAT instance sends a FIN packet to resources behind the NAT instance to close the connection. It does not attempt to continue the connection which is why some connections might be failing.

AWS Direct Connect

Combine Direct Connect & VPN for an IPsec-encrypted private connection.

Establish an AWS VPN over an AWS Direct Connect connection: a) Create your Direct Connect connection. b) Create a public virtual interface for your Direct Connect connection. For Prefixes you want to advertise, enter your customer gateway device’s public IP address and any network prefixes that you want to advertise. Note: Your public virtual interface receives all AWS public IP address prefixes from each AWS Region (except the AWS China Region). These include the public IP addresses of AWS managed VPN endpoints. c) Create a new VPN connection. Be sure to use the same customer gateway’s public IP address that you used in the previous step.Note: You can configure the customer gateway in Border Gateway Protocol (BGP) with an Autonomous System Number (ASN). d) Configure your VPN to connect to your VPC. For example configurations, see tutorials for creating VPCs.
For hybrid network architecture that is highly available and supports high bandwidth, configure the Direct Connect based hybrid network to achieve maximum resiliency for critical workloads by using separate connections from different service providers that terminate on separate devices in more than one location.
For a cheap backup alternative of DX, configure backup hardware VPN connection as a failover option.
To connect to services such as EC2 using just Direct Connect, you need to create a private virtual interface.
If you want to encrypt the traffic flowing through Direct Connect, you will need to use the public virtual interface of DX to create a VPN connection.
Configure a public virtual interface from the Direct Connect connection to connect to AWS resources that are reachable by a public IP address (such as an S3 bucket).
With a public virtual interface, you can: a) Connect to all AWS public IP addresses globally. b) Create public virtual interfaces in any DX location to receive Amazon’s global IP routes c) Access publicly routable Amazon services in any AWS Region (except for the AWS China Region).
With a private virtual interface, you can: a) Connect VPC resources (such as Amazon Elastic Compute Cloud (Amazon EC2) instances or load balancers) on your private IP address or endpoint. b) Connect a private virtual interface to a DX gateway. Then, associate the DX gateway with one or more virtual private gateways in any AWS Region (except the AWS China Region). c) Connect to multiple VPCs in any AWS Region (except the AWS China Region), because a virtual private gateway is associated with a single VPC.

AWS Site-to-Site VPN

To create the customer gateway resource in AWS: a) The internet-routable IP address for the devic’s external interface. b) The type of routing: static or dynamic. c) For dynamic routing, the Border Gateway Protocol (BGP) Autonomous System Number (ASN).

Migrations

Use the AWS Cloud Adoption Readiness Tool (CART) to generate a migration assessment report to identify gaps in organizational skills and processes.

Migration Hub

Central place to visualize migration process including the discovery phase.
Provides key metrics and progress for individual applications, regardless of which tools are being used to migrate them.

AWS Application Migrations Service

Highly automated lift-and-shift (rehost) solution that simplifies, expedites, and reduces the cost of migrating applications to AWS.
The first setup step for Application Migration Service is creating the Replication Settings template. Add source servers to Application Migration Service by installing the AWS Replication Agent (also referred to as the Agent) on them. The Agent can be installed on both Linux and Windows servers.

AWS Application Discovery Service

Helps you plan your migration to the AWS cloud by collecting usage and configuration data about your on-premises servers.
Integrates with Migration Hub.
Agenteless Discovery with the Application Discovery Service Agentless Collector through your VMware vCenter. Collects IPs, hostnames, MAC addresses, disk resource allocation, utilization data, and computes average and peak for CPU, RAM, disk I/O.
Agent-based discovery by deploying the Application Discovery Agent(windows and linux) on each of your VMs. Collects static configuration data, system performance, I/O network connections, and running processes.
Data exploration in Amazon Athena allows you to analyze the data collected from all the discovered on-premises servers by Discovery Agents in one place.

AWS Server Migration Service(SMS)

An agentless service for migrating thousands of on-premises workloads to AWS
Each server volume replicated is saved as a new Amazon Machine Image (AMI).
AWS SMS creates a new EBS snapshot with every replication. It replicates server volumes from your on-premises environment to S3 temporarily and purges them from S3 right after creating EBS snapshots.

AWS DataSync

Simplifies and accelerates data migrations to AWS as well as moving data between on-premises storage, edge locations, other clouds, and AWS Storage.
Can move data directly to Glacier or Glacier Deep Archive.
Uses an agent to read and write data from your storage systems. A single DataSync agent is capable of saturating a 10 Gbps network link.
Connects with standard protocols: Network File System (NFS), SMB, or the Amazon S3 API.
It comes with retry and network resiliency mechanisms, network optimizations, built-in task scheduling, monitoring.
Natively integrated with Amazon S3, Amazon EFS, Amazon FSx for Windows File Server, Amazon CloudWatch, and AWS CloudTrail.
Use DataSync to migrate existing data to S3 & storage gw(e.g. file gw) to retain access to migrated data & ongoing updates from on-premises.
A 1Gbps connection at full utilization can transfer approximately 10 TB of data in a day.

Storage Gateway

Hybrid cloud storage service that provides on premises access and cloud storage with Amazon S3.
Storage Gateway doesn’t automatically update the cache when you upload a file directly to Amazon S3. Perform a RefreshCache operation to see the changes on the file share.
Storage Gateway uses an appliance that is installed and hosted on premises as a VM appliance, as a hardware appliance, or in AWS as an Amazon Elastic Compute Cloud (Amazon EC2) instance.
Connects using standard protocols Internet Small Computer System Interface (iSCI),SMB, and NFS.
Low RTO and RPO for offline backups.
Storage Gateway uses Challenge-Handshake Authentication Protocol (CHAP) to authenticate iSCSI and initiator connections.

File Gateway

SMB or NFS access to data in S3 with local caching.

Volume Gateway

Present cloud-based iSCSI block storage volumes to your on-premises applications.
With cached volumes, the AWS Volume Gateway stores the full volume in its Amazon S3 service bucket, and just the recently accessed data is retained in the gateway’s local cache for low-latency access.
Can create point in time snapshots on EBS of gateway volumes.
Gateway-Cached volumes can support volumes of 1,024TB in size
Gateway-stored volume supports volumes of 512 TB size.

Tape Gateway

Supports archiving directly to Glacier and Glacier Deep Archive.

AWS AppSync

Store and sync data across mobile and web apps in real-time.

AWS AppFlow

Automate data flows between software as a service (SaaS) and AWS services.

DMS

DMS data validation to ensure that your data has migrated accurately from the sourceto the target.
KMS encrypts data in the replication instance. The master key is aws/dms by default or a customer managed key(CMK).
For unsupported DB sources, export data to CSV, load to S3, configure table definition JSON doc.
DMS Fleet Advisor will help to discover our data infrastructure.
DMS Schema Conversion or the AWS Schema Conversion Tool (AWS SCT) to automatically assess and convert schemas.
For heterogeneous database migrations, two-step process. Use AWS Schema Conversion Tool to convert the source schema and code to match the target DB, then use DMS to migrate data from the source to the target DB.

Snowball

Up to 80TB, good choice if you have limited bandwidth.
Good choice for up to single digit PB with multiple devices.
If you have less than 10TB probably not the best/cheapest choice.
Data encrypted on device.
The AWS Snowball has a typical 5-7 days turnaround time.

Snowball edge

Onboard compute power for edge-computing.
~100TB
You can’t directly copy data from Snowball Edge devices into AWS Glacier.
To speed up data transfer: Perform multiple write operations at one time, transfer small files in batches, write from multiple sources, dont perform other operations on files during transfer(rename, metadata changes etc), reduce the local network use, eliminate unnecessary hops.
Typically, files that are 1 MB or smaller should be included in batches. There’s no hard limit on the number of files you can have in a batch, though AWS recommends that you limit your batches to about 10,000 files. Having more than 100,000 files in a batch can affect how quickly those files import into Amazon S3 after you return the device. AWS recommends that the total size of each batch be no larger than 100 GB. Batching files is a manual process, which you have to manage.

Snowmobile

~100 PB
For large datasets of 10PB or more in a single location.
Supports loading to S3 or Glacier.

S3 Transfer acceleration

First files transfered to the closest edge location and then routed inside the AWS network.
With S3TA, you pay only for transfers that are accelerated.
Upload to a centralized bucket from all over the world.
Transfer gigabytes to terabytes of data on a regular basis across continents.
After Transfer Acceleration is enabled, it can take up to 20 minutes for you to realize the performance benefit.

Transfer Family

Transfer Family provides fully managed(serverless) support for file transfers directly into and out of Amazon S3 or Amazon EFS.
Support for Secure File Transfer Protocol (SFTP), File Transfer Protocol over SSL (FTPS), and File Transfer Protocol (FTP).

VM Import/Export

CLI command → aws ec2 create-instance-export-task

Data Transfer

No charge for inbound data transfer across all services in all Regions.
Data transfer from AWS to the internet is charged per service, with rates specific to the originating Region.
There is a charge for data transfer across Regions.
Data transfer within the same Availability Zone is free.
Data transfer over a VPC peering connection that stays within an Availability Zone is free. Data transfer over a VPC peering connection that crosses Availability Zones will incur a data transfer charge for ingress/egress traffic. If the VPCs are peered across Regions, standard inter-Region data transfer charges will apply.
Data processing charges apply for each GB sent from a VPC, Direct Connect, or VPN to Transit Gateway.
Direct Connect and VPN also incur charges for data flowing out of AWS.

For choosing between data transfer options:

The AWS Snow Family is a better choice for moving large batches of data at once.
Direct Connect is a better choice for a private networking requirement.
AWS VPN is a better choice if you want to add encryption in transit.

Encryption

Encryption in transit → VPN with IPSec, TLS for network level traffic, SSL certs for web apps and CloudFront, HTTPS listeners for LBs, SSL to encrypt connection to DB instance, VPC endpoints to keep data transit inside AWS.
Encryption at rest → AES256 AWS standard option, client side option, KMS.

KMS

Highly available, durable, fully managed service that lets you create, manage, and control cryptographic keys across your applications and more than 100 AWS services.
Centralized control over the lifecycle and permissions of your keys.
You can import keys from your own key management infrastructure(256-bit symmetric keys.)
Create and use asymmetric KMS keys and data key pairs.
Customer Master Keys(CMKs) includes metadata(key id, creation date, etc), encrypt and decrypt up to 4KB of data. Generate, encrypt, decrypt the data keys used outside of KMS to encrypt data(envelope encryption). Normally used to generate data keys that are then used to encrypt/decrypt data (KEY→ view:yes, manage:yes, used only for my account:yes)
AWS managed CMK (KEY→ view:yes, manage:no, used only for my account:yes)
AWS owned CMK (KEY→ view:no, manage:no, used only for my account:no)
Data keys: encryption keys used to encrypt data, encrypted with CMK, KMS doesn’t track data keys, data keys need to be managed by customer.
Key policies and grants to manage access.
GenerateDataKey → returns plaintext and encrypted data key under the CMK. Remove the plaintext data key after data has been ecnrypted. You can store the encrypted data key along with the encrypted data to later decrypt the data.

If you choose to have AWS KMS automatically rotate keys, you don’t have to re- encrypt your data. AWS KMS automatically keeps previous versions of keys to use for decryption of data encrypted under an old version of a key. All new encryption requests against a key in AWS KMS are encrypted under the newest version of the key.
Schedule key deletion with configurable waiting period from 7 to 30 days.
Up to 100,000 KMS keys per account per Region.
Key policies don’t automatically give permission to the account or any of its users. For example, suppose you create a key policy that gives only one user access to the KMS key. If you then delete that user, the key becomes unmanageable and you must contact AWS Support to regain access to the KMS key.
SSE-S3 requires that Amazon S3 manage the data and the encryption keys.
SSE-C requires that you manage the encryption key.
SSE-KMS requires that AWS manage the data key but you manage the customer master key (CMK) in AWS KMS.
Pricing per key and per api request above the free tier.

Security

ACM

Can import your own certificates.
ACM certificates must be in the same Region as the resource where they are being used. The only exception is Amazon CloudFront, a global service that requires certificates in the US East (N. Virginia) region. ACM certificates in this region that are associated with a CloudFront distribution are distributed to all the geographic locations configured for that distribution.
Default 13 months validity.
Each cert should have at least one fully qualified domain.
Helps you comply with regulatory requirements by making it easy to facilitate secure connections, a common requirement across many compliance programs such as PCI, FedRAMP, and HIPAA.
Server Name Indication (SNI) custom SSL → for multiple domains to serve SSL traffic over the same IP address.

GuardDuty

One-click deployment with no additional software or infrastructure to deploy and manage. By default regional resource.
Continuous intelligent threat detection and security monitoring, VPC flow logs, DNS Logs, CloudTrail event logs, EKS, RDS. Uses existing threat intelligence feeds and lists that contain malicious IPs, domains. ML, behavioral modeling to catch anomalous behaviors, AuroraDB and S3.

Can detect: escalation privileges, exposed credentials, communication with malicious external systems, detect compromised ec2 with malware, detect unauthorized infra deployments, reconnaissance, account compromise.
Invite other accounts to use and become master account → Then you can get findings of member accounts.
Integrates with Security Hub, Detective.
Automated remediation possible with API, cli, EventBridge + Lambda.
Aggregate security findings produced by GuardDuty across Regions using Amazon CloudWatch Events or pushing findings to your data store (like S3) and then aggregating findings as you see fit. You can also send GuardDuty findings to AWS Security Hub and use its cross-Region aggregation capability.
Associate and manage multiple AWS accounts from a single administrator account. GuardDuty is integrated with AWS Organizations, allowing you to delegate an administrator account for GuardDuty for your organization.This delegated administrator (DA) account is a centralized account that consolidates all findings and can configure all member accounts.
Pricing per log events and GB processed.

Shield

Protect against DDo,S, SYN floods, UDP floods, or other reflection attacks.
Shield standard automatically available without extra charge.
Shield advanced → higher lvl protection against larger attacks, 24/7 access to DDoS response team, advanced real time metrics and reports and threat intelligence dashboard.
Shield standard is free. Shield advanced ~3k + data transfer out.
DDoS mitigation without Shield Advanced: a) Use CloudFront b) Add CloudWatch alerts for CPU, NetworkIn c) Set up autoscaling behind ELB d) Integrate WAF with ALB

Web Application Firewall(WAF)

Protect against common web based attacks and exploits.
Security rules that control bot traffic and block common attack patterns such as SQL injection or cross-site scripting (XSS).
Tightly integrates with CloudFront and ALB, API Gateway, and AWS AppSync. AWS WAF rules cannot protect a Network Load Balancer.
Can create rules that can block or rate-limit traffic from specific user-agents, from specific IP addresses, or that contain particular request headers.
Can leverage rate-based rules to limit access to certain parts of a webpage(e.g. login page).
Pricing is per ACL, per rule, per request.

Firewall Manager

Centrally configure and manage firewall rules across your accounts and applications in AWS Organizations.
You can centrally configure AWS WAF rules, AWS Shield Advanced protection, Amazon Virtual Private Cloud (VPC) security groups, AWS Network Firewalls, and Amazon Route 53 Resolver DNS Firewall rules across accounts and resources in your organization. It does not support Network ACLs as of today.

AWS Network Firewall

With Network Firewall, you can filter traffic at the perimeter of your VPC. This includes filtering traffic going to and coming from an internet gateway, NAT gateway, or over VPN or AWS Direct Connect

AWS Config

Configuration history and changes on AWS resources or software(OS and system- level configuration changes with Systems manager integration).
Discovers, maps, and tracks AWS resource relationships in your account.
Pre-built or custom rules (on AWS Lambda) evaluating the configurations of your cloud resources.
Conformance packs are collection of rules + remediation actions into a single entity and deploy it across an Organization. Common baseline for resource configuration policies and best practices across multiple accounts. Conformance packs also provide compliance scores.
Multi-account, multi-Region data aggregation for centralized auditing and governance using an aggregator resource. Associate your AWS Organization to quickly add your accounts. The aggregated dashboard on AWS Config will display the total count of non-compliant rules across your Organization.
Supports extensibility → publish the configuration of third-party resources into AWS Config using our public API operations(e.g. GitHub, Microsoft AD, on premises server).
Visual dashboard to help you quickly spot non-compliant resources and take appropriate action.
Partners who provide solutions that integrate with AWS Config for resource discovery, change management, compliance, or security.
Connect with ITSM / ITOM Software(Jira Service Desk, ServiceNow).
AWS Config applies remediation using AWS Systems Manager Automation documents.
Pricing is per config item, per rule, per conformance pack

Security Hub

Gives you an overview of security and compliance status of your AWS account(s) that performs security best practice checks, aggregates alerts, and enables automated remediation.
Collects and consolidates GuardDuty, Config, Inspector, Macie, WAF, partner solutions.
Integrate security findings from AWS services and third-party products.
With finding aggregation you can use a single region to view and update findings from multiple linked regions and accounts.
AWS Security Hub creates a score to show you how you are doing against security standards and displays it on the main AWS Security Hub dashboard.
Custom actions for remediation with EventBridge, Lambda or Systems Manager.

If a compliance standard, such as PCI-DSS, is already present in AWS Security Hub, then the fully managed AWS Security Hub service is the easiest way to operationalize it.

AWS Secrets Manager

Centrally manage lifecycle of secrets.
Automatic secrets rotation without disrupting applications.
Automatic replication of secrets to multiple AWS Regions.
Config Rules to help you verify that your secrets are configured in accordance with your organization’s security and compliance requirements.
AWS Secrets Manager uses envelope encryption (AES-256 encryption algorithm) to encrypt your secrets in AWS Key Management Service (KMS).
To rotate the keys successfully you need to configure an Amazon VPC interface endpoint to access AWS services running in Amazon VPC private subnets because these subnets don’t have internet access. Pricing is per secret stored and per api call.

Inspector

Automated vulnerability management service. Automatically discovers all Amazon EC2 instances, Lambda functions, and container images residing in Amazon ECR that are identified for scanning, and then immediately starts scanning them for software vulnerabilities and unintended network exposure.
Scans EC2, ECR registry for vulnerabilities and unintended network exposure.
Simplified one-click onboarding and integration with AWS Organizations by setting a Delegated Administrator (DA) account.
All findings are aggregated in the Amazon Inspector console, routed to AWS Security Hub, and pushed through Amazon EventBridge to automate workflows such as ticketing.
Vulnerabilities detected in software dependencies used in AWS Lambda functions are automatically mapped to the underlying Lambda layers, making remediation efforts easier.
You can generate reports in multiple formats (CSV or JSON) with a few clicks in the Amazon Inspector console or through the Amazon Inspector APIs.
Integrates with partners for extensibility. Pricing is per ec2 scanned, per container image scanned, per lambda scanned.

Licence Manager

Allows to define rules for licences and Integrates with EC2 to enforce licensing rules and track usage.

CloudTrail

Auditing, security monitoring, operational troubleshooting → records all API calls.
Management events and Data events(S3 operations).
Event history(90 days of control plane actions at no additional cost).
CloudTrail Lake → managed data lake for capturing, storing, accessing, analyzing user and API activity for audit and security purposes for up to seven years and query logs within seconds for search and analysis. run SQL-based queries on activity logs for auditing within the lake.
You can deliver your ongoing management and data events to S3 and optionally to CloudWatch Logs or EventBridge by creating trails. Trails capture a record of AWS account activities. Up to 5 trails per region.
Enable CloudTrail Insights in your trails to identify unusual operational activity in your AWS accounts. e.g. misbehaving scripts or apps → bursts in IAM calls.
Log file integrity validation feature to see if logs have been tampered.
Possible to capture and store events from muliple regions and multiple accounts in a single location.
Turning on CloudTrail has no impact on performance for your AWS resources or API call latency.
To detect the presence of public S3 objects → CloudTrail, s3 object-logging, EventBridge.
For global services such as AWS Identity and Access Management (IAM), AWS STS, Amazon CloudFront, and Route 53, events are delivered to any trail that includes global services (IncludeGlobalServiceEvents flag).
For multi-region trails enables the flag —is-multi-region-trail
To create an organization trail for all AWS accounts, ensure that the Enable for all accounts in my organization option is checked when you create a new CloudTrail trail. Pricing is per lake (ingestion and storage per GB), per trail( data & management events), and per insight (events analyzed).

DNS

Route53

Highly available and scalable DNS web service.
Your DNS records are organized into “hosted zones” that you configure with Route 53’s API.
You can transfer an external domain to Route53 so that you can conveniently manage your domain names and DNS configuration in a single location.
To keep your domain name with the current registrar, inform the registrar to update the name servers for your domain to the ones associated with your hosted zone.
With query logging, Amazon Route 53 sends logs to CloudWatch Logs.
Route53 uses anycast to help end users’ DNS queries get answered from the optimal Route 53 location.
Maximum of 500 hosted zones and 10,000 resource record sets per hosted zone.
Possible to create multiple hosted zones for the same domain name for testing purposes.
Alias records, which are an Amazon Route 53-specific extension to DNS and let you route traffic to AWS resources, are free. To route domain traffic to an ELB load balancer, use Amazon Route 53 to create an alias record that points to your load balancer. It’s similar to a CNAME record, but you can create an alias record both for the root domain, such as example.com, and for subdomains, such as www.example.com. (You can create CNAME records only for subdomains). a) For EC2 instances, → Type A Record without an Alias b) For ELB, Cloudfront, and S3 → Type A Record with an Alias, c) For RDS → CNAME Record with no Alias.
Supports both forward (AAAA) and reverse (PTR) IPv6 records.
Geo DNS lets you balance load by directing requests to specific endpoints based on the geographic location from which the request originates.
Traffic Flow is an easy-to-use and cost-effective global traffic management service.
Supports health checks over HTTPS, HTTP or TCP.
Each health check’s results are published as Amazon CloudWatch metrics showing the endpoint’s health and, optionally, the latency of the endpoint’s response.
Metric based health checks let you perform DNS failover based on any metric that is available within Amazon CloudWatch, including AWS-provided metrics and custom metrics.
Resolver is integrated with AWS Resource Access Manager (RAM) which provides customers with a simple way to share their resources across AWS accounts or within their AWS Organization.

To resolve any DNS queries for resources in the AWS VPC from the on-premises network, you can create an inbound endpoint on Route 53 Resolver
To resolve DNS queries for any resources in the on-premises network from the AWS VPC, you can create an outbound endpoint on Route 53 Resolver.
You can associate a VPC from one account with a private hosted zone in a different account. You first must authorize the association. In addition, you can’t use the AWS console(use AWS CLI) either to authorize the association or associate the VPCs with the hosted zone. Optional but recommended – Delete the authorization to associate the VPC with the hosted zone.
Allows you to enable Domain Name System Security Extensions (DNSSEC) signing for all existing and new public hosted zones, and enable DNSSEC validation for Amazon Route 53 Resolver. Amazon Route 53 DNSSEC provides data origin authentication and data integrity verification for DNS and can help customers meet compliance mandates, such as FedRAMP. Route 53 cryptographically signs each record in that hosted zone. When you enable DNSSEC validation on the Route 53 Resolver in your VPC, it ensures that DNS responses have not been tampered with in transit. This can prevent DNS Spoofing.
You can specify multiple values for almost any record, but multivalue answer routing also lets you check the health of each resource, so Route 53 returns only value for healthy resources. It’s not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing
Pricing: monthly charge for each hosted zone managed with Route 53, incur charges for every DNS query answered by the Amazon Route 53, annual charge for each domain name registered via or transferred into Route 53.

Storage

S3

S3 Replication enables automatic, asynchronous copying of objects across Amazon S3 buckets. There are two types of Replications: a) Cross-Region replication (CRR) is used to copy objects across Amazon S3 buckets in different AWS Regions. b) Same-Region replication (SRR) is used to copy objects across Amazon S3 buckets in the same AWS Region.
For cross region replication, versioning must be enabled in both sources and destination buckets.
By default, an S3 object is owned by the AWS account that uploaded it. This is true even when the bucket is owned by another account. To get full access to the object, the object owner must explicitly grant the bucket owner access. You can create a bucket policy to require external users to grant bucket-owner-full-control when uploading objects so the bucket owner can have full access to the objects.
You can change the storage class of the replicated items.
Once you version-enable a bucket, it can never return to an unversioned state. Versioning can only be suspended once it has been enabled.
Metadata, which can be included with the object, is not encrypted while being stored on Amazon S3. Therefore, AWS recommends that customers not place sensitive information in Amazon S3 metadata.
Object lock: store objects as locked(only on versioned buckets).
Objects stored in a bucket before enabling versioning have a version ID null.
You can place a retention period on an object version. Different versions of a single object can have different retention modes and periods.
To host a static website, you configure an Amazon S3 bucket for website hosting, and then upload your website content to the bucket. This bucket must have public read access. You must give the bucket the same name as the record that you want to use to route traffic to the bucket.
S3 static website: a) To allow public read access to objects, the account that owns the bucket must own the objects b) on S3 bucket that allows anonymous or public access will not apply to objects that are encrypted with AWS KMS. You must remove KMS encryption from the objects that you want to serve using the Amazon S3 static website endpoint.
Up to 24 hours can pass before the bucket name propagates across all AWS Regions. During this time, you might receive the 307 Temporary Redirect response for requests to Regional endpoints that aren’t in the same Region as your bucket.
Amazon S3 server access logging captures all bucket-level and object-level events.
Using the Range HTTP header in a GET Object request, you can fetch a byte-range from an object, transferring only the specified portion. A byte-range request is a perfect way to get the beginning/end of a file and ensuring we remain efficient during our scan of our S3 bucket.
With Amazon S3 Select, you can scan a subset of an object by specifying a range of bytes to query using the ScanRange parameter.
Max object upload 5GB. When your object size reaches 100 MB, you should consider using multipart uploads. Upload a single object as a set of parts. You can upload these object parts independently and in any order. If transmission of any part fails, you can retransmit that part without affecting other parts.
Max object size 5TB.
Use S3 Access Points to manage access to shared datasets on Amazon S3. VPC Gateway endpoint + S3 access endpoint + bucket policy.
S3 standard IA, one-zone IA, intelligent tier has a minimum storage duration charge of 30 days.
S3 Glacier has a minimum storage duration charge of 90 days.
S3 Glacier deep archive has a minimum storage duration charge of 180 days.
S3 Standard no minimum storage duration
The AWS S3 sync command uses the CopyObject APIs to copy objects between S3 buckets.
You can increase your read or write performance by parallelizing reads with prefixes.
To encrypt an object at the time of upload, you need to add a header called x-amz-server-side-encryption. To enforce object encryption, create an S3 bucket policy that denies any S3 Put request that does not include the x-amz-server-side-encryption header.
When you use server-side encryption with Amazon S3 managed keys (SSE-S3), each object is encrypted with a unique key. As an additional safeguard, it encrypts the key itself with a root key that it regularly rotates.
Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE- S3) as the base level of encryption for every bucket in Amazon S3.
Bucket owners pay for all Amazon S3 storage and data transfer costs associated with their bucket. A bucket owner, however, can configure a bucket to be a Requester Pays bucket. With Requester Pays buckets, the requester instead of the bucket owner pays the cost of the request and the data download from the bucket. The bucket owner always pays the cost of storing data. You must authenticate all requests involving Requester Pays buckets. Requesters must include x-amz-request-payer in their requests either in the header, for POST, GET and HEAD requests, or as a parameter in a REST request to show that they understand that they will be charged for the request and the data download.
S3 notifications events: New object created, object removal, restore object, reduced redundandcy storage object lost, replication,S3 Lifecycle expiration events, S3 Lifecycle transition events, S3 Intelligent-Tiering automatic archival events, Object tagging events, Object ACL PUT events. Enabling notifications is a bucket-level operation; that is, you store notification configuration information in the notification subresource associated with a bucket. Destinations: SNS, SQS, Lambda, Amazon EventBridge

Glacier

Vault Lock allows you to easily deploy and enforce compliance controls for individual S3 Glacier vaults with a vault lock policy.

EBS

Copy snapshots don’t inherit the retention schedule and can be kept indefinitely.
For an encrypted EBS volume data stored at rest on the volume, data moving between the volume and the instance, snapshots created from the volume, and volumes created from those snapshots are all encrypted.
Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances with Nitro system that are in the same Availability Zone.
EBS volume are locked to AZ, to attach to other AZ you have to snapshot it.
Copying an unencrypted snapshot allows encryption.

Instance store

SSD-based instance store volumes support more than a million IOPS for random reads.
Cant create snapshots for instance store volumes.

EFS

POSIX compliant.
1000s on concurrent NFS clients, 10Gbs throughput.
With Amazon EFS, you pay only for the resources that you use.
Use EFS Access Points to manage application access.
Higher price point than EBS.
Maximum days for the EFS lifecycle policy is 90.
Encryption at rest must be enabled at creation time, Encryption in transit can be enabled during mount time.
For encryption in transit, there is no need to add custom security group rules for port 443.
Access controls with endpoints in your Amazon VPC (mount targets) and POSIX- compliant user and group-level permissions.

FSx for Windows

Multi-az possible, automatically provisions and maintains a standby file server in a different Availability Zone.
Test the failover of your Multi-AZ file system by modifying its throughput capacity.
Monitor storage capacity and file system activity using Amazon CloudWatch.
Destination for publishing user access events by logging these events to CloudWatch Logs or streaming to Kinesis Data Firehose.
Accessible over the Server Message Block (SMB) protocol.

FSx for Lustre

High-performance file system.
FSx for Lustre can only be used with Linux instances.

Databases

DynamoDB

Global tables are available across regions with low latency. Must first enable streams.
Can only query on primary key, sort key, or indexes.
All DynamoDB tables are encrypted. There is no option to enable or disable encryption for new or existing tables. By default, all DynamoDB tables are encrypted under an AWS owned customer master key (CMK), which do not write to CloudTrail logs.
You can purchase reserved capacity in advance to lower the costs of running your DynamoDB instance. With reserved capacity, you pay a one-time upfront fee and commit to a minimum usage level over a period of time.
Partition key and sort key – Referred to as a composite primary key, this type of key is composed of two attributes.
With provisioned capacity, you pay for the provision of read and write capacity units for your DynamoDB tables. With provisioned capacity, you can also use auto- scaling to automatically adjust your table’s capacity based on the specified utilization rate to ensure application performance, and also potentially reduce costs. Probably best for you if you have relatively predictable application traffic, run applications whose traffic is consistent, and ramps up or down gradually
DynamoDB on-demand you pay per request for the data reads and writes that your application performs on your tables. DynamoDB instantly accommodates your workloads as they ramp up or down. on-demand capacity mode is probably best when you have new tables with unknown workloads, unpredictable application traffic, and also if you only want to pay exactly for what you use

RDS

Use RDS performance insights to analyze DB load and DB performance. Also can get performance of SQL queries.
Supports Cross-Region Automated Backups. Manual snapshots and Read Replicas are also supported across multiple Regions.
Multi-AZ DB → synchronously replicate the data to a standby instance for failover.
With Read replicas → asynchronously replicate the data uses the engines native replication to update the read replica whenever there is a change to the source DB instance.
Multi region → asynchronously replicate the data to other regions.
Multi-AZ → primary and standby upgraded at the same time.
To leverage reserved instances from another account in the same organization, you have to use instances with the same DB attributes.
Use weighted record sets to distribute requests across your read replicas. Within a Route 53 hosted zone, create individual record sets for each DNS endpoint associated with your read replicas. Then, give them the same weight, and direct requests to the endpoint of the record set.
Amazon RDS does not support certain features in Oracle such as Multitenant Database, Real Application Clusters (RAC), Unified Auditing, Database Vault, and many more.

AuroraDB

Fully managed postgresql, mysql designed for high performance, availability and global scale.
Automatic backups and point-in-time restore, storage autoscaling (of 10 GB up to a maximum of 128 TB), multi region replication.
Up to 15 replicas, automatic failover in case of issues. If no replicas, will attempt to create a new Amazon Aurora DB instance for you automatically.

Global tables for globally distributed applications. storage-based replication to replicate a database across multiple AWS Regions, with typical latency of less than one second. You can use a secondary region as a backup option in case you need to recover quickly from a regional degradation or outage. An Aurora cluster can recover in less than 1 minute even in the event of a complete regional outage This provides your application with an effective Recovery Point Objective (RPO) of 1 second and a Recovery Time Objective (RTO) of less than 1 minute
Serverless option → where the database automatically starts up, shuts down, and scales capacity up or down based on your application’s needs. Good option if there isn’t consistent load on the DB.
Aurora parallel query provides faster analytical queries.
Diagnose and Resolve Performance Bottlenecks with Amazon DevOps Guru for RDS.
Backtrack for Aurora MySQL without needing to restore data from a backup.
Aurora is integrated with Amazon GuardDuty to help you identify potential threats to data stored in Aurora databases.
Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database updates with zero data loss.
Publish general, slow, audit, and error log data to a log group in Amazon CloudWatch Logs.
Instrument your SQL database queries by adding the X-Ray SDK.
Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas.
You can specify the failover priority for Aurora Replicas, each Read Replica is associated with a priority tier (0-15). Aurora will promote the Read Replica that has the highest priority (the lowest numbered tier). If two or more Aurora Replicas share the same priority, then Amazon RDS promotes the replica that is the largest in size.

DocumentDB

Interface or gateway endpoints not supported currently.
DocumentDB Global Clusters: one primary region and up to five read-only secondary regions. You issue write operations directly to the primary cluster in the primary region and Amazon DocumentDB automatically replicates the data to the secondary regions using dedicated infrastructure. Latency is typically under a second.

Elasticache

For caching, which accelerates application and database performance.
Simple object caching → Memcached.
Complex data types(e.g. lists, hashes, bit arrays) → Redis.
Sorting and ranking of datasets(leaderboards) → Redis.
For HA, multi-az, failover → Redis.
Encryption, compliance(e.g. PCI) → Redis.
Global Datastore in Amazon ElastiCache for Redis provides fully managed, fast, reliable and secure cross-region replication.
Amazon ElastiCache for Redis provides fully managed, automatic scaling to maintain steady performance for your application demands.
Redis authentication tokens enable Redis to require a token (password) before allowing clients to run commands.
You can use both in-transit as well as at-rest encryption to guard against unauthorized access of your data on the server.

AWS Backup

With continuous backups, you can restore your AWS Backup-supported resource by rewinding it back to a specific time that you choose within 1 second of precision (going back a maximum of 35 days). Continuous backup works by first creating a full backup of your resource and then constantly backing up your resource’s transaction logs.

Data Analytics

Redshift

Using Amazon Redshift Spectrum, you can efficiently query and retrieve structured and semistructured data from files in Amazon S3 without having to load the data into Amazon Redshift tables.
For DR purposes, you can configure Amazon Redshift to automatically copy snapshots for the cluster to another AWS Region.
To copy snapshots for AWS KMS–encrypted clusters to another AWS Region, you need to create a grant for Redshift to use a KMS customer master key (CMK) in the destination AWS Region.
Pattern: Kinesis Data Firehose → S3 → RedShift COPY cmd → Redshift.
For backups, no extra backup storage costs for up to 100% of your provisioned storage. Therefore, if we have a backup policy with 1-day retention we dont have any extra costs.
Suitable for OLAP scenarios.
You can migrate data to Amazon Redshift databases using AWS Database Migration Service.

EMR

Managed platform for big data frameworks(hadoop, spark).
Vast amount of data, business intelligence workloads.
EMR cluster: Master node: A node that manages the cluster by running software components to coordinate the distribution of data and tasks among other nodes for processing. Core node: A node with software components that run tasks and store data in the Hadoop Distributed File System (HDFS) on your cluster. Task node: A node with software components that only runs tasks and does not store data in HDFS. Task nodes are optional.

Glue

Build ETL, fully managed service.
Glue Data Catalog → central metadata repository.
ETL engine to generate python or scala code.

Kinesis Data Analytics (KDA)

Transform and analyze streaming service in real time used with Apache Flink.
You cannot directly write the output of the records from a Lambda function to KDA.
Used to build SQL queries on streaming data.
Sources: Kinesis Data Streams, Amazon Managed Streaming for Apache Kafka (Amazon MSK), servers, IoT, and more.
Consumers: Kinesis Data Firehose and Lambda.

Kinesis Data Firehose

Automatically scales to match the throughput of your data and requires no ongoing administration. Auto-scaling solution, as there is no need to provision any shards like Kinesis Data Streams.
You can configure Amazon Kinesis Data Firehose to aggregate and collate CloudWatch Logs from different AWS accounts and receive their log events in a centralized logging AWS Account by using a CloudWatch Logs destination and then creating a Subscription Filter.
When a Kinesis data stream is configured as the source of a Firehose delivery stream, Firehose’s PutRecord and PutRecordBatch operations are disabled and Kinesis Agent cannot write to Firehose delivery stream directly. Data needs to be added to the Kinesis data stream through the Kinesis Data Streams PutRecord and PutRecords operations instead.
Sources: Servers, IoT, and any data source that can call the Kinesis API to send the data.
Consumers: Amazon Redshift, Amazon OpenSearch Service, Amazon S3, HTTP endpoints, and more.

Kinesis Data Streams

Facilitate multiple applications consume the same streaming data concurrently and independently. Enables real-time processing of streaming big data, as well as the ability to read and/or replay records in the same order to multiple Amazon Kinesis Applications.
By default, the 2MB/second/shard output is shared between all of the applications consuming data from the stream. use enhanced fan-out if you have multiple consumers retrieving data from a stream in parallel. Consumers receive their own 2MB/second pipe of read throughput per shard.
Default data retention 1 day, can go up to 7.
Sources: Servers, IoT, and any data source that can call the Kinesis API to send the data.
Consumers: Kinesis Data Analytics, Amazon EC2, Amazon EMR, and AWS Lambda.

Kinesis Video Streams

Use to stream live video from devices to the AWS Cloud, or build applications for real-time video processing or batch-oriented video analytics.
Use HLS for live playback. Use the GetHLSStreamingSessionURL API to retrieve the session URL and provide it to your player.

AppStream

Fully managed service which can be configured for application streaming or for delivery of virtual desktops with selective persistence.
Empower remote workers to react quickly to changing conditions.
Monthly fee per streaming user.

AI/ML

Amazon Rekognition

Deep learning, image recognition service, detect objects within an image.
Pattern: Recognize something in videos: a) Kinesis video stream for sending streaming video to Rekognition Video using kinesis PutMedia API b) Amazon Recognition Video Steam processor to manage the analysis c) Kinesis data streams consumer to read the analysis results(e.g. ec2 on asg).
Supports the IndexFaces operation. You can use this operation to detect faces in an image and persist information about facial features that are detected in a collection. This is an example of a storage-based API operation because the service persists information on the server.

Amazon Comprehend

Get insights about the content of docs.
Detect key phrases, language, sentiment, entities in text, intelligent document processing use cases.
Search social feeds for mentions.

Amazon Machine Learning Service

Cloud-based used by devs to leverage ML.
Devs can use visualization tools and wizards to create ML models without deep ML knowledge.

Amazon Textract

ML service that automatically extracts text, handwriting, and data from scanned documents.
It goes beyond simple optical character recognition (OCR) to identify, understand, and extract data from forms and tables.
Process invoices and receipts with the AnalyzeExpense API.
Process ID documents such as driver’s licenses and passports issued by the U.S Government using the AnalyzeID API.

Amazon Transcribe

Convert speech to text. Using Automatic Speech Recognition (ASR) technology, customers can choose to use Amazon Transcribe for a variety of business applications, including transcription of voice-based customer service calls, generation of subtitles on audio/video content, and conduct (text-based) content analysis on audio/video content.

Content Delivery & Global Network

CloudFront

Price Classes let you reduce your delivery prices by excluding Amazon CloudFront’s more expensive edge locations from your Amazon CloudFront distribution.
Reduce latency by delivering data through our globally dispersed points of presence.
Offers traffic encryption and access controls.
Accepts well-formed connections to prevent many common DDoS attacks like SYN floods and UDP reflection attacks from reaching your origin.
With Signed URLs and Signed Cookies, Token Authentication is supported to restrict access to only authenticated viewers.
Supports Server Name Indication (SNI) for custom SSL certificates, along with the ability to take incoming HTTP requests and redirect them to secure HTTPS requests to ensure that clients are always directed to the secure version of your website. If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation and isn’t dedicated to your distribution.
Origin Shield enables a centralized caching layer and optimizes cache hit ratios and collapses requests across regions leading to as few as one origin request per object.
CloudFront supports multiple origins for backend architecture redundancy.
Amazon CloudFront is integrated with Amazon CloudWatch, and automatically publishes six operational metrics per distribution.
Amazon CloudFront uses standard cache control headers you set on your files to identify static and dynamic content.
Geo Restriction feature lets you specify a list of countries in which your users can access your content. Alternatively, you can specify the countries in which your users cannot access your content.
You can turn on HTTP/3 for new and existing Amazon CloudFront distributions.
Field-Level Encryption is a feature of CloudFront that allows you to securely upload user-submitted data such as credit card numbers to your origin servers. The sensitive information provided by your clients is encrypted at the edge closer to the user and remains encrypted throughout your entire application stack, ensuring that only applications that need the data—and have the credentials to decrypt it—are able to do so. To use field-level encryption, you configure your CloudFront distribution to specify the set of fields in POST requests that you want to be encrypted, and the public key to use to encrypt them. You can encrypt up to 10 data fields in a request.
CloudFront by default do not forward query strings, cookies, and many of request headers. You can configure CloudFront to forward selected headers, cookies, and query strings.
Possibility to add or modify request headers forwarded to the origin and then accept only these requests from the origin.
CloudFront Functions is a serverless edge compute feature allowing you to run JavaScript code at CloudFront edge locations for lightweight HTTP(s) transformations and manipulations.
CloudFront signed cookies → provide access to multiple restricted files.
CloudFront signed URLs → access to one file.
To increase your cache hit ratio, you can configure your origin to add a Cache- Control max-age directive to your objects, and specify the longest practical value for max-age. The shorter the cache duration, the more frequently CloudFront forwards another request to your origin to determine whether the object has changed and, if so, to get the latest version.
To improve the cache hit ratio when CloudFront is configured to cache based on request headers, forward and cache based on only specified headers. Remove Authorization HTTP header from the whitelist headers section for cache behavior configured for static content. In addition, AWS recommends not to configure caching based on values in the Date and User-Agent headers
Lambda@Edge is an extension of AWS Lambda allowing you to run code at global edge locations without provisioning or managing servers. Lambda@Edge offers powerful and flexible serverless computing for complex functions and full application logic closer to your viewers.
You cannot directly integrate Cognito User Pools with CloudFront distribution as you have to create aseparate Lambda@Edge function to accomplish the authentication via Cognito User Pools.
lambda@edge lets you execute functions that customize the content that CloudFront delivers. A Lambda function can inspect cookies and rewrite URLs so that users see different versions of a site for A/B testing. Return different objects to viewers based on the device they are using by checking the User-Agent header. Make network calls to external resources to confirm user credentials, or fetch additional content to customize a response.

Global Accelerator(GA)

Directs traffic to optimal endpoints over the AWS global network.
Two static anycast IP addresses that act as a fixed entry point to your application endpoints
Good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP.
AWS Global Accelerator has the following types of endpoints only - Network Load Balancers, Application Load Balancers, Amazon EC2 instances, or Elastic IP addresses (not possible to front CloudFront distribution)
Shift traffic gradually or all at once between the blue and the green environment and vice-versa without being subject to DNS caching on client devices and internet resolvers.
With a custom routing accelerator, you can map one or more users to a specific destination among many destinations. Custom routing accelerators only support virtual private cloud (VPC) subnet endpoint types and route traffic to private IP addresses in that subnet.

CloudFront vs GA

CloudFront uses multiple sets of dynamically changing IP addresses, pricing is mainly based on data transfer out and HTTP requests, uses edge locations to cache content, and is designed to handle HTTP protocol.
Global Accelerator provides a set of static IP addresses as a fixed entry point to your applications, charges a fixed hourly fee and an incremental charge over your standard data transfer rates, uses edge locations to find an optimal pathway to the nearest regional endpoint, and is best with both HTTP and non-HTTP protocols, such as TCP and UDP.

Compute

EC2

Dedicated (Instances) → no other customers share the hardware, May share hardware with instances in YOUR account only.
(Dedicated) Hosts → book an entire physical server and have full control of EC2 instance placement.
When you create a launch configuration, the default value for the instance placement tenancy is null and the instance tenancy is controlled by the tenancy attribute of the VPC.
Good EC2 combo → reserved instances for baseline + on-demand & spot for peaks.
You can only change the tenancy of an instance from dedicated to host, or from host to dedicated after you’ve launched it.
EC2 Fleet lets you provision compute capacity across different instance types, Availability Zones and across On-Demand, Reserved Instances (RI) and Spot Instances.
On-Demand Capacity Reservation → create and manage reserved capacity on Amazon EC2. Define Availability Zone and quantity (number of instances) along with other instance specifications such as instance type and tenancy.
Userdata executed as root by default.

Hibernate

Save contents from RAM to EBS root volume. When instance starts, EBS root volume is restored to its previous state and RAM contents are reloaded.
To use hibernation, the root volume must be an encrypted EBS volume.
When the instance state is stopping, you will not be billed if it is preparing to stop however, you will still be billed if it is just preparing to hibernate.

Spot

EC2 fleet won’t automatically failover to on-demand if ec2 spot capacity is not fully fullfilled.
You pay the Spot price that’s in effect at the beginning of each instance-hour for your running instance. If Spot price changes after you launch the instance, the new price is charged against the instance usage for the subsequent hour.
Recommend using multiple Spot capacity pools to maximize the amount of Spot capacity available to you.
Spot blocks are designed not to be interrupted and will run continuously for the duration you select, independent of Spot market price. In rare situations, Spot blocks may be interrupted due to AWS capacity needs.
Do not support multi-region Fleet requests.

Placement Groups

It is recommended that you launch the number of instances that you need in the placement group in a single launch request and that you use the same instance type for all instances in the placement group. If you try to add more instances to the placement group later, or if you try to launch more than one instance type in the placement group, you increase your chances of getting an insufficient capacity error.
If you receive a capacity error when launching an instance in a placement group that already has running instances, stop and start all of the instances in the placement group, and try the launch again. Restarting the instances may migrate them to hardware that has the capacity for all the requested instances.
Before you move or remove the instance from a placement group, the instance must be in the stopped state. You can move or remove an instance using the AWS CLI or an AWS SDK.

Spread

Maximum of 7 running instances per Availability Zone per group.
Recommended for applications that have a small number of critical instances that should be kept separate from each other.
Spread placement groups provide access to distinct racks, and are therefore suitable for mixing instance types or launching instances over time.

Cluster

Higher per-flow throughput limit of up to 10 Gbps for TCP/IP traffic and are placed in the same high-bisection bandwidth segment of the network.

Partition

Spreads your instances across logical partitions such that groups of instances in one partition do not share the underlying hardware with groups of instances in different partitions.
Used by large distributed and replicated workloads.

EC2 On-demand instance limits

Amazon EC2 is transitioning On-Demand Instance limits from the current instance count-based limits to the new vCPU-based limits to simplify the limit management experience for AWS customers.

EC2 Image Builder

Use RAM to share EC2 Image Builder resources, add the shared components, images, recipes in resource shares and configure principals which are allowed to access the shared resources.
Possible to distribute the AMI to multiple regions or shared with other accounts.

Graviton2

40% better price/performance at 20% lower cost over comparable Intel x86.

Graviton3

25% better price/performance compared to graviton2.

AWS Batch

Dynamically provisions the optimal quantity and type of compute resources (e.g., CPU or memory optimized instances) based on the volume and specific resource requirements of the batch jobs submitted.
No additional charge, only pay for AWS underlying resources you create to store and run your batch jobs.
Use AWS Batch to accelerate content creation, dynamically scale media packaging, and automate asynchronous media supply chain workflows.

Containers

ECS

Fully-managed container orchestration service, with AWS configuration and operational best practices built-in, and no control plane, nodes, or add-ons for you to manage.
ECS Service Connect simplifies building and operating resilient distributed applications and provides rich traffic telemetry in the ECS console and in Amazon CloudWatch. Supports automatic connection draining that helps your client applications switch to a new version of the service endpoint without encountering traffic errors.
Serverless by default with built in Fargate.
Natively integrates with the Security, Identity, and Management and Governance tools.
Blue/green deployments with AWS CodeDeploy help you minimize downtime during application updates. New version of ECS service alongside the old one and test before rerouting traffic with rapid rollback if necessary.
Capacity Providers → running a service in a predefined split percentage across Fargate and Fargate Spot.
Task scheduling for batch jobs.
Service → specified number of tasks are constantly running and restarts tasks if failure occurs.
Customize how tasks are placed onto a cluster of Amazon EC2 instances based on built-in attributes such as instance type, Availability Zone, or user-defined custom attributes.
Autoscaling by integrating Amazon ECS on Fargate with Amazon CloudWatch alarms and Application Auto Scaling.
ECS on ec2 cluster autoscaling → ASG, capacity provider, CloudWatch, scaling policy.
ECS on ec2 service autoscaling → Cloudwatch alarms, Application Auto Scaling, scaling policy.
The scaling policies support a cooldown period. This is the number of seconds to wait for a previous scaling activity to take effect.
Possiblle to scale to zero when there’s no work to be done, set a minimum capacity of 0.

Fargate

Choose for isolation model and security, and avoid managing ec2. If you need more control of compute, or customization options, or GPU for ec2 then dont use it.
Supports graviton2.
Offers a serverless approach for running your Windows containers.

Elastic Container Registry (ECR)

Fully managed and highly available container registry.
Amazon ECR is a Regional service. You can build pipelines to push them to Amazon ECR in one Region, and Amazon ECR can automatically replicate them to other Regions and accounts for deployment to multi-Region clusters.
OCI and Docker support.
Tight integration with inspector for vulnerability management.
Pull through cache repositories help you keep container images sourced from public registries up to date.
AWS PrivateLink endpoints to allow your instances to pull images from your private repositories without traversing through the public internet.
You can request a custom alias for images.
Automatically encrypts images at rest using Amazon S3 server-side encryption or AWS KMS encryption and transfers your container images over HTTPS.

Autoscaling

Lifecycle hooks enable you to perform custom actions as the Auto Scaling group launches or terminates instances.

With launch templates, you can provision capacity across multiple instance types using both On-Demand Instances and Spot Instances.
Auto Scaling doesn’t terminate an instance that came into service based on EC2 status checks and ELB health checks until the health check grace period expires
Cooldown period: It ensures that the Auto Scaling group does not launch or terminate additional EC2 instances before the previous scaling activity takes effect(default 300s).
When there are multiple policies in force at the same time, Auto Scaling chooses the policy that provides the largest capacity for both scale-out and scale-in.
If you have an EC2 Auto Scaling group (ASG) with running instances and you choose to delete the ASG, the instances will be terminated and the ASG will be deleted.
Rebalancing AZs launches new instances before terminating the old ones.
Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it. Later, another scaling activity launches a new instance to replace the terminated instance.

Loadbalancers

When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
By default, cross-zone load balancing is enabled for Application Load Balancer and disabled for Network Load Balancer.

Classic Load Balancer

If your application is built within the Amazon Elastic Compute Cloud (Amazon EC2) Classic network.

Gateway Load Balancer

Deploy and run third-party virtual appliances.

Application Load Balancer

Operates at the application layer(7) routes to ec2, containers, IP, lambda.
Advanced loadbalancing http/https based on url, path, method, header, request attributes, source IP, TLS termination.
Supports sticky sessions(route request to the same target).
Injects a new custom identifier “X-Amzn-Trace-Id” HTTP header on all requests coming into the load balancer for easier tracking.
Multiple certificates with SNI. Bind multiple certificates to the same secure listener on your load balancer.
Seamlessly integrated with Amazon Cognito for user auth and has native support for OpenID Connect (IODC) identity providers (IdPs).
ALB targets with instance ID route to primary private IP in primary NIC, targets using IP addresses route to any private IP from one or more NICs.
Cannot directly upload a self-signed certificate in your ALB
Pricing: per Application Load Balancer-hour, Load Balancer Capacity Units (LCU)(active/new connections, processed bytes, rule evaluations) used per hour.

Network Loadbalancer

Flow hash routing algorithm can only be used with Network Load Balancers.
Network LB has no security groups, lets traffic passing by.
DDos protection: Implement CloudFront and use your Network Load Balancer as the origin. You can also use AWS Shield Advanced.
NLB is a good choice if you expect millions of requests per second.

Serverless, Events, Queues, Notifications

Lambda

Serverless Application Model (SAM) is an open source framework for building serverless applications. traffic shifting feature of SAM to easily test the new version of the Lambda function without having to manually move 100% of the traffic to the new version in one shot.
AWS Lambda currently supports 1000 concurrent executions per AWS account per region. More requests will be throttled.
Lambda extentions through lambda layers to integrate with other tools.
Get the max memory used for a function call from CW logs.
Reserved concurrency – Reserved concurrency creates a pool of requests that can only be used by its function, and also prevents its function from using unreserved concurrency.
Provisioned concurrency – Provisioned concurrency initializes a requested number of execution environments so that they are prepared to respond to your function’s invocations.

API Gateway

Per-client throttling limits are applied to clients that use API keys associated with your usage plan as a client identifier. Note that these limits can’t be higher than the per-account limits.
An API call through API Gateway cannot exceed 29 seconds due to the limits and not possible to increase.
API caching in Amazon API Gateway to cache your endpoint’s responses. With caching, you can reduce the number of calls made to your endpoint and also improve the latency of requests to your API.
For websocket APIs, use @connections in your backend service to send a callback message to a connected client, get connection information, or disconnect the client.
With API Gateway, you can send the stream to an Amazon Kinesis data stream on which you can group requests in batches so there will be a decrease in requests in Lambda.

Step Functions

Can’t trigger an AWS Step Function directly from an S3 event, need a lambda first. Amazon Mechanical Turk (MTurk) is a crowdsourcing marketplace that makes it easier for individuals and businesses to outsource their processes and jobs to a distributed workforce who can perform these tasks virtually. You can integrate A Amazon Mechanical Turk and SWF to implement a set of workflows for batch processing.

EventBridge

All state changes events from AWS services are free
Pay only per custom event, per 3rd part events, and for cross-account events.

SQS

Use group ID with FIFO queues to help with FIFO delivery.
FIFO supports 300 transactions (API calls) per second (300 send, receive, or delete operations per second). When you batch 10 transactions per operation (maximum), FIFO queues can support up to 3,000 (30010) transactions per second.
Message retention 4 days default, 14 days max.
Message timers to set an initial invisibility period for a message added to a queue. The default (minimum) delay for a message is 0 seconds. The maximum is 15 minutes.
Use when you need a) messaging semantics(message-level ack/fail), visibility timeout, b) dynamically increasing concurrency/throughput at read time.
SQS + lambda: For standard queues, Lambda uses long polling to poll a queue until it becomes active. When messages are available, Lambda reads up to five batches and sends them to your function.
To scale to same number of consumers as producers, send data with a Group ID attribute.
A single SQS message queue can contain an unlimited number of messages. However, there is a 120,000 quota for the number of inflight messages for a standard queue and 20,000 for a FIFO queue. Messages are inflight after they have been received from the queue by a consuming component, but have not yet been deletedfrom the queue.
By default, ReceiveMessageWaitTimeSeconds is zero which means it is using Short polling. If it is set to a value greater than zero, then it is Long polling.
You cant change an existing standard queue to FIFO → delete and recreate.
Original and dead letter queue types must match.
You can configure visibility timeout only for specific messages(e.g. with specific headers).
The maxReceiveCount is the number of times a consumer tries receiving a message from a queue without deleting it before being moved to the dead-letter queue. Setting the maxReceiveCount to a low value, such as 1 would result in any failure to receive a message to cause the message to be moved to the dead-letter queue. Such failures include network errors and client dependency errors.

SNS

Use SNS message filtering to assign a filter policy to the topic subscription, and the subscriber will only receive a message that they are interested in.
SNS FIFO for strict message ordering and deduplicated message delivery to one or more subscribers.
Amazon SNS Mobile Push Notifications, you have the ability to send push notification messages directly to apps on mobile devices. Push notification messages sent to a mobile endpoint can appear in the mobile app as message alerts, badge updates, or even sound alerts.

Amazon PinPoint

To send push notifications
offers marketers and developers one customizable tool to deliver customer communications across channels, segments, and campaigns at scale.

CI/CD

CodeCommit

Highly scalable, managed source control service for private git repositories.
Can be used with Git repositories that include submodules.
A single file in a repository cannot be more than 2 GB in size.
Deleting an AWS CodeCommit repository is a destructive one-way operation that cannot be undone.
CodeCommit supports code reviews and enables you to set permissions on branches of your code.
HTTPS or SSH protocols or both to communicate with AWS CodeCommit.
Repositories are automatically encrypted at rest.
Automation use case: Lambda function that will scan the CodeCommit code submissions for IAM credentials, and then send out notifications or perform corrective actions.

CodeBuild

Fully managed continuous integration service that compiles source code, builds packages, runs tests, and produces ready-to-deploy software packages. With CodeBuild, you don’t need to provision, manage, and scale your own build servers.
Supports sources GitHub, GitHub Enterprise, Bitbucket, or Amazon S3. CodeCommit.
CodeBuilld has a Jenkins plugin provides a build step for your Jenkins project to send your build jobs to CodeBuild eliminating the need for provisioning and managing the Jenkins worker nodes.
CodeBuild runs your build in fresh environments isolated from other users and discards each build environment upon completion. CodeBuild provides security and separation at the infrastructure and execution levels.

CodeDeploy

Fully managed, automates deployment to ec2, ecs, lambda, and on-premises.
Protects your application from downtime during deployments through rolling updates and deployment health tracking.
Supports Rolling and Blue/Green updates.
Agents that have been tested on Amazon Linux, Red Hat Enterprise Linux, Ubuntu Server, and Microsoft Windows Server.
CodeDeploy has a Jenkins plugin that provides a post-build step for your Jenkins project. Upon a successful build, it will zip the workspace, upload to S3, and start a new deployment. Supports also other 3rd party integrations.
CodeDeploy to create a deployment process that publishes the new Lambda version but does not send any traffic to it. Then it executes a PreTraffic test to ensure that your new function works as expected. After the test succeeds, CodeDeploy automatically shifts traffic gradually to the new version of the Lambda function.

CodePipeline

Fully managed automate continuous delivery pipelines.
Webhooks, SNS, Slack, Chime, MS Teams for notifications.
Possibility to register a custom action and own custom systems.
Pull source code for your pipeline directly from AWS CodeCommit, GitHub, Amazon ECR, or Amazon S3.
Build and test with CodeBuild.
Deploy using CodeDeploy, Elastic Beanstalk, ECS, Fargate.
Trigger custom actions at any point with lambda.
Allows you to integrate third-party developer tools, like GitHub or Jenkins, into any stage of your release process with one click.

Observability & Monitoring

CloudWatch

Easily collect and store logs and infra, app, container metrics.
Build alarms, dashboards.
Container insights provide automatic dashboards in the CloudWatch console.
Automate response to operational changes with cloudwatch events.
CloudWatch log insights → understand, improve, and debug their applications, by allowing them to search and visualize their logs.
Offers anomaly detection on alarms.
CloudWatch ServiceLens logs, metrics, traces.
Cross-account → Monitoring account is a central AWS account that can view and interact with observability data generated across other accounts.
Possible to have single dashboard to report metrics from different regions.

Xray

Complete view of requests as they travel through your distributed apps and different AWS components with end-to-end tracing capabilities. Identify performance bottlenecks and hard to detect issues .
An X-Ray trace is a set of data points that share the same trace ID.
An X-Ray segment encapsulates all the data points for a single component (for example, authorization service).
An X-Ray annotation is system-defined or user-defined data associated with a segment.
Works with lambda, ecs, ec2, sqs. sns , elastic beanstalk.
Integrate the X-Ray SDK with your application and install the X-Ray agent. For example for ECS, you will need to install the X-Ray agent and instrument your application code.
Captures metadata for requests to RDS/Aurora.
Node.js, Java, and .NET.
Service Map → creates a map of services used by your application with trace data that you can use to drill into specific services or issues. This provides a view of connections between service.
AWS X-Ray enables customers to choose their own sampling rate.
Can use X-Ray to track requests flowing through applications or services across multiple regions and AWS accounts.
X-Ray stores trace data for the last 30 days. This enables you to query trace data going back 30 days.
Your Lambda functions send trace data to X-Ray, and X-Ray processes the data to generate a service map and searchable trace summaries.
Pricing per traces received, retrieved, scanned.

Operations

Systems manager

Systems Manager supports an SSM document for Patch Manager, AWS-RunPatchBaseline, which performs patching operations on instances for both security-related and other types of updates. When the document is run, it uses the patch baseline currently specified as the “default” for an operating system type.
The AWS-ApplyPatchBaseline SSM document supports patching on Windows instances only and doesn’t support Linux instances. For applying patch baselines to both Windows Server and Linux instances, the recommended SSM document is AWS-RunPatchBaseline.
A patch group is an optional means of organizing instances for patching. For example, you can create patch groups for different operating systems (Linux or Windows), different environments (Development, Test, and Production), or different server functions (web servers, file servers, databases).
State Manager, a capability of AWS Systems Manager, sets and maintains the desired state configuration for managed nodes and AWS resources within your AWS account.
In a hybrid environment(AWS + on prem), you must create an IAM role for those resources to communicate with the Systems Manager service.
AWS Systems Manager Automation offers one-click automation for simplifying complex tasks such as creating golden Amazon Machines Images (AMIs) and recovering unreachable EC2 instances.
The AWSSupport-ExecuteEC2Rescue document is designed to perform a combination of Systems Manager actions, AWS CloudFormation actions, and Lambda functions that automate the steps normally required to use EC2Rescue

Systems Manager Parameter Store

Secure, hierarchical storage for configuration data management and secrets management.
You can store values as plain text or encrypted data.

AWS OpsWorks

The stack is the top-level AWS OpsWorks Stacks entity. It represents a set of instances that you want to manage collectively, typically because they have a common purpose such as serving PHP applications.
Every stack contains one or more layers, each of which represents a stack component, such as a load balancer or a set of application servers.
On Linux-based instances in Chef 11.10 or older stacks, run the Update Dependencies stack command.

Infrastructure as Code

CloudFormation

Model a collection of related AWS and third-party resources, provision them quickly and consistently, and manage them throughout their lifecycles, by treating infrastructure as code.
Template describes your desired resources and their dependencies so you can launch and configure them together as a stack.
Offers extensibility with CloudFormation Registry to provisiong 3rd party resources(e.g. monitoring from partners).
CloudFormation StackSets let you provision a common set of AWS resources across multiple accounts and regions, with a single CloudFormation template.
Supports JSON or YAML.
Automates provisioning and updating your infrastructure in a safe and controlled manner. You can use Rollback Triggers to specify the CloudWatch alarms that CloudFormation should monitor during the stack creation and update process. If any of the alarms are triggered, CloudFormation rolls back the entire stack operation to a previously deployed state.
Using ChangeSets, you can preview the proposed changes that CloudFormation intends to make.
Using Drift Detection, you can keep track of changes to resources outside CloudFormation, making sure you always have the most up-to-date picture of your infrastructure.
Automatically manages dependencies between your resources during stack management actions. You don’t need to worry about specifying the order in which resources are created, updated, or deleted; CloudFormation determines the correct sequence of actions to take for each resource when performing stack operations.
Provides a set of application bootstrapping scripts that enable you to install packages, files, and services.
Can be used with Chef and Puppet, Terraform.
By default, the “automatic rollback on error” feature is enabled.
WaitCondition to wait for your app to start, blocking the creation of other resources.
Intrinsic functions can only be used in specific parts of a template: properties, output, metadata, and update policy.
With the DeletionPolicy attribute you can preserve, and in some cases, backup a resource when its stack is deleted.To keep a resource when its stack is deleted, specify Retain, You can use retain for any resource. For Snapshot, CloudFormation creates a snapshot of the resource before deleting it.
Dynamic references provide a compact, powerful way for you to specify external values that are stored and managed in other services, such as the Systems Manager Parameter Store, in your stack templates. Retrieves the value of the specified reference when necessary during stack and change set operations.
To specify how AWS CloudFormation handles rolling updates for an Auto Scaling group, use the AutoScalingRollingUpdate policy.

AWS CDK

It’s an open-source software development framework for defining cloud infrastructure as code with modern programming languages and deploying it through AWS CloudFormation.
When AWS CDK applications are run, they compile down to fully formed CloudFormation JSON/YAML templates that are then submitted to the CloudFormation service for provisioning.

Website and Web App Development

Elastic Beanstalk

To enable managed platform updates configure the update level and the weekly update period.
Blue/Green: CodePipeline, CodeDeploy to blue, CodeBuild to test the code in blue env, use lambda after testing to swap URLs between blue/green.
Immutable deployments perform an immutable update to launch a full set of new instances running the new version of the application in a separate Auto Scaling group alongside the instances running the old version. Immutable deployments can prevent issues caused by partially completed rolling deployments. If the new instances don’t pass health checks, Elastic Beanstalk terminates them, leaving the original instances untouched.

IoT

IoT Greengrass

Open-source edge runtime and cloud service for building, deploying, and managing device software.
Makes it easy to bring intelligence to edge devices. Collect, aggregate, filter, and send data locally. Manage and control what data goes to the cloud for optimized analytics and storage.

IoT Core

Central point of ingress for IoT data. Securely transmit messages to and from all of your IoT devices and applications with low latency and high throughput.
Connect billions of IoT devices and route trillions of messages to AWS services without managing infrastructure.

IoT Device Management

IoT SiteWise

Collect, organize, and analyze industrial equipment data.

IoT TwinMaker

Create digital twins of real-world systems such as buildings, factories, industrial equipment, and production lines.

Other Services

Amazon CloudSearch

Managed solutions for search functionality of website or app.
Index and search both structured data and plain text.
Different types of searches(boolean, range, full text).

Amazon WorkSpaces

Provision virtual, cloud-based Microsoft Windows or Amazon Linux desktops for your users
Amazon WorkSpaces Application Manager (Amazon WAM) offers a fast, flexible, and secure way for you to deploy and manage applications for Amazon WorkSpaces with Windows. software deployment, updates, patching, and retirement.

Building the DevOps Pipeline - Key Concepts & Stages

Tue, 16 May 2023 00:00:00 GMT

Summary: This piece pins down the stages between a commit and production and what each exists to catch. Every stage is a filter with a purpose, and stages nobody can explain are debt with a green checkmark. Order checks by cost, and treat the pipeline as production code: version it, review it, test it.

Who should read it: engineers building their first serious pipeline, and teams whose existing one grew by accretion.

Read the full article on Spacelift →

How to Create Ansible Template [Examples]

Thu, 06 Apr 2023 00:00:00 GMT

Summary: Config files differ per host, and templates close the gap: one Jinja2 file, variables filled at run time. The template module is copy with a rendering step, and loops and conditionals handle the awkward cases like optional blocks and per-host sections. Validate rendered output where the module supports it, so a bad template fails before it lands.

Who should read it: Ansible users still maintaining one config file per environment, and anyone new to Jinja2.

Read the full article on Spacelift →

How to Build on AWS with CDK for Terraform (CDKTF)

Fri, 03 Mar 2023 00:00:00 GMT

Summary: CDKTF puts a general-purpose language on top of the Terraform ecosystem, synthesizing to Terraform so providers, state and the plan model carry over unchanged. The sweet spot is programmatic generation: many similar resources, conditional structures, code shared with an application team. For simple estates HCL stays easier to read and review, so adopt CDKTF for a reason.

Who should read it: developer-heavy teams considering infrastructure in a real language, and Terraform users curious what CDKTF changes.

Read the full article on Spacelift →

Ansible Vault: How to Securely Encrypt Sensitive Data

Wed, 25 Jan 2023 00:00:00 GMT

Summary: Secrets end up in playbooks, repositories leak, and Vault is the built-in answer. Encrypt at the variable level with encrypt_string where you can, since whole encrypted files hide diffs, and map vault IDs to environments. Vault protects data at rest only, so combine it with no_log to keep values out of run output.

Who should read it: any team with credentials in their Ansible tree, especially ones about to make that tree public.

Read the full article on Spacelift →

Working with Ansible Inventory - Basics and Examples

Thu, 01 Dec 2022 00:00:00 GMT

Summary: Inventory decides what Ansible touches, which makes it the highest-stakes file nobody thinks about. Model environments and tiers as groups, keep variables in group_vars and host_vars next to the hosts they describe, and playbooks stay generic. Dynamic inventory is mandatory once hosts are elastic, since static files cannot chase autoscaling.

Who should read it: Ansible users graduating from a single hosts file, and anyone who has run a playbook against the wrong environment.

Read the full article on Spacelift →

Terraform with GitHub Actions: How to Manage & Scale

Thu, 10 Nov 2022 00:00:00 GMT

Summary: GitHub Actions is the default answer when a team already lives on GitHub and wants Terraform automated this week. The core loop is plan on pull request and apply on merge, with the plan posted to the PR and credentials through OIDC federation. State locking, drift and multi-environment coordination remain your homework.

Who should read it: GitHub-native teams automating Terraform, and anyone comparing DIY pipelines with managed platforms.

Read the full article on Spacelift →

45 Best DevOps Books for Engineers to Read in 2026

Fri, 28 Oct 2022 00:00:00 GMT

Summary: Forty-five titles across DevOps, SRE, architecture, security and programming, organized so you can pick by the gap you want to close. The classics earn their reputation: Accelerate for the evidence, the Phoenix Project for the narrative, the SRE book for operations at scale. Reading one book properly beats owning ten.

Who should read it: engineers building a learning path, and leads assembling a team reading list.

Read the full article on Spacelift →

50+ Ansible Best Practices to Follow [Tips & Tricks]

Mon, 26 Sep 2022 00:00:00 GMT

Summary: Ansible is forgiving, which is how playbook estates turn into archaeology. This is the reference list I still point people at: fifty-plus practices from repository layout to secrets handling, with consistent project structure as the highest-leverage habit. Treat it as a menu, adopt what fits, and write your choices down so reviews have a reference.

Who should read it: every team running Ansible in anger, and new joiners who need the house rules explained.

Read the full article on Spacelift →

Atlantis vs. Terraform Cloud / Terraform Enterprise - Comparison

Tue, 06 Sep 2022 00:00:00 GMT

Summary: Atlantis does PR plan and apply well, and little else: you host it, secure it and extend it. Terraform Cloud adds state management, policy, variables and a UI, with pricing and lock-in to match. The decision is mostly about operational appetite, run a tool or buy a platform.

Who should read it: teams choosing their first Terraform automation layer, and Atlantis operators wondering what they are missing.

Read the full article on Spacelift →

How to Automate Terraform Deployments and Infrastructure

Tue, 30 Aug 2022 00:00:00 GMT

Summary: Laptop applies stop scaling the day a second person touches the code, and the loop worth automating is plan on pull request, review, apply on merge. General CI/CD works but leaves state, credentials and plan review as your problem. Purpose-built platforms trade some control for guardrails and visibility that pipelines lack out of the box.

Who should read it: teams still applying from laptops, and anyone choosing between building and buying their Terraform pipeline.

Read the full article on Spacelift →

Terraform vs. Kubernetes: Key Differences and Comparison

Thu, 18 Aug 2022 00:00:00 GMT

Summary: Terraform provisions infrastructure, Kubernetes orchestrates workloads on top of it, and the interesting part is the boundary between them. The strongest pattern uses Terraform to create clusters and Kubernetes to run what lives inside them. Operators blur that line, so decide deliberately which tool owns what.

Who should read it: engineers sorting out responsibilities in a stack that uses both, and anyone asked this question in an interview.

Read the full article on Spacelift →

Ansible Modules - How To Use Them Efficiently (Examples)

Tue, 26 Jul 2022 00:00:00 GMT

Summary: Modules are the unit of work in Ansible, and fluency with a dozen of them covers most days: copy, template, service, package managers, command and shell. Prefer purpose-built modules over shell whenever one exists, because that is where idempotency comes from. When the ecosystem falls short, custom modules are approachable Python.

Who should read it: Ansible users building their vocabulary, and anyone maintaining playbooks full of shell tasks that deserve better.

Read the full article on Spacelift →

16 DevOps Best Practices Every Developer Should Know

Thu, 23 Jun 2022 00:00:00 GMT

Summary: Best practice lists age badly when they chase tools, so this one stuck to practices: small reversible changes as the core mechanic, IaC and CI/CD as the automation floor, shared ownership and observability around them. The anti-patterns section earns the read on its own: a DevOps team as a silo, tools as culture substitutes, dashboards nobody reads.

Who should read it: developers stepping into operational responsibility, and teams auditing their habits against a checklist.

Read the full article on Spacelift →

AWS IAM Policies: Creating an IAM Policy & Best Practices

Wed, 15 Jun 2022 00:00:00 GMT

Summary: Everything in AWS passes through IAM evaluation, and policy JSON is where security intentions become real. The guide covers how the policy types combine (identity, resource, permissions boundaries, SCPs) and the tooling that catches mistakes before production does. Least privilege is iterative: start narrow, widen from access denied errors, version every change.

Who should read it: anyone writing IAM JSON by hand, and engineers who inherited policies with stars in places stars should not be.

Read the full article on Spacelift →

Ansible Roles: Basics, Creating & Using

Wed, 08 Jun 2022 00:00:00 GMT

Summary: Roles are how Ansible code stops being copy-paste: tasks, variables, templates and handlers packaged into reusable units with a conventional layout. The directory convention is the feature, since anyone who knows roles can navigate yours. Place defaults versus vars deliberately, and share new work through collections.

Who should read it: playbook authors repeating themselves across projects, and teams formalizing shared automation.

Read the full article on Spacelift →

21 Terraform Best Practices to Improve your TF workflow

Fri, 13 May 2022 00:00:00 GMT

Summary: Terraform gives you enough rope to build an estate you regret, and this list collects the habits that keep repositories workable as teams grow. Remote state with locking is table stakes, community modules beat hand-rolling, and version everything you consume. Structure decisions compound: small, composable configurations age better than one repository that does everything.

Who should read it: anyone writing Terraform beyond a sandbox, teams inheriting an estate that grew without rules, and reviewers who want a shared reference to point at instead of arguing style in every pull request.

Read the full article on Spacelift →

Terraform Output Values: Complete Guide & Examples

Thu, 28 Apr 2022 00:00:00 GMT

Summary: Outputs look trivial until they become the interface between your configurations. Treat them as a module’s public API and chain them through remote state reads to keep split configurations decoupled. Mark secrets as sensitive, and remember sensitive only affects display; the value still lives in state.

Who should read it: Terraform users past their first module, and teams splitting a monolithic configuration into pieces.

Read the full article on Spacelift →

Ansible Variables: How to Use Different Types of Ansible Variables

Mon, 11 Apr 2022 00:00:00 GMT

Summary: Variables are where Ansible surprises people, with twenty-plus precedence levels. The guide maps the variable types and where each comes from, turning mysterious overrides into explainable behavior. In practice a handful of precedence levels cover most cases, registered variables turn task output into logic, and group_vars in predictable places beat inline cleverness.

Who should read it: anyone who has spent an afternoon discovering why a variable had the wrong value, which is every Ansible user eventually.

Read the full article on Spacelift →

Ansible Playbooks: Complete Guide with Examples

Mon, 28 Mar 2022 00:00:00 GMT

Summary: Playbooks are where Ansible work actually happens and where most of the sharp edges live. The guide walks variables, Vault, handlers, conditionals and loops with a runnable example for each. Learn variable precedence once, pair Vault with no_log to keep secrets out of console output, and treat shell scripts inside playbooks as a smell.

Who should read it: anyone past the hello-world stage with Ansible who wants their playbooks maintainable by someone other than the author.

Read the full article on Spacelift →

Ansible Tutorial for Beginners: Playbook & Examples

Tue, 22 Feb 2022 00:00:00 GMT

Summary: Ansible is still the tool many teams reach for first when they start automating, and this intro builds a real demo environment with two managed hosts so every command has something to run against. The core concepts fit in one sitting: inventory, modules, ad hoc commands, then playbooks. Build the idempotency habit early; rerunning a playbook should change nothing on an already-correct host.

Who should read it: engineers new to Ansible, and anyone who wants a refresher that comes with a reproducible lab instead of slides.

Read the full article on Spacelift →

Architecting for sustainability on AWS

Sun, 13 Feb 2022 00:00:00 GMT

If you are working with AWS chances are that you are already operating with the AWS Well-Architected Framework in mind. If not, I urge you to read it as it addresses best practices and design patterns around 5 pillars; Operational Excellence, Performance, Security, Reliability, Cost Optimization.

Late in 2021, AWS added a new pillar to the Well-Architected Framework, the Sustainability pillar. In this article, we’ll have a look at this new aspect of the framework, try to understand where exactly it applies and discover some architectural practices that will help us to achieve sustainability for our cloud workloads.

AWS Sustainability Pillar

By introducing Sustainability as its new Pillar of the Well-Architected Framework, AWS shows its commitment to environmental sustainability. For the past years, AWS’s main focus was digital transformation and bringing more and more customers to the cloud.

As times are changing though, AWS commits to clean up and decarbonize its operations and offerings. They reportedly are using more renewable energy to power data centers and building new data centers with low-carbon materials among other initiatives.

As data is core to addressing problems nowadays the same applies to the climate crisis. AWS has two programs that are facilitating the usage of data for this cause.

The Open Data Program allows anyone to host for free any type of useful large dataset and share it with the world and the Amazon Sustainability Data Initiative helps reduce cost, time, and technical barriers associated with large datasets around sustainability.

AWS claims that customers can potentially reduce their energy usage by 80% compared to on-premises workloads and they are targeting to power 100% of AWS operations with renewable energy by 2025.

As with the Shared Responsibility model, environmental sustainability is a shared responsibility between AWS and its customers.

Anyone running workloads on the cloud is also responsible for their footprint but also bears the responsibility to put the continuous effort in optimizing them primarily on energy reduction and efficiency.

In practice, this new pillar is a tool that shows us the path towards a more sustainable future by highlighting best practices, design principles, and patterns but also helps us understand better our workloads and take ownership of their environmental impact.

Our responsibility as customers lies in making informed architectural decisions, selecting the right services and products while having efficiency and sustainability in mind.

Sustainability Design Principles

Follow these principles when designing workloads and applications on AWS to maximize sustainability while minimizing environmental impact.

Understand your impact

The first step is to get a better understanding of your workloads and impact. Try to create a model of your current and future impact and measure it. Gather all sources of impact and measure the resources needed and the emissions required per unit of work. Establish some metrics and KPIs to follow in order to be able to track improvements over time

Establish sustainability goals

Set reachable sustainability goals such as reducing cloud resources and support owners to invest in these goals. Plan and architect your workloads with these goals in mind to achieve reduced impact intensity based on our decisions.

Maximize utilization

Utilize your resources wisely and strive to right-size workloads, use elasticity principles whenever possible and implement efficient designs to maximize the underlying energy used by your workloads. Detect and eliminate underused or idle resources and storage.

Anticipate and adopt new, more efficient hardware and software offerings

Stay informed of new offerings and releases, monitor and evaluate new and more efficient product offerings across the whole cloud ecosystem, and design for flexibility to allow changes whenever necessary.

Use managed services

AWS commits to optimize the resource usage of its managed services so opt for them whenever possible to minimize your impact.

Reduce the downstream impact of your cloud workloads

Work with customers and test your services to understand how they use your products and what is the actual impact of this usage. Reduce the amount of energy required to use your products and services.

Improvement Process for sustainability

Of course, all these improvements can’t be achieved from one day to another. To accomplish these goals you have to continually put effort into your architectural decisions, learn from the process, and repeat the cycle.

Identify targets for improvement

Review all your workloads and figure out areas of improvement, low-utilized resources, and bad practices to define your targets.

Evaluate specific improvements

Evaluate possible changes and the outcomes, risk, and cost that these could bring.

Prioritize and plan improvements

Based on the evaluation prioritize accordingly the changes that offer the largest improvement potential and plan for them.

Test and validate improvements

To test your hypothesis and evaluation implement the changes to development environments first in order to validate them before moving forward.

Deploy changes to production

After you have validated the changes, deploy them to production environments across your workloads.

Measure results and replicate successes

The cycle doesn’t end with the deployment to production but continues by measuring the impact, reverting changes that failed, and trying to replicate successful outcomes to other areas and environments.

Make sustainability a non-functional requirement

A byproduct of sustainability as a non-functional business requirement is that your solutions become more cost-effective and efficient. AWS follows a pay only for what you use model so there is also an extra incentive on utilizing fewer resources and getting more value out of them.

At times, reaching sustainability objectives might require trade-offs in other aspects of the system so experiment continually with sustainability improvements that fit your functional requirements.

Best practices for sustainability in the cloud

Optimize your region selection and workload placement, your software, data, hardware, and other processes to increase energy efficiency. Employ best practices across all these areas and aspects of your cloud usage.

Region selection

Choose AWS Regions near Amazon renewable energy projects and Regions where the grid has a published carbon intensity that is lower than other locations.

User behavior patterns

Understand the way users consume and use your workloads to identify improvement in terms of sustainability. Scale your infrastructure according to usage, negotiate impact-friendly SLAs with your customers, eliminate maintenance of unused assets, optimize geographic placement of resources.

Software and architecture patterns

Use patterns for consistent high-utilization of resources but also revise them often to consolidate under-utilized components over time. Decommission unneeded components and strive to optimize the performance of your applications. Apply sustainable data access and storage patterns and optimize areas of code that consume the most time or resources.

Data patterns

Curate your overall data management practices and governance to reduce the storage and data transfer required for your applications and products. Leverage lifecycle policies to transition data to less performant data when it’s acceptable and remove unused data.

Hardware patterns

Continually look for chances to use more efficient hardware and minimize the number of resources needed for your applications. Try to use the most efficient instance type compatible with your workload(e.g. AWS Graviton processor) and use burstable instances to support workloads with infrequent requirements.

Development and Deployment process

Create a culture of experimentation around sustainability objectives and test them before deploying to production. Keep your systems up-to-date to gain performance efficiencies. Use automation to manage the lifecycle of dev and test environments and shut them down when they aren’t used.

For more details check the official AWS documentation for the Sustainability Pillar.

That’s all folks, hope you enjoyed it as much as I did. We had a look into the new AWS Sustainability Pillar of the AWS Well-Architected Framework and pinpointed different design principles and best practices that we can follow to make informed decisions towards improving the sustainability of our cloud usage.

Continuous Development for Kubernetes with Skaffold

Mon, 17 Jan 2022 00:00:00 GMT

Developing modern applications can be a process that involves many steps. Some of these include writing your code, testing, builds, local deployments, persisting your code in a Git repository, running CI/CD jobs, deploying to an environment.

Skaffold attempts to simplify this workflow for developers by gathering all these processes in one place, allowing them to focus on writing code.

Why Skaffold

Skaffold is an open-source project from Google and has some characteristics that make it attractive for developers.

It’s extremely lightweight, runs everywhere with easy-to-remember skaffold commands, has a lot of features for Kubernetes-native development, and is built with optimized development in mind.

Even more, it enables you to focus on your application development locally while Skaffold continuously deploys to your local or remote Kubernetes cluster.

Detects changes in your source code and handles anything related to build, push, test, and deploy automatically. Can be used effectively as part of your CI/CD process as it provides the building blocks of these pipelines.

Simplicity is considered a core aspect of the project as everything is defined in a single pluggable, declarative configuration for your project, the skaffold.yaml file.

Sounds promising right? Let’s go give it a spin!

Simplify your local development experience with Skaffold

First things first; follow this link to install it according to your environment if you would like to follow along.

To simulate a Kubernetes cluster in order to deploy our demo app I am going to use the Kubernetes mode from Docker Desktop, which provides us a single node cluster.

For the needs of this article, we’ll use a simple go web server as our demo application. You can find all the files used for the demo here.

Our main.go file

package main

import (
	"fmt"
	"log"
	"net/http"
)

func handler(w http.ResponseWriter, req *http.Request) {
	fmt.Fprintf(w, "Testing Skaffold")
}

func main() {
	http.HandleFunc("/", handler)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

Dockerfile

FROM golang:1.15.5

COPY main.go .
RUN go build -o /webserver main.go
CMD ["/webserver"]

Kubernetes simple pod manifest

apiVersion: v1
kind: Pod
metadata:
  name: webserver
  labels:
      name: webserver
spec:
  containers:
  - name: webserver
    image: moustakis/skaffold-demo

and service to expose our web app

apiVersion: v1
kind: Service
metadata:
  name: webserver
spec:
  selector:
    name: webserver
  ports:
  - port: 8080
    targetPort: 8080
  type: LoadBalancer

At this stage, since we have our source code, Dockerfile and k8s manifests we can ask skaffold to generate a simple config for us to get started. Simple run skaffold init at the root of the project directory.

Amazing! skaffold.yaml has been created and our k8s manifests and image name were automatically filled for us.

We are ready to try the continuous development flow of skaffold by running skaffold dev next. During dev mode, Skaffold will watch for source file changes, and when it detects them, will rebuild & push your images, test built images, and redeploy the application to your cluster.

skaffold dev is considered Skaffold’s main mode of operation for development, as it allows us to work continuously while iterating our application.

Without any further modifications to the config file, we expect skaffold to build locally our docker image and deploy it to our local k8s cluster.

Super! We already see from the command output that our image was built successfully and the k8s manifests seem to have been deployed. Let’s verify.

Time to check our web server.

Great success, that was extremely easy. What happens if we modify our source code and hit save?

In our main.go file I will change the message as shown below to test the continuous development process.

The moment we hit save, we notice skaffold picked up the changes and reruns the whole flow. After refreshing the browser and we have the updated message, sweet!

Something to note here is that the behavior of skaffold in these cases is always predictable as the actions have certain precedence over one another.

File sync
Build
Test
Deploy

You might prefer to trigger the flow yourself. In this case, skaffold run is your friend. Skaffold will perform the workflow described in skaffold.yaml exactly once.

For debugging purposes try skaffold debug. This mode configures specific containers for debugging in pods per the container’s runtime technology. Check this page for more information about how the debug mode works.

To get an overview of all possible commands simply type skaffold on your terminal.

For detailed information around all the possible configuration options of skaffold.yaml check this page.

Architecture Design and Pipeline Stages

The chain of actions that Skaffold performs can be shown in this picture:

A great feature of Skaffold is that it’s designed with pluggability and customizability in mind. You can modify the workflow according to your needs, skip stages, pick your favorite tools for each stage.

Check this image for different combinations of tools that you can use for each stage.

That’s all folks, hope you enjoyed this. We explored skaffold, a tool that facilitates continuous development and promises to make our development workflows easier.

Build container images with kaniko in Kubernetes

Wed, 20 Oct 2021 00:00:00 GMT

There are a couple of issues with using Docker to build custom images within a Kubernetes cluster.

First, running Docker in a container requires open communication with the Docker daemon running in Kubernetes nodes and that is considered a bad security practice.

Even more, Kubernetes will completely remove the support for Docker as a container runtime after v1.22. The container runtime of a cluster is responsible for pulling and running our container images.

The problem with using Docker as our container runtime in clusters is that it isn’t compliant with the Cointainer Runtime Interface and wasn’t designed to be embedded in Kubernetes.

This change, fortunately, doesn’t affect the usage of Docker images in our clusters as these images aren’t Docker-specific but OCI Open Container Initiative images. That means that images created with Docker will work with all CRI implementations. All our existing images will still work exactly the same.

But it will affect our ability to build Docker images with the Docker engine as this will no longer be supported in Kubernetes.

kaniko for building container images

kaniko is a tool to build container images from a Dockerfile but is suitable for running inside containers and Kubernetes clusters.

The difference is that Kanino doesn’t depend on the Docker daemon and runs completely in the userspace, so by using it instead, we avoid all the issues mentioned above.

kaniko is meant to be run as an image: gcr.io/kaniko-project/executor. The kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry.

Within the executor image, the filesystem is extracted from the base image (the FROM image in the Dockerfile). Then the commands in the Dockerfile are executed, snapshotting the filesystem in userspace after each one. After each command, a layer of changed files is appended to the base image (if there are any) and image metadata are updated.

Demo

Time get our hands-on and try it. We’ll need a Kubernetes cluster and a dockerhub account. To simulate a Kubernetes cluster I am going to use the Kubernetes mode from Docker Desktop, which provides us a single node cluster.

kaniko is using the concept of a build context in order to represent the directory containing a Dockerfile which kaniko will use to build the final image. For the needs of this short demo, we’ll use this Github repo as our build context. Other possible supported storage solution alternatives include GCS Bucket, S3 Bucket, Azure Blob Storage, Local Directory, Local Tar, Standard Input.

When running kaniko, we are going to use the --context flag with the appropriate prefix to specify the location of our build context.

We also define the --destination flag which defines the destination where we would like to push our newly generated Docker image. In our case that’s dockerhub.

The last thing to configure is a Kubernetes Secret that will hold our dockerhub credentials.


➜  kaniko export REGISTRY_SERVER=https://index.docker.io/v1/
➜  kaniko export REGISTRY_USER=<your_dockerhub_username>
➜  kaniko export REGISTRY_PASS=<your_dockerhub_password>
➜  kaniko export REGISTRY_EMAIL=<your_dockerhub_email>


➜  kaniko kubectl create secret \
    docker-registry dockerhub-registry \
    --docker-server=$REGISTRY_SERVER \
    --docker-username=$REGISTRY_USER \
    --docker-password=$REGISTRY_PASS \
    --docker-email=$REGISTRY_EMAIL
secret/dockerhub-registry created

Alright, we are ready to start building Docker images with kaniko. For this demo we’ll use a simple Kubernetes pod that looks like this:

---

apiVersion: v1
kind: Pod
metadata:
  name: kaniko-builder
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--context=git://github.com//Imoustak/kaniko-build-demo.git",
            "--destination=moustakis/kaniko-build-demo:1.0.0",
            "--dockerfile=dockerfile"]
    volumeMounts:
      - name: kaniko-secret
        mountPath: /kaniko/.docker
  restartPolicy: Never
  volumes:
    - name: kaniko-secret
      secret:
        secretName: dockerhub-registry
        items:
          - key: .dockerconfigjson
            path: config.json

With everything set, let’s go ahead and kickstart the build by spawning this pod in our cluster.

➜  kaniko-build-demo git:(main) kubectl apply -f pod.yaml
pod/kaniko-builder created
➜  kaniko-build-demo git:(main) kubectl logs kaniko-builder -f
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Compressing objects: 100% (7/7), done.
Total 10 (delta 1), reused 7 (delta 1), pack-reused 0
INFO[0001] GET KEYCHAIN
INFO[0001] running on kubernetes ....
E1019 16:02:18.955083       1 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
INFO[0009] Retrieving image manifest ubuntu
INFO[0009] Retrieving image ubuntu from registry index.docker.io
INFO[0009] GET KEYCHAIN
INFO[0012] Built cross stage deps: map[]
INFO[0012] Retrieving image manifest ubuntu
INFO[0012] Returning cached image manifest
INFO[0012] Executing 0 build triggers
INFO[0012] Skipping unpacking as no commands require it.
INFO[0012] ENTRYPOINT ["/bin/bash", "-c", "echo hello"]
INFO[0012] GET KEYCHAIN
INFO[0012] Pushing image to moustakis/kaniko-build-demo:1.0.0
INFO[0017] Pushed image to 1 destinations

As simple as that. Our pod grabbed the dockerfile(and any other needed files) from our GitHub repository(our defined build context), build the image, and pushed the result to dockerhub. Let’s head to dockerhub to validate that.

Sweet! Our newly generated image is pushed successfully there.

Another nice option that we can set is caching layers created by RUN and COPY (configured by flag --cache-copy-layers). Before executing a command, kaniko checks the cache for the layer. If it exists, kaniko will pull and extract the cached layer instead of executing the command. If not, kaniko will execute the command and then push the newly created layer to the cache.

Users can opt into caching by setting the --cache=true flag. A remote repository for storing cached layers can be provided via the –cache-repo flag. If this flag isn’t provided, a cached repo will be inferred from the –destination provided.

Different registries for pushing images are also supported apart from dockerhub like Google GCR, Amazon ECR, JFrog Container Registry, JFrog Artifactory.

In case we need to debug something in the kaniko container, we can use the debugger image gcr.io/kaniko-project/executor:debug which contains a shell.

That’s all folks, hope you enjoyed this. We explored an alternative to Docker, kaniko, for building Docker images without any special privileges or permissions.

AWS Solutions Architect Associate Cheat Sheet

Sun, 25 Jul 2021 00:00:00 GMT

This material was gathered during my preparation for the AWS Solutions Architect Associate Exam. I created and curated this cheatsheet with useful information that will be handy to review before taking the exam.

Gathered all the topics and details that I struggled with and I believe this cheatsheet greatly helped me pass this certification and get my badge.

Note that the most important thing to pass this exam is to get a good overall understanding of the basic AWS services first. Use these notes as complementary material and not complete study material for the exam.

This cheat sheet doesn’t include all the information you will need to pass the exam, easy or obvious topics are skipped. It is rather focused on gathering tricky, hidden & more difficult information and questions.

OK enough with the disclaimers, let’s get to it.

EC2

Dedicated (Instances): No other customers will share the hardware. May share hardware with other instances of ONLY your account.
(Dedicated) Hosts: Book an entire physical server and have full control of EC2 instance placement.
You can only change the tenancy of an instance from dedicated to host, or from host to dedicated after you’ve launched it.
Good EC2 combo -> reserved instances for baseline + on-demand & spot for peaks.

Userdata

Executed as root by default.

Hibernate

Hibernation saves the contents from the instance memory (RAM) to your Amazon EBS root volume. When you start your instance: The Amazon EBS root volume is restored to its previous state The RAM contents are reloaded.

To use hibernation, the root volume must be an encrypted EBS volume.
When the instance state is stopping, you will not be billed if it is preparing to stop however, you will still be billed if it is just preparing to hibernate.

Spot instances

A Spot Instance request is either one-time or persistent. If the spot request is persistent, the request is opened again after your Spot Instance is interrupted.
Spot blocks are Spot Instances with a defined duration & are designed not to be interrupted.
If your Spot Instance request is disabled and has an associated stopped Spot Instance, canceling the request does not terminate the instance.

Placement groups

It is recommended that you launch the number of instances that you need in the placement group in a single launch request and that you use the same instance type for all instances in the placement group. If you try to add more instances to the placement group later, or if you try to launch more than one instance type in the placement group, you increase your chances of getting an insufficient capacity error.
If you receive a capacity error when launching an instance in a placement group that already has running instances, stop and start all of the instances in the placement group, and try the launch again. Restarting the instances may migrate them to hardware that has the capacity for all the requested instances.

Spread

Maximum of 7 running instances per Availability Zone per group.
Recommended for applications that have a small number of critical instances that should be kept separate from each other.
Spread placement groups provide access to distinct racks, and are therefore suitable for mixing instance types or launching instances over time.

Cluster

Higher per-flow throughput limit of up to 10 Gbps for TCP/IP traffic and are placed in the same high-bisection bandwidth segment of the network.

Partition

Spreads your instances across logical partitions such that groups of instances in one partition do not share the underlying hardware with groups of instances in different partitions.
Used by large distributed and replicated workloads.

Autoscaling

Lifecycle hooks enable you to perform custom actions as the Auto Scaling group launches or terminates instances.

Lifecycle hooks put the instance into wait state until the script or timeout period ends.
With launch templates, you can provision capacity across multiple instance types using both On-Demand Instances and Spot Instances.
You can put an instance that is in the InService state into the Standby state, update some software or troubleshoot the instance, and then return the instance to service.
Auto Scaling doesn’t terminate an instance that came into service based on EC2 status checks and ELB health checks until the health check grace period expires.
Cooldown period: It ensures that the Auto Scaling group does not launch or terminate additional EC2 instances before the previous scaling activity takes effect(default 300s).
Amazon EC2 Auto Scaling does not immediately terminate instances with an Impaired status.
By default, Amazon EC2 Auto Scaling doesn’t use the results of ELB health checks to determine an instance’s health status when the group’s health check configuration is set to EC2.
When there are multiple policies in force at the same time, Auto Scaling chooses the policy that provides the largest capacity for both scale-out and scale-in.
The default value for the instance placement tenancy is null and the instance tenancy is controlled by the tenancy attribute of the VPC. If you set the Launch Configuration Tenancy to default and the VPC Tenancy is set to dedicated, then the instances have dedicated tenancy. If you set the Launch Configuration Tenancy to dedicated and the VPC Tenancy is set to default, then again the instances have dedicated tenancy.
If you have an EC2 Auto Scaling group (ASG) with running instances and you choose to delete the ASG, the instances will be terminated and the ASG will be deleted.
Rebalancing AZs launches new instances before terminating the old ones.
Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it. Later, another scaling activity launches a new instance to replace the terminated instance.

S3

S3 standard: There is no minimum storage duration charge and no retrieval fee (use case: if you want to keep data for a few days only)
Object-level permissions: For actions inside the bucket(e.g. GetObject), add /* after arn, -> arn:aws:s3:::test/*
With bucket policies, you can grant users within your AWS Account or other AWS Accounts access to your Amazon S3 resources.
The AWS S3 sync command uses the CopyObject APIs to copy objects between S3 buckets.
By default, S3 replication only supports copying new Amazon S3 objects after it is enabled.
Max upload 5GB per time, for more use multi-part upload. If the object to upload is > 100 MB, you should consider using multipart uploads.
Amazon S3 delivers strong read-after-write consistency automatically.
You can increase your read or write performance by parallelizing reads with prefixes.
Once you version-enable a bucket, it can never return to an unversioned state. Versioning can only be suspended once it has been enabled.
No S3 data transfer charges when data is transferred in from the internet.
Also with S3TA, you pay only for transfers that are accelerated.
Using the Range HTTP header in a GET Object request, you can fetch a byte-range from an object, transferring only the specified portion. A byte-range request is a perfect way to get the beginning of a file.
You can place a retention period on an object version. Different versions of a single object can have different retention modes and periods.
Max object size 5TB.
For replication must enable versioning in source and destination.
By default, an S3 object is owned by the AWS account that uploaded it, even in a bucket in a different account. To get full access to the object, the object owner must explicitly grant the bucket owner access. You can create a bucket policy to require external users to grant bucket-owner-full-control when uploading objects so the bucket owner can have full access to the objects.
Object lock: store objects as locked(only on versioned buckets).
Metadata, which can be included with the object, is not encrypted while being stored on Amazon S3. Therefore, AWS recommends that customers not place sensitive information in Amazon S3 metadata.
S3 event notification allows destinations: SQS standard, Lambda, SNS.
Allowed names for S3 website endpoints: http://bucket-name.s3-website.Region.amazonaws.com & http://bucket-name.s3-website-Region.amazonaws.com
S3 Select scan a subset of an object by specifying a range of bytes to query based on the bucket’s name and the object’s key.
With S3 Select, you can use simple structured query language (SQL) statements to filter the contents of an Amazon S3 object and retrieve just the subset of data that you need. CSV, JSON, or Apache Parquet format.
S3 can publish notifications for the following events: New object-created events, Object removal events, Restore object events, Reduced Redundancy Storage (RRS) object lost events, Replication events.
To encrypt an object at the time of upload, you need to add a header called x-amz-server-side-encryption. To enforce object encryption, create an S3 bucket policy that denies any S3 Put request that does not include the x-amz-server-side-encryption header.
To enable S3 website: a) An S3 bucket that is configured to host a static website. The bucket must have the same name as your domain or subdomain b) a registered domain name c) Route 53 as the DNS service for the domain.
S3 server access logs provide detailed records for the requests that are made to an S3 bucket.
3,500 requests per second to add data and 5,500 requests per second to retrieve data.
You can have an S3 bucket that has different objects stored in S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, and S3 One Zone-IA.

S3 IA

S3 One Zone-IA is for data that is accessed less frequently but requires rapid access when needed.
The minimum storage duration is 30 days before you can transition objects from S3 Standard to S3 Standard IA or One Zone-IA.(This limitation does not apply to Intelligent Tiering, Glacier, and Glacier Deep Archive)

S3 Lifecycle Transitions

Supported lifecycle transitions - waterfall model:

The S3 Standard storage class to any other storage class.
Any storage class to the S3 Glacier or S3 Glacier Deep Archive storage classes.
The S3 Standard-IA storage class to the S3 Intelligent-Tiering or S3 One Zone-IA storage classes.
The S3 Intelligent-Tiering storage class to the S3 One Zone-IA storage class.
The S3 Glacier storage class to the S3 Glacier Deep Archive storage class.

Encrypted objects remain encrypted throughout the storage class transition process.

Glacier

Glacier supports encryption by default for both data at rest as well as in-transit.
The minimal storage duration period is 90 days for the S3 Glacier storage class and 180 days for S3 Glacier Deep Archive.
Data can be stored directly in Amazon S3 Glacier Deep Archive.

Snowball

Snowball Edge storage optimised: 80TB 40 vCPUs, 1 TB of SATA SSD storage, and up to 40 Gb network connectivity.
You can’t directly copy data from Snowball Edge devices into AWS Glacier.
For data < 10PB or distributed in multiple locations.
Snowball Edge compute optimised(52 vCPUs, 42 TB of usable block or object storage, and an optional GPU).
Snowball Edge possibility for storage clustering.
AWS OpsHub is a graphical user interface you can use to manage your AWS Snowball devices.

Snowmobile

Each Snowmobile has a total capacity of up to 100 petabytes.
For data > 10PB in a single location.

IAM

Permissions Boundary to limit max access of users. They can only be applied to roles or users, not IAM groups.

IAM Policy Evaluation Logic: if there is an explicit deny, the final decision is deny for the resource.
When you assume a role, you give up your original permissions and take the permissions of the assigned role.
When using a resource-based policy the principal doesn’t have to give up his permissions.
In a policy condition: aws:RequestedRegion represents the target of the API call.
You can share an AMI with another account.
Trust Policy: only IAM resource-based policy.
If you got your certificate from a third-party CA, import the certificate into ACM or upload it to the IAM certificate store.
With web identity federation, you don’t need to create custom sign-in code or manage your own user identities. Instead, users of your app can sign in using a well-known external identity provider (IdP), such as Login with Amazon, Facebook, Google, or any other OpenID Connect (OIDC)-compatible IdP.

Security Token Service(STS)

Temporary security credentials that can control access to your AWS resources.

AWS Organizations

It does not offer federation capability.
To migrate an account to another Organization: remove member account, send an invite to new Org, Accept the invite to the new Org from the member account.
SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines.
SCPs affect all users and roles in the attached accounts, including the root user.
SCPs do not affect any service-linked role.

VPC

VPN connection: Virtual Private Gateway endpoint on the AWS VPC side - Customer Gateway on the on-premises side.
You can’t have a VPC with only a public subnet and AWS Site-to-Site VPN.
Private IPs allowed ranges: 10.0.0.0/8 (10.0.0.0 - 10.255.255.255), 172.16.0.0/12 (172.16.0.0 - 172.31.255.255), 192.168.0.0/16(192.168.0.0 - 192.168.255.255)
AWS reserves 5 Ip addresses in each subnet.
Shared services VPC, which provides access to services required by workloads in each of the VPCs. This might include directory services or VPC endpoints. Sharing resources from a central location instead of building them in each VPC may reduce administrative overhead and cost.
Use AZ ID to uniquely identify the Availability Zones across the two AWS Accounts.
By default, non-default subnets have the IPv4 public addressing(assign public IP) attribute set to false, and default subnets have this attribute set to true.
You cannot disable IPv4 support for your VPC and subnets since this is the default IP addressing system for Amazon VPC and Amazon EC2.
Every subnet that you create is automatically associated with the main route table for the VPC.
Allowed block size in VPC is between a /16 netmask (65,536 IP addresses) and /28 netmask.
While primary ENIs cannot be detached from an instance, secondary ENIs can be detached and attached to a different instance.

Security Groups

If nothing is defined in a security group then all access is blocked.

NACL

NACLs are stateless so outbound rules have to be evaluated again.
Defined at Subnet level.
Should allow outbound traffic from ephemeral ports.
NACL rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it’s applied immediately regardless of any higher-numbered rule that may contradict it.

Cloudhub

Multiple AWS Site-to-Site VPN connections, you can provide secure communication between sites using the AWS VPN CloudHub including Direct Connect connections.
Supports IP Multicast.
Low-cost primary or secondary network connectivity between locations, only for VPNs.

Direct Connect

Maximum resilience is achieved by separate connections terminating on separate devices in more than one location.

Dedicated connection 1-10 Gbps.
Hosted connection 50Mbps -10Gbps, add or remove capacity on demand.
Data in transit not encrypted, but private.

Transit Gateway

Network transit hub that you can use to interconnect your virtual private clouds (VPC) and on-premises networks.
AWS Transit Gateway also enables you to scale the IPsec VPN throughput with equal-cost multi-path (ECMP) routing support over multiple VPN tunnels.

NAT Instance

Can be used as a bastion, supports security groups, supports port-forwarding, must disable ec2 flag source/destination check.

Nat Gateway

Only for IPv4.
Set up in a public subnet.
In a specific AZ and can only be used by instances in other subnets.

Egress-only Internet Gateway:

nat for ipv6.

Route53

Routing policy multi-value supports up to 8 healthy records for each multi-value query.
To integrate an external domain to route53, update the nameservers on the 3rd party registrar with your public hosted zone.
To resolve any DNS queries for resources in the AWS VPC from the on-premises network, you can create an inbound endpoint on Route 53 Resolver, and then DNS resolvers on the on-premises network can forward DNS queries to Route 53 Resolver via this endpoint.
To resolve DNS queries for any resources in the on-premises network from the AWS VPC, you can create an outbound endpoint on Route 53 Resolver, and then Route 53 Resolver can conditionally forward queries to resolvers on the on-premises network via this endpoint.
Cannot create a CNAME record for the top node of the DNS namespace. So, if you register the DNS name mpla.com the zone apex is mpla.com You can’t create a CNAME record for mpla.com but you can create an alias record for mpla.com that routes traffic to www.mpla.com.
Route 53 doesn't charge for alias queries to AWS resources but Route 53 does charge for CNAME queries.
For each VPC that you want to associate with the Route 53 hosted zone, change the following VPC settings to true: enableDnsHostnames, enableDnsSupport.
You configure active-active failover using any routing policy (or combination of routing policies) other than failover, and you configure active-passive failover using the failover routing policy.
Active-Active Failover when you want all of your resources to be available the majority of the time.
Active-Passive Failover when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable.

EBS

By default, the root volume for an AMI backed by Amazon EBS is deleted when the instance terminates.
For an encrypted EBS volume data stored at rest on the volume, data moving between the volume and the instance, snapshots created from the volume, and volumes created from those snapshots are all encrypted.
GP2: system boot volumes, 1GB - 16TB, max IOPS 16,000, if you add 1TB you get +3000IOPS, for low latency interactive apps.
io1/io2: 4GB-16TB, max 64,000 IOPS, 50:1 IOPS:GB ratio.
io2 Block Express volumes, Provisioned IOPS (PIOPS) up to 256,000, with an IOPS:GiB ratio of 1,000:1, for submillisecond latency for > 64,000 IOPS or 1000 MB/s throughput.
Throughput optimised HDD(st1): max throughput 500 MB/s - max 500 IOPS, Big data, log processing, data warehouses.
Cold HDD(scl): max throughput 250 MB/s - max 250 IOPS, throughput-oriented storage that is infrequently accessed, low storage cost scenarios.
Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances with Nitro system that are in the same Availability Zone
Throughput Optimized HDD (st1) and Cold HDD (sc1) volume types cannot be used for boot volumes.

Locked to AZ, to attach to other AZ you have to snapshot it.
Copying an unencrypted snapshot allows encryption.
When copying an AMI to another region, automatically creates the underlying EBS snapshot also in the new region.
RAID 0 to increase performance.
RAID 1 to increase fault tolerance.
If the instance is already running, you can set DeleteOnTermination to False using the command line for the root EBS volume.
An in-progress snapshot is not affected by ongoing reads and writes to the volume hence, you can still use the EBS volume normally.
Enforce the encryption of the new EBS volumes and snapshot copies that you create with Encryption by Default feature(no effect on existing EBS volumes or snapshots). If you enable it for a Region, you cannot disable it for individual volumes or snapshots in that Region.
When you enable encryption by default, you can launch an instance only if the instance type supports EBS encryption.
Amazon EBS does not support asymmetric CMKs.

Instance Store

Temporary block-level storage for your instance.
Ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances, such as a load-balanced pool of web servers

For high I/O performance, instance store volumes are a better option.
You cant resize the instance store.

EFS

Control which EC2 instances can access your EFS file system with security group rules and IAM policies.
1000s on concurrent NFS clients, 10Gbs throughput.
Use EFS Access Points to manage application access.
Max I/O performance mode is used to scale to higher levels of aggregate throughput and operations per second - tradeoff of slightly higher latencies.
General Purpose performance mode is ideal for latency-sensitive use cases.
POSIX compliant.
Provisioned Throughput mode: for applications with high throughput to storage (MiB/s per TiB) ratios, or with requirements greater than those allowed by the Bursting Throughput mode.
Bursting Throughput mode: designed to burst to high throughput levels for periods of time.
Higher price point than EBS.
Maximum days for the EFS lifecycle policy is 90.

Amazon FSx for Lustre:

Run the world’s most popular high-performance file system.
For machine learning, high-performance computing (HPC), video processing, and financial modeling.
Ability to both process the ‘hot data’ in a parallel and distributed fashion as well as easily store the ‘cold data’ on Amazon S3.

RDS

Multi A-Z synchronous replication across AZs. Replication between the primary and standby instances does not incur additional data transfer charges.
Read replicas asynchronous replication across AZs or cross-region, up to 5.

Backups every 5min, ability to restore at any point in time.
Supports storage autoscaling.
IAM database authentication works with MySQL and PostgreSQL. Use an authentication token with a lifetime of 15 minutes.
RDS provides metrics in real-time for the operating system (OS) that your DB instance runs on with Enhanced Monitoring(RDS processes, RDS child processes, OS processes).
To encrypt unencrypted RDS database: create a snapshot of your DB instance, and then create an encrypted copy of that snapshot, restore DB from encrypted snapshot, terminate previous DB.
Upgrades to the database engine level require downtime. Even if your RDS DB instance uses a Multi-AZ deployment, both the primary and standby DB instances are upgraded at the same time. This causes downtime until the upgrade is complete, and the duration of the downtime varies based on the size of your DB instance.
RDS applies OS updates by performing maintenance on the standby, then promoting the standby to primary, and finally performing maintenance on the old primary, which becomes the new standby.
Maximum backup retention period for automated backup is 35 days.

Aurora

Auto-scales up to 128 TB per database instance.
Aurora cluster: one Primary DB instance - up to 15 replicas(read-only).

You can specify the failover priority for Aurora Replicas, each Read Replica is associated with a priority tier (0-15). Aurora will promote the Read Replica that has the highest priority (the lowest numbered tier). If two or more Aurora Replicas share the same priority, then Amazon RDS promotes the replica that is the largest in size.
Aurora Global Database is designed for globally distributed applications, allowing a single Amazon Aurora database to span multiple AWS regions, sub-second data access in any region.
Storage automatically grows in increments of 10GB.
In a multi-master cluster, all DB instances can perform write operations(scale writes, avoid downtime for writes) - continuous availability for applications where you can’t afford even brief downtime for database write operations.
Using endpoints, you can map each connection to the appropriate instance or group of instances based on your use case. For clusters with DB instances of different capacities or configurations, you can connect to custom endpoints associated with different subsets of DB instances.
Reader endpoint automatically performs load-balancing among all the Aurora Replicas.
For diagnosis or tuning, you can connect to a specific instance endpoint to examine details about a specific DB instance.
If you are running Aurora Serverless and the DB instance or AZ becomes unavailable, Aurora will automatically recreate the DB instance in a different AZ.
If you have a single instance, Aurora will attempt to create a new DB Instance in the same Availability Zone as the original instance. This replacement of the original instance is done on a best-effort basis and may not succeed.

DynamoDB

DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for Amazon DynamoDB that delivers up to a 10 times performance improvement—from milliseconds to microseconds.
Tables must have provisioned read and write capacity units RCU, WRC.
DynamoDB Streams allow changes in DynamoDB to be streamed to other services(read by Lambda etc, 24h retention on streams).
Global Tables support multi-region replication, low latency, disaster recovery. Must first enable Streams.
Can only query on primary key, sort key, or indexes.
All DynamoDB tables are encrypted. There is no option to enable or disable encryption for new or existing tables. By default, all DynamoDB tables are encrypted under an AWS owned customer master key (CMK), which do not write to CloudTrail logs.
If the shard iterator expires immediately before you can use it, this might indicate that the DynamoDB table used by Kinesis does not have enough capacity to store the lease data. To solve increase the write capacity assigned to the shard table.

Elasticache

For sub-millisecond latency caching, ElastiCache is the best choice.

Memcached

Supports multithreaded architecture.

Redis

Redis HIPAA compliant, supports replication, high availability, and cluster sharding.
In-memory data store that provides sub-millisecond latency.
IAM Auth is not supported by ElastiCache.
Redis AUTH(enable Redis to require a token (password) before allowing clients to execute commands, thereby improving data security).

Redshift

With Spectrum, you can efficiently query and retrieve structured and semistructured data from files in Amazon S3 without having to load the data into Amazon Redshift tables.

For OLAP: online analytical processing.
Redshift enhanced VPC routing, copy/unload goes through VPC.
Possibility to copy snapshots for a cluster to another region for DR.

Cloudwatch

Metrics belong to namespaces, Dimension is an attribute of a metric, Up to 10 dimensions per metric.
Automatically recover ec2: If your instance has a public IPv4 address, it retains the public IPv4 address after recovery. During instance recovery, the instance is migrated during an instance reboot, and any data that is in-memory is lost.
You can use CloudWatch Events to run Amazon ECS tasks when certain AWS events occur.

EventBridge

Recommended when you want to build an application that reacts to events from SaaS applications and/or AWS services. Only event-based service that integrates directly with third-party SaaS partners.

Encryption/Secrets

Key Policies: control access to keys, you cannot control access without them.
Automatic key rotation: CMK every one year.
SSE-KMS is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. When you use server-side encryption with AWS KMS (SSE-KMS), you can specify a customer-managed CMK that you have already created. SSE-KMS provides you with an audit trail that shows when your CMK was used and by whom.
Deleting a customer master key (CMK) has enforced a waiting period, you schedule key deletion(minimum of 7 days up to a maximum of 30 days(default))
SSE-C - With Server-Side Encryption with Customer-Provided Keys (SSE-C), you manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks and decryption when you access your objects.
SSE-S3 - When you use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), each object is encrypted with a unique key. Uses 256-bit Advanced Encryption Standard (AES-256).
Client-side encryption when there is a proprietary encryption algorithm.

Secrets Manager

Nice RDS integration.
Force secret rotation every X days.

SSM Parameter Store

Allow assigning TTL to a parameter(expiration date) to force update/delete of sensitive data.

CloudHSM

Dedicated hardware, you manage your own encryption keys.
Good option to use with SSE-C.
It is possible to lose keys that were created since the most recent daily backup if the CloudHSM cluster that you are using fails and you are not using two or more HSMs.

Kinesis

Kinesis Data Streams

Default data retention 1 day, can go up to 7.
1MB/sec/shard ingest capacity.
By default, the 2MB/second/shard output is shared between all of the applications consuming data from the stream.
Use enhanced fan-out if you have multiple consumers retrieving data from a stream in parallel, automatically scales throughput with the number of shards.
Ability for multiple apps to consume the same stream concurrently.
Ability to consume records in the same order a few hours later.
Routing related records to the same record processor. For example, counting and aggregation are simpler when all records for a given key are routed to the same record processor.

Kinesis Firehose

Automatically scales to match the throughput of your data and requires no ongoing administration. Auto-scaling solution, as there is no need to provision any shards like Kinesis Data Streams.
Kinesis Agent cannot write to a Kinesis Firehose for which the delivery stream source is already set as Kinesis Data Streams.
Data into Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, generic HTTP endpoints and Datadog, New Relic, MongoDB, Splunk.
Load streaming data into Redshift for near real-time analytics.

SQS

When you need messaging semantics(ack/fail) and visibility timeout(default 30s).
Dynamically increasing concurrency/throughput at read time.
FIFO queues support up to 3,000 messages(batch 10 messages per operation- max) per second with batching(300 without), have an 80-character queue name limit.
Message retention 4 days default, 14 days max.
Limit 256kb per message sent.
To scale to same number of consumers as producers, send data with a Group ID attribute.
Delay queues let you postpone the delivery of new messages to a queue for several seconds. The default (minimum) delay for a queue is 0 seconds. The maximum is 15 minutes.
You can use message timers to set an initial invisibility period for a message added to a queue. Default delay for a message is 0 seconds. The maximum is 15 minutes.
Temporary queues help you save development time and deployment costs when using common message patterns such as request-response. To better support short-lived, lightweight messaging destinations, AWS recommends Amazon SQS Temporary Queue Client. The key concept behind the client is the Virtual Queue. Virtual queues let you multiplex many low-traffic queues onto a single SQS queue.

AWS recommends using separate queues to provide prioritization of work.
A single SQS message queue can contain an unlimited number of messages. However, there is a 120,000 quota for the number of inflight messages for a standard queue and 20,000 for a FIFO queue. Messages are inflight after they have been received from the queue by a consuming component, but have not yet been deleted from the queue.
Standard queues provide at-least-once delivery, which means that each message is delivered at least once.
FIFO queues provide exactly once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.
An Amazon SQS message can contain up to 10 metadata attributes.
By default, ReceiveMessageWaitTimeSeconds is zero which means it is using Short polling. If it is set to a value greater than zero, then it is Long polling.

SNS

Event producers send events to 1 topic, we can have many subs.
100000 topics limit
Use SNS message filtering to assign a filter policy to the topic subscription, and the subscriber will only receive a message that they are interested in.
SNS FIFO for strict message ordering and deduplicated message delivery to one or more subscribers

LoadBalancers

LBs can scale but not instantaneously.
Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300s(can be set between 1s to 3600s) seconds before completing the deregistration process, which can help in-flight requests to the target to complete(connection drain).
When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones evenly.

By default, cross-zone load balancing is enabled for Application Load Balancer and disabled for Network Load Balancer
ELB cannot distribute incoming traffic for targets deployed in different regions.
Access logging is an optional feature of Elastic Load Balancing that is disabled by default. Use to analyze traffic patterns and troubleshoot issues.

Application LoadBalancer

ALB targets with instance ID route to primary private IP in primary NIC, targets using IP addresses route to any private IP from one or more NICs.
Host-based Routing: You can route a client request based on the Host field of the HTTP header allowing you to route to multiple domains from the same load balancer.
Path-based Routing: You can route a client request based on the URL path of the HTTP header.
HTTP header-based routing: You can route a client request based on the value of any standard or custom HTTP header.
HTTP method-based routing: You can route a client request based on any standard or custom HTTP method.
Query string parameter-based routing: You can route a client request based on the query string or query parameters.
Source IP address CIDR-based routing: You can route a client request based on source IP address CIDR from where the request originates.
ALB not registered any targets with the target groups -> 503 error.
Use Cognito Authentication via Cognito User Pools for your ALB.
With SNI support AWS makes it easy to use more than one certificate with the same ALB.
You can host multiple TLS secured applications, each with its own TLS certificate, behind a single ALB. In order to use SNI, all you need to do is bind multiple certificates to the same secure listener on your load balancer. ALB will automatically choose the optimal TLS certificate for each client.
ALBs support Weighted Target Groups routing.

Network LoadBalancer

NLB traffic is routed using the private IP address.
Network LB has no security groups, lets traffic passing by.
With Network Load Balancer (NLB), you can offload the decryption/encryption of TLS traffic from your application servers to the NLB.

Classic LoadBalancer

CLB does not support Server Name Indication (SNI).

Lambda

Supports 1000 concurrent executions per AWS account per region, contact support to raise the limit if needed.
Supported languages: C#/.NET, GO, node.js, Python, Java, Ruby.
lamda@edge: deploy lambda to each region alongside your CloudFront CDN.
You can set your memory from 128MB to 10,240MB
If your Lambda function accesses a VPC, you must make sure that your VPC has sufficient ENI or subnect IPs capacity to support the scale requirements of your Lambda function.

Step Functions

Serverless workflows orchestration.

Cloudfront

Delivering data out of CloudFront can be more cost-effective than delivering it from S3 directly to your users.
Use CloudFront to improve application performance to serve static content from S3.
Dynamic content does not flow through regional edge caches, but goes directly to the origin - Proxy methods PUT/POST/PATCH/OPTIONS/DELETE go directly to the origin.
Preferred to handle spikes in traffic over GA.
You cannot directly integrate Cognito User Pools with CloudFront distribution as you have to create a separate Lambda@Edge function to accomplish the authentication via Cognito User Pools.
CloudFront can route to multiple origins based on the content type.
Field-level encryption: The sensitive information provided by your users is encrypted at the edge (You can’t encrypt all of the data in a request with field-level encryption; you must specify individual fields to encrypt).
CloudFront signed cookies -> provide access to multiple restricted files.
CloudFront signed URLs -> access to one file.
Can also use an EC2 instance or a custom origin in configuring CloudFront.
The Cache-Control and Expires headers control how long objects stay in the cache. The Cache-Control max-age directive lets you specify how long (in seconds) you want an object to remain in the cache before CloudFront gets the object again from the origin server. The minimum expiration time CloudFront supports is 0 seconds for web distributions and 3600 seconds for RTMP distributions.

Global Accelerator(GA)

Directs traffic to optimal endpoints over the AWS global network.
Improves the availability and performance of your internet applications.
Two static anycast IP addresses that act as a fixed entry point to your application endpoints.

Good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP.
Uses endpoint weights to determine the proportion of traffic that is directed to endpoints in an endpoint group(can be used in blue/green deployments).

WAF

Use AWS WAF to block or allow requests based on conditions that you specify, such as the IP addresses.
Geographic (Geo) Match Conditions in AWS WAF to restrict application access based on the geographic location of your viewers - choose the countries from which AWS WAF should allow access.
Protects against SQL injection and Cross-Site Scripting.
Rate based rules(DDoS protection).

Firewall Manager

Centrally configure and manage firewall rules across your accounts and applications in AWS Organizations.
You can centrally configure AWS WAF rules, AWS Shield Advanced protection, Amazon Virtual Private Cloud (VPC) security groups, AWS Network Firewalls, and Amazon Route 53 Resolver DNS Firewall rules across accounts and resources in your organization. It does not support Network ACLs as of today.

AWS Shield

DDoS, protection against SYN/UDP floods, reflection attacks, and other layer/3 & layer 4 attacks.

EMR

Cloud big data platform for processing vast amounts of data using Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi, and Presto, Hadoop.

Beanstalk

Easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker.
Automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring.
You retain full control over the AWS resources powering your application and can access the underlying resources at any time.
Application files are stored in S3. The server log files can also optionally be stored in S3 or in CloudWatch Logs.

CloudFormation

StackSet extends the functionality of stacks by enabling you to create, update, or delete stacks across multiple accounts and regions with a single operation.
Use the CreationPolicy attribute when you want to wait on resource configuration actions before stack creation proceeds.

Cognito

User pools

Provide built-in user management e.g. sign-in and register functionality for apps.

Identity pools

Provide temporary credentials for AWS access to users.

AWS Database Migration Service

Seamlessly migrate data from supported sources to relational databases, data warehouses, streaming platforms, and other data stores in AWS cloud. (e.g. quickly move data from S3 to Kinesis data streams, not only for DBs).

Storage Gateway

File Gateway

SMB or NFS access to data in S3 with local caching.

Volume Gateway

Present cloud-based iSCSI block storage volumes to your on-premises applications.

Tape Gateway

Supports archiving directly to Glacier and Glacier Deep Archive.

DataSync

Move large data from on-premise to AWS.
Can move data directly to Glacier or Glacier Deep Archive.

AppSync

Store and sync data across mobile and web apps in real-time.

CloudTrail

By default, CloudTrail event log files are encrypted using Amazon S3 server-side encryption (SSE).

Xray

AWS X-Ray helps developers analyze and debug production, distributed applications, such as those built using a microservices architecture.
End-to-end view of requests as they travel through your application, and shows a map of your application’s underlying components.
The X-Ray agent can assume a role to publish data into an account different from the one in which it is running.

GuardDuty

Threat detection that enables you to continuously monitor and protect your AWS accounts, workloads, and data stored in Amazon S3.
Analyses AWS CloudTrail Events, Amazon VPC Flow Logs, and DNS Logs.
Disabling the service in the general settings deletes all the remaining data.

Macie

Discover and protect your sensitive data on Amazon S3.

Inspector

Helps you check for unintended network accessibility of your Amazon EC2 instances and for vulnerabilities on those EC2 instances.

Recognition

Automate your image and video analysis with machine learning.

VPC Endpoints

When you create a VPC endpoint, you can attach an endpoint policy that controls access to the service to which you are connecting.

Gateway Endpoints

GE is a gateway that you specify as a target for a route in your route table for traffic destined to a supported AWS service.
S3 & DynamoDB only.

Interface Endpoints

An elastic network interface with a private IP address from the IP address range of your subnet that serves as an entry point for traffic destined to a supported service.

Elastic Network Adapter(ENA)

Enhanced networking capabilities with network speeds of up to 100 Gbps.
Supports Windows.

Elastic Fabric Adapter (EFA)

Network device that you can attach to your Amazon EC2 instance to accelerate High-Performance Computing (HPC) and machine learning applications.
ENA with added capabilities.
Doesn’t support Windows.
EFA support can be enabled either at the launch of the instance or added to a stopped instance. EFA devices cannot be attached to a running instance.

API Gateway

Rest APIs - stateless client-server communication.
Websocket APIs - statefull full-duplex communication.
All of the APIs created with Amazon API Gateway expose HTTPS endpoints only

SWF Simple Workflow Service

Use if you need: external signals to intervene, or child processes to return values to parent processes.
For decoupled architectures.
Provides useful guarantees around task assignments. It ensures that a task is never duplicated and is assigned only once.

AWS Backup

Centralized backup service.
A backup plan is a policy expression that defines when and how you want to back up your AWS resources.

AWS Batch

Multi-node parallel jobs.

AWS ParallelCluster

Cluster management tool to deploy HPC, automate creation of vpc, subnet, cluster type etc.

AD Connector

If you only need to allow your on-premises users to log in to AWS applications and services with their Active Directory credentials.

AWS Managed Microsoft AD

Configure a trust relationship between AWS Managed Microsoft AD in the AWS Cloud and your existing on-premises Microsoft Active Directory, providing users and groups with access to resources in either domain, using single sign-on (SSO).

Data Transfer

No charge for inbound data transfer across all services in all Regions.
Data transfer from AWS to the internet is charged per service, with rates specific to the originating Region.
There is a charge for data transfer across Regions.
Data transfer within the same Availability Zone is free.
Data transfer over a VPC peering connection that stays within an Availability Zone is free. Data transfer over a VPC peering connection that crosses Availability Zones will incur a data transfer charge for ingress/egress traffic. If the VPCs are peered across Regions, standard inter-Region data transfer charges will apply.
Data processing charges apply for each GB sent from a VPC, Direct Connect, or VPN to Transit Gateway.
Direct Connect & VPN also incur charges for data flowing out of AWS.

Important ports:

FTP: 21
SSH: 22
SFTP: 22 (same as SSH)
HTTP: 80
HTTPS: 443
RDP: TCP 3389 and UDP 3389

RDS Databases ports:

PostgreSQL: 5432
MySQL: 3306
Oracle RDS: 1521
MSSQL Server: 1433
MariaDB: 3306 (same as MySQL)
Aurora: 5432 (if PostgreSQL compatible) or 3306 (if MySQL compatible)

Disaster Recovery in AWS

RPO: Recovery Point Objective -> how much data loss we are willing to recover
RTO: Recovery Time Objective -> downtime between disaster and RTO

Exploring AWS Serverless Architectures

Sun, 21 Mar 2021 00:00:00 GMT

This article contains several patterns and common architectural choices for building software solutions leveraging mostly AWS serverless services.

Why Serverless

Serverless services help us abstract our computing infrastructure so that we can focus solely on business logic.

Even more, When our app is not running we don’t pay for idle server time, but only for what we use. Serverless services scale horizontally & auto-magically and we don’t have to guess our capacity needs upfront.

We can deploy to production quickly, benefiting from zero infrastructure provisioning & maintenance that these services offer.

These services have built-in fault tolerance and support feature deployments without downtime.

Transition to Serverless

In order to enjoy all these benefits, we should try to transition from traditional monolith to microservices with event-driven architectures. This isn’t always an easy transition and requires some changes in how we approach our applications and infrastructure.

We need to start thinking about how we can start decoupling the different services from our monolith and separate responsibilities and roles between them. In the process of “thinking” Serverless, we have to understand tradeoffs for our design choices and use common patterns for event-Driven Architectures & microservices.

Serverless apps use technology-agnostic APIs with decoupled communication. Code is executed in response to events where state and code are decoupled. Integration between components is done via messaging to create asynchronous communication flows.

From monolith to microservices, use the concepts of Domain-driven design to untangle highly coupled applications. The main idea is that we establish a bounded context for each microservice and agree on boundaries between teams & responsibilities.

This way each component can scale independently. Furthermore, your schedule-based tasks could be transformed easily to Lambda functions that run on a schedule for example.

Example Serverless Architectures

Let’s take a look at how we can leverage and combine different AWS Services to build Serverless Architectures.

In the above example for a RESTful microservice, the order of information starts with an API call over HTTP. Amazon API Gateway handles the requests and responses accordingly and triggers Lambda that executes the business logic and stores the result in DynamoDB.

In order to decouple the synchronous connection between Amazon Gateway and Lambda Function, we could use a message queue, SQS.

That has multiple advantages like leveraging built-in retry mechanisms if something fails, the abstraction of Lambda running time, taking care of messages that can’t be processed at the moment, the possibility to add an extra Dead-Letter Queue for messages that fail continuously.

In cases that we have to chain multiple Lambda Functions together we can use Step Functions to orchestrate Lambda workflows and make our life easier since we keep orchestration out of our code, Lambdas are triggered automatically and the state and logs of each step are kept.

This way the Lambda functions are focused only on business logic and Step Functions control the sequence and timing of each task and the state of the whole workflow.

For situations where we need to provide updates to a client regarding the status of a job, we could use a service like AWS AppSync to listen for updates using for example WebSockets with GraphQL subscriptions.

AWS AppSync is a fully managed service that makes it easy to develop GraphQL APIs by handling the heavy lifting of securely connecting to data sources like AWS DynamoDB, Lambda, and more.

With AWS AppSync, clients can automatically subscribe and receive status updates as they occur. This is a great pattern when data drives the user interface and is ideal for data that is streaming or may yield more than a single response.

For serverless data processing, we can leverage Amazon Kineses streaming services to ingest and process large volumes of data in near real-time.

For example, we could use Amazon Kinesis Data Firehose to send data and automatically deliver them to the destination that we specify, for example S3.

We could also configure Amazon Kinesis Data Firehose to perform data transformation via specified Lambda Functions as the records are processed, to streamline our architecture. Finally, we could use a tool like Amazon Athena to perform analysis on our stored data.

A similar architecture for a data pipeline could use Kinesis Data streams to get big data in real-time and leverage Kinesis Data Firehose to offload our data in an Amazon ingestion S3 bucket.

The S3 events in our ingestion bucket could be used to send messages to an SQS queue that triggers a Lambda. This Lambda triggers Amazon Athena to query the ingestion S3 bucket and stores the results in a reporting S3 bucket.

Finally, we could use Amazon QuickSight to visualize our data from the reporting S3 bucket

Similar to the pattern we saw earlier (API Gateway, Lambda, SQS, DynamoDB) we can achieve a serverless web application architecture by combining it with Amazon Cognito for authentication, and Amazon S3 and Amazon CloudFront to quickly serve up static content from anywhere.

That’s all folks, hope you enjoyed this. We explored Serverless options, architectures, and common patterns on AWS and explored how we can use and combine different services to benefit from the advantages or Serverless. Let’s start building!

CKA - Kubernetes Certified Administrator Cheatsheet

Sun, 17 Jan 2021 00:00:00 GMT

This material was gathered during my preparation for the CKA certification exam. I created and curated this cheatsheet with useful commands and information that will be handy to review before taking the exam.

If you want to know how to prepare for the CKA exam, check my How to pass CKA post.

Core Concepts

View resources in namespace dev:

kubectl get pods -n dev

View all pods in all namespaces:

kubectl get pods -A

View all resources in all namespaces:

kubectl get all -A

Generate a pod yaml file with nginx image and label env=prod:

kubectl run nginx --image=nginx --labels=env=prod --dry-run=client -o yaml > nginx_pod.yaml

Delete a pod nginx fast:

kubectl delete pod nginx --grace-period 0 --force

Generate Deployment yaml file:

kubectl create deploy --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Access a service test-service in a different namespace dev:

test-service.dev

Create a service for a pod valid-pod, which serves on port 444 with the name frontend:

kubectl expose pod valid-pod --port=444 --name=frontend

Recreate the contents of a yaml file:

kubectl replace --force -f nginx.yaml

Edit details of a deployment nginx:

kubectl edit deploy nginx

Set image of a deployment nginx:

kubectl set image deploy nginx nginx=nginx:1.18

Scale deployment nginx to 4 replicas and record the action:

kubectl scale deploy nginx --repliacs=4 --record

Get events in current namespace:

kubectl get events

Scheduling

Get pods with their labels:

kubectl get pods --show-labels

Get the pods that are labeled env=dev:

kubectl get pods -l env=dev

Get taints of node node01:

kubectl describe node node01 | grep -i Taints:

Label node node01 with label size=small:

kubectl label nodes node01 size=small

Default static pods path:

/etc/kubernetes/manifests

Check pod nginx logs:

kubectl logs nginx

Check pod logs with multiple containers:

kubectl logs <pod_name> -c <container_name>

Monitoring

Check node resources usage:

kubectl top node

Check pod and their containers resource usage:

kubectl top pod --containers=true

Application Lifecycle Management

Check rollout status of deployment app:

kubectl rollout status deployment/app

Check rollout history of deployment app:

kubectl rollout history deployment/app

Undo rollout:

kubectl rollout undo deployment/app

Create configmap app-config with env=dev:

kubectl create configmap app-config --from-literal=env=dev

Create secret app-secret with pass=123:

kubectl create secret generic app-secret --from-literal=pass=123

Cluster Maintenance

Drain node node01 of all workloads:

kubectl drain node01

Make the node schedulable again:

kubectl uncordon node01

Upgrade cluster to 1.18 with kubeadm:

kubeadm upgrade plan
apt-get upgrade -y kubeadm=1.18.0-00
kubeadm upgrade apply v1.18.0
apt-get upgrade -y kubelet=1.18.0-00
systemctl restart kubelet

Backup etcd:

export ETCDCTL_API=3
etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /tmp/etcd-backup.db

Restore etcd:

ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db --data-dir /var/lib/etcd-backup

After edit /etc/kubernetes/manifests/etcd.yaml and change /var/lib/etcd to /var/lib/etcd-backup.

Security

Create service account sa_1

kubectl create serviceaccount sa_1

Check kube-apiserver certificate details:

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

Approve certificate singing request for user john:

kubectl certificate approve john

Check the current kubeconfig file:

kubectl config view

Check current context:

kubectl config current-context

Use context dev-user@dev:

kubectl config use-context prod-user@production

Validate if user john can create deployments:

kubectl auth can-i create deployments --as john

Create role dev to be able to create secrets:

kubectl create role dev --verb=create --resource=secret

Bind the role dev to user john:

kubectl create rolebinding dev-john --role dev --user john

Check namespaced resources:

kubectl api-resources --namespaced=true

Troubleshooting

View all the kube-system related pods:

kubectl get pods -n kube-system

Check if all nodes are in ready state:

kubectl get nodes

Check memory, cpu and disk usage on node:

df -h
top

Check status of kubelet service on node:

systemctl status kubelet

Check kubelet service logs:

sudo journalctl -u kubelet

View kubelet service details:

ps -aux | grep kubelet

Check cluster info:

kubectl cluster-info

Gather info

Find pod CIDR:

kubectl describe node | less -p PodCIDR

Get pods in all namespaces sorted by creation timestamp:

kubectl get pod -A --sort-by=.metadata.creationTimestamp

Find the service CIDR of node-master:

ssh node0master
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep range

Find which CNI plugin is used on node-master:

ls /etc/cni/net.d/

Find events ordered by creation timestamp:

kubectl get events -A --sort-by=.metadata.creationTimestamp

Find internal IP of all nodes:

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

General notes

To create a daemonset, use kubectl create deploy command to create a .yaml file and then change the kind and remove replicas & strategy.
To find the static pod manifest path, check the exec command of kubelet service or staticPodPath parameter of kubelet’s config file.
To create a static pod, place a yaml definition file in the staticPodPath directory.
To identify static pods look for the suffix -<node_name> on pods.
To add a new scheduler copy the existing one and add to the container’s command the flags--leader-elect=false and --scheduler-name=my-scheduler-name. To use the new scheduler under spec of a pod definition file specify the option schedulerName.
To add a default command to a pod use command that overrides the default ENTRYPOINT from Dockerfile. Use args to override the Dockerfile CMD command for the commmand’s extra parameters.

How to pass CKA - Kubernetes Certified Administrator

Wed, 13 Jan 2021 00:00:00 GMT

Just passed the CKA - Kubernetes Certified Administrator certification exam in January with the new format and I’ll share my preparation with you. Follow this recipe and you will be ready to get your hands on CKA too!

Study material & strategy

Get this course https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ and go over all the videos at least once.

There are a lot of details so maybe you want to keep notes. If you dont feel like taking notes, check my CKA Cheatsheet and study notes.

Complete successfully all the practice tests along with the mock exams at least 3 times.

While doing the practice tests try to use only the official documentation to simulate the real exam. In the examination, you’re only allowed to have one other browser tab open with the Kubernetes documentation. These pages only:

https://kubernetes.io/docs
https://github.com/kubernetes
https://kubernetes.io/blog

That means for example you can’t access discuss.kubernetes.io. Pay attention to that and try to complete the practice tests and exams only with the allowed resources.

Bookmark documentation pages you find useful while solving the practice tests.
Verify you have read at least once the kubectl-cheatsheet as it can be very useful for some questions.
Pay extra attention to: etcd backup/restore, Persistent Volumes & Claims and how to configure them, kubeadm upgrade, RBAC , Network Policies, Ingress, DNS for services and pods, Advanced and Manual scheduling, How to debug a broken cluster
Verify you can answer all the questions from this repo
When you feel ready, you can try this practice test killer sh. It costs an extra amount but I found the material super useful as the last step to validate my level of readiness. This exam is more difficult than the actual one so you may fail the first time. Study the questions, check the answer & tips and retry.

Before the exam read: Handbook, Important Tips, FAQ
To save some time during the exam you can set in your terminal:

alias k=kubectl
export do="--dry-run=client -o yaml"

After completing these steps I guarantee that you’ll feel quite confident!

May the kubectl be with you!

Manage Docker Storage & Volumes

Fri, 08 Jan 2021 00:00:00 GMT

TL;DR Overview of how docker storage & volumes work and how to manage them.

In this fourth part of the Dockerventure series, we are going to focus on how docker handles storage, how it manages container file systems, and showcase how we can effectively manage our data with volumes.

Check here for the first 3 parts: Intro Docker, Dockerfiles, Useful Docker commands

Default Docker File System

By default at creation time, docker creates the directory /var/lib/docker where it stores all its data regarding containers, images, volumes, etc.

When a new container is started, a new read-write container layer is added on top of the read-only image layers that were created during the build phase.

This container layer exists only while the container exists and when the container is killed this layer along with all the changes we made on top is lost.

For example, if I bash inside my docker container that holds the server.py file modifies it, and saves it, a copy of this file is saved on the read-write temporary container layer while the image read-only layer isn’t affected.

Persist data with volumes

To persist newly created data beyond the container’s lifetime, we can use docker volumes.

To do this we can create a docker volume by executing docker volume create myvolume. This automatically creates a directory under /var/lib/docker/volumes/myvolume in our host.

Let’s use this persistent volume while running a container.

Let’s say for example that we would like to spawn a postgres database container. We would like to preserve our db data even if for example our container stops, restarts, or gets killed.

To do this let’s mount the postgres default /var/lib/postgresql directory inside the postgres container to my newly created myvolume by running:

docker run -v myvolume:/var/lib/postgres postgres

Note that when specifying the -v option we define the name of the volume on the left side of : and the path inside the container on the right side.

-v <volume_name>:<path_inside_the_container>

Now the directory /var/lib/postgresql inside the container is mounted on our myvolume volume on our host under /var/lib/docker/volumes/myvolume and any data written there will be persisted.

This is called volume mounting as we are mounting one of the docker volumes.

Another option is to mount an already existing host directory to a directory inside the container.

For example, let’s say we already have a directory configured with lots of capacity to store our db data under /db_data.

In this case, instead of specifying a volume name, we will specify a path on our host:

docker run -v /db_data:/var/lib/postgres postgres

This is called bind mounting and in this case, after the -v option we define the path on the host on the left side of : and the path inside the container on the right side.

-v <path_on_the_host>:<path_inside_the_container>

Something to note here is that using -v is the old fashioned way while there is a new more verbose way to define mounts.

The new preferred way is to use the --mount flag and define specifically the type of the mount. The last example using this option is transformed like this:

docker run --mount type=bind,source=/db_data,target=/var/lib/postgres postgres

Storage drivers

All the above operations fall into the responsibility of storage drivers. Storage drivers allow us to create data in the writable layer of our container.

There is a list of storage drivers and docker picks the best storage driver automatically available on our system. These drivers have different characteristics, and selecting a specific one depends on our workload’s use case and needs.

For a detailed comparison and info check the official documentation select-storage-driver

To check what is the storage driver used in your system run:

docker info

Summary

The fourth part of our Dockerventure around storage and volumes has come to an end. We discussed how docker handles data, filesystems, volumes, and layers.

Showed examples of how to use volumes, the 2 different types of mounts volume mounting and bind mounting and in the end, had a quick look on docker storage drivers.

Docker Ninja Tricks

Thu, 07 Jan 2021 00:00:00 GMT

TL;DR Useful docker commands to have in your arsenal.

So far we’ve seen the basic functionality of Docker, had a detailed look on Dockerfiles, and common commands used to manage/view/build/share containers and images.

In this post, I am going to try to gather some other useful Docker commands that will make our life easier operating dockerized systems.

Usefull Docker Commands

In the previous 2 parts, we ’ve already seen:

docker run docker ps & docker ps -a docker stop docker start docker logs docker help docker login docker rm docker build docker images docker push

So I’ll move forward to other more sneaky commands.

If you want to check how the previous Docker commands can be used in action check my 2 previous posts Intro to Docker and deep dive on Dockerfiles.

docker –version

Quite self-explanatory, shows the currently installed version.

docker rmi

Used to delete docker images. More or less similar to docker rm but for images instead of containers.

docker exec

This command is used to execute a command on a running container. The most common use case is to access a running container to debug something. docker exec -it <cotnainer_id> bash

docker inspect

Used to get detailed low-level information on Docker objects like containers and images. If you are looking for details like Ip addresses, volumes, stuff around networking, image layers, etc this should be your first place to look.

docker restart

Quite self-explanatory, restarts a docker container.

docker system prune

Used for housekeeping and cleaning in order to remove all unused containers, networks, and images, combine with --volumes to clean volumes too.

docker top

Display the running processes of a container.

docker volume

Manage volumes by combining with the subcommands create , inspect ls prune, rm.

docker stats

Get a live stream of resource usage of your running containers. Quite useful for debugging purposes as it shows info about CPU, Mem, Net I/O, Block I/O , Pids.

docker network

Manage docker networking by combining with the subcommands create , connect, disconnect, inspect, ls, prune, rm.

Check the next part regarding Docker Storage here

Taming the Dockerfile

Tue, 05 Jan 2021 00:00:00 GMT

Taming the Dockerfile beast - Dockerventure Part 2

TL;DR Build and share your own managed docker images.

In this second part of the Dockerventure series, we are going to focus on how we can define our own custom images with Dockerfiles, how we can build those images, and publish them in Dockerhub so we can share them with the rest of the world!

If you missed my intro to Docker click here Exploring the Docker world

Docker images & Dockerfile basics

In Docker’s world, the image definition is described inside a file called Dockerfile.

The Dockerfile describes how to assemble an environment for a container that contains all the necessary information and metadata on how to run it based on this image.

To containerize our applications, we have to write Dockerfiles that define step by step how are images are built.

Let’s look at one Dockerfile and discuss it’s building blocks. This Dockerfile defines an image that basically sets up a python flask server and shows a message with a color that we picked.

FROM python:3.7-alpine

# set env var color
ENV color=blue

# set working directory
WORKDIR /server

# copy the dependencies file to the working directory
COPY requirements.txt .

# install dependencies
RUN pip install -r requirements.txt

# copy the script file to the working directory
COPY server.py .

CMD [ "python", "./server.py" ]

The order of the commands in a Dockerfile matters as they are executed top-down and each one of them is considered as one layer of our image.

For reference, this is our python file server.py that outputs the selected color and we would like to dockerize:

from flask import Flask
import os

server = Flask(__name__)

color = os.environ['color']

@server.route("/")
def hey():
  return "Hey there my favourite color is: {}!".format(color)

if __name__ == "__main__":
   server.run(host='0.0.0.0')

FROM

Let’s start with the FROM command which is required in every Dockerfile. It’s the initial image on top of which we start to build our custom one.

Can be either a minimum Linux distribution or some image configured already with the basic tools we need for our application. In our case, since we are going to run a python script, we used python:3.7-alpine.

ENV

ENV refers to an environment variable and is one of the ways to set them. These environment variables are used extensively to inject key/value pairs for building and running containers.

Environment variables are quite handy for these use cases as they work on every os, config, environment. In our case, we set the color we picked.

RUN

RUN command is used to execute shell commands inside the container while it’s building it. We use RUN to create files, folders, install dependencies, run shell scripts, and various other tasks that we would like to run inside our container at creation time to prepare it.

To combine multiple commands with the same RUN statement you can use &&. This way we can include multiple commands in a single layer in our image.

WORKDIR

WORKDIR is changing the working directory inside our container.

COPY

COPY is used to copy files inside the container. This is useful to transfer for example executable files and various other files used by the container. In our case, we copy our python script along with its dependencies definitions.

CMD

CMD is the final command that will be run every time we launch a new container from this image or restart a container. In our example, we are just executing our python app at runtime.

Build an image from a Dockerfile

To build our Dockerfile and produce an image that can be used to create a containerized version of our app, we need to execute the docker build command.

The docker build command requires just a path in order to set the build context, the directory where to build from. That is enough if we use the default name Dockerfile for our build files.

If we choose to pick a custom Dockerfile name, we can specify this with the -f flag. We can also specify a custom tag and a repository at which to save the new image with the -t flag.

To build our image, we have to run this command from the directory where our Dockerfile1 lives.

docker build -t myflaskserver:0.0.1 -f Dockerfile1 .

In the above command, we specify -t flag and we add a custom tag for our image, myflaskserver. We can also define a numbered version after : like 0.0.1.

Alright if you tried the above command with our Dockerfile you should have built an image locally. Let’s verify this by executing:

docker images

There we can see our new image along with some info like REPOSITORY TAG IMAGE ID CREATED SIZE.

Now we are ready to use our newly created image to generate a containerized version of our python flask server. Let’s go ahead and try that.

docker run -d -p 5000:5000 myflaskserver:0.0.1
docker ps

Now try curl on localhost on port 5000 or open your browser at locahost:5000 and you should see a message like below:

curl localhost:5000

Amazing our containerized python server works as expected!

Let’s try something else. Let’s use the environment variable color to change the message. First,let’s kill the previous container by executing docker rm -f <docker-container-id>. Then:

docker run -d -p 5000:5000 -e color=green myflaskserver:0.0.1

And again if you try curl or go to your browser at localhost:5000 you should see the color has changed:

Publish a custom Docker image

Alright, so far we have our custom image and verified that it works as expected.

Next, we would like to store this image on Dockerhub, so we can share it with other people.

To do that we’ll need a Dockerhub account so if you don’t have one go ahead and register here. After you created your account, you can log in from the command line with docker login.

In order to publish our image to our account on Dockerhub, we must tag it using with the docker account id like that: docker build <Your Docker ID>/myflaskserver:0.0.1

For example, my Docker ID is moustakis:

docker build -t moustakis/myflaskserver:0.0.1 -f Dockerfile1 .

And then we can simply run:

docker push moustakis/myflaskserver:0.0.1

This will automatically create a public repository for our image. Go ahead and explore your newly published image here. Congrats on your first published image!

Dockerfile Best Practises

As the last step let’s examine some best practices on creating Dockerfiles and try to improve our previous Dockerfile a bit.

Instruction order matters

To leverage efficiently the build cache mechanism place the instructions that tend to change more frequently after the ones that change less often.

For example, taken from our previous Dockerfile, our dependencies tend to change less frequently than our code. So we decided to first copy the requirements.txt, install them and then copy the server.py.

Notice that we could copy both the requirements.txt and server.py using the same layer but we chose not to leverage the caching mechanism on the less often changed requirements.txt.

# copy the dependencies file to the working directory
COPY requirements.txt .

# install dependencies
RUN pip install -r requirements.txt

# copy the script file to the working directory
COPY server.py .

Ephemeral containers

Keep in mind that containers by nature are destroyed and replaced all the time, so the containers that we create with Dockerfiles should be able to terminate and rebuilt.

Use .dockerignore

Similar to .gitignore, used to exclude files that aren’t relevant to the build.

Multi-stage builds FTW

By including files or packages that aren’t necessary in our final image we end up with larger build times and larger image sizes.

That results in more time to build, push, and pull our images along with some other disadvantages like increasing the possible attack surface by some malicious outsider.

To avoid this, we can create different stages in our Dockerfile, for example:

FROM python:3.7-alpine as base

ENV color=blue

FROM base as builder

RUN mkdir /install
WORKDIR /install

# copy the dependencies file to the working directory
COPY requirements.txt /requirements.txt

# install dependencies
RUN pip install --prefix=/install -r /requirements.txt

FROM base
COPY --from=builder /install /usr/local

# set the working directory in the container
WORKDIR /server

COPY server.py ./

ENTRYPOINT [ "python" ]
CMD ["./server.py" ]

In the above Dockerfile we use the builder stage to install build our dependencies but strip them from our final application image.

The first stage is only used for building dependencies and we copy to our final stage only the necessary files produced from the first stage. To define a stage, we use the as argument to the FROM command as shown.

Go ahead and build this image and then run docker images and compare the size of the two images, the second one should be smaller:

docker build -t <Your Docker ID>/myflaskserver2:0.0.1 -f Dockerfile2 .
docker images

Install only the necessary packages

It’s never a good idea to install more stuff than you need, keep it simple and add only completely necessary packages otherwise you’ll find yourself fighting to maintain dependencies.

One container for one job

Each of your images should be defined to execute one specific job. The Docker architecture favors decoupling applications as much as possible so try to separate your container’s responsibilities as much as possible.

This way you can achieve horizontal scaling, reusability, easier maintenance, and faster development lifecycles.

Other useful Dockerfile instructions

LABEL

Labels can be added to the image for various reasons like organization, automation, versioning, etc. Use the LABEL command followed by a key-value pair:

LABEL version="0.0.1"

EXPOSE

Defines the ports on which the container listens for connections to be used.

ENTRYPOINT

Defines the default command to run in a container if specified. To overwrite, we need to specify the command --entrypoint at runtime.

If only the CMD instruction exists then the CMD is executed and can be overwritten by placing at the end of the docker run another command.

If an ENTRYPOINT is defined in a dockerfile then the value of CMD e.g. CMD ["5"] will be passed as a parameter to the value of ENTRYPOINT ENTRYPOINT ["sleep]. In our second Dockerfile example we modified the initial

CMD [ "python", "./server.py" ]

to:

ENTRYPOINT [ "python" ]
CMD ["./server.py" ]

This way we specify that python is the image’s main command and the "./server.py" is the default flag passed to the entrypoint.

For example, if we would just like to check the python version, we could specify the --version after our docker run command which will replace the execution of our python file "./server.py".

VOLUME

Used to define some persistent volumes for any mutable parts of the image. Anything that isn’t considered ephemeral and should be persisted further the container’s lifecycle.

Summary

That concludes the second part of our Dockerventure. Hope you enjoyed our deep dive into Dockerfiles as much as I did.

We explained and analyzed some of the fundamental and most used Dockerfile instructions, wrote a simple Dockerfile for our python server, and learned how to build and push our custom images to Dockerhub.

In the end, we saw some best practices around Dockerfiles and tried to implement some of these to improve our first Dockerfile. Here you can find the next episode on Useful Docker commands.

Exploring the Docker world

Sun, 03 Jan 2021 00:00:00 GMT

TL;DR Intro to Docker’s basic functionality and concepts. Keep reading if you are new to Docker or want to learn about it.

Today we are going to focus on a fundamental modern software technology, Docker. We are trying to analyze Docker by answering three simple questions around it. What is Docker, why should we adopt its usage, and when is the right time for this.

We are going to explain some of its basic components and the high-level picture of how they work together. Finally, we are going hands-on on our first Docker trip by spawning a containerized webserver in seconds!

If you are already familiar with Docker but would like to check the second part of this Docker adventure where we investigate more advanced topics, click here: Taming the Dockerfile

What is this sorcery - Docker Intro

Docker is an open source tool designed to make our life easier(or sometimes harder) regarding creating, building, deploying, and run software applications.

This is achieved by packaging applications into containers along with everything else they need, allowing them to be considered and deployed as one package.

Our code with its dependencies, libraries, tools, runtime environment, and operating system is combined into a standard unit of software that can technically run in every environment without any other requirement, well apart from Docker itself being present.

This is actually the magic of Docker, eliminating the need to care about different environments, installing dependencies while allowing our software to run on any machine. This means that Devs can focus on writing and developing their code and Ops have a new flexible tool in their arsenal to help them manage complex software systems.

Docker Architecture

Docker is like a client-server application including a server called the docker daemon process(dockerd), a REST API that provides interfaces to talk to the daemon and a command line interface client(command docker).

The communication goes like this:

The client is the main way of interaction for the users and via commands like docker run informs the daemon what is supposed to be done. Then the daemon which is listening for those requests gets to work by managing accordingly the various docker objects.

The docker client and daemon can live on the same system (the case of running docker locally on your machine for example) or the client can connect remotely to a remote daemon.

Why should I use Docker

Containers are considered the once in a decade shift in infrastructure and if you are working in any sector related to software development or IT this is one of the fundamental tools that you should know.

It’s the shift to the next object of computation as in some years(if not already) running software in containers will be the default practice. They are considered the fastest-growing cloud-enabling technology and Docker is the face behind all this.

There are of course other container tools but Docker is the defacto containerization technology and definitely the most used one. The real power that Docker provides us though is speed.

Speed of software development & delivery, speed of building and testing, speed of providing value, speed of bringing our software from idea to production.

Even more, as previously mentioned in the What section, containers reduce complexity by allowing us to run and test the software everywhere the same way. That abstraction simplifies and makes it easier to handle a lot of the problems around managing software lifecycle.

When is the right time to start using Docker

I know that migrating or learning a new tool and technology can be challenging but Docker makes this transition really smooth and focuses a lot on the migration experience.

Finally, we have a tool that can be used easily by any role in software development or IT like devs, ops, testers, build engineers, sysadmins etc and NOW is the time to jump on the docker ship.

The nice thing about Docker is that it doesn't require any code changes to your existing software and that’s actually one of the main reasons explaining why it has been adopted so quickly.

Fundamental Docker Concepts

Before we jump into our first hands-on quick Docker trip, let’s first define some vocabulary that we’ll need.

Image

An image is the application we would like to run along with binaries, libraries and everything that ultimately makes our source code, including also metadata about how to run it.

Dockerfile

A Dockerfile is a recipe to create our Docker images. We are going to deep dive into Dockerfiles in the next episode. For now, if you want to have a look at the Dockerfile that we are going to use check here

Container

A container is a running instance of an image running as a process. So in the end containers are just processes limited by what resources they can access.

Image Registry

Images are usually stored in registries and Dockerhub is the default registry for Docker. Dockerhub is for docker images what Github is for source code.

Ok enough with the blah blah, show us

Ok by now you should be fully onboard on the Docker train chu chuuuu, demo time.

If you don’t have already Docker installed here is the link to the official documentation regarding installation instructions per platform. For this demo, we are going to use the nginx webserver image, which can be found here.

Go in your terminal and just run:

docker run -p 80:80 -d nginx

And dadaaaaaah you have an nginx webserver up and running. To validate go to your web browser and type: localhost:80 and you should see something like this:

Well done running your first docker container! That was easy, wasn’t it?

Let’s go see what happened there. When we run this command docker tried to look for a docker image named nginx, couldn’t find any so it went to Dockerhub and downloaded the latest image and then started it in a newly created container.

Also with the -p 80:80 option, we instructed our container to expose traffic on our host IP at port 80 and route it to the container IP port 80, pure magic. The -d option runs the container in the background and allows us to continue using the same terminal for other stuff.

To verify this go back to your terminal and run the command that lists our running containers:

docker ps

And you should see something similar to this:

Note there is various info there. You get your container id (every container has a unique id), the image from which it spawned, the default command used when the container starts when was your container created, it’s status, what ports are exposed and a random & usually funny name attached to it (if you don’t specifically specify one).

To stop a running container get the id from the above output and execute:

docker stop 1663e7b52343

now running the same command again should return nothing:

docker ps

If you want to see your stopped containers run:

docker ps -a

Ok, let’s say I want to specify a name for my container so that I can reference it easily and I don’t have to grab the id every time, that can be achieved by using the --name flag.

docker run -p 80:80 -d --name webserver nginx

Now if you execute again docker ps you will see that the container has the specified name and can be for example stopped by running:

docker stop webserver

If you stopped our webserver go ahead and restart the container by running:

docker start webserver

This again starts the same previously stopped container instead of the run command which will create a new one.

Ok, what if we want to check how our webserver is doing? Let’s go check some logs:

docker logs webserver

And you should see something similar to this:

Let’s try to generate some more logs, go to your browser at localhost:80 where our nginx webserver is exposed and hit the refresh button a couple of times. Now let’s execute again:

docker logs webserver

Now you should have more logs in your webserver showing all the get requests you just did:

If you like also you can follow the logs in the terminal by specifying the -f flag. Try

docker logs -f webserver

And back to your browser hit the refresh button a couple of times and you will see the log stream being updated real-time.

The Docker tool has a lot of useful commands, and you’ll have to play a bit with them to explore them all. To list all the different docker commands just run:

docker help

It returns a list of options and commands. If you would like to learn more info regarding one specific command, for example, the login command, you can run:

docker help login

And you get more information regarding the login command

Alright, let’s say we are done with our quick demo, and we would like to clean our containers.

Go ahead and run docker ps -a to list all your containers, running or not. To remove them, we’ll use the docker rm command.

If you try to use this command on a running container, you’ll get an error that you can't remove a running container. We’ll use -f flag to force the deletion in this case, note that it will be the same if you first stopped the running containers with the docker stop command.

Let’s go and remove both the 2 containers we created previously in one go:

docker rm -f webserver 1663e7b52343

Summary

Alright, that was it folks, a quick intro to Docker answering What-Why-When questions around it, defining some basic components, and finally getting our hands dirty with a small demo.

Hope you enjoyed this as much as I did and if you want to learn more, check the second part of our Docker trip Taming the Dockerfile where we deep dive into more advanced Docker topics and we are going to build our first Dockerfile.