AWS-ready WordPress architecture
Build in WordPress. Run the platform on AWS.
Keep WordPress as the familiar content, editing, layout, and admin layer while identity, APIs, static delivery, AI, workflows, and protected runtime logic run through modular services in the customer’s AWS account.
Runtime model
Visitor or editor
↓
WordPress experience layer
↓
WP Suite integration layer
↓
Customer-owned AWS services
WordPress remains the CMS and working environment. The AWS account, deployed infrastructure, runtime data, and service costs remain under customer control.

Platform capabilities
Add cloud capabilities without turning WordPress into the application backend.
Start with the requirement already present in a project, then add other modules without changing the overall ownership model or editorial workflow.
Identity and protected access
Use Gatey with Amazon Cognito for sign-in, registration, SSO, MFA, user attributes, protected experiences, and JWT- or IAM-secured API access.
AI and knowledge experiences
Use AI-Kit for on-device tools, knowledge-base search, DocSearch, chat experiences, and optional AWS-backed processing when the browser is not the right runtime.
Forms and workflow entry points
Use Flow for forms, multi-step journeys, process maps, webhooks, file uploads, email actions, and event-driven workflow paths.
Static delivery and protected frontends
Export WordPress output for S3 and CloudFront delivery, then combine static pages with browser-based authentication and AWS-backed application features.

Platform layers
Each layer has one clear responsibility.
01
Experience layer
The browser renders the public site, authenticated journeys, editor-facing tools, and customer-facing interactions. The frontend may remain in WordPress, go headless, or be exported statically.
02
Content layer
WordPress manages content models, media, editorial workflows, page building, and the admin experience teams already know.
03
Integration layer
WP Suite blocks, plugins, configuration, and browser-side utilities connect the WordPress experience to authentication, APIs, AI, publishing, and workflows.
04
AWS runtime layer
Services such as Cognito, API Gateway, Lambda, S3, CloudFront, Bedrock, WAF, and EventBridge provide the deployed runtime in the target AWS account.
Adoption path
Start with one need. Expand into a platform.
WP Suite is modular, so an existing WordPress project can adopt the architecture incrementally instead of being rebuilt as one large migration.
- Choose the first boundary — Identify the immediate requirement: authentication, protected APIs, AI, workflow automation, or static delivery.
- Connect the WordPress site — Install and configure the relevant WP Suite module where editors and developers already manage the project.
- Deploy the required AWS services — Provision only the backend components the use case needs in the customer or target AWS account.
- Reuse and extend — Add further capabilities through the same integration and ownership model as project requirements grow.

Next step
Deploy the runtime your WordPress project actually needs.
Review the available backend components, choose the services required for the current use case, and keep the architecture ready for later expansion.
