Quick Navigation
- Start here — Technology selection
- Cloud fundamentals
- Infrastructure design
- Cloud patterns
- Security design
- Identity and access management
- Cost and lock-in
- FinOps
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture decisions live in the abstract until they're made real by technology choices — the platforms, the compute, the networking, the security controls. I've seen teams choose technology for the wrong reasons — because they used it before, because it's trending, because a vendor suggested it. The right choice depends on context.
Technology and infrastructure design is where you choose what actually runs the solution — and every choice is a trade-off between capability, cost, complexity, and lock-in.
The decisions that matter most: What to run it on — cloud provider, service model, region. How to secure it — zero trust, least privilege, defence in depth. How much it costs — and whether cost was considered before or after the architecture was designed.
Keep it in mind.
1. Technology selection — How to choose, not just what to choose
Teams choose technology for the wrong reasons — because they used it before, because it's trending, because a vendor suggested it. The right choice depends on context.
Technology selection is a decision under constraints. The best technology is the one that fits your specific context — your team's skills, your operational capabilities, your budget, your regulatory requirements, and your architecture principles.
A structured approach: Define the decision criteria — what matters most for this choice? Identify options — what are the realistic candidates? Evaluate against criteria — how does each option perform? Assess trade-offs — what does each option cost you? Document the decision — so it's understood and revisitable.
flowchart TD
NEED["🏗️ Technology Need\nComponent requires a database"]
NEED --> CRIT["📋 Define Criteria\nPerformance · Cost · Skills · Lock-in · Ecosystem"]
CRIT --> OPTS["🔍 Identify Options\nPostgreSQL · DynamoDB · MongoDB · CosmosDB"]
OPTS --> EVAL["⚖️ Evaluate\nScore each option against criteria"]
EVAL --> TRADE["📊 Trade-offs\nWhat does each option cost you?"]
TRADE --> DEC["✅ Decision\nDocumented with rationale"]
Evaluation criteria template: Performance requirements — what does the workload need? Team skills and experience — can your team operate this? Operational complexity — how hard is it to run? Cost (initial + ongoing) — what's the TCO? Vendor lock-in risk — how hard is it to leave? Community and ecosystem — is there support? Regulatory compliance — does it meet requirements? Integration with existing stack — does it fit? Scalability characteristics — how does it scale? Support and SLA availability — what's the guarantee?
Common selection anti-patterns: Résumé-driven development — technology chosen because engineer wants it on their CV. Fix: evaluate against actual project criteria. Shiny object syndrome — new technology adopted without clear need. Fix: prove the need before the tool. Golden hammer — one technology used for everything. Fix: different problems need different tools. Vendor capture — architecture designed around vendor's sales pitch. Fix: evaluate independently; assess lock-in. Not invented here — rejecting proven solutions because the team didn't build them. Fix: buy or adopt where differentiation isn't required.
Technology selection isn't about finding the best tool — it's about finding the best fit for your constraints. Choose technology by fit to context, not by trend or familiarity.
Try it yourself — The selection check
Take your last technology choice. Run it through the check:
| Question | Your answer |
|---|---|
| What criteria did you evaluate against? | |
| What alternatives did you consider? | |
| What trade-offs did you accept? | |
| Is the decision documented with rationale? |
If you can't answer the second and third questions, you didn't select — you defaulted.
2. Cloud fundamentals — IaaS, PaaS, SaaS, and when each applies
"Move to the cloud" isn't one decision — it's a spectrum of decisions about how much control you give up and how much responsibility the provider takes.
Cloud service models define the line between what you manage and what the provider manages.
flowchart TD
CLOUD["☁️ Cloud Service Models"]
CLOUD --> IAAS["🖥️ IaaS\nInfrastructure as a Service\nYou manage: OS, runtime, apps\nProvider manages: Hardware, networking\nExample: EC2, Azure VMs"]
CLOUD --> PAAS["⚙️ PaaS\nPlatform as a Service\nYou manage: Application code\nProvider manages: OS, runtime, scaling\nExample: Heroku, App Engine, Azure App Service"]
CLOUD --> SAAS["📦 SaaS\nSoftware as a Service\nYou manage: Configuration, data\nProvider manages: Everything else\nExample: Salesforce, Slack, Office 365"]
IAAS --> TRADEOFF1["Maximum control\nMaximum responsibility"]
PAAS --> TRADEOFF2["Balanced\nLess control, less ops burden"]
SAAS --> TRADEOFF3["Minimum control\nMinimum responsibility"]
The decision isn't "which is best" — it's "where on this spectrum fits our needs?" IaaS when you need full control — custom OS, specific runtime versions, compliance requirements. PaaS when you want to focus on code — the platform handles scaling, patching, deployment. SaaS when the capability isn't your differentiation — buy it, configure it, use it.
Detailed comparison:
| You manage | IaaS | PaaS | SaaS |
|---|---|---|---|
| Application code | ✅ | ✅ | ❌ |
| Data | ✅ | ✅ | Partial |
| Runtime / middleware | ✅ | ❌ | ❌ |
| Operating system | ✅ | ❌ | ❌ |
| Virtualisation | ❌ | ❌ | ❌ |
| Servers / storage | ❌ | ❌ | ❌ |
| Networking | ❌ | ❌ | ❌ |
Additional models: FaaS (Function as a Service) — run code without managing any infrastructure. AWS Lambda, Azure Functions. CaaS (Container as a Service) — run containers without managing orchestration. AWS ECS, Azure Container Instances. DBaaS (Database as a Service) — managed databases without server management. RDS, CosmosDB, Cloud SQL.
Multi-cloud and hybrid considerations: Single cloud — one provider for everything. Simplicity, deep provider expertise, best pricing. Multi-cloud — multiple providers for different workloads. Regulatory requirements, risk diversification, best-of-breed. Hybrid — on-premises + cloud. Data sovereignty, existing investments, gradual migration.
The cloud model you choose determines the trade-off between control and operational burden. IaaS = you manage more. PaaS = balanced. SaaS = provider manages more.
Try it yourself — The cloud model check
For your current workloads, where do they sit?
| Workload | Current model | Should it be? | Why? |
|---|---|---|---|
If everything is IaaS, you're carrying unnecessary ops burden. If everything is SaaS, you may have lock-in you haven't assessed.
3. Infrastructure design — Compute, storage, networking, and environments
Behind every running application is infrastructure — compute to run code, storage to hold data, networking to connect components, and environments to separate development from production.
Infrastructure design answers four questions: Compute — where does the code run? (VMs, containers, serverless). Storage — where does the data live? (block, object, file, database). Networking — how do components connect? (VPCs, load balancers, DNS, CDN). Environments — what separates dev from staging from production? (isolation, promotion, parity).
flowchart TD
INFRA["🏗️ Infrastructure"]
INFRA --> COMP["💻 Compute\nVMs · Containers · Serverless\nAuto-scaling · Spot instances"]
INFRA --> STOR["💾 Storage\nBlock · Object · File\nDatabases · Caches · Queues"]
INFRA --> NET["🌐 Networking\nVPCs · Subnets · Load balancers\nDNS · CDN · Firewalls"]
INFRA --> ENV["🔧 Environments\nDev · Staging · Production\nIsolation · Parity · Promotion"]
Compute options: Virtual Machines — full OS control, high overhead (patching, scaling). Best for legacy apps, specific OS requirements. Containers (Docker/K8s) — application-level control, medium overhead (orchestration). Best for microservices, portable workloads. Serverless (Lambda/Functions) — minimal control, low overhead (pay per execution). Best for event-driven, bursty, stateless workloads.
Storage options: Block storage — raw disk volumes. Databases, VM boot disks. Object storage — flat namespace, HTTP access. Files, images, backups, logs. File storage — hierarchical, shared access. Legacy apps, shared file systems. Relational database — structured, ACID, SQL. Transactional data, complex queries. NoSQL database — flexible schema, horizontal scale. High throughput, flexible data. Cache — in-memory, fast access. Session data, hot queries. Queue — message buffer. Async processing, decoupling.
Environment design principles: Parity — dev, staging, production should be as similar as possible. Isolation — environments should not share resources or data. Automation — environments should be created and destroyed via code (IaC). Promotion — code moves through environments in a defined pipeline.
Infrastructure is the foundation — get it wrong and no amount of good application design will save the solution. Infrastructure = compute + storage + networking + environments — the four pillars every solution stands on.
Try it yourself — The infrastructure check
For your current solution:
| Pillar | Current state | Gap |
|---|---|---|
| Compute | ||
| Storage | ||
| Networking | ||
| Environments |
If environments aren't isolated or automated, you have a delivery risk.
4. Cloud patterns — Multi-region, auto-scaling, serverless, managed services
Cloud providers offer powerful patterns that solve infrastructure problems at scale — but choosing the wrong pattern wastes money and adds complexity.
These are the cloud-native patterns every architect must understand:
flowchart TD
PAT["🌐 Cloud Patterns"]
PAT --> MR["🌍 Multi-Region\nDeploy across geographies\nFor availability and latency"]
PAT --> AS["📈 Auto-Scaling\nScale automatically with demand\nFor unpredictable workloads"]
PAT --> SV["⚡ Serverless\nNo servers to manage\nPay per execution"]
PAT --> MS["🔧 Managed Services\nProvider manages the hard parts\nDatabases, queues, ML, analytics"]
Multi-region — deploy in multiple geographies for availability and latency. Cost: complexity, data replication, eventual consistency. Auto-scaling — automatically add/remove compute based on load. Cost: cold start latency, stateless requirement. Serverless — no infrastructure to manage, pay per execution. Cost: vendor lock-in, cold starts, limited execution time. Managed services — let the provider handle databases, queues, ML, analytics. Cost: lock-in, less control, potential cost surprises at scale.
Multi-region patterns: Active-active — all regions serve traffic simultaneously. Maximum availability — but complex data sync. Active-passive — one region serves, others stand by. Simpler — but failover has latency. Global load balancing — route to nearest healthy region. Better latency — but adds a dependency.
Auto-scaling types: Horizontal scaling — add more instances. Stateless workloads, web servers. Vertical scaling — increase instance size. Databases, stateful workloads. Predictive scaling — scale based on forecast. Known traffic patterns (e.g., business hours). Reactive scaling — scale based on metrics. Unpredictable traffic.
Serverless considerations: Cold start — first invocation after idle — latency spike. Execution limits — most platforms limit execution time (15 min on AWS Lambda). Statelessness — no persistent state between invocations. Cost model — pay per invocation × duration × memory.
Cloud patterns trade control for convenience — the question is whether that trade is worth it for your context. Cloud patterns = trading control for convenience — know what you're giving up.
Try it yourself — The pattern check
Which cloud patterns are you using?
| Pattern | In use? | Trade-off accepted? |
|---|---|---|
| Multi-region | ||
| Auto-scaling | ||
| Serverless | ||
| Managed services |
If you're using managed services without assessing lock-in, you're accepting a trade-off you haven't measured.
5. Security design principles — Zero trust, least privilege, defence in depth
Security is often treated as a checklist at the end of design. By then, the architecture has already made security decisions — most of them unconsciously.
Security must be designed in from the start. Three principles guide every security decision:
flowchart TD
SEC["🔒 Security Principles"]
SEC --> ZT["🛡️ Zero Trust\nNever trust, always verify\nEvery request is authenticated\nregardless of network location"]
SEC --> LP["🔑 Least Privilege\nGrant minimum access needed\nRevoke when no longer required"]
SEC --> DID["🏰 Defence in Depth\nMultiple layers of security\nNo single point of failure"]
ZT --> IMPL1["Identity everywhere\nMicro-segmentation\nEncrypted by default"]
LP --> IMPL2["Role-based access\nJust-in-time permissions\nRegular access reviews"]
DID --> IMPL3["Network · Application · Data\nEach layer independently secured\nAssume breach"]
Zero trust — don't trust any network, user, or service by default. Verify every request. Least privilege — give the minimum access needed for the minimum time needed. Defence in depth — assume any single layer can be breached. Secure every layer independently.
Security control categories: Network — segmentation, firewalls, WAF, DDoS protection. VPC, security groups, CloudFlare. Application — input validation, auth, encryption, rate limiting. OAuth, JWT, TLS, OWASP Top 10. Data — encryption at rest/transit, masking, classification. KMS, field-level encryption, DLP. Identity — MFA, SSO, RBAC, service-to-service auth. Azure AD, Okta, SPIFFE. Monitoring — SIEM, intrusion detection, audit logging. Splunk, GuardDuty, CloudTrail. Compliance — standards adherence, audit trails, evidence. SOC 2, ISO 27001, PCI DSS.
Zero trust implementation: Traditional: trust the network → authenticate at perimeter → access everything inside. Zero trust: authenticate every request → authorise per resource → assume breach → log everything.
Security architecture checklist: Every component authenticates its callers (no implicit trust). Every data store encrypts data at rest and in transit. Every API requires authentication and authorisation. Every action is logged with who, what, when, where. Every environment is isolated from production. Every secret is managed — no hardcoded credentials.
Security isn't a product you buy or a checklist you complete — it's a set of design principles applied at every layer. Zero trust + least privilege + defence in depth — the three principles that should appear in every architecture decision.
Try it yourself — The security check
Does your architecture follow the three principles?
| Principle | In place? | Evidence |
|---|---|---|
| Zero trust | ||
| Least privilege | ||
| Defence in depth |
If any principle isn't designed in, you have a security gap.
6. Identity and access management — Authentication, authorisation, and federation
Every request to every component needs to answer two questions: "Who are you?" (authentication) and "What are you allowed to do?" (authorisation). Getting this wrong means either security breaches or user frustration.
Identity and Access Management (IAM) is the infrastructure that answers those questions consistently across the entire system.
flowchart TD
IAM["🔑 Identity & Access Management"]
IAM --> AUTHN["🪪 Authentication\nWho are you?\nPasswords · MFA · Tokens · Certificates"]
IAM --> AUTHZ["📋 Authorisation\nWhat can you do?\nRBAC · ABAC · Policies"]
IAM --> FED["🌐 Federation\nUse identity from another system\nSSO · Social login · SAML · OIDC"]
AUTHN --> IMPL1["Multi-factor\nPasswordless\nService-to-service tokens"]
AUTHZ --> IMPL2["Role-based (RBAC)\nAttribute-based (ABAC)\nPolicy-based"]
FED --> IMPL3["Corporate SSO\nSocial providers\nCross-org trust"]
Authentication — verify identity. MFA is the minimum for human users. Service accounts use tokens or certificates. Authorisation — determine permissions. RBAC for simplicity, ABAC for flexibility, policy-based for fine-grained control. Federation — use identity from external systems. SSO for user convenience, SAML/OIDC for enterprise integration.
Authentication methods: Password — legacy, low-security. Low — vulnerable to phishing, reuse. Password + MFA — standard for most applications. Medium — second factor reduces risk. Passwordless (FIDO2/WebAuthn) — modern, high-security. High — phishing-resistant. Service tokens (JWT/OAuth) — service-to-service. Depends on token management. Certificates (mTLS) — internal service mesh. High — mutual authentication.
Authorisation models: RBAC — users assigned to roles, roles have permissions. Simple access control, clear job functions. ABAC — access based on attributes (user, resource, environment). Complex rules, context-dependent access. Policy-based — policies define who can do what under which conditions. Fine-grained, auditable, infrastructure-as-code.
Federation protocols: SAML 2.0 — enterprise SSO, legacy applications. OpenID Connect (OIDC) — modern web/mobile applications. OAuth 2.0 — API authorisation, delegated access. SPIFFE/SPIRE — service-to-service identity in microservices.
IAM isn't just a security concern — it's an architectural pattern that affects every component, every API, and every user interaction. IAM = authenticate everyone, authorise everything, federate where it makes sense.
Try it yourself — The IAM check
How does your system handle identity?
| Question | Your answer |
|---|---|
| How do users authenticate? | |
| How do services authenticate to each other? | |
| What authorisation model do you use? | |
| Do you federate identity? |
If services don't authenticate to each other, you have implicit trust — which is zero trust's opposite.
7. Cost and lock-in — The hidden trade-offs in every infrastructure decision
Every technology decision has a cost — but cost is often considered after the architecture is designed. By then, the expensive decisions are already made.
Two hidden costs shape every infrastructure decision:
flowchart TD
COST["💰 Hidden Costs"]
COST --> DIRECT["💵 Direct Cost\nWhat you pay the provider\nCompute · Storage · Data transfer\nLicences · Support"]
COST --> LOCK["🔒 Lock-in Cost\nWhat it costs to leave\nMigration effort · Retraining\nData extraction · Redesign"]
DIRECT --> GROW["📈 Costs grow with scale\nWhat seems cheap at POC\nbecomes expensive at production"]
LOCK --> TRAP["🪤 Lock-in trap\nSwitching costs exceed\nthe cost of staying"]
Direct cost — the bill. Compute, storage, data transfer, licences. Often under-estimated because POC costs aren't production costs. Lock-in cost — the exit price. How much would it cost to move to a different provider or technology? This is the cost you pay later.
Every infrastructure decision must answer: "What does this cost today, and what does it cost to change later?"
Cost categories: Compute — VMs, containers, serverless invocations. Often missed: idle capacity, over-provisioning. Storage — databases, object storage, backups. Often missed: data transfer costs, backup storage. Network — data transfer between regions/services. Often missed: egress charges — the #1 cloud bill surprise. Licences — software, support tiers, premium features. Often missed: per-seat licensing that scales with team. Operations — monitoring, logging, alerting tools. Often missed: log volume costs at scale. People — training, hiring, retention. Often missed: skills scarcity premium.
Lock-in assessment: Data lock-in — can I export my data in a standard format? Mitigation: use standard formats, design for portability. API lock-in — am I using provider-specific APIs everywhere? Mitigation: use abstraction layers, open standards. Skill lock-in — does my team only know this provider? Mitigation: cross-train, hire broadly, use portable patterns. Architecture lock-in — is my architecture only possible on this provider? Mitigation: design for portability where cost-effective.
The cheapest option today is often the most expensive option tomorrow — especially if switching costs are hidden. Always calculate the exit cost — not just the entry price.
Try it yourself — The lock-in check
For your key technology choices:
| Technology | Exit cost | Exit path documented? |
|---|---|---|
If you haven't calculated the exit cost, you're locked in — you just don't know the price yet.
8. FinOps and cloud cost management — How cost optimisation is now a first-class architecture concern
Cloud billing is different from on-premises budgeting. Costs are variable, usage-based, and can spike without warning. Without discipline, cloud costs grow faster than value.
FinOps is the practice of bringing financial accountability to cloud spending. It's not just cost-cutting — it's making cost-aware decisions at every level of the architecture.
flowchart TD
FINOPS["📉 FinOps"]
FINOPS --> VIS["👁️ Visibility\nKnow what you spend\nand why"]
FINOPS --> OPT["🔧 Optimisation\nRight-size, reserve, schedule\nEliminate waste"]
FINOPS --> GOV["🏛️ Governance\nBudgets, alerts, policies\nAccountability per team"]
VIS --> TOOLS["Cost dashboards\nTagging strategy\nChargeback / showback"]
OPT --> ACTIONS["Reserved instances\nSpot instances\nAuto-scaling\nScheduling (dev/test off-hours)"]
GOV --> POLICIES["Budget alerts\nCost anomaly detection\nTag enforcement"]
The three phases: Visibility — know what you spend, where, and why. Tag everything. Attribute costs to teams and capabilities. Optimisation — right-size resources, use reserved/spot pricing, schedule non-production environments, eliminate waste. Governance — set budgets, alert on anomalies, make teams accountable for their own cloud spend.
FinOps maturity: Crawl — visibility. Tag resources, create cost dashboards, showback reports. Walk — optimisation. Right-size, reserve capacity, schedule environments, clean up waste. Run — governance. Budgets per team, cost anomaly detection, unit economics, architectural cost modelling.
Optimisation levers: Right-sizing — 20-40% savings. Requires monitoring and adjustment. Reserved instances — 30-70% savings. Commitment — pay even if unused. Spot/preemptible instances — 60-90% savings. Can be terminated at any time. Scheduling — 40-60% savings (non-prod). Requires automation. Deleting unused resources — variable savings. Requires regular audits.
Cost-aware architecture decisions: Data transfer — cross-region and egress are expensive — design data flow to minimise. Serverless vs containers — serverless is cheap at low volume, expensive at high volume. Managed vs self-managed — managed services cost more but reduce operational burden. Caching — reduces database reads and compute — direct cost savings. Batch vs real-time — batch processing is cheaper than real-time streaming.
FinOps isn't a finance function — it's an architectural discipline. Cost-aware architects make different, better decisions. FinOps = visibility + optimisation + governance — making cost a first-class architecture concern.
Try it yourself — The FinOps check
Where is your organisation on the FinOps maturity curve?
| Phase | In place? | Evidence |
|---|---|---|
| Crawl (visibility) | ||
| Walk (optimisation) | ||
| Run (governance) |
If you're not at Crawl, you don't know what you're spending.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ARCH["📐 Architecture Design\nAbstract decisions"]
ARCH --> TECH["🎯 Technology Selection\nChoose what fits your context"]
TECH --> CLOUD["☁️ Cloud Model\nIaaS · PaaS · SaaS · Serverless"]
CLOUD --> INFRA["🏗️ Infrastructure\nCompute · Storage · Network · Environments"]
INFRA --> SEC["🔒 Security\nZero trust · Least privilege · Defence in depth"]
SEC --> COST["💰 Cost Management\nVisibility · Optimisation · Governance"]
COST --> RUN["✅ Running Solution\nSecure · Scalable · Cost-effective"]
The foundation:
Every technology choice is a trade-off — between capability, cost, complexity, and lock-in. No option is free. Choose by fit to context, not by trend. Security must be designed in, not added on — zero trust, least privilege, defence in depth should appear in every architecture decision, not just the security review. Cost is an architectural concern, not a finance concern — FinOps makes cost visible and manageable, but architects must consider cost at design time, not billing time.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Decision |
|---|---|---|
| Technology selection | Choose by fit, not trend | Criteria-based evaluation |
| IaaS | Maximum control, maximum responsibility | Full OS management |
| PaaS | Balanced control and convenience | Focus on code, platform manages rest |
| SaaS | Minimum control, minimum responsibility | Buy and configure |
| Serverless | No servers, pay per execution | Stateless, event-driven |
| Compute | Where code runs | VMs, containers, or functions |
| Storage | Where data lives | Block, object, file, or database |
| Networking | How components connect | VPCs, load balancers, CDN |
| Zero trust | Never trust, always verify | Authenticate every request |
| Least privilege | Minimum access, minimum time | RBAC, ABAC, just-in-time |
| Defence in depth | Multiple independent layers | Network + app + data security |
| IAM | Authenticate, authorise, federate | MFA, RBAC, SSO |
| Lock-in | The exit cost | Data, API, skill, architecture |
| FinOps | Cost as architecture concern | Visibility + optimisation + governance |
How to know if this landed
You'll know this has landed when someone stops choosing technology by trend and starts choosing by fit to context. Technology selections are documented with rationale — not just "we chose X." Security principles (zero trust, least privilege, defence in depth) appear in architecture decisions. Every component authenticates its callers — no implicit trust. Cloud costs are visible per team and per capability — not just a single bill. Non-production environments are scheduled off outside business hours. Lock-in is assessed for every significant technology choice — exit paths are documented. And infrastructure is managed as code — environments are reproducible.
What changes when the mental model clicks
I've run this session with a financial services platform migrating to cloud — on-premises infrastructure with 18-month refresh cycles and manual provisioning. Security was perimeter-based — everything inside the firewall was trusted. Cloud costs after initial migration were 3x the projected budget — no cost visibility, no tagging. Vendor lock-in to a proprietary database made any future migration a multi-year programme. The gap at the start is usually not about understanding cloud — it's about not designing for cost and lock-in from the start.
What changes after this session:
Teams stop treating cost as a finance concern and start treating it as an architectural concern. The technology selection exercise — "what criteria, what alternatives, what trade-offs?" — is always the moment things click. People stop treating security as a checklist and start treating it as a design principle. Their results get better. They stop getting surprised by cloud bills when the real problem was that they hadn't tagged resources.
The FinOps exercise tends to immediately change how teams think about their cloud spend. They start tagging everything, creating dashboards, scheduling non-prod environments. Their costs go down. They stop treating cloud costs as inevitable when the real problem was that they hadn't made cost visible.
Book a Workshop
Ready to make technology, infrastructure, and security design deliberate?
or
2-day workshop includes technology selection exercise — apply the framework to your real decisions, cloud model assessment — where on the IaaS/PaaS/SaaS spectrum fits your context, infrastructure design workshop — compute, storage, networking, environments, security design review — zero trust, least privilege, defence in depth applied to your architecture, IAM design — authentication, authorisation, federation for your system, cost and lock-in analysis — calculate TCO and exit costs for your key choices, FinOps setup — tagging, dashboards, and governance for your cloud spend, and infrastructure decision framework + cloud pattern reference + security controls map.