Policy Model
The building blocks of the AWS Extension — resources, their specs, results, and how they relate to each other.
The AWS Extension Policy Model defines the resources the extension manages and how they relate to each other. Understanding this model helps you understand what the extension can do and why the creation flow follows the order it does.
The Resource Hierarchy
The AWS Extension organizes infrastructure as a hierarchy. Each level depends on the one above it:
Network Baseline → Cluster Baseline → Environment → Resource Group → Kubernetes and Cloud Resources
A Network Baseline establishes the VPC — the networking foundation everything else runs on. A Cluster Baseline provisions an EKS cluster inside that network. An Environment is a logical grouping that holds one or more Resource Groups, along with the Plans those resources can draw from.
A Resource Group is the isolation boundary. Each one provisions its own IAM role and policies, security groups, KMS key, and EC2 key pair, and every resource created inside it inherits those boundaries. A Resource Group holds two kinds of children:
Kubernetes resources — namespaces, workloads, jobs and cron jobs, ingress, config maps, secrets, storage, and Helm releases.
Cloud resources — S3 buckets, RDS instances and clusters, ElastiCache, SNS topics, SQS queues, Lambda functions, Secrets Manager secrets, SSM parameters, EFS, MSK, ECR, and EC2 hosts.
Plans catalog AWS account-level resources — hosted zones, ACM certificates, and AMIs — that Environments associate and their resources can reference.
Faults surface issues across any resource at any level of the hierarchy.
Resource Lifecycle
Every resource in the AWS Extension follows the same status lifecycle. Each resource has a Spec tab showing what was requested, a Result tab showing what was provisioned, and a link to the underlying ticket that executed the work. Updates trigger a reconciliation — the agent handles only the delta, not a full teardown and rebuild.
Resource Types
Last updated
Was this helpful?