A development team wants its own user interface for deploying AWS resources such as EC2 instances, even though there is already an established automated infrastructure pipeline used by the organization. Management has approved building the new tool, so the DevOps team needs to determine a safe implementation approach.
One idea is to create an API that the UI can call. The API could use the AWS SDK, boto3, CloudFormation, or another infrastructure-as-code framework to provision resources based on configuration submitted by developers. The difficult part is designing IAM permissions: the tool may need broad privileges, potentially close to administrator access, unless the available resource types and configurations are tightly restricted.
What architecture and controls would you recommend for this kind of self-service provisioning? How can we preserve infrastructure-as-code practices, approvals, auditability, tagging, and security while still giving developers a simpler interface?
5 Answers
Before building anything, clarify what problem the team is trying to solve. If they only want faster access to a few standard environments, a catalog of approved, reusable components may be enough. Giving them a general-purpose AWS provisioning API can create a second platform to operate and may introduce significant security and support overhead.
Keep the actual infrastructure in code and have the API update a Git-based configuration rather than creating resources directly. For example, the UI could choose approved Terraform modules or CloudFormation templates and submit parameter values. A pull request or automated pipeline can then validate, approve, deploy, and record the change. That gives you a clear audit trail and keeps the deployed state documented.
I would avoid granting the service administrator-level permissions and avoid letting users submit arbitrary infrastructure definitions. Use narrowly scoped deployment roles, an allowlist of modules or products, policy validation, quotas, mandatory tags, and centralized logging. Every request should go through the same validation and deployment controls as the existing pipeline, even if the front end makes the process look self-service.
CloudFormation stacks, templates, and parameters could also provide the foundation. Define the allowed resource types and settings in reusable templates, then expose only the parameters that developers are supposed to control. Apply consistent tagging, naming, networking, and ownership rules in the templates instead of allowing arbitrary API calls.
AWS Service Catalog is worth considering. It is designed for self-service provisioning while allowing the platform team to define approved products, templates, parameters, constraints, and deployment roles. You can manage the catalog through your existing infrastructure-as-code and CI/CD processes instead of giving the UI unrestricted AWS permissions.
That makes sense. The main concern is preserving the controls and history from the existing pipeline instead of creating a privileged shortcut around it.