About this article
This article is the eighth deep dive in the “System Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering the security foundation to weave through the infrastructure layer.
WAF, DDoS protection, IDS/IPS, IAM, encryption, secrets management — layered into defense in depth — is the basis. Adding it later sends costs through the roof. This article maps the functions to build in at the system-architecture stage; per-area deep dives (auth methods, authorization models, crypto algorithms, vulnerability assessment) live in the “Security Architecture” category.
More articles in this category
“We’re too small to be a target” is the most dangerous belief
Public IP addresses are scanned by bots 24/7/365. Even tiny personal services become targets for brute force, vulnerability scans, and port scans the moment they go public. “Nobody knows about us yet, so we’re fine” is a premise that has never held on the Internet.
A small validation API server gets thousands of scan accesses logged within 24 hours of going public — not unusual. Attackers aren’t humans, they’re bots, and they scan all IPs in order without picking targets. Regardless of scale, “target the moment you publish” is the correct framing.
Security is “unbolted-on-able.” Build it in from day one — that’s the rule.
Scope of this article
This article focuses on “the system-architecture-stage map of which security functions to embed in the infrastructure layer.” Per-area deep dives (auth methods, authorization models, crypto algorithms, vulnerability assessment, etc.) are all consolidated in the “Security Architecture” category articles.
| Per-area | Deep-dive location |
|---|---|
| Auth (MFA / Passkey / SSO) | Auth design (other category) |
| Authorization / IAM (RBAC / least privilege) | Authorization & IAM (other category) |
| Encryption (TLS / KMS / key management) | Encryption (other category) |
| WAF / DDoS / IDS/IPS / VPN | Network security (other category) |
| Zero Trust / ZTNA | Zero Trust (other category) |
| Secrets management | Secrets management (other category) |
| Vulnerability assessment / SBOM | Vulnerability assessment (other category) |
The question for this article is “where in the system architecture do you put what?” Concrete selections are in the other category’s articles.
Defense in Depth
Defense in depth is the principle of stopping attacks across multiple layers rather than relying on a single line. Build multiple gates from edge to interior so that breaching one stops at the next.
flowchart TB
NET([Internet<br/>= the world incl. attackers]) --> WAF
WAF[WAF<br/>SQLi / XSS block]
DDOS[CDN / DDoS<br/>Absorb mass requests]
ALB[ALB / SG / NACL<br/>Port / IP / protocol control]
AUTH[App authN/authZ<br/>User & permission check]
DB[(DB encryption<br/>Data-itself protection)]
WAF --> DDOS --> ALB --> AUTH --> DB
classDef threat fill:#fee2e2,stroke:#dc2626;
classDef edge fill:#fef3c7,stroke:#d97706;
classDef net fill:#f0f9ff,stroke:#0369a1;
classDef app fill:#dbeafe,stroke:#2563eb;
classDef data fill:#fae8ff,stroke:#a21caf;
class NET threat;
class WAF,DDOS edge;
class ALB net;
class AUTH app;
class DB data;Stopping everything at the entrance is unrealistic. “Assume something gets breached somewhere” and design for damage minimization. The cloud-security default is defense in depth + Zero Trust. Configurations outside this aren’t getting picked anymore.
Don’t stop attacks at one wall. Designs where the next layer holds when the previous breaks are the basis.
Major security-foundation building blocks
The list of components to “decide what goes where” at system-architecture design time. Detailed selection (products, settings, ops rules) is in the other-category articles. Use this for placement and gap-checking.
| Layer | Function | Examples |
|---|---|---|
| Edge (L7) | WAF | AWS WAF / Cloudflare / Akamai |
| Edge (L3/L4) | DDoS / CDN | CloudFront / Cloudflare / Shield |
| Network internal | IDS/IPS / micro-segment | GuardDuty / Network Firewall |
| Access control | ZTNA (Zero Trust Network Access) | Cloudflare Access / Zscaler |
| Identity | SSO + IAM Role + MFA | Okta / Entra ID / IAM Identity Center |
| Secrets | Key management / secrets | Secrets Manager / Vault / KMS |
| Data | TLS / at-rest encryption / CMK | ACM / KMS / CloudHSM |
| Continuous audit | Vulnerability scan / SBOM / CSPM | Dependabot / Trivy / Security Hub |
System-architecture design must answer every row at minimum. “Later” does not exist.
List compliance requirements before design
Industry, geography, and customer requirements set the security baselines you must meet. Certification takes time and money, so listing them at design time prevents major rebuilds later. This sits at system-architecture’s first decision rather than per-area deep dives, so it’s covered here.
| Standard | Applies to |
|---|---|
| PCI DSS | Systems handling credit-card payments |
| ISMS / ISO 27001 | General information security; corporate certification |
| Personal Data Protection laws / GDPR | Personal data |
| SOC 2 | SaaS provider security / availability |
| HIPAA | Healthcare data (US) |
| Government Cloud | Japanese government / municipalities |
A SaaS provider getting SOC 2 Type II dramatically improves enterprise sales. SaaS targeting Japanese finance / public sector often must comply with ISMS + FISC (Financial Information Systems Center safety standards). Deciding SOC 2 after launch produces months of delay redesigning logging.
Phase-by-phase security adoption roadmap
“Everything at once” is unrealistic. Required vs recommended by phase. Below is in order of incident-likelihood without it.
| Phase | Top priority | Next | Monthly cost |
|---|---|---|---|
| 1 MVP / individual | HTTPS (Let’s Encrypt), MFA, IAM Roles, Dependabot | WAF (Cloudflare free), Secret Scanning | $0 |
| 2 Small SaaS | + AWS WAF / Shield Standard, Secrets Manager, CloudTrail | + GuardDuty, Config, SSO | $300+ |
| 3 Mid-sized SaaS | + Security Hub, SIEM (log aggregation), vulnerability scan in CI | + SOC 2 Type II, ISMS prep, Policy as Code | $3k+ |
| 4 Enterprise | + 24/7 SOC, DLP, Zero Trust (ZTNA) | + Red Team / annual pentest | $30k+ |
| 5 Regulated industries (finance, healthcare, public) | Industry certifications (FISC / HIPAA / Government Cloud) mandatory from day one | — | Variable |
MFA, Dependabot, Secret Scanning, HTTPS — these four are mandatory even at MVP. Postponing means hours-after-launch IAM-key leaks and dependency-chain intrusion. The December 2021 Log4Shell (Log4j CVE-2021-44228) demonstrated how one library vulnerability cascaded into chained attacks worldwide.
Even at MVP, install MFA, Secret Scanning, Dependabot, HTTPS day one. “Later” does not exist.
System-architecture-stage traps
Per-product configuration mistakes go to the other category. This article lists canonical system-architecture-stage incidents. The decision mistakes the architect needs to avoid first.
| Forbidden move | Why |
|---|---|
| Listing security requirements late in design | SOC 2 / FISC requirements ripple back to logging and network-segmentation design. Late discovery causes months of rework |
| Production and dev in the same account | Dev mistakes propagate to prod. AWS: separate by Organization from day one |
| Public bastion without IP restriction | Brute-force will find it. Use SSM Session Manager or ZTNA — eliminate the bastion |
| MFA only for some admins | One MFA-less admin becomes the entry point |
| CloudTrail / audit logs in the production account | Compromised attackers wipe logs. Different account + Object Lock required |
| Long-term IAM access keys | One key leak = full takeover. OIDC + IAM Role short-lived tokens are the modern default |
| TLS 1.0 / 1.1 left enabled | Customer audits and financial certifications fail. TLS 1.2 minimum, ideally 1.3 |
| Security infra managed via GUI without code | No change history, not reproducible. Lean on Terraform / CDK + Policy as Code |
The 2022 Okta breach (some customers’ credentials accessed via a support contractor) and LastPass leak (encrypted vault copies in attacker hands) demonstrate that even security companies get breached. Design assuming “we won’t get breached” does not hold.
Design-stage decision errors become multi-month remediation projects after launch. No compromise on the first design.
The AI-era lens
With AI-driven development as the assumption, security foundation’s deciding axis becomes “can it be expressed as Policy as Code?”
WAF rules, IAM policies, network ACLs, encryption policies — declared in code, with the workflow “AI generates -> human reviews -> CI static-analyzes.” Click-through GUI security tools leave no change history, can’t be reviewed by AI, and are obsolete.
| AI-era favorable | AI-era unfavorable |
|---|---|
| Policy as Code (OPA — Open Policy Agent, Cedar — AWS authorization language, tfsec — Terraform static analysis) | GUI-set proprietary security products |
| OIDC (standard auth protocol) federation, short-lived tokens | Long-term IAM keys in Secrets management |
| CSPM (Cloud Security Posture Management — automated cloud misconfig detection) | Manual audit, Excel inventories |
| SBOM (Software Bill of Materials), SLSA (supply-chain integrity) for vulnerability management | Custom-format vulnerability ledgers |
Conversely, AI-generated code carries hallucination risks (calling non-existent libraries, using deprecated auth APIs). SAST (Static Application Security Testing) and dependency scanning (Dependabot/Snyk) must be in CI, with the guard “do not deploy AI-generated code unverified.”
In the AI era, “security is also code.” GUI-only security products don’t get picked.
Common misreadings
- “Small services aren’t on attackers’ radar” -> Attackers are bots, not humans, scanning all IPs in order regardless of target. Independent of scale, “target the moment you publish.”
- “Inside the corporate LAN is safe” -> Endpoint malware infections, insider threats, VPN leaks make corporate LAN “thinly internet.” Zero Trust is the assumption.
- “WAF means we don’t need app-side protection” -> WAF is one barrier. Skipping SQL-injection and authorization checks in the app is a landmine.
- “Security is for the operations phase” -> IAM, encryption, logging design are inseparable from initial architecture. Bolting on is multi-month remediation — a soft choice.
”Public repo for hours” (industry case)
A new engineer accidentally pushed a script with AWS access keys to a public repo, and within hours, attackers had spun up tens of thousands of dollars of EC2 instances for crypto mining. Reported repeatedly in many countries.
The moment it lands on GitHub, bots scrape within seconds. Even after deletion, Git history retains it.
The lesson: “noticing and deleting is too late.” Detect at pre-push hooks, or — better — never issue long-term keys (OIDC / temporary credentials only). Security’s “I’ll be careful” falls apart the moment it depends on human attention.
Don’t rely on individual willpower. Defend through structure. That’s the rule.
What you must decide — what’s your project’s answer?
Articulate your project’s answer in 1-2 sentences for each:
- Compliance requirements (SOC 2 / ISMS / PCI DSS, etc.)
- Per-layer products in defense in depth (WAF / DDoS / IDS/IPS)
- ZTNA adoption (timing of VPN migration)
- IAM strategy (SSO / Role / MFA mandatory scope)
- Secrets-management foundation (Secrets Manager / Vault)
- Encryption policy (in-transit / at-rest / app-layer)
- Audit-log isolated-account storage and WORM
- Scope of Policy as Code adoption
Per-item concrete selections live in the “Security Architecture” category articles.
How to make the final call
Security foundation’s selection core is the constraint “can’t be added later.” Changing auth methods, encrypting all data, applying WAF to every API after launch is months of major construction; build it in at design time and don’t skimp on initial cost.
The optimism “we’re too small to be a target” doesn’t hold; reverse from the reality that public IPs are scanned 24/7/365 by bots.
The basis is the three-piece set “defense in depth + least privilege + Zero Trust.” No alternative. Concretely: layer with WAF/CDN/SG, IAM via SSO + Role to remove long-term keys, replace internal-LAN-assumption VPN with ZTNA.
This article’s role is the building-block map; per-layer product selection, settings, and operations live in the dedicated other-category articles. For AI-driven development, ability to express security policy as code (Policy as Code) is the absolute requirement; GUI-only products fail review and audit.
Selection priority:
- List compliance requirements first and embed in design.
- Each layer of defense in depth (edge / network / Identity / data) gets a “who owns this” assignment.
- IAM strategy: SSO + Role switching as default; long-term keys are exceptions.
- Policy-as-Code support as a check item for every product selection.
“Built in at design time, expressed as code in operations.” Security isn’t bolted on — it’s there from the first line.
Summary
This article covered the security foundation map at the system-architecture stage — defense in depth, compliance, phase-by-phase roadmap, and the AI-era angle.
Security cannot be bolted on, so build it in from line one of the design. Even at MVP, MFA, Dependabot, Secret Scanning, HTTPS are mandatory day one; further layers stack as scale and industry require.
The next article covers monitoring and operations (the three pillars of observability, the four golden signals).
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (13/89)