← Vissza az AWS Cloud oldalra

Landing Zone + Amazon Bedrock — egy accountos referencia architektúra

Bevezetés

AWS Landing Zone + Bedrock architektúra áttekintő diagram
Kattintson a képre a teljes méretű diagram megnyitásához.

Ez az architektúra minta egyetlen AWS workload accountban összevonja a vállalati Landing Zone alapokat, egy hostolt alkalmazást és a privát Amazon Bedrock integrációt. A cél: auditálható, több zónás, defense-in-depth hálózat és zárt AI-szolgáltatás-elérés VPC Interface Endpointokon keresztül.

A referencia modell a klasszikus enterprise Landing Zone szolgáltatások (identitás, peremhálózat, naplózás, titkosítás, költségirányítás) és a generatív AI workload (Amazon Bedrock, Knowledge Bases, Agents) együtt élnek. A workload eu-central-1 régióban fut; a Bedrock szolgáltatás régiója a diagramon us-east-1 jelöléssel szerepel — ez tükrözi a gyakori gyakorlatot, amikor a foundation model katalógus vagy a szolgáltatás elérhetősége miatt külön régiót választunk, miközben a VPC endpointok és az alkalmazás subnetek Frankfurtban maradnak.

A forgalom két fő ingress útvonalon érkezik: nyilvános internet (CloudFront → ALB → NWFW) és on-premise Site-to-Site VPN. Mindkét útvonal a Network Firewall (NWFW) inspection subneteken keresztül halad, mielőtt elérné az Application Load Balancert vagy a compute réteget. A Bedrock API hívások nem mennek ki az internetre: dedikált Interface VPC Endpointok (runtime, agent-runtime, control, agent-control) biztosítják a privát, IAM-alapú elérést.

2. Architektúra hatókör és feltételezések

  • Account modell: egy workload account (Organizations tag/account szintű governance a diagram bal oldalán).
  • Hálózat: egy Workload VPC, két Availability Zone, szegmentált subnet rétegek.
  • Compute: EC2, ECS/Fargate és Lambda párhuzamosan — tipikus hibrid migrációs vagy modernizációs állapot.
  • Adat: RDS Multi-AZ (primary AZ A, standby AZ B), opcionális Aurora pgvector a RAG alternatívájaként.
  • Megfelelőség: CIS / AWS Foundational Security Best Practices (FSBP) aggregáció Security Hubban; GDPR-kompatibilis naplóarchívum.

3. Identitás, hozzáférés és governance

3.1 Identity & Access

A felhasználók és adminisztrátorok IAM Identity Center (SSO) felől érkeznek, külső IdP-vel (Azure AD / Okta) SAML/SCIM integrációval. Az account szintű IAM szerepkörök és policy-k least-privilege elven épülnek; az AWS Organizations lehetővé teszi a tag policy-k és account guardrail-ek későbbi multi-account kiterjesztését anélkül, hogy az azonnali workload elrendezés bonyolódna.

3.2 Cost & Governance

AWS Budgets és Cost Explorer költségkereteket és eltéréseket figyel; a Tag Policies és Resource Groups egységes címkézést kényszerítenek (környezet, cost center, adatosztály), ami elengedhetetlen a FinOps és a Bedrock modell-használat allokációjához.

4. Peremhálózat, DNS és bejövő forgalom

4.1 DNS & Edge

A Route 53 public és private hosted zone-okat kezel. Az ACM TLS tanúsítványokat szolgáltat az ALB és CloudFront számára. Az AWS WAF és Shield Standard a webes réteg DDoS és OWASP-szerű védelmét erősíti a CloudFront/ALB előtt.

4.2 Ingress flow (piros vonalak a diagramon)

  1. Internet → CloudFront (globális edge) → ALB subnet.
  2. Internet → IGW → NWFW (FW subnet) → NAT GW / ALB irány.
  3. On-premise → Site-to-Site VPN → NWFW → belső célok (pl. EC2).

