Best Practices Library

A set of cloud design principles and check-lists for building secure, high-performing, resilient, and efficient workloads on AWS.

Microsoft’s five-pillar guidance (reliability, security, cost, performance, ops) for designing and operating workloads on Azure.

Prescriptive guidance covering reliability, cost, performance, security, and operational excellence for GCP workloads.

The CNCF’s formal definition of cloud-native computing and core principles for micro-services, containers, and dynamic orchestration.

Twelve practical guidelines for building modern, portable, cloud-ready web applications.

Codified principles (error budgets, toil elimination, SLIs/SLOs) for operating large-scale services reliably.

Research-backed metrics (deployment frequency, lead time, MTTR, change failure rate) for high-performing software teams.

Framework emphasising Culture, Automation, Lean, Measurement, and Sharing as pillars of DevOps success.

Declarative, verifiable and automated operations — using Git as the single source of truth for infra and apps.

Incrementally replacing legacy systems by routing new functionality to a new service while ‘strangling’ the old.

Operating two identical production environments to achieve zero-downtime releases and quick rollbacks.

Progressively rolling out new software to a small subset of users to minimise risk before full release.

The ten most critical web application security risks; updated community consensus.

Guidelines for secure software development practices across the SDLC (SP 800-218).

End-to-end integrity guarantees for software supply-chain; defines levels 1-4.

Lightweight Bill-of-Materials standard for software components, vulnerabilities, and licenses.

Best practices for securing Terraform, CloudFormation, and ARM templates in CI/CD pipelines.

Baseline, restricted, and privileged policy levels for securing pod workloads.

Guidance on building, shipping, and running secure cloud-native applications.

Best practices for generating consistent traces, metrics, and logs using OpenTelemetry.

Standard approaches for selecting golden signals (Rate-Errors-Duration / Utilisation-Saturation-Errors).

Core performance metrics (LCP, FID, CLS, INP) for measuring real-world user experience.

A checklist covering operability, reliability, deployability, and observability of micro-services.

Domain-oriented, self-serve data infrastructure principles promoting product thinking for data.

Community conventions for naming, structuring, and documenting dbt transformation projects.

Opinionated REST and gRPC design rules: resource-oriented URIs, plural nouns, pagination, errors.

Cross-company REST consistency rules (nouns, verbs, versioning, errors).

Backwards-compatible evolution strategy and pinned versions for API consumers.

Consistent MAJOR.MINOR.PATCH versioning rules for APIs and packages.

Machine-readable Git commit messages enabling automated changelogs and semantic releases.

Branching strategy promoting short-lived branches, frequent commits to trunk, and feature flags.

Operational guidelines for creating, managing, and retiring feature toggles safely.

Encourages earlier testing (unit, security, performance) in the SDLC to catch defects sooner.

Consumer-driven contract testing methodology to ensure micro-service compatibility.

Run controlled experiments to build confidence in system resilience under turbulent conditions.

Shared responsibility model for cloud spend: Inform, Optimize, Operate phases.

End-to-end practices merging agile, DevOps, and design thinking for cloud transformation.

Scaled Agile Framework’s model for continuous exploration, integration, deployment, and release on demand.

Industry baseline for information-security policies and management controls.

Guidelines to integrate trustworthiness considerations into the design, development, and deployment of AI systems.

First comprehensive regulatory framework for trustworthy AI in the European Union.

Seven commitments guiding the ethical development and deployment of AI at Google.

Company-wide governance framework translating principles into measurable requirements.

Mitigation strategies (RLHF, red-teaming, tiered access) for large language model deployment.

Guidelines for writing reusable, versioned, and documented Terraform modules.

Recommendations for structure, naming, versioning, and values of Helm charts.

Steps to build minimal, non-root, signed container images with SBOMs.

Conceptual zero-trust model: continuous verification, least privilege, assume breach.

Framework embedding privacy into systems engineering from the outset.

Iterative roadmap for refactoring, re-platforming, and replacing legacy systems using automation and AI.

A framework of security requirements that defines testable controls for designing, building, and verifying secure web applications and services.

A maturity model that helps organizations assess and improve their software security program across governance, design, implementation, verification, and operations.

A ranked list of the most critical security risks specific to APIs, covering broken authorization, authentication, and unsafe resource consumption.

