Capstone — submit architecture, demo URL and cost analysis report

The Capstone submission is the final deliverable of Course 5. You will submit three artefacts that together demonstrate production-ready multi-cloud architecture competency: a live demo URL serving the IPL scorecard API from the deployed AWS-Azure-GCP platform, a 12-month multi-cloud cost model showing the architecture meets the $500/month cost constraint, and a written Well-Architected review identifying the architecture’s top three High Risk Issues with remediation proposals. These artefacts mirror what a Solutions Architect submits to an enterprise client at the end of an architecture engagement.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.

The submission is evaluated on three dimensions. Technical correctness assesses whether the platform meets functional requirements: both AWS regions respond, DynamoDB Global Tables replication is active, Azure Traffic Manager geographic routing is configured, and the GitHub Actions WIF pipeline deploys without stored credentials. FinOps quality assesses the cost model’s accuracy. WAF rigour assesses whether the three HRIs are genuine gaps with specific, actionable remediations and correct pillar assignments.

Allocate your 100 minutes as follows: 15 minutes to compile and organise the three artefacts, 30 minutes to write the Well-Architected review narrative from your running notes, 30 minutes to run the final end-to-end validation tests and fix any issues found, and 25 minutes to prepare the submission package. Do not spend the full 100 minutes on the Well-Architected review at the expense of the validation tests; a beautifully-written review that accompanies a broken deployment scores lower than a concise review that accompanies a functioning platform.

Submission Requirements

Artefact 1 — Live Demo URL: a publicly-accessible HTTPS URL at api.ipl.srihayavadhana.in/api/scores/IPL2024FINAL (or your test domain) that returns JSON match data with X-Served-By header, and a screenshot of the Route 53 console showing the health checks as Healthy.
Artefact 2 — Cost Model: a Google Sheets or Excel spreadsheet with separate worksheets for Traffic Inputs, AWS Pricing, Azure Pricing, GCP Pricing, and 12-Month Summary; all calculations as formulas (no hardcoded totals); annual total between $3,000 and $6,000.
Artefact 3 — Well-Architected Review: a 500 to 1,000 word document identifying the top three HRIs, each with the WAT question that generated it, the specific gap in the as-built architecture, and a concrete remediation proposal with estimated effort and impact.
Supporting evidence: GitHub Actions workflow run screenshot showing OIDC authentication (no stored credentials); DynamoDB console screenshot showing Singapore replica ACTIVE; Azure Traffic Manager profile screenshot showing both endpoints Healthy.
Optional bonus: an SSM Automation Document for the DR failover runbook with the RTO measured in a drill, worth 10% bonus marks on the Reliability pillar score.

Evaluation Rubric

Technical Correctness (40 points): Demo URL responds HTTP 200 from Mumbai (20 pts); DynamoDB Global Tables replication active in Singapore (10 pts); GitHub Actions WIF pipeline with no stored credentials (10 pts).
FinOps Quality (30 points): Cost model covers all three clouds with correct pricing (10 pts); DR tier costs are included as separate line items (5 pts); committed-use discounts applied to stable baseline (5 pts); annual total within 10% of the reference model range (10 pts).
Well-Architected Rigour (30 points): Three HRIs identified from genuine architectural gaps, not invented findings (15 pts); each HRI includes specific WAT question, specific gap, and specific actionable remediation (10 pts); at least one Serverless Lens HRI included (5 pts).
Bonus DR Runbook (10 points): SSM Automation Document deployed and tested with measured RTO under 90 seconds documented.

Final End-to-End Validation

Before submitting, run the complete validation checklist that confirms all three milestones are working together as a platform rather than as individual components. The integration tests go beyond what each milestone’s individual validation confirmed: they test cross-component interactions like the CloudFront cache behaviour routing to the correct DynamoDB region and the Traffic Manager geographic routing switching correctly between AWS and Azure.

Analogy🏏Cricket