A Network Firewall (NWFW) AZ A és AZ B FW subnetjeiben stateful szabályokkal szűr a forgalmat — ez a központi inspection pont az IGW és a workload subnetek között.

5. Workload VPC — hálózati zónák

A NAT Gateway AZ-onként egy-egy példányt kap az outbound internethez (patch, külső API — nem Bedrock). A VPC Endpoints (S3 Gateway, KMS, SSM, CloudWatch Logs) és a VPC Flow Logs csökkentik a nyilvános útvonalat és növelik a láthatóságot. A compute rétegből az ALB → EC2/ECS/Lambda → RDS Primary forgalom a diagram kék (solid) vonalaival van jelölve; az RDS Primary ↔ Standby szinkron replikáció Multi-AZ-t valósít meg.

6. Biztonság, audit és naplóarchitektúra

6.1 Audit Sources → Aggregator

A CloudTrail management és data plane eseményeket rögzít; a AWS Config erőforrás-konfigurációt snapshot-ol S3-ba és findingeket küld a Security Hub felé (CIS / FSBP). A GuardDuty és az IAM Access Analyzer további finding források. A Security Hub központosítja a megfelelőségi állapotot, és riasztást küld SNS-en (e-mail / ticketing integráció).

6.2 Log Storage & Encryption

A S3 Log Archive Object Lock-kal és SSE-KMS titkosítással hosszú távú, manipulációálló tárolást ad; külön bucket a Config snapshotoknak. A KMS CMK és Secrets Manager az alkalmazás- és adatréteg titkok kezelését szolgálja — beleértve a Bedrock invocation és agent konfiguráció érzékeny adatait is.

6.3 Monitoring & Operations

A CloudWatch metrikák és logok az operatív riasztások alapjai; a Systems Manager patch, session manager és parameter store funkciókat lát el az EC2 fleet felé. Az AWS Backup central vault-ból RDS (és egyéb) védett másolatokat készít — a diagram szürke (dashed) vonalai a governance/audit adatfolyamokat jelölik.

7. Amazon Bedrock — privát AI réteg

7.1 VPC Interface Endpoints (AI subnet)

Mindkét AZ AI subnetjében négy Interface VPC Endpoint található: bedrock-runtime, bedrock-agent-runtime, bedrock-control, bedrock-agent-control. Az alkalmazás subnetekből (Lambda/ECS) érkező hívások PrivateLink-en keresztül érik el a Bedrock szolgáltatást — nincs nyilvános IP a modell inferenciához.

7.2 Bedrock Core és Foundation Models

A Bedrock szolgáltatás és a Bedrock Guardrails a felelős AI használat alapkövei (tartalomszűrés, denied topics, PII maszkolás). A Foundation Models réteg több modellt támogat: Claude, Llama 3, DeepSeek, Titan Text/Embed — modellválasztás workload és adatvédelmi követelmény szerint.

7.3 Knowledge Bases (RAG)

A Bedrock Knowledge Base S3-ból származó forrás dokumentumokat indexel; a vektor tároló OpenSearch Serverless (elsődleges) vagy alternatívaként Aurora PostgreSQL pgvector. A retrieval-augmented generation így teljesen AWS-n belül marad, auditálható S3 és CloudTrail lábon.

7.4 Agents és Action Groups

A Bedrock Agent orchestrálja az eszközhasználatot: Lambda Action Group, API Gateway (OpenAPI schema) vagy S3-ban tárolt API schema. Ez lehetővé teszi a vállalati rendszerek biztonságos, IAM-határolt integrációját anélkül, hogy az LLM közvetlenül kapna hálózati hozzáférést.

7.5 Invocation Logging

A Bedrock invocation logok CloudWatch Logs-ba és archív S3 bucketbe kerülnek; a CloudTrail külön auditálja a Bedrock API műveleteket. Ez összhangban van a GDPR/NIS2 dokumentálhatósági elvárásokkal és az incidens-válasz (forensics) igényével.

