HourTab

Blog › ICP guides

Cloud architect on retainer: tracking ongoing cloud infrastructure advisory and demonstrating cloud platform value between migration projects and annual architecture reviews

July 18, 2026 · ~15 min read

The cloud migration project and the annual platform review are the visible events in a cloud architecture engagement. When a CTO presents the infrastructure modernization results to the board, when an engineering director justifies the cloud architecture investment to the CFO, when a VP Infrastructure reports the security posture improvement to the CISO — those are the artifacts on the table: the migration completion report from the AWS-to-multi-cloud move last year, the Well-Architected Framework review that produced a 47-item remediation backlog, the cost optimization project that reduced the monthly cloud spend by 28%. What none of those artifacts shows is the continuous cloud platform governance between those visible milestones, or whether that ongoing advisory is what maintained the security posture, controlled the cost drift, and kept the infrastructure configurations sound as new services were added and existing services grew.

The cloud platform advisory session that identified a VPC peering configuration creating an unintended transitive routing path between the production and staging environments — where a peering connection added by a developer to allow a staging service to call a production reference data API had inadvertently created a path where any service in the staging environment could initiate connections to services in the production environment that the security group rules had not been designed to handle — that prevented a security boundary violation that would have required a network re-architecture to close if it had been discovered through a security audit rather than through proactive advisory. The multi-region design review that found the proposed database failover strategy did not account for the replication lag during the highest-write-volume period — where the asynchronous replication configuration would produce a recovery point objective gap of up to 4 minutes under the traffic conditions that were most statistically likely to cause a primary region failure, against a business-defined RPO of 30 seconds that the architecture documentation had not revisited since the write volume had doubled — that prevented the engineering organization from operating a failover architecture that could not meet its documented recovery commitment under real-world conditions.

The security architecture review that identified an IAM policy granting s3:* permissions to a Lambda function that was only required to write to a single bucket prefix — where the permissive policy had been copied from another function during a rapid feature development cycle and had never been scoped down, and where the overly broad permissions created a path for data exfiltration if the function's code was compromised or a malicious payload was injected through the input event — that prevented a privilege escalation vulnerability that would have been flagged in the next SOC 2 audit as a finding requiring remediation. The cloud cost governance session that identified a cluster of RDS instances in the development environment that had been provisioned with Multi-AZ enabled — a configuration that doubles the instance cost and is appropriate for production availability requirements but unnecessary for development environments that can tolerate a brief availability interruption during a zone failure — where disabling Multi-AZ for the development instances reduced the monthly RDS cost for the development environment by $2,400.

Cloud architects and cloud infrastructure consultants on monthly retainer do their most consequential work in the continuous stretches between major migration projects and annual platform reviews: the cloud platform advisory that evaluates new service configurations and architectural changes before they reach production; the security architecture review that maintains the least-privilege posture across IAM policies, network access controls, and service endpoint configurations; the multi-region and availability design guidance that ensures the resilience architecture meets the organization’s documented recovery objectives; the cloud cost governance that monitors spend drift and identifies optimization opportunities before they become budget overruns; and the migration architecture advisory that designs the sequencing, data transfer strategy, and cutover procedures for workloads being moved between environments or providers. All of that advisory is invisible to the engineering director, CTO, and board without a work log that connects the ongoing cloud platform governance to the security posture, cost profile, and availability design it maintains.

Cloud architect versus software architect versus DevOps engineer: the primary distinctions

Three infrastructure-adjacent technical advisory roles are routinely conflated in engineering leadership conversations: the cloud architect, the software architect, and the DevOps engineer. The conflation produces situations where the cloud platform governance function — the discipline that evaluates cloud service selection decisions, maintains the security architecture posture, governs the multi-region availability design, and monitors the cloud cost profile — is either missing, distributed across advisors without clear ownership, or misassigned to advisors whose expertise covers adjacent but distinct domains.

A software architect on retainer governs the structural design of the application itself: service boundaries and the coupling implications of each boundary choice; data model designs and the query pattern implications of each schema decision; API contract governance and the versioning strategy that allows services to evolve without breaking consumers; and the architectural patterns and anti-patterns that determine how maintainable and evolvable the application will be as it grows. A software architect asks “how should the application be structured so it can be built, maintained, and evolved by the engineering team sustainably?” A cloud architect asks “what cloud platform configuration, network topology, and availability design does the application require to run reliably, securely, and cost-effectively within the cloud environment?” The software architect designs the application structure; the cloud architect designs the cloud infrastructure that the application runs within. Both are architectural governance functions, but they govern different layers of the system.