A standard of security requirements for mobile apps, covering storage, cryptography, authentication, network communication, and platform interaction.

An annually updated list of the most common and impactful software weaknesses, derived from real-world vulnerability data, to guide prevention and prioritization.

A voluntary framework of cybersecurity outcomes organized into six functions, govern, identify, protect, detect, respond, and recover, for managing organizational cyber risk.

A comprehensive catalog of security and privacy controls for information systems, organized into control families with baselines for different risk levels.

A prioritized set of 18 safeguards and implementation groups that defend against the most common cyber attacks, mapped to other major frameworks.

A set of security practices integrated across every phase of software development, from training and design through implementation, verification, and response.

A structured method for finding security threats by category, spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Guidance and recommended values for HTTP response security headers that harden web applications against common client-side attacks.

An open standard for signing software artifacts using short-lived certificates tied to identity, removing the burden of managing long-lived private keys.

A framework that secures the software supply chain by cryptographically verifying that each step in the build and release process was performed as intended.

Practices for storing, rotating, and accessing credentials and keys securely, keeping them out of source code and limiting their exposure.

A security principle that grants every user, service, and process only the minimum access required to perform its function, and no more.

A development practice where engineers merge code into a shared mainline many times a day, each merge verified by an automated build and test suite.

A discipline where software is built so it can be released to production safely at any time, with every change proven release-ready by an automated pipeline.

An automated, staged path that takes every code change from commit through build, tests, and successive environments, providing a single auditable route to production.

A lightweight, branch-based workflow built around short-lived feature branches, pull requests, and continuous deployment from a single always-deployable main branch.

A structured Git branching model using long-lived main and develop branches plus dedicated feature, release, and hotfix branches to coordinate scheduled releases.

A zero-downtime schema change technique that adds new structures, migrates reads and writes in phases, then removes the old structures once nothing depends on them.

An operations model where servers and components are never modified after deployment; changes ship as freshly built, versioned replacements rather than in-place edits.

Defining CI/CD pipelines in version-controlled configuration files stored alongside the application, so the delivery process is reviewable, reproducible, and auditable.

The practice of storing, versioning, and governing build artifacts and dependencies in a dedicated repository so the same trusted binary is promoted from build to production.

A progressive rollout strategy that releases changes to expanding audience groups, or rings, validating each ring before exposing the next to limit blast radius.

Deploying new functionality to production in a hidden state and exercising it with real traffic before exposing it to users, to validate behavior and capacity safely.

A set of practices ensuring a given source plus build environment always produces bit-for-bit identical binaries, so anyone can independently verify what shipped.

Automating checks such as formatting, linting, and secret scanning that run on every Git commit, catching issues locally before they ever reach the shared repository.

A delivery cadence where releases ship on a fixed schedule and any change not ready in time simply catches the next train, decoupling release timing from feature completion.

Managing application and system configuration in version-controlled, machine-readable files instead of manual settings, making configuration reviewable, auditable, and reproducible.

A target reliability level for a service, expressed as a measurable percentage of good events over a window, used to balance reliability against feature velocity.

The allowed amount of unreliability derived from an SLO (100% minus the target), spent deliberately to balance new features against reliability work.

Google SRE's four core metrics for monitoring a user-facing system: latency, traffic, errors, and saturation.

Standardized names and attributes for telemetry (spans, metrics, logs) so observability data is consistent and portable across tools and languages.

Emitting logs as machine-parseable key-value records (typically JSON) with consistent fields, so logs can be searched, filtered, and correlated at scale.

Techniques for instrumenting and propagating trace context across services so requests can be followed end-to-end, with sampling and span design that aid debugging.

Guidance for naming metrics, controlling label cardinality, and writing alerting rules in Prometheus, the CNCF metrics and alerting system.

Alerting on user-visible symptoms (errors, latency, SLO burn) rather than internal causes, to reduce noise and page only on things that matter.

A structured process for detecting, coordinating, and resolving outages with clear roles, communication, and severity levels to restore service quickly.

Post-incident reviews focused on systemic causes and learning rather than individual blame, producing concrete action items to prevent recurrence.

Sustainable on-call practices covering rotation design, escalation, actionable alerts, runbooks, and workload limits to keep services reliable without burning out engineers.

Codifying operational procedures as automated, repeatable workflows so common incident responses and maintenance tasks run reliably with less manual toil.