🏏 Think of it like cricket: A final nets session before the big match does not just check each player can bat or bowl alone — it runs full-scenario simulations to expose the seams between them: does the opening pair actually call and run together, does the bowler's plan match the captain's field. Just as those seams are invisible when each skill is tested in isolation, this validation deliberately tests the joins between milestones that each milestone's own checks could not see: the Mumbai API check alone cannot tell whether Singapore's replica has fallen behind, and the replica check alone cannot tell whether Route 53 would actually route there. Just as the simulation proves the eleven function as a team, the suite chains checks across DynamoDB, CloudFront, WAF, Route 53, Traffic Manager, and IAM in one run — confirming CloudFront routes to the correct DynamoDB region and Traffic Manager switches between AWS and Azure. The payoff: a capstone is only as reliable as its weakest cross-component seam, and testing those seams together is what proves the three milestones form one platform rather than three separate deployments.

python

import requests, boto3, subprocess, time

# Final end-to-end validation suite.
ASSERT_PASS = []

def check(name, condition, details=''):
    status = '✓ PASS' if condition else '✗ FAIL'
    ASSERT_PASS.append(condition)
    print(f'{status}  {name}')
    if not condition and details:
        print(f'       {details}')

# ── AWS Primary Region ──
resp_mum = requests.get('https://api.ipl.srihayavadhana.in/api/scores/IPL2024FINAL', timeout=5)
check('Mumbai API responds HTTP 200', resp_mum.status_code == 200)
check('Response contains innings data', len(resp_mum.json()) > 0)
check('X-Served-By header present', 'X-Served-By' in resp_mum.headers)
check('Cache-Control header set',    'max-age' in resp_mum.headers.get('Cache-Control', ''))

# ── DynamoDB Global Tables ──
ddb_sin = boto3.client('dynamodb', region_name='ap-southeast-1')
desc = ddb_sin.describe_table(TableName='ipl-scores-global')['Table']
sg_replica = next((r for r in desc.get('Replicas', []) if r['RegionName']=='ap-southeast-1'), None)
check('Singapore DynamoDB replica exists', sg_replica is not None)
check('Singapore replica is ACTIVE', sg_replica and sg_replica['ReplicaStatus']=='ACTIVE')

# ── CloudFront WAF ──
wafv2 = boto3.client('wafv2', region_name='us-east-1')
acls = wafv2.list_web_acls(Scope='CLOUDFRONT')['WebACLs']
ipl_acl = next((a for a in acls if 'ipl' in a['Name'].lower()), None)
check('CloudFront WAF WebACL exists', ipl_acl is not None)

# ── Route 53 Health Checks ──
r53 = boto3.client('route53')
hcs = r53.list_health_checks()['HealthChecks']
ipl_hcs = [hc for hc in hcs if 'ipl' in str(hc).lower()]
hc_statuses = [r53.get_health_check_status(HealthCheckId=hc['Id'])['HealthCheckObservations'] for hc in ipl_hcs]
healthy = all(obs['StatusReport']['Status'].startswith('Success') for obs_list in hc_statuses for obs in obs_list)
check('Route 53 health checks all Healthy', healthy, 'Check Route 53 console for failing health check IPs')

# ── GitHub Actions: no stored credentials ──
iam = boto3.client('iam')
try:
    keys = iam.list_access_keys(UserName='github-deploy-user')['AccessKeyMetadata']
    check('No IAM access keys for deployment (WIF only)', len(keys)==0,
          'Found IAM access keys - remove and use WIF')
except iam.exceptions.NoSuchEntityException:
    check('No IAM deploy user (WIF only)', True)  # correct: no IAM user, using WIF

print(f'\nValidation: {sum(ASSERT_PASS)}/{len(ASSERT_PASS)} checks passed.')
if all(ASSERT_PASS):
    print('All checks passed. Ready to submit.')
else:
    print('Fix failing checks before submitting.')

