No history yet

Self-Service Portal Integration

Architecting the Self-Service Layer

With the core infrastructure automated and hardened, the focus shifts to operational efficiency. Managing 1,200+ WorkSpaces through support tickets is untenable. A self-service portal is necessary to empower users while maintaining strict governance. Two primary architectural patterns exist for this: leveraging AWS Service Catalog or building a custom serverless application.

AWS Service Catalog provides a managed way to create and govern a portfolio of IT services. You can define a WorkSpace product with specific versions (bundles) and constraints, then grant users access to provision or manage them. It integrates with ITSM tools and has built-in approval mechanisms. However, this approach can be rigid. Customizing the user experience or implementing complex, multi-step approval logic that deviates from the standard ITSM connector flows can be challenging.

For maximum flexibility, a custom serverless application is the superior choice. This architecture typically involves a static web front-end hosted in an S3 bucket, served via CloudFront. This front-end communicates with a RESTful API built using and backed by AWS Lambda functions. This approach gives you complete control over the user interface, the exact actions exposed, and the intricate details of the backend approval and execution logic. Authentication is handled by an API Gateway Lambda authorizer, which validates a JWT from your corporate IdP to securely identify the user and their associated WorkSpace.

Integrating Approval Workflows

A key institutional requirement is an approval workflow for any action that incurs significant cost, such as changing a WorkSpace bundle from 'Standard' to 'Performance'. This prevents uncontrolled spending and ensures changes are justified. Integrating with an existing ITSM platform like ServiceNow or Jira is crucial for a seamless operational experience.

The process begins when a user submits a 'Modify Bundle' request. The initial Lambda function does not execute the change. Instead, it gathers user details and request parameters, then makes an API call to the ITSM tool to create a new approval ticket, pre-populated with all necessary information.

The ticket is routed to the user's manager for approval. Once the manager approves the ticket in the ITSM platform, the platform must notify our serverless application. This is achieved using webhooks. You configure a webhook in ServiceNow or Jira that triggers on ticket status change (e.g., to 'Approved') and sends a POST request to a dedicated 'approval' endpoint in our API Gateway.

This endpoint is backed by a second Lambda function. This function validates the webhook payload to prevent spoofing, confirms the approval status, and then places a message onto an SQS queue. A final 'executor' Lambda function polls this queue, picks up the approved job, and makes the call to the AWS WorkSpaces API to perform the ModifyWorkspaceProperties action. Using an SQS queue adds resilience, ensuring that even if the final API call fails temporarily, the request can be retried without losing the approval context.

// Example: JSON payload sent from Request Handler Lambda to create a ServiceNow ticket
{
  "short_description": "Request to upgrade AWS WorkSpace bundle for jdoe",
  "description": "User jdoe has requested to upgrade WorkSpace ws-a1b2c3d4 from 'STANDARD' to 'PERFORMANCE'. Justification: 'Requires more CPU for data analysis tasks.'",
  "requested_for": "jdoe@example.com",
  "assignment_group": "IT Infrastructure",
  "u_custom_field_workspace_id": "ws-a1b2c3d4",
  "u_custom_field_target_bundle_id": "wsb-p8s7q6r5"
}

Governing Self-Service Actions

Beyond approvals, the portal must enforce guardrails. Simple actions like 'Restart' can be executed immediately, as they are non-destructive and have no cost impact. The API Gateway method for this action would invoke a Lambda function that calls the RebootWorkspaces API directly.

The 'Rebuild' action is more sensitive. It reverts the WorkSpace C: drive to the last custom image while preserving the user's D: drive (the user profile volume). While useful for fixing a broken WorkSpace, it causes downtime and can't be undone. Governance here might involve rate-limiting requests per user or requiring a justification text field, which is logged for auditing purposes even if manager approval isn't required. The portal's Lambda backend would call the RebuildWorkspaces API.

Automated notifications are essential for a good user experience. Throughout the process, the Lambda functions should publish events to an topic. For instance:

  1. Request Submitted: User receives an email that their request is pending approval, including a link to the ITSM ticket.
  2. Request Approved/Denied: User is notified of the manager's decision.
  3. Execution Started: User is informed that their WorkSpace will be modified shortly and may be unavailable.
  4. Execution Complete: A final notification confirms the action was successful.

This architecture provides a powerful, scalable, and auditable system that dramatically reduces administrative overhead. It empowers users to resolve their own issues and request resources within a controlled framework, freeing up the IT team to focus on higher-value work.