# Architecture specs # Executive Summary monolayer provisions AWS managed services inside the customer AWS account. The platform model deliberately avoids customer-operated application servers and replaces traditional host sizing with AWS service-native controls: Lambda memory, Fargate vCPU and memory, Aurora Capacity Units, DynamoDB request units, ElastiCache node families, CodeBuild compute modes, CloudFront distribution controls, AppSync resolver limits, EventBridge request envelopes, Step Functions workflow execution controls, and ECR repository policies. This specification defines the technical operating model for monolayer Autopilot across compute, data, edge delivery, orchestration, networking, storage, security, observability, and governance. It is written for engineering leaders, platform teams, security reviewers, enterprise architects, and implementation partners who need a clear view of what monolayer provisions, what the customer controls, and how capacity and operational responsibilities are expressed. ## Key Points - monolayer provisions AWS managed services inside the customer AWS account. - Capacity is expressed through service-native controls instead of customer-operated host sizing. - Identity, networking, encryption, audit, observability, and governance remain customer account native. ### Strategic design principles monolayer follows a managed-infrastructure architecture. The customer AWS account remains the authoritative boundary for identity, network placement, encryption, audit data, regional configuration, and service-level governance. monolayer Autopilot provides the provisioning and operating pattern, while AWS managed services provide runtime primitives. Service-native capacity replaces host-native capacity. Runtime sizing is expressed through AWS managed service controls instead of EC2 instance ownership. The customer-owned security boundary remains central. IAM, VPCs, security groups, KMS, SECRets Manager, logs, traces, WAF, repository policies, and resource policies remain under the customer account boundary. Managed operations are the default. Long-lived application hosts, patch cycles, and customer-managed orchestration servers are avoided. ### Scope **In scope:** request compute through AWS Lambda and AWS AppSync resolvers; container compute through AWS Fargate and Amazon ECR; build compute through AWS CodeBuild; relational data through Amazon Aurora; cache data through Amazon ElastiCache; key-value and object data through Amazon DynamoDB and Amazon S3; edge delivery through Amazon CloudFront; event integration through Amazon EventBridge; workflow orchestration through AWS Step Functions; and account-native networking, storage, security, observability, and governance controls. **Out of scope:** customer-operated EC2 application server fleets, direct customer sizing of EC2 instance types for application hosts, customer-managed patching of application server operating systems, customer-managed long-lived workflow orchestration hosts, product pricing, commercial terms, support SLAs, contractual service-level commitments, application-specific schemas, business logic, release plans, or user experience requirements. ### Reference architecture monolayer provisions managed AWS resources inside the customer AWS account. The runtime architecture is composed of managed compute, managed data services, managed edge delivery, event routing, workflow orchestration, image registries, and build execution. At a high level, monolayer provisions AWS managed services in the customer account. Compute executes through Lambda, Fargate, AppSync resolvers, and CodeBuild rather than customer-operated servers. Data persists in Aurora, DynamoDB, S3, and ElastiCache according to workload needs. Edge and API access are exposed through CloudFront, AppSync, and service endpoints. Eventing and orchestration are handled through EventBridge and Step Functions. Customer account controls govern IAM, networking, logging, encryption, regional placement, and auditability. ### Operational boundary Provisioning: monolayer creates and configures user managed AWS services. The customer manages account, region, IAM, networking, encryption, and governance boundaries. AWS exposes service APIs and control planes. Runtime compute: monolayer uses serverless managed compute services. The customer sets service-specific runtime controls where exposed. AWS runs functions, containers, resolvers, and builds. Data services: monolayer provisions managed data resources. The customer controls access, encryption, lifecycle, backup policy, and topology. AWS operates storage engines and service durability via mechanisms. Networking, security, and observability remain account-native. Customers own VPCs, subnets, endpoints, routing, security groups, TLS policy, IAM, KMS, SECRets Manager, WAF, resource policies, logs, metrics, traces, alarms, and retention policy. ### Delivery flow Provisioning: create and manage AWS services in the customer AWS account using IAM, CPV, encryption, telemetry, and resource configuration policies. Scaling: through AWS-native service configurations such as memory, vCPU, request units, network failovers, cache behaviors, and quotas. Operating: observed and governed managed services without direct operating application services, using logs, traces, policies, alarms, backup workflows, and service requestato. ### Intent and functionality transition Request compute delivered by AWS Lambda and AWS AppSync resolvers, which can exhibit precision through concurrency, net minimum latency, guaranteed throughput, and duration. Container compute delivered by AWS Fargate and Amazon ECR, which showcase level-based VPC and memory placement and isolation. Build compute provided directly by AWS CodeBuild, which integrates into EC2 and serverless environments, on-demand, for resources. Event data delivered by Amazon Aurora and S3, ensuring granular access controls, request units, partitions, prefixes, storage classes, and quotas. Edge, event, and workflow capacity are expressed through CloudFront distributions, EventBridge buses and targets, and Step Functions state transitions and execution quotas. ### Service catalog AWS Lambda provides event and request compute. Memory is configurable from 128MB to 10,240MB in 1MB increments, and CPU, network, and I/O scale with memory. AWS Fargate provides serverless container runtime. Linux tasks are expressed as task-level vCPU and memory, with placement and isolation managed at the task level. AWS CodeBuild provides managed build execution with EC2 or Lambda compute modes, ephemeral builds, project configuration, fleets, roles, and quotas. Amazon Aurora provides managed relational databases using Aurora Serverless v2 ACUs or provisioned capacity. Amazon ElastiCache provides managed cache layers through node families, shards, replicas, snapshots, and parameter groups. Amazon EventBridge provides event bus and integration fabric. AWS Step Functions provides deployment and workflow orchestration. Amazon ECR provides the container image registry for build and runtime artifacts. ### Network, storage, and security specifications Networking is configured through VPC subnets, security groups, managed endpoints, TLS policies, private AWS service access, and edge distribution controls. Services expose AWS-managed endpoints while customer routing and access rules remain explicit. Storage is expressed through managed service constructs rather than attached host disks. Lambda, Fargate, CodeBuild, Aurora, ElastiCache, DynamoDB, S3, EventBridge, Step Functions, and ECR each expose service-native storage and durability controls. Security is account-native and service-specific. The customer AWS account remains the authority for identity, networking, encryption, and audit data. Core controls include IAM roles and policies, least-privilege deployment roles, runtime execution roles and task roles, service resource policies, KMS encryption, SECRets Manager integration, VPC isolation, subnet placement, security groups, TLS, WAF, repository policies, logs, traces, execution history, and audit signals. ### Observability and operations monolayer operations are based on managed service telemetry rather than host telemetry from customer-operated servers. ### Implementation readiness and acceptance Before production adoption, teams should approve target AWS account and region strategy, define IAM roles and deployment boundaries, design VPC subnets and routing, approve KMS and encryption policy, define SECRets Manager usage, configure logging and alarms, document backup and recovery expectations, review service quotas, configure ECR lifecycle and scanning, define edge security controls, agree data lifecycle policies, and establish operational runbooks. A monolayer deployment conforms to this specification when application runtime capacity is expressed through managed service controls, all provisioned resources reside inside the customer AWS account boundary, IAM and audit controls are customer-governed, compute and data services map to the service catalog, network access is explicitly governed, storage is service-native, observability is actionable, and quotas, backup policies, and lifecycle policies are reviewed before production launch.