Managed Cloud Services on AWS and Azure
Accountable operational support for selected cloud environments.
Monitoring, administration, incident response, optimisation and service reporting under an agreed scope.
Discuss this requirement →Start with the environment, risk and required outcome.
Monitoring, administration, incident response, optimisation and service reporting under an agreed scope. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
What managed cloud actually means
Moving to cloud changes what has to be managed. It does not remove the need to manage it.
The shared responsibility model is the reason. The provider is responsible for the security of the cloud, meaning the physical infrastructure, the hypervisor and the managed service internals. You are responsible for security in the cloud, meaning your configuration, your identities, your data, your network design, your patching and your backups.
That boundary is where most of the surprises live. Organisations that moved to cloud expecting the provider to handle operations find that they now own a set of responsibilities they previously had, plus a few new ones, and the bill arrives monthly rather than as a capital purchase.
The five things that need an owner
Cost
Cloud spend grows quietly and it is the most visible failure. More on this below because it is usually the presenting problem.
Security configuration
Identity and access, network exposure, encryption, logging and the public storage bucket that nobody meant to make public.
Backup
Snapshots are not backups. A snapshot in the same account and region as the resource it protects shares that account’s fate.
Patching and currency
Virtual machines in cloud need patching exactly as they did on premises. Managed database and container services need version currency, and providers deprecate versions on a schedule that will not wait for you.
Capacity and performance
Right-sizing, scaling policy and knowing whether the thing that is slow is under-provisioned or badly written.
Cost control, which is usually why you called
Cloud bills grow for a small number of consistent reasons and all of them are addressable.
Resources that were never turned off
Development environments running at weekends. Test instances from a project that closed. Load balancers with nothing behind them. Unattached storage volumes still billing. This is typically the largest single item and it needs nothing but an inventory and a decision.
Over-provisioning
Instances sized for a peak that was estimated rather than measured. The on-premises habit of sizing for three years of growth carries over into an environment where you can resize in minutes, and nobody goes back.
On-demand pricing for steady workloads
Anything running continuously should be on a commitment. Reserved instances and savings plans on AWS, reservations on Azure, typically save between thirty and sixty percent against on-demand for the same compute. The reason organisations do not use them is uncertainty about what they will still be running in a year, which is a planning problem rather than a pricing one.
Storage tiering never applied
Data sitting on the most expensive tier because that is where it landed. Lifecycle policies that move objects to infrequent access and archive tiers are straightforward and rarely configured.
Data transfer
Egress costs and cross-region and cross-availability-zone traffic. Architecture decisions that looked free on a diagram appear on the bill. This is the one people are least likely to predict.
No tagging, so no accountability
Without a tagging standard applied consistently, spend cannot be attributed to a team, a project or a client. Nobody owns a number they cannot see, and cost control without attribution is a series of arguments.
How we approach it
Inventory and attribution first, then the easy wins, then commitments. In that order, because buying a three-year commitment on an instance you are about to switch off is a common and expensive mistake.
We report cloud spend monthly against trend with attribution by tag, so the conversation is about specific resources rather than about the total.
The South African regions and data residency
AWS operates the Africa (Cape Town) region. Microsoft Azure operates South Africa North in Johannesburg and South Africa West in Cape Town. Both give you in-country hosting.
Why it matters. POPIA restricts transfers of personal information outside South Africa unless specific conditions are met, including that the recipient is subject to a law or binding agreement providing an adequate level of protection. Hosting in a local region removes that question for the data that sits there.
It is not automatic. A workload in a local region can still transfer data out through backups, logging, analytics, monitoring or a managed service whose control plane sits elsewhere. Establishing where data actually goes is a design exercise rather than a region setting, and it is worth doing explicitly if you handle personal information at any scale.
Latency
In-country hosting gives materially better latency for South African users. For interactive applications and for anything chatty between the client and the server, the difference against a European or American region is noticeable rather than theoretical.
Service availability
Local regions do not carry the full service catalogue of the largest regions and new services arrive later. Check availability for the specific services your architecture depends on before committing to a region, because discovering a gap after migration is expensive.
Cost
Local region pricing is generally higher than the largest regions. Where the workload has no residency or latency requirement, that difference is worth weighing rather than assuming local is correct.
Security baseline
The findings in cloud environments are consistent and most of them are configuration rather than product.
Identity
Root and global administrator accounts with multi-factor authentication and used only for what genuinely requires them. Human access through federated identity rather than long-lived access keys. Service access through roles and managed identities rather than credentials in configuration files. Access keys rotated, or better, not created.
Least privilege
Broad administrative policies attached because a narrower one was harder to write. This is the most common finding and it is worth periodic review rather than a one-off fix, because it accumulates.
Network exposure
Security groups and network security rules permitting broad inbound access. Management ports reachable from the internet. Databases with public endpoints. These are usually accidental and they are trivially discoverable from outside.
Storage
Public buckets and containers, and unencrypted volumes. Both are defaults you can change centrally.
Logging
CloudTrail or Azure activity logging enabled across all regions, retained and stored somewhere that an attacker with access to the environment cannot delete. Logging that can be turned off by the party you would be investigating is of limited value.
Guardrails
Service control policies or Azure Policy to prevent misconfiguration rather than detect it afterwards. Preventing a public bucket is better than alerting on one.
What Namandla delivers
Assessment
Current cost with attribution, security posture against a baseline, backup coverage, patch currency and architecture review.
Cost optimisation
Inventory and cleanup, right-sizing, commitment strategy, storage lifecycle, tagging standard and monthly reporting with attribution.
Security baseline implementation
Identity, least privilege, network exposure, encryption, logging and preventive guardrails.
Managed operations
Monitoring and alerting, patching for virtual machines, version currency for managed services, backup operation and restore testing, capacity management and incident response under the response commitments on /it-services/.
Landing zone design where you are starting out or consolidating: account and subscription structure, identity, network topology, logging and policy baseline.
Migration where a workload is moving, assessed per workload rather than as a policy.
Remote delivery nationally. Onsite in Gauteng where a hybrid environment needs it.
Common questions about Cloud Managed Services
What are managed cloud services?
Managed cloud services means a provider takes operational responsibility for your cloud environment: cost, security configuration, backup, patching, monitoring and capacity, against agreed standards and with reporting.
Moving to cloud does not remove operations, it changes them. Under the shared responsibility model the provider secures the infrastructure and you remain responsible for configuration, identity, data, network design, patching and backup. Managed cloud services is someone owning that half.
Is AWS available in South Africa?
Yes. AWS operates the Africa (Cape Town) region and Microsoft Azure operates South Africa North in Johannesburg and South Africa West in Cape Town. Both provide in-country hosting.
Local regions give better latency for South African users and they simplify the data residency question. They also carry a smaller service catalogue than the largest global regions and new services arrive later, so check availability for the services your architecture actually needs before committing.
Does POPIA require us to host in South Africa?
Not outright. POPIA restricts transfers of personal information outside South Africa unless specific conditions are met, including that the recipient is subject to a law or binding agreement providing adequate protection.
Hosting locally removes the question for data that stays there. It is not automatic, because a workload in a local region can still send data offshore through backups, logging, analytics or a managed service whose control plane sits elsewhere. Where you handle personal information at scale, mapping where data actually goes is worth doing explicitly. Whether your specific processing complies is a question for your information officer, and we give them an accurate description of the architecture to assess.
How much can we save on our cloud bill?
In environments we assess, twenty to forty percent is a common range, though it varies substantially and any figure quoted before looking at your account is a guess.
The savings come from resources that were never switched off, over-provisioned instances, on-demand pricing for steady workloads that should be on commitments, storage sitting on the wrong tier and avoidable data transfer. The first category is usually the largest and it requires nothing but an inventory and a decision.
Why does our cloud bill keep growing?
Usually because nobody owns it. Cloud makes provisioning easy and decommissioning optional, so resources accumulate. Without a tagging standard, spend cannot be attributed to a team or project, and nobody manages a number they cannot see.
The fix is attribution first. Once every resource carries an owner tag and the monthly report breaks spend down by that tag, the conversation moves from the total to specific resources with specific owners. That single change does more for cost control than most optimisation exercises.
Do we still need to patch servers in the cloud?
Yes. Virtual machines in AWS or Azure need patching exactly as they did on premises. The provider patches the underlying infrastructure, not your operating systems.
Managed services shift more of this: a managed database service handles the engine patching, but you remain responsible for staying on a supported version, and providers deprecate versions on a published schedule that will not wait for you. Version currency on managed services is a real and frequently missed obligation.
Are cloud snapshots the same as backups?
No. A snapshot stored in the same account and region as the resource it protects shares that account’s fate. If the account is compromised or a resource is deleted along with its snapshots, you have nothing.
Backup in cloud means copies in a separate account or subscription, ideally a separate region, with immutability or delete protection enabled, and restore testing on a schedule. Snapshots are excellent for fast rollback of a change. They are not a backup strategy.
Can you manage a hybrid environment?
Yes, and most South African mid-market environments are hybrid rather than fully cloud. Servers on premises, Microsoft 365 in cloud, some workloads in AWS or Azure, and identity spanning all of it.
Hybrid identity is the part that needs the most attention, because directory synchronisation is a single point of failure that fails quietly. A sync that has been failing for three weeks shows up as new starters unable to sign in and leavers still able to.
Should we move everything to the cloud?
No. Assess per workload. Some workloads are cheaper, faster or simpler on premises, and some cannot move for latency, licensing or regulatory reasons.
The workloads that usually should move are email, file storage, backup targets, development environments and anything with unpredictable demand. The workloads that usually should not are latency-sensitive production systems, anything with a licence model that penalises virtual cores, and stable applications on hardware with life left in it. Moving something that works, for no functional reason, spends money and adds risk in exchange for nothing.
How does cloud cost compare to on-premises?
It depends entirely on the workload profile. Variable and unpredictable demand is cheaper in cloud. Steady, predictable, high-utilisation workloads are frequently cheaper on owned hardware over a three to five year horizon.
The comparison people get wrong is capital against operating cost rather than total cost. A fair comparison includes hardware refresh, hosting or facilities, power, cooling, hypervisor licensing, backup infrastructure and the staff time to run it, against cloud compute, storage, transfer and management. Done honestly, the answer varies by workload, which is why we assess rather than assert.
What reporting do we get?
Monthly cost with trend and attribution by tag, security posture against the baseline, backup coverage and restore test results, patch and version currency and capacity and utilisation.
The cost report is the one that gets read, and it is built to support a decision. Total spend with a percentage change tells you the direction. Spend attributed by owner tag with the largest movements identified tells you what to do about it.
When do we not need managed cloud services?
If your cloud footprint is Microsoft 365 and nothing else, you need Microsoft 365 management rather than cloud infrastructure management. Those are different services.
Managed cloud earns its cost once you have infrastructure to run: virtual machines, databases, networking, a bill that is growing or a residency or security requirement you have to be able to evidence. If you have three virtual machines and a stable bill, an annual review and a good security baseline will cover you. We will tell you when that is where you sit.