Managed Services on AWS
Managed services on AWS
Operating AWS well depends less on adding tooling and more on structuring accounts, then applying Amazon CloudWatch, AWS Config, AWS Systems Manager and AWS Security Hub consistently across all of them. Most estates we assess have those services enabled somewhere and applied nowhere in particular. We standardise the operational layer organisation-wide, hold it in code, and run the environment from the signals it produces.
Why AWS
When this is the right platform.
- A multi-account structure under AWS Organizations separates blast radius, cost and permissions by design. Attribution becomes largely a property of where a workload sits, rather than a tagging discipline someone has to police forever.
- Amazon CloudWatch, AWS Config and AWS CloudTrail together give a consistent spine of metrics, configuration history and API activity, so an investigation can establish what changed, when and by whom without additional tooling.
- AWS Systems Manager provides patching, inventory, automation runbooks and session-based access through an agent already present on current Amazon Machine Images, so routine administration does not require open inbound ports or a bastion fleet.
- CloudWatch Application Signals expresses reliability as service level objectives against latency and error rate, which gives an operations conversation a target drawn from the service rather than from host metrics.
- Service control policies and Config rules apply organisation-wide, giving preventive and detective controls that survive a team spinning up a new account without telling anyone.
- Teams already working with Linux, containers and open-source tooling transfer their operational practice directly, and the same practice covers Amazon EC2, Amazon ECS, Amazon EKS and AWS Lambda workloads.
Where it is less suited
We would rather say this now than after a migration.
- CloudWatch charges separately for custom metrics, high-resolution metrics, log ingestion, storage, dashboards and Application Signals. A chatty application can turn CloudWatch Logs into a meaningful line item on its own, so log levels, retention and metric cardinality need setting per workload before the environment grows.
- AWS Config bills per configuration item recorded, which means cost tracks how often your environment changes rather than how big it is. Recording every resource type in every region, or an autoscaling group cycling instances, produces charges that look unexplained until someone scopes the recorder deliberately.
- Multi-account is the right pattern, and it adds real operational overhead. Identity federation, Config aggregators, Security Hub delegated administration and cross-account roles all have to be built and maintained before the estate becomes straightforward to run.
- AWS Security Hub and Amazon GuardDuty produce volume. Without agreed suppression rules and a severity model that reflects your architecture, the finding list becomes noise and people stop opening it.
- Several AWS services solve adjacent problems, such as patching through Systems Manager Patch Manager versus rebuilding from a new image. Without a written standard, different teams pick differently and the estate ends up with two operating models in it.
- Security service naming and packaging has shifted recently, so vendor documentation, blog posts and existing code do not all agree. We confirm current behaviour against your deployed configuration rather than trusting an article.
Business outcomes
What AWS delivers here.
- Cost attributed by structure, not by hope
- Finance gets spend broken down by account, application and environment in AWS Cost Explorer, with AWS Budgets thresholds they set themselves. Savings Plans and Reserved Instance coverage is reviewed before expiry rather than discovered after it.Agreed measure: Share of spend attributable to an owning account and application, plus commitment coverage checked before each expiry date.
- Configuration you can prove
- Internal risk teams and external assessors get AWS Config history showing what a resource looked like at a point in time and exactly when it changed. Most evidence requests then become a query instead of a small project.Agreed measure: Whether a named control can be evidenced from Config history without asking a workload team, tested on a sample at handover.
- Operational access without standing exposure
- Platform teams administer instances through AWS Systems Manager Session Manager, so routine access is permissioned, logged and does not depend on open inbound ports or shared keys. Auditors get a record of who connected to what.Agreed measure: Count of long-lived access keys and open inbound administrative ports remaining, tracked down from the baseline taken at transition.
- Findings that actually get closed
- Security leads get one aggregated view across accounts from AWS Security Hub and Amazon GuardDuty, with suppression rules agreed up front and the reason recorded. The monthly conversation becomes about what changed, not about volume.Agreed measure: Findings closed against findings suppressed with a recorded reason, measured from the finding volume captured at transition.
- Patch compliance reported by account
- Patch baselines and maintenance windows are defined per workload in AWS Systems Manager Patch Manager, and compliance is reported by account rather than instance by instance. Exceptions carry an owner and a review date.Agreed measure: Patch compliance per account against the maintenance windows agreed with each workload owner, with exceptions named.
- Restores you have watched happen
- Continuity owners get results from AWS Backup restore tests run against the recovery objective agreed per workload. Each test records what it proved and what it did not cover, so the gaps are known before an outage rather than after.Agreed measure: Restore tests and failover drills completed per workload against the recovery objective agreed before build.
Common client problems
What we usually hear first.
We have 30 accounts and no consistent view of any of them.
We put Config aggregation, Security Hub delegated administration and centralised CloudWatch and CloudTrail destinations in place, so one account gives the organisation-wide picture. That aggregation layer is real engineering work rather than a setting, and it is the piece most estates are missing. Where accounts should not exist at all, we plan consolidation instead of leaving the sprawl to grow.
CloudWatch Logs is costing us more than the application it monitors.
Log groups are reviewed for retention, sampling and log level, with rarely queried data moved to cheaper storage and queried on demand. Custom and high-resolution metrics get the same treatment, because they are billed separately and accumulate quietly. Metric filters and alarms stay on the paths that matter, so coverage does not fall away with the cost.
Security Hub shows thousands of findings so nobody reads it any more.
We agree which standards genuinely apply, suppress controls that do not fit your architecture with the reason recorded, and rank what remains by exposure and data sensitivity. The list that survives is short enough to work through inside a month. Suppression is a decision with an owner, not a way of making a dashboard look better.
Patching happens when somebody remembers.
Patch baselines and maintenance windows are defined per workload in AWS Systems Manager Patch Manager, and compliance is reported by account rather than instance by instance. Where the workload is containerised, the honest answer is often to rebuild from a fresh image instead of patching in place, and we write down which standard applies to which workload so two operating models do not develop.
Our Glue jobs fail overnight and we find out when the dashboard is empty.
Job runs, data freshness and row-count anomalies are monitored as alerts with a named owner, separating transient failures that retry cleanly from real breakage that needs a person. Repeat failures go onto the improvement backlog rather than being rerun indefinitely.
Our AWS bill for Config went up and nobody changed anything.
Config bills per configuration item recorded, so cost tracks how much your environment changes rather than how large it is. An autoscaling group cycling instances, or recording every resource type in every region, produces volume nobody asked for. We scope recording to the resource types and regions you actually govern, choose the recording mode per type, and review rule and conformance pack evaluations for the ones nobody reads.
How we deliver
Our AWS delivery approach.
- 01
AWS estate assessment and transition
We establish what exists across every account before accepting responsibility for any of it. The output is a transition plan, a remediation list and a written acceptance point.
- Accounts and cross-account dependencies. Accounts, organisational units, workloads and cross-account dependencies inventoried, including the accounts nobody has opened since the day they were created.
- Config recorder coverage per region. AWS Config recorder and aggregator coverage checked account by account and region by region to find where configuration history is simply not being captured.
- CloudWatch spend and alarm coverage. Log group retention, custom metric volume and alarm coverage assessed, with current spend recorded by observability component rather than as one line.
- Backup coverage and restore history. AWS Backup plan coverage checked per resource type, along with restore test history and whether recovery objectives are documented anywhere at all.
- Posture baseline before reporting starts. AWS Security Hub standards, control failures and Amazon GuardDuty finding volume baselined so posture progress can be measured from a known starting point.
- IAM keys and trust relationships reviewed. Roles, long-lived access keys and cross-account trust relationships examined, with anything unsafe to operate flagged before transition completes.
- 02
Operating platform on AWS
The operational layer is standardised across accounts and held in code, so a newly created account inherits the same monitoring, guardrails and backup behaviour on its first day.
- Alarms tied to business indicators. Amazon CloudWatch alarms, composite alarms and Application Signals objectives defined against service-level indicators drawn from the business process, not only from CPU and memory.
- Log retention set per workload. Log group retention, subscription filters and metric filters configured per workload, with high-volume rarely queried data routed to cheaper storage.
- Config rules aggregated centrally. AWS Config rules and conformance packs deployed across the organisation with results aggregated into a delegated administrator account.
- Systems Manager for the repeated work. Patch baselines, maintenance windows, inventory collection and automation documents built for the routine tasks the team repeats by hand today.
- Backup plans with vault lock. AWS Backup plans, vault lock settings and cross-account copies configured per workload class, aligned to the recovery objective agreed with each owner.
- Budgets the business chooses. AWS Budgets and cost anomaly detection set to thresholds and recipients the business selects, rather than a default nobody reads.
- 03
Security operations on AWS
Posture, detection and access hygiene run on a fixed cycle with recorded outcomes. What arrives each month is evidence of state and movement, not reassurance.
- Security Hub findings triaged, not counted. Findings aggregated across accounts with suppression rules agreed and the reason recorded, and the remainder tracked to closed, accepted or scheduled.
- GuardDuty investigated with context. Findings examined alongside CloudTrail and Config history, with detections that reflect normal behaviour in your environment tuned rather than ignored.
- IAM reviews on a fixed cycle. Roles, permission boundaries, long-lived access keys and cross-account trust reviewed on schedule, with anything no longer justified removed.
- Secret rotation actually configured. AWS Secrets Manager rotation configuration and certificate expiry monitored, with rotation on a schedule agreed with each application owner.
- Inspector findings owned per workload. Amazon Inspector vulnerability findings tracked workload by workload, with exceptions held against a named owner and a review date.
- Evidence, never certification. Operational evidence produced to support your alignment to frameworks such as the Essential Eight; assessment and certification stay with an accredited third party.
- 04
Enabling your AWS team
Dashboards, runbooks and code are handed over, and your engineers are shown how to operate them. A good managed service reduces your dependence on the provider over time.
- Dashboards and queries in your accounts. CloudWatch dashboards and saved Logs Insights queries published in your own accounts, so engineers can answer routine questions directly.
- Automation documents in your repository. Systems Manager automation documents and infrastructure code kept in your repository and reviewed through your normal pull request process.
- Monthly review with both audiences. A service review with the platform owner and business sponsor covering incidents, changes, Config compliance, Security Hub movement and cost.
- Service desk trained on real alarms. First-line triage taught for the alarms your desk will actually receive, including what to escalate and what simply needs watching.
- Cost views finance controls. Direct access to the Cost Explorer views and Budgets finance owns, with the account and tagging model explained in their language.
- 05
The ongoing AWS service
The work that runs every month once transition is complete. Coverage hours, contact channels, escalation steps and reporting cadence are agreed in your service description rather than implied.
- Workload and pipeline health watched. Workload, pipeline and AI endpoint health monitored through CloudWatch alarms and objectives, acted on under the arrangements set out in your service description.
- Incidents coordinated with AWS Support. Support case management under your agreement, stakeholder communication and a written review for significant events.
- Patching inside your change process. Systems Manager maintenance windows run within your change process, with compliance reported by account each month rather than on request.
- Restore tests and failover drills. AWS Backup restore tests and AWS Elastic Disaster Recovery drills executed on the agreed schedule, recording what each proved and what it did not.
- Cost reviewed against budget variance. Cost Explorer data and Budgets variance examined monthly, with rightsizing, idle resource and commitment recommendations presented as costed options.
- One ranked improvement backlog. A backlog spanning Config drift, Security Hub findings, resilience gaps and cost actions, ranked by business value and worked down each cycle.
Reference architecture
The AWS operating platform, layer by layer.
How the pieces fit together on AWS. Every engagement adapts this, and we will tell you which layers you already have.
- 01
Collect
Metrics, traces and configuration history gathered per account and region.
- CloudWatch agent
- Application Signals
- CloudTrail and Config recorder
- 02
Aggregate
One delegated account gives the organisation-wide view instead of 30 consoles.
- Delegated administrator
- Config aggregator
- Central log destinations
- 03
Detect and respond
Alarms tied to a business indicator, routed to an owner with a runbook.
- CloudWatch alarms and SLOs
- Amazon EventBridge routing
- Systems Manager automation
- 04
Protect
Posture, tested restore and patch compliance reported account by account.
- Security Hub and GuardDuty
- AWS Backup with vault lock
- Patch Manager baselines
- 05
Report
Spend attributed by account and tag, exported in a standard schema.
- Cost Explorer and Budgets
- FOCUS 1.0 data export
- Sponsor report pack
Across every layer
- IAM Identity Center permission sets, with no long-lived access keys
- AWS Config rules for drift detection across accounts
- Dashboards, runbooks and templates held in your accounts, not ours
- A named human approval before any production change
- Coverage hours and reporting cadence set in the service description
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Monitoring and operations
Amazon CloudWatchMetrics, logs, alarms, dashboards and Application Signals objectives for the estate. We design alarm coverage against business indicators and manage log retention so observability cost stays a deliberate choice.
AWS Systems ManagerPatch baselines, inventory, automation documents and session-based access, so routine administration is logged and does not need open inbound ports.
Configuration, change and cost
AWS ConfigConfiguration history and rule evaluation aggregated across accounts, used for drift detection and for answering evidence requests with a query. We scope recording per resource type, because it bills per configuration item.
AWS CloudTrailAPI activity record we use to establish what changed, when and by whom during incident review and access investigations.
AWS Cost ExplorerSpend analysis by account, tag and service, including Savings Plans and Reserved Instance coverage reviewed ahead of expiry.
AWS BudgetsThreshold and forecast alerts owned by the business, so a cost conversation starts before the invoice arrives rather than after it.
Security posture and detection
AWS Security HubAggregated posture findings across accounts against the standards you choose, with suppression rules agreed and the reasoning recorded.
Amazon GuardDutyThreat detection across account, network and data-plane activity, investigated with CloudTrail and Config context before anything is escalated.
Amazon InspectorContinuous vulnerability assessment of EC2 instances, container images and Lambda functions, tracked per workload with owned exceptions.
AWS Secrets ManagerSecret storage and rotation we monitor for configuration and age, rotating on a schedule agreed with each application owner.
Backup and resilience
AWS BackupCentral backup plans, vault lock and cross-account copies per workload class, plus the scheduled restore tests that prove them.
AWS Elastic Disaster RecoveryReplication and failover for workloads whose recovery objective cannot be met by backup alone, exercised through planned drills.
Data and AI operations
AWS GlueJob and crawler operation, monitored for run outcome, duration and data freshness, with a named owner for every pipeline.
Amazon BedrockWhere generative AI workloads run. We monitor invocation volume, latency, cost and output quality against an evaluation set your experts review, and keep guardrail configuration under change control.
Amazon SageMaker AIModel endpoints we operate, watching latency, error rate, drift indicators and cost per inference against the thresholds agreed at design.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
AWS questions
What people ask about doing this on AWS.
Cost, lock-in and the parts that go wrong, answered before you have to ask twice.
Is this the same as AWS Managed Services, the AWS offering called AMS?
No, and the distinction matters commercially. AMS is AWS operating your infrastructure under its own operations plans, which suits organisations that want a large vendor accountable for a conventional estate and are willing to work inside its guardrails. Worth knowing if you are evaluating it: AWS has published an end of support date of 30 June 2027 for the AMS Advanced plan, with customers moving to Accelerate, so confirm the current position before building a plan around it. We are a smaller Australian firm doing more opinionated work, and where AMS is genuinely the better fit we will say so.
Why is CloudWatch costing more than the application it monitors?
Usually a combination of debug-level logging left on in production, retention set to never expire, and custom metrics with high cardinality that nobody realised are billed per metric per month. Dashboards and Application Signals add their own lines. We review log groups for level, retention and sampling, move rarely queried data to cheaper storage, and cut metric cardinality where the dimension was never used in an alarm. The trade-off we make explicit is that querying data in cheaper storage is slower, which matters during an incident.
Do we need a tool like Datadog, or is CloudWatch enough?
For most estates we operate, CloudWatch plus Config and CloudTrail is enough, and the money is better spent on tuning what is there than on a second telemetry bill. Where a third-party platform genuinely earns its cost is deep distributed tracing across many services, a materially better cross-account experience, and consolidating a hybrid or multi-cloud estate into one view. Be aware that agent-based tools price on hosts and ingested volume, so the bill grows the same way CloudWatch does. We will happily operate whichever you choose rather than pushing a tool we resell, because we do not resell one.
We have 30 accounts. Is multi-account worth the overhead?
Yes for isolation and cost attribution, and the overhead is real rather than imagined. Every operational service needs an organisation-wide story: Config aggregation, Security Hub delegated administration, centralised logging destinations, cross-account roles and identity federation. Done once and held in code, a new account inherits the operating model on day one. Done per account by hand, 30 accounts means 30 partly configured environments, which is the situation we most often inherit. If your estate is a handful of workloads with one team, fewer accounts is a defensible answer.
What access do you need in our AWS accounts?
Federated access through IAM Identity Center with permission sets scoped to what we are accountable for, not administrator across the organisation. We do not want long-lived access keys, and we would rather you removed the ones you have. Session Manager gives us logged instance access without inbound ports or shared keys, and every action we take lands in your CloudTrail in your accounts. The management account stays yours and out of daily use, which is also the right pattern regardless of who operates the estate.
If we leave, what do we actually lose?
Us, and nothing else that matters. The alarms, Config rules and conformance packs, Systems Manager documents, backup plans, dashboards and Logs Insights queries all live in your accounts, defined in templates in your repository. Handback is a scheduled activity with knowledge transfer rather than an extraction. The genuine switching cost is the tuning history: which detections were suppressed and why, which alarm thresholds were wrong at first, which workloads have a known resilience gap. We keep that as written decisions so it transfers with the configuration.
Related industries
Where this work has the most leverage.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Free discovery workshop
Start with a managed services discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.