Cloud architecture is often discussed as a choice between products. For a growing team, the more useful starting point is the work the system must support: who operates it, what must stay available, what data it stores, and how the team will recover when a change goes wrong. Those answers help keep the infrastructure understandable as the product grows.
Start with the workload and its owner
Make a short inventory of the application, database, file storage, background jobs, and third-party services. For each part, name the team or person responsible for routine changes and for responding to a failure. This avoids an infrastructure map that lists components but leaves out who can act on them.
Write down the service expectations in plain language. For example: which user journeys must work during a partial outage, how quickly the team needs to notice a problem, and how much recent data the business could tolerate losing. The answers guide later choices about redundancy, alerting, backup frequency, and recovery time.
Draw boundaries around access
Separate production from development and testing so experiments do not share live data or credentials by default. Give engineers, deployment automation, and support processes distinct accounts or roles where the platform allows it. A person who only needs to read logs should not need permission to change network rules or delete a database.
Keep credentials in a managed secret store or the deployment platform’s protected environment settings. Rotate a credential when its purpose changes, an owner leaves, or exposure is suspected. Avoid copying secrets into source files, build logs, tickets, or chat transcripts.
- Use separate environments and credentials.
- Prefer short-lived or narrowly scoped access where available.
- Record who owns each important secret and how it is rotated.
Plan for recovery before the incident
A backup is useful only if it can be restored. Decide which data needs a backup, how often it should run, how long copies should be retained, and where recovery copies should live. Keep recovery access separate from the credentials used by the running application when the platform supports it.
Practice restoring a copy into a safe environment. Check that the application can use it, that the restored data is recent enough, and that the team knows the steps. A short restore exercise often reveals missing permissions, undocumented dependencies, or a backup that was never complete.
Make failures visible and actionable
Collect enough logs and metrics to answer three questions: is the service available, are important user actions succeeding, and what changed near the time of a problem? Keep secrets and sensitive user data out of logs. Give alerts an owner and a next step; an alert that no one is expected to handle becomes background noise.
A simple service dashboard can begin with availability, request failures, latency, queue depth, and database health. Add detail when the team has a question those signals cannot answer. More telemetry is not automatically better if nobody can interpret it or act on it.
Grow the platform in small, reversible steps
Begin with the smallest architecture that meets the written requirements. Use repeatable deployment steps, review changes to production configuration, and keep rollback instructions close to the release process. When a service becomes a bottleneck or a team needs a stronger boundary, make that change for a reason the team can explain.
Review the foundation when the product adds a new data type, customer group, region, or operational promise. Those changes can alter access, retention, recovery, or capacity needs. A brief review at the right time is easier than rebuilding around assumptions that no longer hold.