---
version: alpha
name: Cloudscape Cloud Ops Interface
description: "A cloud-operations console interface inspired by Cloudscape Design System and AWS management-console patterns. It uses a neutral service canvas, dense app layout, blue action accent, high-information tables, side navigation, split panels, flashbar/alert messaging, wizard and collection patterns, light/dark modes, strong accessibility guidance, and responsive behavior for infrastructure, security, observability, and admin products."

colors:
  primary: "#0972d3"
  primary-hover: "#033160"
  on-primary: "#ffffff"
  canvas: "#f2f3f3"
  surface: "#ffffff"
  surface-card: "#ffffff"
  surface-soft: "#f9fafa"
  surface-inset: "#eaeded"
  surface-selected: "#e7f4ff"
  ink: "#16191f"
  body: "#414d5c"
  muted: "#5f6b7a"
  subtle: "#879596"
  hairline: "#d5dbdb"
  hairline-strong: "#aab7b8"
  focus: "#0972d3"
  success: "#037f0c"
  success-surface: "#f2fcf3"
  warning: "#855900"
  warning-surface: "#fff8e5"
  danger: "#d13212"
  danger-surface: "#fff3f1"
  info: "#0972d3"
  info-surface: "#f1f8ff"
  inverse-canvas: "#0f141a"
  inverse-surface: "#1b2229"
  inverse-card: "#161d24"
  inverse-ink: "#f2f8fd"
  inverse-body: "#d5dbdb"
  inverse-hairline: "#3c4858"

typography:
  display-xl:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 44px
    fontWeight: 700
    lineHeight: 1.12
    letterSpacing: 0
  heading-lg:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 28px
    fontWeight: 700
    lineHeight: 1.2
    letterSpacing: 0
  heading-md:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 20px
    fontWeight: 700
    lineHeight: 1.3
    letterSpacing: 0
  body:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 14px
    fontWeight: 400
    lineHeight: 1.5
    letterSpacing: 0
  body-sm:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 12px
    fontWeight: 400
    lineHeight: 1.45
    letterSpacing: 0
  caption:
    fontFamily: "Amazon Ember, Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
    fontSize: 11px
    fontWeight: 700
    lineHeight: 1.3
    letterSpacing: 0
  mono:
    fontFamily: "ui-monospace, SFMono-Regular, Menlo, Consolas, Liberation Mono, monospace"
    fontSize: 12px
    fontWeight: 500
    lineHeight: 1.5
    letterSpacing: 0

rounded:
  none: 0px
  xs: 2px
  sm: 4px
  md: 6px
  lg: 8px
  pill: 9999px

spacing:
  base: 8px
  xs: 4px
  sm: 8px
  md: 12px
  lg: 16px
  xl: 24px
  xxl: 32px
  section: 64px

components:
  button-primary:
    backgroundColor: "{colors.primary}"
    textColor: "{colors.on-primary}"
    typography: "{typography.body}"
    rounded: "{rounded.sm}"
    padding: 8px 14px
  button-normal:
    backgroundColor: "{colors.surface-card}"
    textColor: "{colors.ink}"
    typography: "{typography.body}"
    rounded: "{rounded.sm}"
    padding: 8px 14px
    borderColor: "{colors.hairline-strong}"
  container:
    backgroundColor: "{colors.surface-card}"
    textColor: "{colors.body}"
    typography: "{typography.body}"
    rounded: "{rounded.lg}"
    padding: 20px
    borderColor: "{colors.hairline}"
  alert:
    backgroundColor: "{colors.info-surface}"
    textColor: "{colors.body}"
    typography: "{typography.body}"
    rounded: "{rounded.sm}"
    padding: 12px 16px
    borderColor: "{colors.primary}"
  table-row:
    backgroundColor: "{colors.surface-card}"
    textColor: "{colors.body}"
    typography: "{typography.body}"
    rounded: "{rounded.none}"
    padding: 11px 16px
    borderColor: "{colors.hairline}"
  status-badge:
    backgroundColor: "{colors.success-surface}"
    textColor: "{colors.success}"
    typography: "{typography.caption}"
    rounded: "{rounded.pill}"
    padding: 2px 8px

