A courts case-management vendor insists on an exotic database engine feature that Amazon RDS does not support, and the county otherwise standardizes on managed RDS and Aurora. How should architects treat a self-managed database on Amazon EC2?
Select an answer to reveal the explanation.
Short Explanation
Self-managed on EC2 is the exception desk, not the county standard. If courts truly need a feature RDS doesn't have, document it, run it on EC2, and keep an exit ramp. Don't turn one vendor quirk into a fleet of homemade databases.
Full Explanation
When a courts case-management vendor insists on an exotic database engine feature that Amazon RDS does not support, and the county otherwise standardizes on managed RDS and Aurora, architects should allow a self-managed database on EC2 only for the documented feature exception, with an exit plan toward managed services when feasible. That exception discipline protects the municipal standard without rejecting the courts workload. Making self-managed databases on EC2 the default for every departmental system to keep options open fails standardization and multiplies patching risk. Rejecting the courts workload from AWS because RDS cannot host that one feature fails by abandoning a viable EC2-hosted exception path. Converting the exotic engine to Amazon ElastiCache for Redis so no database remains fails purpose—cache is not a substitute for a courts system of record. Exam caveat: self-managed on EC2 is an exception with an exit plan, not the default. Operational check: document the required feature and RDS gap, approve EC2 hosting with hardening baselines, define exit criteria toward managed, monitor patch SLAs, and revisit quarterly with the courts vendor. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.