How to use this tool

Architecture Change Impact Analyser — Guide

A walkthrough of the impact analyser: how the risk engine works, what each input controls in the output, what the severity levels mean, and how to use the exported report in your change management process.

What is this tool for?

Infrastructure changes in payment environments fail in predictable ways. A service migration corrupts data during cutover. An IAM tightening denies access to a Lambda that was never listed in the dependency map. A KMS key rotation leaves three services unable to decrypt their secrets. A network change breaks a TLS certificate SAN that nobody noticed was hardcoded.

The Architecture Change Impact Analyser is a pre-change planning tool. You describe the change you are planning — the service, the type of change, the environment, and the downstream services you know about. The risk engine evaluates the combination against known failure patterns and produces a severity-rated report with a specific action checklist.

The output is designed to be attached to a change request ticket and shared with the downstream service owners who need to be notified before the change goes ahead.

Step-by-step walkthrough

Step 1 — Describe the change
  1. Service Being Changed: select the AWS service type you are modifying. 20 service types are available — from Lambda and ECS to KMS, IAM, and CloudFront. Choose the type that most closely matches the primary service being modified.
  2. Type of Change: select the nature of the change. Options cover Migration, Replacement, Scaling, Network, IAM, Configuration, Deprecation, Version Upgrade, Encryption, and Endpoint changes. This selection has the largest single influence on the risk output — a Configuration update carries very different risk to a Migration.
  3. Target Environment: select where the change will be applied. Production and "All Environments" add the live traffic exposure risk factor, which is the most significant severity multiplier in the risk engine.
Step 2 — Tag downstream services
  1. Click every service that consumes or depends on the service being changed. This includes direct callers (e.g. a Lambda that reads from the RDS instance you are migrating) and indirect consumers (e.g. a web client that calls an API Gateway backed by that Lambda).
  2. The downstream count drives the Blast Radius risk calculation. 5 or more downstream services triggers a High blast radius warning. 8 or more escalates to Critical.
  3. If you are unsure, err on the side of tagging more services. The cost of over-communication to a service owner who turns out to be unaffected is far lower than the cost of a downstream service breaking silently.
Step 3 — Add context (optional)
  1. Use the notes field to add specifics the structured fields cannot capture — for example: the maintenance window you have planned, the version numbers involved in an upgrade, or which accounts and regions are in scope for a multi-environment change.
  2. Notes containing more than 20 characters trigger an "Analyst Note" risk item in the output, reminding you to ensure the specific context has been documented in your change request ticket.
Step 4 — Review the report and export
  1. Click Analyse Impact. The report generates in under 2 seconds.
  2. Review the overall severity and the three summary metrics: Services Affected, Compliance Flags, and Rollback Complexity.
  3. Work through the Risk Areas section. Each item explains why the risk was flagged and what to validate. Pay particular attention to Critical and High items — these represent the failure modes most likely to cause a production incident.
  4. The Recommended Actions are ordered by priority. The first action is always opening a formal change request. Complete the list in order before deploying.
  5. Click Export Report to download arch-change-impact-[date].md. Attach it to your change request ticket and share the action checklist with the relevant service owners.

Severity levels explained

Severity is calculated by a weighted risk score. Multiple risk factors accumulate — a production data-layer migration with 8 downstream services will score higher than a staging configuration update with no downstream dependencies. The score thresholds below are calibrated against common payment environment failure patterns.
CriticalScore ≥ 10Do not proceed without a formal change management process, named rollback engineer, and explicit sign-off. Consider a staged rollout or blue/green deployment.
HighScore 7–9Staging validation, downstream notification, and a defined rollback trigger threshold are required before production deployment.
MediumScore 4–6Standard change management applies. Validate downstream services and communicate the change window to affected team leads.
LowScore 0–3Low-risk change. Follow standard deployment checklist and monitor error rates for 30 minutes post-deployment.

Risk areas the engine evaluates

Not every risk area will appear in every report. Each one is only surfaced when your specific inputs trigger the relevant condition. A report with fewer risk areas is not necessarily lower risk — it may simply mean that the specific combination you have described does not trigger those patterns.
Live Traffic ExposureTriggered when the target environment is Production or All Environments. Any misconfiguration immediately affects live payment flows — the highest-priority risk in every analysis.
Data IntegrityTriggered for changes to RDS, Aurora, DynamoDB, or ElastiCache. Migrations and replacements escalate to critical. Configuration-only changes escalate to high. Covers schema drift, replication lag, and connection pool exhaustion.
Network ConnectivityTriggered for VPC, API Gateway, and CloudFront changes. Covers silent DNS breakage, TLS certificate SAN mismatches, and service-to-service connectivity failures that are hard to detect until traffic flows.
Access ControlTriggered for IAM Role / Policy changes or when "IAM / Access Change" is selected as the change type. Unintended denials after a policy tightening are the most common post-deployment incident type for IAM changes.
PCI-DSS ComplianceTriggered when an IAM change targets a production environment that handles cardholder data. PCI-DSS v4.0 Requirement 7 mandates re-validation of access control assignments after any role or policy change in a CDE.
Encryption & Key ManagementTriggered for KMS Key changes or when "Encryption / KMS Change" is selected. Rotating or replacing a KMS key without updating all dependent services causes decryption failures that can be catastrophic in payment environments.
Blast RadiusTriggered when 5 or more downstream services are selected. High downstream dependency count means a failed change cascades broadly. The risk scales to critical at 8 or more downstream services.
Downstream DependenciesTriggered when 1–4 downstream services are selected. Covers hardcoded endpoints, connection strings, and ARN references that will break when the upstream service changes.

Key terms

Blast RadiusThe number of services that will be affected if a change causes an unexpected failure. A large blast radius means a failed change will cascade to many downstream consumers — increasing the urgency of rollback and the difficulty of isolating the failure.
Rollback ComplexityAn estimate of how difficult it would be to reverse the change after it has been applied. High means data may have been mutated in a new format, making a simple redeploy insufficient. Always define your rollback procedure before starting a High or Critical change.
Compliance FlagA marker that indicates the change combination has implications for a regulatory or compliance framework — specifically PCI-DSS v4.0. Each compliance flag in the report references the specific requirement section that is affected.
CDE (Cardholder Data Environment)The set of systems that store, process, or transmit cardholder data. PCI-DSS compliance obligations apply to the CDE and the systems connected to it. The impact analyser uses production + IAM change as a proxy for CDE risk — adjust based on your actual CDE scope.
Dual-Write StrategyA migration technique where both the old and new data stores are written to simultaneously for a validation period. Allows verification of data consistency before cutting read traffic to the new store. Recommended by the tool for all data-layer migrations.
IAM Access AnalyzerAn AWS service that analyses resource-based policies and IAM policies to identify access that is more permissive or more restrictive than intended. The tool recommends running Access Analyzer before and after any IAM change to catch unintended denials or grants.

Frequently asked questions

Ready to assess your change?
Describe the change in under 2 minutes and get a risk-rated report with a full action checklist.