8. Kulcs architektúra-döntések (AWS Well-Architected)

  • Biztonság: Defense in depth — WAF, NWFW, private subnetek, VPC endpoints, KMS, Guardrails.
  • Megbízhatóság: Multi-AZ ALB, NAT, RDS; stateless compute horizontális skálázással.
  • Teljesítmény: CloudFront edge cache; Bedrock endpoint AZ-colocated; RDS read path optimalizálható.
  • Költség: NAT GW és NWFW fix költség — FinOps monitoring kötelező; Bedrock token-alapú költség tag-elés.
  • Üzemeltetés: Központi naplózás, Security Hub, SSM — IaC (Terraform) ajánlott a diagram „AI-assisted IaC” céljával összhangban.

9. Következő lépések (multi-account evolúció)

Ez az egy accountos referencia gyors indulást ad. Produkciós enterprise környezetben jellemző a szétválasztás: Management, Network, Log Archive, Security Tooling és Workload accountokra — a jelenlegi diagram komponensei közvetlenül map-elhetők Terraform IaC modulokra. A Bedrock endpoint policy-k és SCP-k segítségével account szinten lehet korlátozni a model ID-kat és régiókat.

Introduction

AWS Landing Zone + Bedrock architecture overview diagram
Click the image to open the full-size diagram.

This architecture pattern consolidates enterprise Landing Zone foundations, a hosted application, and private Amazon Bedrock integration in a single AWS workload account. The goal is an auditable, multi-AZ, defense-in-depth network with closed AI service access via VPC interface endpoints.

The reference model combines classic enterprise Landing Zone services (identity, perimeter networking, logging, encryption, cost governance) with a generative AI workload (Amazon Bedrock, Knowledge Bases, Agents). The workload runs in eu-central-1; the Bedrock service region is labeled us-east-1 on the diagram — reflecting common practice when a separate region is chosen for foundation model catalog or service availability, while VPC endpoints and application subnets remain in Frankfurt.

Traffic arrives on two main ingress paths: public internet (CloudFront → ALB → NWFW) and on-premises Site-to-Site VPN. Both paths pass through Network Firewall (NWFW) inspection subnets before reaching the Application Load Balancer or compute tier. Bedrock API calls do not traverse the internet: dedicated interface VPC endpoints (runtime, agent-runtime, control, agent-control) provide private, IAM-based access.

2. Architecture scope and assumptions

  • Account model: one workload account (Organizations tag/account-level governance on the left of the diagram).
  • Network: one workload VPC, two Availability Zones, segmented subnet tiers.
  • Compute: EC2, ECS/Fargate, and Lambda in parallel — typical hybrid migration or modernization state.
  • Data: RDS Multi-AZ (primary in AZ A, standby in AZ B), optional Aurora pgvector as a RAG alternative.
  • Compliance: CIS / AWS Foundational Security Best Practices (FSBP) aggregation in Security Hub; GDPR-compatible log archive.

3. Identity, access, and governance

3.1 Identity & Access

Users and administrators authenticate via IAM Identity Center (SSO) with an external IdP (Azure AD / Okta) using SAML/SCIM integration. Account-level IAM roles and policies follow least privilege; AWS Organizations enables tag policies and account guardrails for later multi-account expansion without complicating the immediate workload layout.

3.2 Cost & Governance

AWS Budgets and Cost Explorer track budgets and variances; tag policies and resource groups enforce consistent tagging (environment, cost center, data classification), which is essential for FinOps and allocating Bedrock model usage.

4. Perimeter, DNS, and ingress

4.1 DNS & Edge

Route 53 manages public and private hosted zones. ACM provides TLS certificates for the ALB and CloudFront. AWS WAF and Shield Standard strengthen DDoS and OWASP-style protection in front of CloudFront/ALB.

4.2 Ingress flow (red lines on the diagram)

  1. Internet → CloudFront (global edge) → ALB subnet.
  2. Internet → IGW → NWFW (FW subnet) → NAT GW / ALB path.
  3. On-premises → Site-to-Site VPN → NWFW → internal targets (e.g. EC2).