layout:
  shell: "Cloud console app layout with service side navigation, breadcrumb, page header, tools/help rail, split panel, collection table, flashbar alerts, and wizard/detail patterns."
  grid: "Use full-width operational pages with a 240px service rail on desktop. Content containers stack vertically; collection tables dominate the main region."
  density: "High density but not cramped. Data tables, filters, key-value pairs, and actions remain scan-ready with explicit empty/loading/error states."
  interaction: "Use collection preferences, filtering, pagination, selection state, expandable rows, split panels, and wizard steps with visible validation and recovery."

guidance:
  do:
    - "Begin with service context, resource count, region/account scope, and next action."
    - "Use collection tables for resources and operational objects."
    - "Keep alerts, validation, and permissions close to the affected workflow."
    - "Provide preferences, density, filtering, pagination, and keyboard support for large tables."
    - "Use split panels for secondary detail without losing table context."
  dont:
    - "Do not copy AWS product branding, service icons, or console chrome into unrelated products."
    - "Do not hide errors in toast-only messages."
    - "Do not replace resource tables with decorative card grids when comparison matters."
    - "Do not use blue as decoration; it marks action, focus, and information."

caseStudy:
  source: "Cloudscape Design System and Cloudscape React components"
  urls:
    - "https://cloudscape.design/"
    - "https://cloudscape.design/get-started/for-developers/using-cloudscape-components/"
    - "https://github.com/cloudscape-design/components"
    - "https://github.com/cloudscape-design/components/blob/main/LICENSE"
    - "https://www.amazon.design/systems-design/cloudscape-open-source-design-system"
  analysis: "Cloudscape describes itself as an open source design system for building intuitive, engaging, inclusive experiences at scale, with code components, pattern guidelines, demos, visual modes, accessibility, and responsive support. Its source code is published under Apache 2.0. The reusable lesson is operational structure: app layout, navigation, collection table, split panel, wizard, flashbar, accessibility options, and preference controls should make cloud-scale resources comparable and recoverable."
---

# Cloudscape Cloud Ops Interface

Use this system for cloud operations, infrastructure control planes, security consoles, observability tools, database administration, IAM workflows, enterprise settings, incident dashboards, and any product where users compare many resources under account, region, permission, or environment constraints.

The posture is operational and explicit. The first viewport should show the service context, scope, resource count, table or workflow state, and the next safe action. Decorative storytelling belongs behind task clarity.

## Overview

Cloudscape Cloud Ops abstracts the reusable design logic of Cloudscape into an Interface resource. It captures console-grade information architecture: service navigation, page header, flashbar, collection tables, filters, pagination, split panels, wizards, and help rails.

It should feel like a serious operations console rather than a generic admin template. Users are often making risky decisions, so state, scope, permissions, validation, and recovery paths must stay visible.

## Colors

### Brand & Accent

Use `primary` #0972d3 for primary actions, links, focus, selected navigation, and informational emphasis. It is not a decorative glow or marketing gradient.

### Surface

Use `canvas` #f2f3f3 for the app shell, `surface-card` #ffffff for containers and tables, `surface-soft` #f9fafa for grouped headers, and `surface-inset` #eaeded for code-like or nested regions.

### Text

Use `ink` #16191f for page headers and key labels, `body` #414d5c for table content and reading, `muted` #5f6b7a for help text, and `subtle` #879596 for timestamps and low-priority metadata.

### Hairlines & Borders

Use `hairline` #d5dbdb for normal containers and row separation. Use `hairline-strong` #aab7b8 for inputs, selected rows, and divider emphasis. Keep shadows minimal; containers are bounded by border and layout.

### Semantic

Use success, warning, danger, and info colors only for real operational state. Every alert and status badge must include text, severity, and a recovery or next-step instruction.