The validation suite tests every critical integration point in the capstone. The DynamoDB replica check confirms the data layer’s active-active replication is operational; a replica in CREATING or UPDATING state means replication is not yet available and failover to Singapore would serve stale data. The IAM access key check confirms no deploy user was created as a shortcut around WIF configuration; the presence of IAM access keys for a deployment user is a Security HRI that would be flagged in the Well-Architected review.

Run the validation suite at least 24 hours before the submission deadline to allow time to investigate and fix any failures. Common failure causes at this stage: a CloudFormation stack in the wrong status (UPDATE_ROLLBACK_COMPLETE) from a failed deploy, a DynamoDB replica that was deleted and recreated causing a brief CREATING status, or a CloudFront distribution update still in InProgress status after a configuration change. All three states resolve automatically but may take 5 to 30 minutes.

Common Submission Mistakes

Including hardcoded cost values in the spreadsheet instead of formulas: traffic input changes should propagate automatically to all cost calculations; hardcoded values require manual recalculation and are not auditable.
Submitting a Well-Architected review that identifies hypothetical HRIs not present in the as-built architecture: every HRI must be a genuine finding from the WAT review of the actual deployed resources, not a generic security recommendation.
Forgetting to include the Azure Traffic Manager and replication pipeline costs in the cost model: the warm standby tier costs $30-60 per month and must appear as separate line items, not be omitted because it is not the primary traffic path.
Using the default Lambda execution role (AWS Lambda Basic Execution Role) or DynamoDBFullAccess: both are Security HRIs that the WAF review should identify; if found during final validation, they are also quick remediations to implement before submission.
Submitting only the Mumbai API endpoint without confirming the Singapore replica responds independently: the Singapore endpoint should be separately curl-tested to confirm it serves data before submission, because the active-active design requires both regions to be independently functional.

A Note on Production Readiness

The capstone architecture is production-ready in the sense that it applies every major architectural pattern the course has taught: active-active multi-region deployment, CDN edge caching, WAF protection, keyless CI/CD authentication, multi-cloud failback, FinOps cost governance, DR automation, and Well-Architected review. These are the same patterns used by production platforms serving millions of users daily.

A real production deployment would add several additional layers not in scope for this course: multi-tenant data isolation, advanced monitoring with distributed tracing, API versioning strategy, load testing to validate the architecture’s performance under 10x the expected peak, a formal change management process for production deployments, and a quarterly GameDay with the full operations team. The capstone builds the architectural foundation; production maturity is built through operational experience on top of this foundation.

The skills demonstrated in this capstone — multi-cloud serverless architecture, FinOps cost modelling, DR planning and automation, and Well-Architected review — are the skills that differentiate a cloud engineer from a cloud architect. A cloud engineer deploys services; a cloud architect designs systems that meet business requirements for cost, reliability, security, and performance simultaneously across multiple cloud providers. You have built and reviewed a system that does exactly that.

Analogy🏏Cricket

🏏 Think of it like cricket: The Capstone submission is the IPL Final scorecard: a complete record of the full match that documents every partnership, every bowling spell, and every fielding contribution that resulted in the final outcome. Just as the scorecard is not just the final score but the complete evidence of how that score was achieved, the capstone submission is not just a deployed URL but the complete evidence of how every architectural decision was made, what it costs, how it recovers from failure, and what its remaining risks are. Just as the match-winning captain’s interview covers both the tactical decisions that worked and the mistakes that nearly cost the match, the Well-Architected review covers both the architectural decisions that met requirements and the High Risk Issues that remain as future improvements. Just as the IPL season culminates in the Final that tests every skill the team has developed, Course 5 culminates in the Capstone that tests every architectural pattern the course has taught. This reveals why the capstone includes not just implementation but also FinOps, DR, and review: a production-ready cloud architecture is not proven by deployment alone but by the evidence that it meets its cost, reliability, security, and performance targets simultaneously under review by a structured framework.