Network Firewall (NWFW) in AZ A and AZ B FW subnets filters traffic with stateful rules — the central inspection point between the IGW and workload subnets.

5. Workload VPC — network zones

NAT Gateway has one instance per AZ for outbound internet (patching, external APIs — not Bedrock). VPC endpoints (S3 gateway, KMS, SSM, CloudWatch Logs) and VPC flow logs reduce public paths and improve visibility. From the compute tier, ALB → EC2/ECS/Lambda → RDS primary traffic is shown with blue (solid) lines on the diagram; RDS primary ↔ standby synchronous replication delivers Multi-AZ.

6. Security, audit, and logging architecture

6.1 Audit sources → aggregator

CloudTrail records management and data plane events; AWS Config snapshots resource configuration to S3 and sends findings to Security Hub (CIS / FSBP). GuardDuty and IAM Access Analyzer are additional finding sources. Security Hub centralizes compliance posture and sends alerts via SNS (email / ticketing integration).

6.2 Log storage & encryption

S3 log archive with Object Lock and SSE-KMS provides long-term, tamper-resistant storage; a separate bucket holds Config snapshots. KMS CMK and Secrets Manager manage application and data-tier secrets — including sensitive Bedrock invocation and agent configuration data.

6.3 Monitoring & operations

CloudWatch metrics and logs underpin operational alerts; Systems Manager delivers patching, Session Manager, and Parameter Store for the EC2 fleet. AWS Backup creates protected copies of RDS (and other resources) from a central vault — gray (dashed) lines on the diagram denote governance/audit data flows.

7. Amazon Bedrock — private AI layer

7.1 VPC interface endpoints (AI subnet)

Each AZ AI subnet hosts four interface VPC endpoints: bedrock-runtime, bedrock-agent-runtime, bedrock-control, bedrock-agent-control. Calls from application subnets (Lambda/ECS) reach Bedrock over PrivateLink — no public IP for model inference.

7.2 Bedrock core and foundation models

Bedrock and Bedrock Guardrails are the foundation of responsible AI use (content filtering, denied topics, PII masking). The foundation models layer supports multiple models: Claude, Llama 3, DeepSeek, Titan Text/Embed — model choice follows workload and privacy requirements.

7.3 Knowledge bases (RAG)

Bedrock Knowledge Base indexes source documents from S3; vector storage uses OpenSearch Serverless (primary) or alternatively Aurora PostgreSQL pgvector. Retrieval-augmented generation stays entirely within AWS, with auditable S3 and CloudTrail trails.

7.4 Agents and action groups

Bedrock Agent orchestrates tool use: Lambda action group, API Gateway (OpenAPI schema), or API schema stored in S3. This enables secure, IAM-bounded integration with enterprise systems without granting the LLM direct network access.

7.5 Invocation logging

Bedrock invocation logs go to CloudWatch Logs and an archive S3 bucket; CloudTrail separately audits Bedrock API operations. This aligns with GDPR/NIS2 documentation requirements and incident response (forensics) needs.

8. Key architecture decisions (AWS Well-Architected)

  • Security: Defense in depth — WAF, NWFW, private subnets, VPC endpoints, KMS, Guardrails.
  • Reliability: Multi-AZ ALB, NAT, RDS; horizontally scaled stateless compute.
  • Performance: CloudFront edge cache; Bedrock endpoints AZ-colocated; RDS read path can be optimized.
  • Cost: NAT GW and NWFW fixed cost — FinOps monitoring required; tag Bedrock token-based spend.
  • Operations: Centralized logging, Security Hub, SSM — IaC (Terraform) recommended, aligned with the diagram’s “AI-assisted IaC” goal.

9. Next steps (multi-account evolution)

This single-account reference enables a fast start. In production enterprise environments, separation into Management, Network, Log Archive, Security Tooling, and Workload accounts is typical — components on the current diagram map directly to Terraform IaC modules. Bedrock endpoint policies and SCPs can restrict model IDs and regions at the account level.