What you’ll take away
- Assign both platform and workload owners, then describe the allowed connections between production, testing, deployment, and shared services.
- Place each control where it can enforce the intended restriction, with protected evidence and a named operator.
- Approve launch against implemented behavior, including successful business requests, denied access, and tested operational procedures.
In this guide
Start with the service customers will use
A fictional equipment maintenance company is preparing a customer portal. Customers will see upcoming service visits and download maintenance reports for their own equipment. The application needs a public entry point, a database, document storage, and an outbound notification service. Developers need somewhere to test changes. Operations staff need to investigate problems and recover the service. Each of those needs creates an access decision before the first production customer signs in.
Secure cloud architecture brings those decisions together while the structure is still easy to change. Begin with the information the portal handles, the people and systems that need it, and the business operations that depend on it. Mark where customer records enter, where reports are stored, and which outside services receive data. Include administrative access and the route for delivering new application versions alongside the customer journey.
Write the important decisions in terms the business can review. In this example, development uses synthetic records, customers access reports through the portal, and production administration requires a defined privileged role. The company also needs reliable evidence of changes and a practical recovery method. These are proposed requirements for the fictional workload. The design must identify the controls, owners, and acceptance checks that will make them observable in the built environment.
Assign responsibility across the provider, platform, and workload
Choosing a managed service changes the operating work the company retains. AWS’s Shared Responsibility Model explains that customer responsibilities vary with the services selected and how they are integrated. [1] For the portal, list the responsibilities for each chosen service, including access configuration, application changes, data protection, logging, and recovery settings. Check them against that provider’s service documentation so the operating plan matches the services the team will actually deploy.
Within the company, distinguish the shared platform from the portal workload. Microsoft’s current Azure landing-zone guidance separates platform capabilities and governance from resources that workload teams deploy and operate within those guardrails. [2] That provides a useful example of the ownership split. A small company might assign both roles to the same people, but the duties still need to be explicit.
The platform owner might maintain the organization hierarchy, workforce sign-in, baseline policies, and central logging. The portal owner maintains the application, its runtime permissions, customer authorization, data handling, and recovery procedure. Agree on who handles the joins. If a platform policy rejects a deployment, who investigates it? If the application stops sending audit events, who notices and restores delivery? Name an owner and escalation route for each shared dependency, including anything an outside provider operates.
Choose production boundaries before the prototype expands
Decide where production, development, testing, and shared security resources belong. AWS Well-Architected guidance recommends account separation between environments such as production, development, and test. [3] Other providers have their own resource and policy structures. Select the appropriate boundary for the chosen platform, then document how identities, permissions, and governance rules apply across it. The account or subscription diagram should explain the permitted connections as well as the separate boxes.
For the fictional portal, the development environment contains synthetic customer records and its own database and document store. Production has separate data resources and runtime identities. A release process receives a deliberately scoped production deployment role. This is an approved connection between the delivery system and production, so its authority needs to be visible in the design. An ordinary development session should have no route to read production reports under the agreed policy.
Review convenience features that can cross the intended boundary. A shared troubleshooting account, copied database backup, broadly trusted deployment identity, or central support tool can create access that the diagram overlooks. Ask what each connection is for and which operation it needs. If developers require a realistic test fixture, choose an approved way to create it and verify its contents. Assign the cost and administration of the extra environments so the team can sustain the separation after launch.
Separate environments. Name the permitted links.
+ document storage
Separate environment. No direct access to production data is intended.
- Shared platform → environmentsIdentity and policy controls
- Approved release → production roleScoped deployment permission
- Both environments → central logsProtected access and retention
Specify the allowed traffic and the permissions behind it
Draw the portal’s required connections individually. Customer traffic enters through the approved public application endpoint. The application reaches its private database and document storage. Administrators use a controlled management path. Notifications go to the approved external service. Give each connection a purpose, source, destination, authentication method, and owner. This makes it possible to question an unexpected route when the configuration is reviewed.
Private connectivity addresses the route to a service, while that service still needs an authorization decision. NIST SP 800-207 explains that network location alone should confer no implicit trust and treats authentication and authorization as discrete functions. [4] In the portal design, restrict which runtime identity can read stored reports even when the storage endpoint is private. Review service-level public-access settings as well as network routes and name resolution.
Choose outbound paths with the same care. Identify whether the workload needs a notification provider, software updates, or an on-premises business system, and determine how each connection will be controlled and observed. Document what happens if private name resolution or a connection fails. The operating procedure should preserve the agreed boundary while the team restores service. Acceptance checks should exercise both an approved application request and an unauthorized request from the relevant test location and identity.
Design protected evidence and usable recovery
Decide which events the company needs to understand an administrative change, investigate customer access, and notice a broken control. Infrastructure activity, identity activity, and application events answer different questions. The portal owner can identify the application events needed to explain access to reports, while the platform owner specifies collection and protection. Agree on useful fields, access restrictions, retention, and how to detect a collection failure without copying unnecessary customer content into logs.
The AWS Security Reference Architecture uses a dedicated Log Archive account and specifies protected, immutable storage with controlled access to the records. [5] For the chosen cloud, document the actual mechanisms that protect the archive, including permissions, retention settings, and encryption-key access where applicable. A centralized destination also needs an operating process. Name who reviews the relevant alerts, who can investigate retained events, and how changes to collection are approved.
Apply the same ownership discipline to backup and key-management decisions. Define which data must be recoverable, the restoration objective, who can initiate recovery, and which credentials or keys the procedure needs. If the design uses customer-controlled keys, assign responsibility for their administration and lifecycle. Before launch, have the operator perform an agreed restoration in a safe environment and retain the result. The team should be able to explain how recovery works when a routine application identity is unavailable.
Place controls where they can enforce the decision
A control placement map turns requirements into implementation work. For each requirement, name the component that enforces it, the owner, and the evidence that will show it works. The portal’s restriction on publicly readable reports might involve organization policy, storage configuration, and application authorization. Each has a different job. The design needs to state which action each control prevents and which users or resources it covers.
Use organization or account policies for restrictions that should apply broadly, resource-level controls for the individual service, and delivery checks for reviewing proposed changes. AWS’s account guidance describes using the hierarchy to apply inherited preventive controls. [3] Their interaction with resource permissions still needs review. In the portal, the platform policy may constrain a storage configuration while the runtime role determines which objects the application can use.
Keep preventive controls and detection tied to their intended behavior. A configuration check may reject a public storage setting before deployment, an enforced policy may deny the attempted change, and a monitoring rule may alert when exposure is detected. Give each an acceptance check that matches its function. Record any coverage gap, such as changes made through an administrative route outside the usual delivery workflow. Confirm that an approved portal deployment and normal customer request still succeed after the restrictions are applied.
A control needs a location and a job.
- Organization
- Preventive
Restrict covered resource creation to approved regions.
- Account / environment
- Detective
Flag public data exposure and configuration drift.
- Workload
- Preventive
Authorize each customer’s access to maintenance reports.
- Delivery pipeline
- Preventive
Restrict the production role to approved release jobs.
Agree on launch evidence while the design is still being reviewed
Approve the architecture with a build plan that names the acceptance checks. Once implemented, collect evidence from the configuration and the running workload. For this portal, that includes an authorized customer retrieving the right report, a development identity being denied production data access, an approved deployment completing, a relevant event arriving in the protected archive, and the agreed restore and rollback procedures working under the tested conditions.
Consider an illustrative launch review in which the private data path works but application audit events have yet to reach the archive. Record that check as open, assign the responsible owners, and decide whether the missing visibility prevents the proposed launch. A screenshot of the intended logging configuration leaves the delivery question unresolved. Retest the event path after the change and preserve the observed result alongside the design requirement.
Where an authorized decision maker considers an exception, describe the specific gap, affected scope, reason, exposure, temporary measures, owner, and expiry or review trigger. Evaluate it against the requirements the project must meet. Keep the decision visible to the operators who will inherit it. Launch acceptance should identify the release, environment, checks completed, and open conditions. Changes to data sensitivity, connectivity, identity trust, or platform policy should trigger review of the assumptions they affect.
Review evidence and unresolved conditions together.
- BoundaryUnapproved route is denied.
- Normal useApproved portal request succeeds.
- VisibilityTest event reaches the response owner.
- RecoveryAgreed restore and rollback checks pass.
Record the risk, owner, interim protection, authorized approver, and expiry or review date.
The accountable decision owner records the accepted scope and conditions.
Hand the builders decisions they can implement
The final design package should let an engineer explain what to build and why. Include the environment hierarchy, data and management flows, identity model, network decisions, logging and key design, and the control placement map. Link the build tasks to their acceptance checks. Preserve the reasons for material choices so the team can evaluate a later request for another region, a new integration, or broader support access without reconstructing the original discussion.
Source Point Security’s Secure Cloud Architecture Design starts with requirements workshops covering the workload, data, environments, sign-in, connectivity, and platform versus workload ownership. It produces architecture diagrams, a design decision record, a control placement map, draft guardrails, a risk register, and a build plan with acceptance checks. The design engagement prepares the implementation decisions and handoff. Agree separately on who builds, operates, and validates the deployed environment.
After implementation, SPS’s Cloud Security Assessment & Configuration Review can examine the agreed configuration against the selected baseline and return confirmed findings with evidence. Choose that follow-up around the questions left by the build. For the initial design discussion, bring the customer workflow, data types, intended cloud services, operating owners, and launch constraints. Those inputs let the architecture address the service the business is actually preparing to run and give the launch team concrete decisions to verify.
Set the cloud design before the build becomes difficult to change
Bring your proposed workload, data flows, and launch requirements. We can define an architecture design engagement with clear boundaries, control ownership, and acceptance checks.
Discuss Secure Cloud Architecture Design