A development team wants a custom UI 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 system, so the DevOps team needs to determine a safe implementation.
The initial idea is to expose an API that the UI can call, with the backend using an AWS SDK such as boto3, or possibly CDK, to create resources from developer-provided configuration. The concern is IAM: allowing the backend to provision arbitrary resources could require permissions close to administrator access. Infrastructure deployment has traditionally been restricted to the DevOps team, so this would be the first time developers receive a self-service deployment workflow.
What architecture would you recommend? Should the UI call a controlled API, trigger the existing infrastructure pipeline, use AWS Service Catalog, or follow another approach? How would you handle permissions, approvals, isolation, and developer autonomy?
5 Answers
AWS Service Catalog is worth evaluating. You can publish approved CloudFormation or Terraform products, define allowed parameters and defaults, and let developers provision them without granting unrestricted access to the underlying AWS APIs. It also has APIs if the organization requires a custom UI, so you may not need to implement a separate resource-provisioning engine.
Give developers autonomy within clear boundaries rather than handing out near-admin credentials. Separate sandbox and production accounts or environments, use IAM roles with least privilege, enforce organization policies and service-control guardrails, and restrict what the deployment role can create. For production, require review or approval; for disposable development environments, allow more automation and self-service.
A custom UI that supports every AWS feature will become a large, fragile proxy for AWS. Limit the product to a small catalog of supported use cases and expand it only when there is a real need.
Before designing the system, find out what problem the team is actually trying to solve. They may want faster environments, fewer DevOps bottlenecks, or a simpler interface—not a second infrastructure platform. If the existing pipeline is too slow or difficult to use, improve it and add a self-service layer on top instead of duplicating deployment logic.
If management still requires a separate experience, make it a thin front end over the established pipeline. Add validation, quotas, approval gates for sensitive environments, and complete audit trails.
There is also an organizational issue here. Developers should be able to deploy and own their applications, but that does not mean every team needs unrestricted access to production infrastructure. Work toward shared ownership and cross-training rather than maintaining a permanent DevOps-versus-development boundary. The implementation can still use roles and controls, but the goal should be autonomy through safe platform capabilities, not a second silo.
I would avoid building an API that directly creates arbitrary AWS resources. Keep Terraform, CloudFormation, or your existing IaC system as the source of truth, then expose approved modules or templates with a small set of validated inputs. The UI can submit a request that triggers the existing pipeline, where you retain plan, review, policy checks, audit logging, and controlled execution. The backend should assume narrowly scoped roles rather than having broad administrator permissions.
Prebuilt Terraform modules work well for this. Developers get useful self-service without being able to invent unrestricted infrastructure, and the modules can enforce networking, tagging, encryption, and instance-size policies.