A development team wants its own user interface for deploying AWS resources such as EC2 instances, even though the organization already has a shared automated infrastructure pipeline that handles these deployments. Management has approved building the new tool, so the challenge is designing it safely and in a way that does not create unnecessary duplication or operational risk.
One possible approach is to build an API that the UI calls, with the backend using an AWS SDK such as boto3 or the AWS SDK for the chosen language. The API would interpret configuration supplied by developers and create the requested resources. However, this raises significant questions around IAM permissions, since the backend might need broad privileges that approach administrator-level access.
Historically, infrastructure code has been managed exclusively by the DevOps team. This would be the first time another team could request and deploy resources through its own tooling. What architecture and governance model would you use? How can the team provide self-service while preserving security, approvals, auditability, reusable infrastructure patterns, and the existing CI/CD workflow?
4 Answers
AWS Service Catalog is a strong fit for this kind of self-service. DevOps can define approved products or templates, including the networking, IAM, tagging, and instance settings that are allowed. Developers get a simpler catalog-style experience without receiving broad permissions to create arbitrary infrastructure. Your existing CI/CD process can manage the catalog products and their updates.
Before designing the API, clarify what problem the team is actually trying to solve. If the request is mainly about faster access, standard environments, or removing repetitive tickets, the existing platform might be extended with reusable templates and a self-service workflow. Duplicating the deployment system means another tool to secure, maintain, document, and support, so the new interface should add a clear capability rather than reproduce the same pipeline.
Keep the infrastructure as code and make the UI update a version-controlled configuration rather than directly creating resources. For example, the API could validate a request, update a Terraform module or CloudFormation parameters in a repository, and then let the normal CI/CD pipeline plan, approve, and deploy the change. That gives you an audit trail, review points, drift detection, and infrastructure that remains documented in code.
I would avoid giving an API administrator-equivalent credentials and avoid letting users submit arbitrary templates. Build approved modules or constructs with a limited set of parameters, validate them, and deploy through a controlled role. Enforce account boundaries, tagging, quotas, expiration dates, logging, and policy checks. The UI should expose supported use cases, not become a second unrestricted AWS console.
Even if the organization keeps the new interface, it can still be treated as a front end for the existing platform instead of a separate provisioning engine. That keeps the deployment controls and operational ownership centralized while giving the development team the workflow they asked for.