A DevOps engineer on retainer focuses on the software delivery infrastructure: the CI/CD pipelines that build, test, and deploy the application; the infrastructure-as-code that provisions and configures the cloud resources the application requires; the deployment procedures and rollback mechanisms that govern how changes are introduced to production; the monitoring and alerting systems that detect production problems; and the cloud cost governance at the delivery infrastructure level. A DevOps engineer asks “how do we deliver changes to the application reliably and operate the production system observably?” The distinction from a cloud architect matters: the DevOps engineer governs the delivery tooling and operational practices; the cloud architect governs the underlying cloud platform architecture that the delivery tooling and application run within. A DevOps engineer who advises on Terraform module structure is advising on the infrastructure-as-code tooling; a cloud architect who reviews the VPC architecture those modules produce is advising on the platform design itself.

A cloud architect on retainer focuses specifically on the cloud infrastructure layer: the cloud platform services the application uses and the architectural implications of each service selection; the network topology, VPC configuration, and security boundary design that determines how the application's components communicate and what access controls govern cross-service communication; the account and organizational structure that governs access, cost allocation, and security boundary enforcement across environments; the multi-region and availability architecture that determines the system's resilience to cloud provider failures; and the cost governance that ensures the cloud spend remains aligned with the engineering budget and the traffic profile of the applications running in the environment.

What ongoing cloud architecture retainer advisory actually consists of

Cloud platform advisory

Cloud platform decisions — which managed services to use, how to configure the network topology, how to structure the account organization, how to manage the identity and access configuration — have implications that compound over years. The managed database service selected for a new application determines the scaling model, the backup and recovery capability, and the cost profile of that application’s data tier for the foreseeable future. The VPC architecture established for a new environment determines the security boundary design and the network connectivity options for every service deployed into that environment. The IAM account structure established for the organization determines how access is governed, how costs are allocated, and how security controls are enforced across every environment in the account.

Cloud platform advisory on retainer covers the ongoing evaluation of cloud service selection decisions, network architecture changes, account structure modifications, and platform configuration changes before they are applied to production environments: evaluating each proposed change against the organization’s security posture requirements, cost profile targets, operational complexity constraints, and the technical architecture of the existing infrastructure. It also covers the advisory on the cloud platform evolution decisions that determine which managed services can replace custom-built infrastructure components, which architectural patterns are appropriate for the organization’s scale and operational maturity, and which cloud provider feature releases are relevant to the organization’s near-term infrastructure roadmap.

On retainer: reviewing proposed cloud service configurations and architectural changes before production application; attending or conducting cloud architecture review sessions when decisions have significant security, cost, or operational complexity implications; and maintaining the cloud architecture decision record that documents the rationale for significant platform choices so future engineers understand why the infrastructure is configured the way it is.

Security architecture review

Cloud security architecture is not a one-time configuration — it is a posture that must be maintained against a continuously evolving set of service configurations, IAM policies, network access rules, and application deployment patterns. An IAM policy that was correctly scoped when a Lambda function was first deployed may be too permissive twelve months later if the function’s responsibilities have been redefined but the original policy has not been updated to reflect the narrower scope. A VPC security group that was correctly configured for the original service topology may allow unintended traffic paths after a new service is deployed into the same VPC without a corresponding security group review. An S3 bucket access policy that was appropriately configured for the original data classification may be inconsistent with the compliance requirements that apply to the data the bucket now stores after the application’s data scope was expanded.

Security architecture review on retainer covers the ongoing review of IAM policies for least-privilege compliance: evaluating whether each policy grants only the permissions required for the associated role’s documented function, identifying policies that grant service-wide permissions (“s3:*”) where specific action permissions are sufficient, and identifying privilege escalation paths created by combinations of policies that individually appear reasonable. It covers VPC configuration review: evaluating security group rules for unintended access paths, reviewing network ACL configurations for boundary enforcement, and assessing service endpoint configurations for the network isolation guarantees they provide. And it covers encryption and key management review: evaluating the encryption-at-rest and encryption-in-transit configuration for services handling sensitive data and the key rotation and access policies for the KMS keys governing that encryption.

On retainer: conducting regular security architecture reviews of IAM, network, and encryption configurations; reviewing proposed security configuration changes before production application; advising on the security architecture improvements that reduce the organization’s attack surface and improve the compliance posture for SOC 2, ISO 27001, or regulatory frameworks applicable to the organization.

Multi-region and availability design guidance

