Cloud architecture and the well-architected pillars

AWS organises its advice to architects into six pillars, and although the vocabulary is Amazon's, the questions apply on every platform. Microsoft and Google publish comparable frameworks of their own. The pillars are useful less as a checklist than as a reminder that improving one quality nearly always costs another.

How the exams frame the job

The Solutions Architect Associate exam guide states that it tests design against the Well-Architected Framework and splits its content into four domains: secure, resilient, high-performing and cost-optimised architectures. Each question describes a requirement and asks which combination of services meets it best, so the skill on trial is elimination: spotting the option that is correct but too expensive, or cheap but fragile. The expert and professional tiers change the scenario, not the principle. AZ-305 expects one design that settles identity, data, infrastructure and continuity together; SAP-C02 and Google's Professional Cloud Architect add existing systems, regulators and budgets to the stem.

Good architects also write things down. A short decision record for each significant choice, stating the options considered, the one chosen and the pillar it sacrificed, lets a successor understand why the system looks the way it does. It also turns vague requirements into measurable ones: a recovery time, an acceptable data loss, a latency budget, a monthly spending ceiling. Without such figures, every design review becomes an argument about taste.

Where newcomers misjudge the role

The commonest mistake is treating architecture as service selection. Knowing that a queue decouples two components is exam knowledge; knowing whether this team can operate that queue at three in the morning is architecture. The second is designing for scale nobody has asked for, which buys complexity with the reliability budget. The third is skipping the review: AWS offers a free Well-Architected Tool in its console for assessing a workload against the pillars, and walking a design through such questions with the people who will run it catches more problems than any diagram. Architects usually come from development or administration for exactly this reason. They have operated the kind of system they now design, and they know which parts of it fail. The neighbouring topics on networking, storage and databases and migration supply the building blocks those decisions are made from.