A development team wants a custom user interface for deploying resources such as EC2 instances, even though the organization already has an automated infrastructure pipeline that everyone uses. Management has approved building a separate solution, so the infrastructure team needs to implement it.
My initial idea is to create an API layer that the UI can call. The backend could use the AWS SDK, Boto3, CDK, or another approach to process configuration files and provision the requested resources. The difficult part is IAM: the service may need permissions close to administrator access, which creates obvious security and governance concerns.
Historically, infrastructure code and deployment permissions have stayed within the infrastructure team. This would be the first time a development team could provision its own resources through custom tooling. How would you architect this? What controls, AWS services, or deployment patterns would you use?
5 Answers
There is also an organizational angle: developers should have meaningful deployment autonomy, but that does not require every team to build its own infrastructure platform. A shared platform team can provide paved roads, templates, observability, and documented interfaces while application teams own their services. If the current process is too restrictive, improve that process and understand what capability is missing before duplicating it.
If a separate UI is unavoidable, make it a request and orchestration layer rather than an unrestricted AWS proxy. Authenticate users through the company identity provider, authorize specific products and environments, validate every input against an allowlist, enforce quotas and tags, and require approvals for production or high-risk changes. The backend should assume narrowly scoped deployment roles and ideally submit changes to the existing pipeline instead of creating resources synchronously.
I would avoid creating a second system that provisions AWS resources directly. Keep the existing infrastructure-as-code pipeline as the source of truth and offer developers approved, reusable modules with a limited set of inputs. Their UI could generate a pull request or configuration change, then let the normal validation, policy checks, review, and deployment process handle it. That gives them a self-service experience without handing a web service broad administrator permissions.
Prebuilt Terraform modules or similar templates are a good fit here. They can expose only supported options while keeping networking, security, tagging, and backup settings under platform control.
First clarify the problem they are trying to solve. They may not actually need a custom provisioning engine; they may need faster access to a few standardized environments or less friction in the current pipeline. AWS Service Catalog, CloudFormation templates, or a portal backed by approved templates can provide self-service while keeping permissions and guardrails centralized. A custom API should be the last option, not the starting point.
For experimentation, give the team a separate AWS account or isolated environment with budgets, expiration policies, and limited permissions. Keep production and shared environments behind the established deployment process. That lets them iterate freely without turning a new custom UI into a high-privilege control plane that the infrastructure team must secure and operate forever.
An approval gate is useful, but it should complement preventive controls rather than replace them. A reviewer should not be expected to catch an invalid subnet, excessive instance size, or an unsafe IAM policy manually.