The availability architecture of a cloud-hosted application determines its resilience to cloud provider failures: availability zone outages, regional outages, service-level disruptions, and inter-service dependency failures. The recovery point objective and recovery time objective that a system is designed to meet under those failure conditions are architectural commitments that must be validated against the actual failure modes of the services in the system — and those failure modes must be re-evaluated when the system's architecture changes, the traffic profile grows, or the cloud provider changes the underlying behavior of a managed service.

Multi-region and availability design guidance on retainer covers the ongoing evaluation of the availability architecture for the organization’s critical systems: reviewing the failover configuration against the documented recovery objectives, assessing the replication strategy for the data tier under the write volume and consistency requirements of the actual production workload, evaluating the traffic routing configuration for its behavior during partial failure scenarios, and reviewing the recovery procedures for their executability under the time pressure of a real regional failure. It also covers the advisory on the availability architecture design for new systems being added to the production environment, ensuring that the recovery objective commitments made to the business stakeholders are achievable given the cloud service configurations being used and the data volume and consistency requirements of the application.

On retainer: reviewing availability architecture for critical systems on a regular cadence; advising on multi-region design for new systems that have availability requirements the current single-region architecture cannot meet; conducting failover architecture reviews when traffic volume or write patterns change significantly enough to affect replication lag characteristics; and maintaining the availability architecture documentation that records the recovery objective commitments and the architectural mechanisms designed to meet them.

Cloud cost governance

Cloud infrastructure costs are unique in their capacity to drift invisibly. A compute resource provisioned for a peak traffic event that has passed continues accumulating cost at the same rate after the event as during it. A database instance sized for a projected growth trajectory that did not materialize continues running at that size regardless of the actual utilization. A data transfer pattern established when the application architecture was simpler continues accumulating egress charges at a rate that made sense for the original architecture and no longer makes sense for the evolved architecture that could route the same data differently. Cloud cost governance requires continuous monitoring because the cloud billing model produces cost at the rate of resource provisioning, not at the rate of value generation.

Cloud cost governance on retainer covers the ongoing review of cloud billing data against the engineering budget and the traffic profile of the applications running in the environment: identifying unused and underutilized resources; reviewing the compute, database, and caching resource sizing against current utilization data; evaluating reserved instance and savings plan coverage against the stable, predictable workloads that are paying on-demand rates; identifying data transfer and inter-service communication patterns that drive unnecessary egress costs; and advising on the architectural changes that reduce ongoing cloud cost without requiring service migrations or availability compromises.

On retainer: reviewing cloud billing data on a monthly cadence; generating right-sizing recommendations backed by utilization data; identifying reserved instance and savings plan purchase opportunities; advising on the architectural changes with the best cost-to-effort ratio; and monitoring the cloud cost trend against the engineering budget so that cost anomalies are identified and resolved before they compound into budget overruns.

Migration architecture advisory

Cloud migrations are among the highest-risk infrastructure operations an engineering organization undertakes: the workload being migrated is typically in active production use during the migration; the data being moved may have consistency requirements that the migration procedure must preserve; the cutover from the source to the target environment must be executed within a window that minimizes the impact on users; and the rollback from a failed migration must be executable quickly enough to meet the organization’s availability commitments. Migration architecture advisory is the discipline that designs the sequencing, data transfer strategy, cutover procedure, and rollback plan that make the migration executable within those constraints.

Migration architecture advisory on retainer covers the design of migration procedures for workloads being moved between cloud providers, between cloud regions, between account structures, or from on-premises infrastructure to cloud: evaluating the migration sequencing against the dependency graph of the services being migrated; designing the data transfer strategy for the migration’s data volume and consistency requirements; evaluating the cutover procedure against the recovery time objective for the migration window; and designing the rollback plan for the failure scenarios that are most likely to occur during the migration’s critical path.

The work that most commonly goes unlogged in a cloud architect retainer

The most consistently underlogged cloud architecture advisory work falls into two patterns: review and advisory work that confirmed the proposed configuration was appropriate, and advisory work that prevented a cloud platform problem before it manifested rather than resolving one after it had affected the production environment. Both patterns produce the misimpression that the retainer period was uneventful when it contained the continuous governance that maintains the security posture, availability design, and cost profile the organization relies on.

Cloud platform advisory sessions that recommended the proposed configuration are the canonical underlogging case. A review of a VPC architecture change, an IAM policy modification, or a cloud service selection decision that concluded the proposed approach was appropriate for the organization’s security posture and operational requirements required the same advisory analysis as a review that identified a configuration problem: the proposed VPC configuration had to be evaluated against the security boundary requirements; the IAM policy had to be reviewed against the least-privilege principle and the escalation path implications; the cloud service selection had to be evaluated against the operational complexity, cost profile, and feature requirements of the workload. The conclusion that the proposed approach is correct is the result of analysis, not the absence of it.