Forecasting future demand and provisioning resources ahead of need, combining organic growth, launches, and headroom to avoid both outages and waste.

Systematically identifying and eliminating repetitive, manual, automatable operational work so engineers can spend time on durable engineering instead.

Building instrumentation into software as a first-class part of development so engineers can ask new questions of production behavior without shipping new code.

AWS guidance for reducing the environmental impact of cloud workloads by maximizing utilization, right-sizing, and choosing efficient regions, services, and hardware.

A decision framework for choosing how to migrate each application to the cloud across seven options: retire, retain, rehost, relocate, repurchase, replatform, and refactor.

A pre-configured, secure, multi-account cloud foundation with baked-in identity, networking, governance, and guardrails so teams can deploy workloads safely at scale.

An architecture pattern that separates the model that writes data (commands) from the model that reads it (queries), allowing each side to scale and evolve independently.

An architecture pattern that stores every change to application state as an immutable sequence of events, making the event log the source of truth instead of current state.

A pattern for managing data consistency across microservices using a sequence of local transactions coordinated by events or a central orchestrator, with compensating actions on failure.

A resilience pattern that stops calls to a failing dependency once errors cross a threshold, preventing cascading failures and giving the dependency time to recover.

A resilience pattern that isolates resources into separate pools so a failure or overload in one part of a system cannot consume the resources others depend on.

An architecture pattern that gives each frontend client its own tailored backend service, instead of forcing web, mobile, and other clients to share one general-purpose API.

An architecture pattern that places a single entry point in front of backend services to handle routing, authentication, rate limiting, and other cross-cutting concerns.

Guidance for using a service mesh to manage service-to-service traffic, security, and observability through sidecar proxies, keeping that logic out of application code.

A design pattern that deploys a helper component alongside the main application in the same unit, adding capabilities like proxying, logging, or config without changing the app.

An architecture that partitions a system into independent, self-contained cells, each serving a subset of traffic, to limit blast radius and scale through replication.

An architecture that isolates core application logic behind ports, with adapters connecting external concerns like databases and UIs, so the core stays independent of technology.

A software design approach that models complex business domains in code, using a shared language and bounded contexts to align software structure with the business it serves.

An architecture that keeps a single deployable application but enforces strong internal module boundaries, capturing many microservices benefits without distributed-system complexity.

A structured set of roles, policies, and processes that make an organization accountable for the quality, security, and proper use of its data assets.

The practice of measuring, monitoring, and improving data across dimensions like accuracy, completeness, consistency, timeliness, and validity so it stays fit for use.

Explicit, version-controlled agreements between data producers and consumers that define schema, semantics, quality, and SLAs to prevent breaking changes.

A layered data design that refines data through Bronze (raw), Silver (cleaned and conformed), and Gold (business-ready) tables to improve quality and reuse.

An architecture that combines the low-cost, open storage of a data lake with the transactions, schema, and performance of a data warehouse using open table formats.

Guidance on when to transform data before loading (ETL) versus loading raw and transforming in the warehouse (ELT), and how to run each pattern well.

The traceable record of data's origin, movement, and transformation across systems, enabling impact analysis, debugging, compliance, and trust.

The practice of moving modeled data from the warehouse back into operational tools like CRM and marketing platforms so business teams act on it directly.

A centralized system for defining, storing, and serving machine learning features consistently for training and inference, avoiding skew and duplicated work.

The discipline of applying DevOps and engineering rigor to machine learning so models are built, deployed, monitored, and retrained reliably and reproducibly.

Continuously tracking deployed ML models for performance decay, data drift, and concept drift so degradation is caught and corrected before it harms outcomes.

Versioning datasets, models, and ML pipelines alongside code so experiments are reproducible, using Git for metadata and external storage for large files.

Managing how data schemas change over time with compatibility rules and a central registry so producers and consumers evolve without breaking each other.

A searchable inventory of an organization's data assets with metadata, ownership, and lineage so people can find, understand, and trust the data they need.

Design and operational guidance for building reliable, scalable event streaming on Apache Kafka, covering topics, partitions, delivery semantics, and consumers.

RAG grounds a large language model in external documents retrieved at query time, reducing hallucination and letting answers reflect current, private data without retraining the model.

