Shared responsibility on AWS: what your managed host does and what you do

"Do you manage our database usernames, accounts, and indexes?" It is a fair question, and the answer surprises some people: no. On a managed AWS environment, responsibility is split three ways, between AWS, your managed host, and your organization. Knowing where the lines fall saves time when something goes wrong, and avoids the worst outcome: a task everyone assumed someone else was doing.

The three layers

AWS's own model splits security of the cloud from security in the cloud. AWS looks after the data centers, hardware, network, and the virtualization layer. Everything built on top is the customer's side. When you work with a managed host, your side is split again: the host operates the infrastructure and platform, and your organization keeps what is uniquely yours.

Databases: where the line sits

eWay's database scope is the platform: keeping the engine patched and on a supported version, taking and testing backups, securing access to the server, and improving performance. The database's contents belong to your organization and your application: the user accounts your applications and staff use, the tables and schema, the indexes your queries depend on, and the data. When eWay finds a slow query or a missing index during performance work, eWay tells you what it found and what would help; your application team decides on and makes changes to the database's design.

This split exists for a good reason. Schema and indexes are part of how your application works. A change made by someone outside the application team can break features, reports, or integrations that the host cannot see.

Examples that come up

• "Add a database user for our report writer." Your database administrator or developer creates it. eWay can confirm network access to the database is allowed from where the report writer connects.
• "The site is slow." eWay checks the infrastructure, caching, and database server, and shares any slow queries found. Rewriting the query or changing an index is your team's change.
• "Restore yesterday's data." eWay restores from backup into a parallel copy; your team confirms which records are correct.
• "Our plugin has a vulnerability." For CMS sites eWay manages, eWay updates it. For custom code, your developers fix it and eWay deploys it.

Where confusion usually starts

• "Managed" means different things. AWS calls RDS a managed database because AWS runs the server. Your managed host operates the environment. Neither manages your data.
• The agency built it, the host runs it. When a site was built by an agency, custom features stay the agency's or your team's responsibility unless that work is handed over in writing.
• Accounts inside applications. Users in your CMS, CRM, or database are your organization's to create and remove, even though the host can see the systems they live in.

Common questions

Who owns the AWS account? Ideally your organization, with eWay given role-based access; see who owns your AWS account.

Is security all eWay's job? The infrastructure side is. Strong passwords for CMS users, who gets access, and what data you collect are decisions only your organization can make.

Where is this written down? Your service agreement defines the scope for your environments. This article explains the usual split in plain terms.

How eWay works within this model

On managed infrastructure, eWay owns everything above the hypervisor: the network design, operating systems, server software, managed CMS updates, monitoring, backups, and security controls. Your organization owns content, CMS user roles, custom code you author, and data classification. Patches are validated in non-production first, every production change has a tested rollback, and every privileged session is logged.

What to include in a support ticket

• What you need, and whether it touches the database's contents or the platform
• The environment and application affected

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: the AWS Well-Architected Framework and what managed hosting should include.