Security architecture reviews that found no compliance gaps are consistently underlogged by cloud architects who conflate “all permissions were correctly scoped” with “no review was required.” A review of the IAM policies, security group configurations, and network ACLs for a set of services that confirmed all reviewed permissions were appropriately scoped to the minimum required access required the same review work as a session that identified an overly permissive policy: each IAM policy had to be read and evaluated against the function’s documented requirements; each security group rule had to be checked against the intended traffic flows; each network ACL had to be reviewed against the security boundary the VPC was designed to enforce. The security posture that is confirmed compliant after review is in a materially different state than the security posture that has not been reviewed; the difference is the confirmation, not the absence of work.

Multi-region design reviews that confirmed adequate resilience are systematically underlogged because the review that confirms the failover architecture meets the documented recovery objectives appears, in the retainer record, to have produced nothing. In practice: the replication configuration had to be reviewed against the write volume and consistency requirements of the actual production workload; the failover sequencing had to be evaluated against the recovery time objective; the recovery procedures had to be assessed for executability under time pressure; and the traffic routing configuration had to be reviewed for its behavior during partial failure scenarios where only some services in the system have failed. The review that confirms adequacy required the same analysis as the review that identified a gap; logging only the gaps systematically understates the architecture governance work and creates a misleading picture of the retainer’s value.

Cloud cost monitoring reviews that found the cost profile within budget are consistently underlogged by consultants who conflate “the bills are acceptable this month” with “the review produced no value.” The monthly review of the cloud billing data, resource utilization metrics, and reserved instance coverage that confirmed the cost profile was within budget still required the billing data to be retrieved and analyzed, the utilization metrics to be checked against the provisioned capacity, and the reserved instance coverage to be verified against the current on-demand usage. The engineering organization that knows its cloud cost profile has been reviewed and is within target is in a materially different position than one that assumes the same thing without the review.

Retainer rates for cloud architects and cloud infrastructure consultants

Cloud architect retainer rates vary with experience level, cloud provider specialization, and the complexity of the cloud environment under advisory:

Advisory-only retainers (platform review, security architecture review, multi-region design, cost governance) are typically priced differently from implementation retainers that include hands-on cloud configuration or migration execution. Pure advisory retainers focus the engagement on the governance function where the cloud architect’s leverage is highest — reviewing and advising before configurations are applied, rather than executing the changes directly.

The most common retainer structure for cloud architects is a minimum monthly hour commitment — typically 10–20 hours — with additional hours available at the agreed hourly rate for periods when a major migration project, an annual Well-Architected Framework review, or a security audit response requires deeper engagement.

Making cloud architecture retainer advisory visible to engineering leadership

The principal challenge in cloud architect retainer relationships is not the quality of the cloud platform governance — it is the legibility of that governance to the CTOs, VP Engineering, and CISO stakeholders who are making the retention decision. A cloud architect who reviews every significant platform configuration change before it reaches production, maintains the security architecture posture through ongoing IAM and network review, evaluates the availability design against real-world failure modes, and monitors the cloud cost profile monthly is producing continuous value that is structurally invisible to anyone not present in the advisory sessions. The engineering organization that benefits from cloud platform governance often cannot articulate precisely why the cloud security posture has remained compliant, why the availability architecture has not been caught by a replication lag gap, or why the cloud costs have stayed within budget — because the value of ongoing cloud platform governance is experienced as the absence of the problems it prevents.

The work log that connects advisory sessions to specific platform configuration reviews, security architecture findings, availability design assessments, and cost optimization recommendations is the primary mechanism for making cloud architecture value legible over time. An entry that records the VPC peering configuration identified as creating an unintended transitive routing path, and the security boundary violation it would have produced, gives the CISO and engineering director a concrete example of what the cloud platform advisory function produces. An entry that records the multi-region failover architecture gap identified, the replication lag conditions under which the documented RPO would not be met, and the architectural recommendation for addressing the gap allows the engineering director to understand what the availability design guidance function produces. An entry that records the cost anomaly identified, the resources terminated or right-sized, and the monthly savings achieved allows engineering leadership and finance stakeholders to understand what the cost governance function produces.

A retainer dashboard that makes the cloud architect’s work log visible to the engineering director, CTO, or CISO without requiring the consultant to send a monthly report email converts the work log from a private record into a shared artifact of the advisory relationship. The engineering leader who can see the full month’s platform advisory sessions, security architecture reviews, availability design guidance, and cost optimization findings in a single URL understands immediately what the cloud architecture retainer is producing — and has a concrete record to reference when making renewal decisions or communicating the cloud governance investment to the board.

