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 ECRrepository 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 Functio; 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.

Operating boundary

Provisioning: monolayer creates and configures managed AWS services. The customer approves account, region, IAM, networking, encryption, and governance boundaries. AWS exposes service APIs and control planes.

Runtime compute: monolayer uses serverless and 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 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

Provision: create managed AWS services in the customer AWS account using IAM, VPC, encryption, telemetry, and resource configuration controls.

Scale: tune capacity through AWS-native service controls such as memory, vCPU, ACUs, request units, node families, cache behavior, and quotas.

Operate: observe and govern managed services without directly operating application servers, using logs, traces, policies, alarms, backups, workflow history, and service quotas.

Instance family translation

Request compute is delivered by AWS Lambda and AWS AppSync resolvers, with capacity expressed through memory, concurrency, runtime limits, request duration, and quotas.

Container compute is delivered by AWS Fargate and Amazon ECR, with task-level vCPU and memory plus managed placement and isolation.

Build compute is delivered by AWS CodeBuild, with EC2 and Lambda compute modes, on-demand builds, and reserved fleets.

Relational data is delivered by Amazon Aurora, using Aurora Serverless v2 ACUs or provisioned DB capacity. Cache data is delivered by Amazon ElastiCache through managed cache node families and replication topology.

Key-value and object data are delivered by Amazon DynamoDB and Amazon S3 through 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 128 MB to 10,240 MB in 1 MB 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.