## Typography

### Font Family

Use Amazon Ember only when available and appropriate; otherwise use Inter or system UI. Keep the product portable by relying on font metrics rather than brand-specific font ownership.

### Hierarchy

Page titles stay around 28-44px. Operational content mostly lives at 14px. Avoid oversized hero type that displaces resource data or status.

### Principles

Write explicit labels: Resource ID, Region, Status, Owner, Last modified, Permission, Policy, and Alarm state. Do not use poetic copy in high-risk operations flows.

### Note on Font Substitutes

Inter and system UI preserve the console-like rhythm well enough. If using a different enterprise font, keep 14px table readability and medium label weights.

## Layout

### Spacing System

Use an 8px base. Containers use 16-20px padding. Table rows use 10-12px vertical padding. Wizard steps and form groups use 16px to 24px between logical decisions.

### Grid & Container

Desktop uses a service rail plus main content. Main content is full-width because data tables and filters need horizontal room. Split panels open beside or below tables depending on width.

### Whitespace Philosophy

Whitespace is used to separate risk boundaries: filter area, action bar, table, alerts, and detail panel. Do not add ornamental whitespace that hides resource context.

## Elevation & Depth

Depth is mostly structural: sticky headers, borders, table grouping, split panels, and modal/wizard overlays. Use elevation only for popovers and modal dialogs that must interrupt the flow.

## Shapes

Use small 4-8px radii. Buttons and controls are utilitarian. Avoid soft consumer-style pills except for status badges and filter tokens.

## Components

### Buttons

Primary buttons use blue. Normal buttons use white, border, and dark text. Destructive actions should be separated, confirmed, and paired with scope details.

### Cards & Containers

Containers group operational context, but resource comparison belongs in tables. Use cards for summary, configuration, and status panels, not for large resource collections.

### Inputs & Forms

Forms must show label, optional/required status, hint, validation, and recovery. Long workflows should use wizards with visible steps and review screens.

### Navigation

Use service side navigation for resource families. Page-level tabs or segmented views can separate Overview, Resources, Monitoring, Settings, and Permissions.

### Signature Components

Use app layout, breadcrumbs, page header, flashbar, collection table, preferences, filter token, pagination, split panel, key-value pairs, and wizard review page.

## Do's and Don'ts

Do show account/region/environment scope. Do use tables for resource comparison. Do keep alerts actionable. Do support keyboard and preferences. Do provide empty/loading/error states.

Don't copy AWS service icons or console chrome. Don't use toast-only error reporting. Don't use card grids for resources that must be compared. Don't bury destructive scope in confirmation copy.

## Responsive Behavior

### Breakpoints

At 1024px, side navigation can collapse and split panels move below the table. At 720px, tables become horizontally scrollable with frozen priority columns or stacked resource summaries. At small mobile widths, wizards show one decision per screen.

### Touch Targets

Touch-first actions should be at least 44px high. Dense table controls may stay smaller on desktop but need keyboard and focus parity.

### Collapsing Strategy

Keep resource name, status, region/scope, and primary action visible before secondary metrics. Filters collapse into a summary token row. Preferences remain accessible.

### Image Behavior

Do not use decorative imagery. Use diagrams only when they clarify topology, flow, or dependency, and provide a text alternative.

## Iteration Guide

1. Define the operational object and its risk model.
2. List required scope: account, region, environment, permission, service, owner.
3. Choose table, wizard, split panel, or alert pattern based on user decision.
4. Map all statuses to semantic badges with text.
5. Add filtering, pagination, preferences, empty, loading, permission, and error states.
6. Verify keyboard path, focus visibility, mobile table behavior, and destructive action confirmation.

## Known Gaps

This resource abstracts Cloudscape and cloud-console patterns. It does not grant permission to copy AWS branding, service icons, console chrome, or proprietary product details. Cloudscape components and docs evolve, so production implementation should check the current official package, accessibility notes, and license.