The cloud architecture events that matter most to log

Three categories of cloud architecture advisory work warrant particular attention in the retainer record because they represent the highest-leverage applications of the cloud architect’s expertise and the clearest evidence of the cloud platform governance function working as intended.

Security architecture findings. IAM policy misconfigurations, unintended network access paths, privilege escalation vulnerabilities, and encryption gaps — identified before they were exploited or flagged in a security audit — represent the highest-value single advisory events in most cloud architect retainer engagements. The work log entry should capture the specific misconfiguration, the security impact if it had not been identified, and the recommendation for remediation. These entries translate directly to the CISO and board-level conversation about the cloud security governance investment.

Availability architecture gaps resolved before failure. Multi-region design reviews that identified recovery objective gaps, replication configuration issues, or traffic routing failures under partial failure scenarios represent the availability governance function at its highest value. The work log entry should capture the specific availability gap, the failure scenario in which it would have manifested, and the architectural recommendation for closing it. The production incident that did not happen because the availability architecture was reviewed and corrected is the most important retainer outcome the cloud architect can produce.

Cost optimization with measurable outcomes. Cloud cost governance reviews that identified specific resources, configurations, or architectural patterns driving unnecessary cost — and produced quantified recommendations for addressing them — represent the most legible value for finance and business stakeholders evaluating the retainer. The work log entry should capture the specific cost driver, the recommended change, and the estimated or measured monthly savings. Cloud architects who consistently identify cost optimization opportunities that exceed their retainer cost have a straightforward renewal conversation.

Frequently asked questions

What does a cloud architect on retainer typically do?

A cloud architect or cloud infrastructure consultant on monthly retainer typically provides cloud platform advisory (reviewing cloud service selection decisions, VPC architecture changes, and account structure modifications before production application), security architecture review (reviewing IAM policies, network access controls, and encryption configurations for least-privilege compliance), multi-region and availability design guidance (evaluating failover architecture, replication strategy, and recovery procedures against documented recovery objectives), cloud cost governance (monitoring spend drift and identifying right-sizing, reserved instance, and architectural optimization opportunities), and migration architecture advisory (designing migration sequencing, data transfer strategy, and cutover procedures for workloads being moved between environments or providers). The migration project and the annual platform review are the visible milestones; the continuous cloud platform governance between those events is the ongoing retainer function.

How is a cloud architect different from a software architect or a DevOps engineer on retainer?

A cloud architect governs the cloud infrastructure layer: platform service selection, network topology, security boundaries, account structure, availability design, and cost profile. A software architect governs the application layer: service boundaries, data model designs, API contracts, and the architectural patterns of the software system itself. A DevOps engineer governs the delivery infrastructure: CI/CD pipelines, infrastructure-as-code tooling, deployment procedures, and production monitoring systems. The cloud architect designs the infrastructure that the software architect’s application runs within, and that the DevOps engineer delivers changes to. A software architect retainer and a DevOps engineer retainer cover distinct advisory domains that all three can serve simultaneously without overlap when the scope of each engagement is clearly defined.

What cloud architect retainer work is most commonly underlogged?

Cloud platform advisory sessions that recommended the proposed configuration, security architecture reviews that found no compliance gaps, multi-region design reviews that confirmed adequate resilience, and cost monitoring reviews where the cost profile was within budget. All represent genuine governance work whose value is in the ongoing confirmation and prevention rather than in the correction of identified problems — and all are systematically underlogged by consultants who conflate “no problem found” with “no work done.”

What should a cloud architect retainer agreement include?

Cloud account and environment access scope, scope boundary between advisory and implementation, cloud provider NDA and data handling requirements for billing and security configuration data, cost governance authority and change approval process, incident response availability if included in the retainer scope, and a shared work log visible to engineering leadership and CISO stakeholders that documents the ongoing cloud platform advisory, security reviews, and cost optimization findings.

How should cloud architect retainer hours be logged?

Log entries should capture the cloud architecture function (platform advisory, security review, availability design, cost governance, migration advisory), the specific service or configuration reviewed, the activity performed, and the recommendation or finding. Every session should be logged, including platform advisory sessions that approved proposed configurations and security reviews that found no compliance gaps. The cloud architecture review that confirmed the platform configuration was appropriate required the same review work as the review that identified a misconfiguration; logging only the sessions that found problems systematically understates the volume of platform governance work and misrepresents the retainer’s value.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark. No client login required. See how it works →