Prompt engineering is the practice of designing clear instructions, examples, and structure so a large language model returns accurate, consistent, and useful output.

LLM evaluation measures model and application quality with repeatable tests, scoring accuracy, faithfulness, safety, and cost so teams can ship and improve with evidence.

LLM guardrails are programmatic checks on model inputs and outputs that enforce safety, format, topic, and policy rules, blocking or correcting unsafe or off-policy responses.

AI red teaming is structured adversarial testing of AI systems to find harmful, biased, or insecure behavior before attackers or real users do, using crafted attacks and probes.

The Model Context Protocol is an open standard that lets AI applications connect to external tools and data sources through a uniform client-server interface.

AI agent design patterns are reusable structures for LLM systems that plan, use tools, and act over multiple steps, covering reflection, tool use, planning, and multi-agent collaboration.

LLM observability is the practice of tracing, logging, and measuring LLM applications in production to monitor quality, cost, latency, and safety and to debug failures.

A vector database stores embeddings and serves fast similarity search for AI features like RAG and semantic search; best practices cover indexing, metadata, and freshness.

The OWASP Top 10 for LLM Applications lists the most critical security risks for generative AI systems, including prompt injection, sensitive data disclosure, and supply chain risk.

Prompt injection defense protects LLM applications from attacks that hide malicious instructions in user input or retrieved content to override the system's intended behavior.

ISO/IEC 42001 is the first international standard for an Artificial Intelligence Management System, giving organizations a certifiable framework to govern AI responsibly.

AI TRiSM is a framework for managing the trust, risk, and security of AI systems across explainability, model operations, data protection, and runtime application security.

LLM cost optimization reduces the spend of running language model applications through model selection, caching, prompt efficiency, and token-aware design without sacrificing quality.

A decision framework for choosing between fine-tuning, RAG, or both, based on whether the goal is new knowledge, consistent behavior, freshness, or domain adaptation.

Hallucination mitigation reduces confident but false LLM output through grounding, retrieval, citation, verification, and uncertainty handling so answers can be trusted.

A four-level model for grading how fully an HTTP API embraces REST, from RPC-style endpoints up to hypermedia controls (HATEOAS).

Guidance for writing accurate, machine-readable OpenAPI documents that describe HTTP APIs and drive docs, client SDKs, mocks, and contract tests.

Practical guidance for designing GraphQL schemas and servers: typed schemas, pagination, error handling, query cost limits, and avoiding the N+1 problem.

Guidance for building high-performance gRPC services with Protocol Buffers: service design, streaming, deadlines, error codes, and backward-compatible schema evolution.

An approach that treats the API contract as a product designed before implementation, so teams agree on the interface, then build clients and servers in parallel.

A pattern where clients send a unique key with unsafe requests so the server can safely retry without applying the same operation twice, preventing duplicate charges or records.

Controlling how many requests a client can make in a time window to protect API capacity, ensure fair use, and defend against abuse, using algorithms like token bucket.

Techniques for returning large result sets in pages without breaking under concurrent writes: offset, cursor (keyset), and page-token pagination, with stable ordering.

Guidance for sending and receiving reliable webhooks: signature verification, idempotent handlers, retries with backoff, and fast acknowledgement of events.

OAuth 2.0 delegates authorization via access tokens; OpenID Connect adds an identity layer for authentication. Together they secure API access and single sign-on.

A standard, machine-readable format for describing event-driven and message-based APIs across protocols like Kafka, MQTT, and AMQP, analogous to OpenAPI for REST.

An IETF standard JSON format for machine-readable HTTP error responses, defining fields like type, title, status, detail, and instance for consistent error handling.

Evolving an API without breaking existing clients by making only additive changes, versioning breaking changes, and deprecating fields gracefully over time.

A convention for building JSON APIs that standardizes resource structure, relationships, pagination, filtering, and sparse fieldsets to reduce bikeshedding and over-fetching.

A frontend strategy that builds a baseline experience with semantic HTML first, then layers CSS and JavaScript so the site works for every browser and device.

The W3C Web Content Accessibility Guidelines 2.2 define testable success criteria across four principles so web content is perceivable, operable, understandable, and robust.

A performance budget sets quantitative limits on metrics like page weight, request count, and load timings, enforced in development and CI to stop regressions.

