Case study — illustrative reference architecture
Secure Cloud Migration
Modernizing a legacy on-premises business application into a segmented, observable cloud design.
Context
Scenario & business problem
Scenario
A hypothetical mid-size organization runs a legacy business application on aging on-premises infrastructure with a single database server, manual deployments, and limited recovery capability.
Business problem
Hardware is out of support, outages are recovered manually, and the team cannot evidence recovery capability or access control. The organization needs a target architecture that reduces infrastructure dependency while improving security, availability, and operational visibility — without a cost profile it cannot forecast.
Business drivers
- Reduce dependency on end-of-life on-premises infrastructure
- Improve application availability during component failure
- Strengthen security boundaries and access control
- Improve recovery capability with tested restores
- Support future scaling without re-platforming again
- Improve observability across application, data, and network tiers
- Control and forecast cloud cost
Current-state challenges
- Single database server with no automated failover
- Backups written to the same site as the primary system
- Credentials stored in application configuration files
- Flat internal network with no tier segmentation
- Manual releases with no repeatable rollback
- Logs held locally on each host and lost on rebuild
Who is affected
Stakeholders
Executive Sponsor
Predictable cost and a defensible modernization timeline.
Application Team
Deployment velocity and stable non-production environments.
Security Engineering
Segmentation, encryption, secrets handling, and audit evidence.
Cloud Operations
Runbooks, alerting quality, and a supportable operating model.
Identity Team
Central identity, no shared accounts, reviewable privileged access.
Finance / FinOps
Tagging, budgets, and visibility of run-rate by environment.
Analysis
Requirements, assumptions & constraints
Functional behaviour is separated from measurable quality attributes so that tradeoffs can be argued against numbers rather than opinions.
Functional requirements
- Serve the existing business workflows without functional regression
- Expose service APIs consumed by internal back-office tooling
- Support scheduled batch reporting against a read replica
- Provide role-based access to administrative functions
- Retain document attachments with integrity verification
- Support environment promotion from development through production
Non-functional requirements
- Availability objective of 99.9% for the customer-visible tier
- Recovery time objective of 4 hours; recovery point objective of 15 minutes
- All data encrypted in transit and at rest with managed keys
- No administrative access without multi-factor authentication
- Centralized log retention of 12 months for security-relevant events
- Horizontal scale to three times current peak throughput
Assumptions
- Application can run in containers without source rewrite
- A single cloud region with multiple availability zones is sufficient
- Existing identity provider can federate to the cloud platform
- Data volumes remain under the managed database service ceiling
Constraints
- Small operations team with limited platform engineering capacity
- Migration cutover limited to a weekend maintenance window
- Legacy reporting tool requires SQL connectivity
- Capital spend frozen; costs must move to operating expenditure
Guardrails
Architecture principles
Private by default; public exposure is an explicit decisionManaged services before self-managed infrastructureEvery environment reproducible from source controlTelemetry centralized before migration, not after
Design
Target architecture
Components, trust zones, and the flows that cross their boundaries.
Target architecture — segmented cloud landing zone
Business traffic enters through an edge and web application firewall, where the public TLS session is terminated and inspected. The edge then re-encrypts traffic over a second TLS session to the application load balancer and onward to the private application tier; the data tier is reachable only from that application tier. Identity, secrets, telemetry, and delivery are shared platform services on a separate control path.
Zone 1 — Public edge
Internet-facing, WAF inspectedBusiness users
Browser and back-office clients
Edge / WAF
Public TLS session terminates here for inspection: rate limiting, OWASP rules, then re-encryption to the load balancer
Application load balancer
Accepts the re-encrypted TLS session from the edge only; multi-zone, health-checked private targets
Zone 2 — Private application tier
Private — no direct internet exposure, ingress only from the load balancerWeb / presentation service
Containers across 3 availability zones
API & service tier
Internal service endpoints, mTLS between services
Batch & scheduled jobs
Reporting extracts against replica
Zone 3 — Private data tier
Private — no direct internet exposure, reachable only from the application tierManaged relational database
Primary with synchronous standby
Read replica
Reporting and analytical reads
Object storage
Attachments, versioned, lifecycle policies
Backup vault
Cross-region copies, immutability window
Zone 4 — Shared platform services
Control and governance planeIdentity provider
Workforce SSO, MFA, RBAC groups
Managed secrets & keys
Rotation, per-environment scoping
Central logging & metrics
12-month retention, correlated traces
Deployment pipeline
Build, scan, approve, deploy, roll back
Cost governance
Tagging policy, budgets, anomaly alerts
Flows & boundaries
- Business users Edge / WAFStep 1 — public HTTPS session, terminated and inspected at the edgeRuntime data path
- Edge / WAF Application load balancerStep 2 — filtered traffic re-encrypted over a second TLS sessionRuntime data path
- Application load balancer Web / presentation serviceStep 3 — TLS into the private subnet, security-group scoped targetsRuntime data path
- Web / presentation service API & service tierStep 4 — internal service calls over mTLSRuntime data path
- API & service tier Managed relational databaseStep 5 — TLS, least-privilege database rolesRuntime data path
- Batch & scheduled jobs Read replicaScheduled reporting extracts read from the replica, never the primaryRuntime data path
- API & service tier Object storageAttachment read/write over private endpointsRuntime data path
- Identity provider Web / presentation service & API tierSide flow — SSO assertion + MFA claim validated on every sessionAuthentication / authorization
- API & service tier Managed secrets & keysSide flow — runtime credential and key retrieval, no config filesControl & telemetry
- Application tier (all services) Central logging & metricsSide flow — structured logs, metrics, traces and audit eventsControl & telemetry
- Deployment pipeline Application tierManagement plane, not runtime traffic — signed artifacts promoted through an approval gateDeployment / management plane
- Managed relational database Backup vaultBackup — continuous backup, 15-minute recovery point, cross-region copyBackup & recovery
- Object storage Backup vaultBackup — versioned object replication into the immutability windowBackup & recovery
- Backup vault Managed relational database / Object storageRecovery — restore path exercised during recovery rehearsalsBackup & recovery
Controls
Security, resilience & operational controls
Identity & access
- Workforce SSO
- Federated sign-in with MFA; no local application accounts.
- Role-based access
- Group-driven roles for read, operate, and administer.
- Just-in-time admin
- Elevation is requested, time-bound, and logged.
Network segmentation
- Three-zone subnet model
- Public edge, private application, private data.
- Security groups
- Tier-to-tier rules only; no lateral any-to-any paths.
- Private service endpoints
- Platform services reached without internet egress.
Data protection
- Encryption in transit
- TLS everywhere including service-to-service calls.
- Encryption at rest
- Managed keys with rotation and separated key administration.
- Secrets management
- Managed secrets service replaces configuration-file credentials.
Resilience & recovery
- Multi-zone deployment
- Application and database standby in separate zones.
- Backup and restore
- Automated backups with quarterly timed restore tests.
- Disaster recovery
- Cross-region copies with a documented rebuild runbook.
Operations & governance
- Centralized logging
- Application, platform, and audit logs in one searchable store.
- Monitoring and alerting
- Golden-signal alerts routed to an on-call rotation.
- Cost governance
- Mandatory tagging, per-environment budgets, anomaly alerts.
Honesty
Tradeoff analysis
Every architectural gain is paid for somewhere. These are the bills.
| Choice | What it gains | What it costs |
|---|---|---|
| Managed database over self-managed | Patching, backups, and failover are handled by the platform rather than the team. | Less low-level tuning control, a higher per-hour price, and dependency on the provider's maintenance windows. |
| Multi-zone redundancy | Intended to maintain service through a single availability-zone failure, subject to application, dependency, and failover health. | Materially increases data-tier infrastructure and cross-zone traffic cost, adds write latency, and makes failover a recurring testing commitment. |
| Private-only application services | Reduces direct internet exposure of compute and data by centralizing ingress through inspected paths. | Requires deliberate egress and administrative-access patterns, more network design work, and slower troubleshooting. |
| Managed secrets service | Keeps application credentials out of source control and container/application images, with per-identity audit and scheduled rotation. | Adds a runtime dependency in the critical path, plus caching, retry, and degradation handling in application code. |
ADRs
Architecture decision records
ADR-001
Managed database service vs self-managed database
Accepted- Context
- The legacy system runs a self-managed database on end-of-life hardware with manual backups and no failover. The operations team is small and has no dedicated database administrator.
- Decision
- Adopt a managed relational database service with automated backups, patching, and a synchronous standby.
- Alternatives considered
- Self-managed database on cloud virtual machines
- Lift-and-shift of the existing database host
- Refactor to a distributed database engine
- Benefits
- Removes patching and backup toil from a small team
- Failover and point-in-time recovery are platform features
- Recovery point objective of 15 minutes achievable without custom tooling
- Tradeoffs
- Higher per-hour cost than raw compute
- Limited operating-system and engine-level tuning
- Version upgrade timing partly dictated by the provider
- Operational impact
- Operations shifts from database maintenance to monitoring and query performance work; runbooks reference platform failover rather than manual recovery.
ADR-002
Multi-zone availability vs single-zone deployment
Accepted- Context
- The availability objective is 99.9% with a 4-hour recovery time. A single-zone deployment is cheaper but exposes the application to a full outage from one facility event.
- Decision
- Deploy application and data tiers across three availability zones with a synchronous database standby.
- Alternatives considered
- Single-zone deployment with restore-from-backup recovery
- Two-zone deployment with asynchronous replication
- Cross-region active-active
- Benefits
- The design is intended to maintain service through a single availability-zone failure, subject to application, dependency, and failover health
- Maintenance can be performed zone by zone
- Supports the stated recovery objectives without heroics
- Tradeoffs
- Multi-zone redundancy materially increases data-tier infrastructure and cross-zone traffic cost
- Cross-zone traffic adds write latency and network charges
- More complex capacity planning
- Operational impact
- Deployment and load testing must account for zone-aware routing; failover must be exercised through game days and recovery testing to remain credible.
ADR-003
Private application services vs public exposure
Accepted- Context
- The legacy application was reachable from a flat internal network. In the target design, compute could be placed in public subnets for simplicity or kept private behind the load balancer.
- Decision
- Place application and data tiers in private subnets; only the edge and load balancer are internet-facing, with private endpoints for platform services.
- Alternatives considered
- Public subnets with host firewalls
- Public compute restricted by IP allow-lists
- VPN-only access to all tiers
- Benefits
- Reduces direct internet exposure of compute and data rather than relying on host-level defenses alone
- Forces traffic through inspected, logged ingress
- Simplifies evidence for boundary control reviews
- Tradeoffs
- More network design and troubleshooting effort
- Requires deliberate patterns for egress and administrative access
- Slightly slower initial developer onboarding
- Operational impact
- Support access happens through identity-brokered sessions rather than direct connections; egress must be explicitly designed for updates and third-party calls.
ADR-004
Managed secrets service vs application configuration files
Accepted- Context
- Credentials are currently stored in configuration files on application hosts, are rarely rotated, and are copied between environments.
- Decision
- Retrieve all credentials at runtime from a managed secrets service with per-environment scoping and scheduled rotation.
- Alternatives considered
- Encrypted configuration files with a deployment-time key
- Environment variables injected by the pipeline
- Self-hosted secrets manager
- Benefits
- The target design keeps application credentials out of source control and container/application images
- Rotation becomes a routine operation instead of a project
- Access to secrets is authorized and audited per identity
- Tradeoffs
- Introduces a runtime dependency on the secrets service
- Adds cold-start latency on credential retrieval
- Requires caching and failure handling in application code
- Operational impact
- Applications need retry and cache logic; incident runbooks must cover secrets-service degradation.
Governance
Risks & mitigations
| ID | Scenario | Likelihood | Impact | Component | Mitigation | Residual | Owner |
|---|---|---|---|---|---|---|---|
| RSK-01 | Migration cutover exceeds the maintenance window and leaves data in an inconsistent state. | Medium | High | Data tier / cutover process | Two full rehearsals with timed rollback, and a documented go/no-go checkpoint. | Low | Cloud Operations |
| RSK-02 | Over-permissive security-group rules copied from the legacy flat network allow lateral movement. | Medium | High | Network segmentation | Least-privilege rule baseline, flow-log review, and rule tightening in the hardening phase. | Medium | Security Engineering |
| RSK-03 | Cloud spend exceeds forecast after multi-zone redundancy and log retention are enabled. | High | Medium | Cost governance | Mandatory tagging, per-environment budgets, anomaly alerts, and a right-sizing review in Phase 6. | Medium | Platform Engineering |
| RSK-04 | Legacy credentials remain in configuration files after migration and are never rotated. | Medium | High | Secrets management | Pipeline secret scanning plus a hardening-phase task to rotate every migrated credential. | Low | Security Engineering |
| RSK-15 | Application team bypasses the deployment pipeline to make an emergency production change. | Medium | Medium | CI/CD & change control | Emergency-change path with just-in-time elevation, automatic logging, and retrospective review. | Low | Application Team |
Sequencing
Reference implementation roadmap
These phases describe a reference implementation approach. They are not a record of a real production deployment.
- Phase 1
Discovery & Requirements
- Inventory application components and integrations
- Agree availability, recovery, and security objectives
- Map data classification and retention needs
Exit criteria Signed-off requirements and constraints baseline.
- Phase 2
Foundation
- Build landing zone, subnets, and identity federation
- Stand up logging, secrets, and cost tagging policy
- Codify environments in infrastructure definitions
Exit criteria Empty but governed environments reproducible from source.
- Phase 3
Migration / Implementation
- Containerize and deploy application and API tiers
- Replicate data and rehearse cutover twice
- Cut over in the agreed maintenance window
Exit criteria Production traffic served from the target architecture.
- Phase 4
Security & Operational Hardening
- Tighten security-group rules to observed flows
- Rotate all migrated credentials into the secrets service
- Complete runbooks and alert routing
Exit criteria No standing admin access and no config-file credentials.
- Phase 5
Validation
- Timed restore test against the recovery objective
- Zone-failure game day
- Access review and logging completeness check
Exit criteria Evidence pack demonstrating objectives are met.
- Phase 6
Optimization
- Right-size compute and storage against real usage
- Tune autoscaling and alert thresholds
- Review architecture decisions and retire workarounds
Exit criteria Stable run-rate within the agreed budget envelope.
Evidence
Validation approach
- Timed restore of the database meets the 4-hour recovery objective
- Zone-failure drill completes without manual data-tier intervention
- Penetration-test style review finds no publicly reachable compute
- Log completeness check confirms audit events for all admin actions