An approach that designs the smallest-screen experience first, then progressively adds layout and features for larger viewports, prioritizing content and performance.

Techniques to reduce image bytes and improve loading using modern formats, responsive sizing, compression, lazy loading, and CDNs without sacrificing visual quality.

A methodology by Brad Frost for building UI from five composable levels: atoms, molecules, organisms, templates, and pages, giving design systems a consistent structure.

A development approach that builds UIs bottom-up from isolated, reusable components, developed and tested independently before assembly into pages and apps.

A design system is a single source of truth combining reusable components, design tokens, patterns, and guidelines that keep products consistent and faster to build.

An architecture that splits a web app into independently developed and deployed frontend pieces owned by separate teams, then composes them into one experience.

Web apps that use service workers, a manifest, and HTTPS to deliver installable, offline-capable, app-like experiences from a single codebase across platforms.

A W3C security standard delivered via an HTTP header that controls which sources a browser may load, mitigating cross-site scripting and data injection attacks.

An approach by Ethan Marcotte that uses fluid grids, flexible media, and media queries so one layout adapts seamlessly across screen sizes and devices.

Techniques that defer loading of non-critical code and assets and split bundles by route or component, reducing initial payload and speeding up first load.

Designing and building UIs so they can adapt to multiple languages, regions, and formats without code changes, separating translatable text from logic.

A testing strategy that favors many fast unit tests, fewer integration tests, and a small number of slow end-to-end tests.

A testing model that weights integration tests most heavily, balancing static analysis, unit, integration, and end-to-end tests by confidence-per-cost.

A development discipline where you write a failing test first, write minimal code to pass it, then refactor, in short red-green-refactor cycles.

A collaborative practice that expresses requirements as concrete, executable examples in plain language shared by business, development, and testing.

A technique that asserts general properties of code and lets a framework generate many randomized inputs to find counterexamples and shrink them.

A technique that injects small faults (mutants) into code and checks whether tests detect them, measuring how effective the test suite really is.

A disciplined approach to detecting, quarantining, and fixing nondeterministic tests so CI signal stays trustworthy and developers keep merging.

Guidance on using code coverage as a signal of untested code rather than a target, including diff coverage and avoiding coverage gaming.

Guidance for effective, fast, and respectful code review, drawn from Google's engineering practices, to improve code health over time.

A shared, explicit checklist of conditions a work item must meet to be considered complete, ensuring consistent quality across a team.

Guidance for writing reliable, maintainable end-to-end tests that exercise critical user journeys without becoming slow and flaky.

Practices for provisioning realistic, isolated, and compliant test data so tests are reliable, repeatable, and free of production data exposure.

Integrating SAST tools into the CI pipeline to scan source code for security vulnerabilities automatically on every change.

Automated testing that captures screenshots of UI states and compares them against baselines to detect unintended visual changes.

Scrum is a lightweight agile framework for delivering products in short, fixed-length iterations called sprints, using empirical inspection and adaptation to manage complex work.

The Kanban Method is an evolutionary approach to managing knowledge work that visualizes flow, limits work in progress, and improves delivery continuously without prescribing fixed iterations.

Lean Software Development applies Lean manufacturing principles to software, emphasizing eliminating waste, amplifying learning, deferring decisions, and delivering fast to maximize customer value.

Team Topologies is a model for organizing business and technology teams using four team types and three interaction modes to optimize fast flow and reduce cognitive load.

InnerSource applies open source development practices inside an organization, letting teams share, contribute to, and reuse internal code through transparent, contribution-friendly repositories.

An Architecture Decision Record (ADR) is a short, version-controlled document that captures one significant architectural decision, its context, and its consequences for future maintainers.

The C4 model is a lean, hierarchical way to diagram software architecture at four levels of abstraction: System Context, Containers, Components, and Code.

Documentation as Code treats docs like software: stored in version control, written in plain text, reviewed in pull requests, and published automatically through continuous integration.

Keep a Changelog is a convention for writing human-readable, chronologically ordered changelogs grouped by change type, so users and maintainers can see what changed in each release.

Platform engineering builds and runs internal self-service platforms and paved roads that let product teams ship software faster with lower cognitive load and consistent guardrails.

An Internal Developer Platform (IDP) is the self-service product built by platform teams that gives developers golden paths to provision, build, deploy, and operate software with built-in guardrails.