Opening an AWS account takes a few minutes. Operating one so that it is secure, recoverable, observable and not quietly expensive is a continuing job, and it is the job most organizations underestimate because the platform makes the first part so easy.
This page sets out what a managed AWS environment involves: how the account structure is arranged, what has to be designed rather than defaulted, and what the operating rhythm looks like afterwards.
Where the platform ends and you begin
AWS is explicit that security is shared. The provider is responsible for security of the cloud, meaning the infrastructure that runs the services. The customer is responsible for security in the cloud, meaning what they configure and store within them. See the AWS Shared Responsibility Model.
The practical consequence is that almost every widely reported cloud data exposure has been on the customer side of that line, and usually a configuration rather than a breach. That is not a criticism of the model; it is the reason the customer side needs somebody accountable for it. Cloud Security and Shared Responsibility covers where the line falls by service model.
Account structure comes first
The single most consequential early decision is how accounts are arranged, because it is the boundary that everything else inherits. A single account holding production, development and everything else provides no blast radius control, makes cost attribution guesswork and forces all access control to be expressed in policy rather than in separation.
A workable structure separates environments at the account level, applies guardrails centrally, and aggregates billing so that spend can be attributed without reconstruction. Getting this right at the start is cheap. Restructuring later is a migration in its own right, which is why it so often does not happen.
Networking: the VPC is the architecture
A virtual private cloud is not a formality to be accepted with defaults. Address ranges have to be planned so that they do not collide with what you already run or with what you might acquire, subnets separated by tier and availability zone, routing made deliberate, and egress controlled rather than assumed.
Connectivity back to private infrastructure belongs in the same design. Whether that is an encrypted tunnel or a dedicated interconnect depends on what crosses it and what breaks when it is down, which is the question set out in Hybrid Cloud Infrastructure.
Identity is the control plane
In a cloud environment, identity is the perimeter. Access management determines what every human and every workload can do, and it is the layer where a small mistake has the largest reach.
The disciplines are unglamorous and well established: no long-lived credentials where a role will do, permissions scoped to what a workload actually needs rather than to what was convenient during development, federation to the organization's authoritative directory so that leavers are removed once, and review of what has accumulated. The last of these is the one that decays, because permissions are granted under time pressure and removed by nobody.
Resilience is designed, not purchased
AWS publishes design principles for reliability that are worth reading as a checklist rather than a philosophy: recover automatically from failure, test recovery procedures, scale horizontally to increase aggregate availability, stop guessing capacity and manage change through automation. See the AWS Well-Architected reliability design principles.
The second of those is the one most often skipped. Testing recovery procedures in a cloud environment is easier than anywhere else, because the environment can be recreated from configuration rather than rebuilt from hardware, and it remains the thing least likely to have been done. Designing Infrastructure for High Availability covers the architecture, and Disaster Recovery: RTO, RPO and Recovery Planning the objectives.
Storage and data protection
Object storage is durable and is not a backup. Durability protects against the storage layer losing data; it does nothing about a deletion, a bad deployment or an encryption event, all of which replicate faithfully. Versioning, lifecycle rules, access logging and a copy held under different credentials are what convert durable storage into recoverable storage.
Block storage snapshots deserve the same scrutiny. A snapshot schedule that nobody has restored from is a backup report rather than a recovery capability, which is the argument made at more length in Backup and Data Protection.
Observability and the operating rhythm
Metrics, logs and alarms are available by default in a way they never were on owned hardware, which creates its own failure mode: a great deal is collected, retention is unbounded, and nobody has decided what a page-worthy condition is.
The useful work is choosing what indicates service failure rather than component noise, setting retention deliberately because log storage is a real line in the bill, and defining the route from an alarm to a person. Infrastructure Monitoring and Management covers the discipline.
Cost is an operating discipline
AWS bills accurately for whatever exists, including things nobody needs. The recurring causes are workloads rehosted at their original size, storage that accumulates without lifecycle rules, environments left running outside working hours, and commitments bought for a shape of demand that has since changed.
Tagging is the foundation, because attribution is impossible without it and retrofitting tags across a mature estate is tedious enough that it rarely happens. Cloud Cost Optimization and FinOps covers the practice.
Compute: choosing the right abstraction
AWS offers several ways to run the same workload, and the choice determines how much operational surface you retain. Virtual machines give the most control and leave you owning the operating system, its patching and its lifecycle. Container services move that boundary up. Serverless functions move it further still, at the cost of a stronger coupling to the platform.
The decision is usually made once, by whoever built the first workload, and then copied. It is worth making deliberately per workload class, because the operational cost of a fleet of virtual machines is real and recurring, and the portability cost of serverless is real and deferred. Neither is wrong; defaulting is.
Where virtual machines are the answer, everything in Server and Operating System Management applies exactly as it does on owned hardware. The platform does not patch the operating system for you, and assuming otherwise is a recurring source of estates that are years behind.
Configuration as code, or configuration as archaeology
An environment assembled through a web console is an environment nobody can reproduce. That matters most at the two moments it is hardest to fix: during recovery, when the target has to be rebuilt quickly, and during an audit, when the question is what changed and who approved it.
Defining infrastructure declaratively, holding it in version control and applying it through a pipeline turns both of those into ordinary queries. It also makes the reliability principle about managing change through automation achievable rather than aspirational. The cost is discipline early; the return is that the environment has a description that is true.
What the operating rhythm looks like
A managed AWS environment has a small number of things that happen on a schedule rather than on discovery.
- Weekly. Patch status across the fleet, alarm review, and anything that has been running longer than it should.
- Monthly. Cost review against the previous period with variances explained, permission changes reviewed, and untagged resources chased.
- Quarterly. A restore exercised and timed, capacity and commitment shape reconsidered, and the account guardrails checked against what has actually been created.
- Annually. An architecture review against the current service set, because the platform changes faster than most estates do.
The value of a rhythm is that it converts a set of tasks that would each individually lose a scheduling argument into a standing commitment. That is most of what buying a managed service actually buys.
Government workloads
AWS operates GovCloud regions intended for workloads with United States regulatory requirements. Using them is a placement decision with real consequences for which services are available and how access is managed. It is not, by itself, evidence that a workload or a service meets any particular authorization: every compliance statement needs its own basis, and the region alone does not supply one. Government and Public-Sector Cloud Infrastructure covers that ground properly.
What LABUSA runs on AWS
LABUSA uses AWS public cloud and AWS GovCloud (US), with services including Route 53, EC2, S3, VPC and IAM, as part of its hybrid infrastructure and service-delivery environment. LABUSA also uses AWS as part of its disaster recovery architecture to support failover of designated websites and web applications from LABUSA-managed private infrastructure, and has designed and configured hybrid web architectures that use AWS for production workload delivery and additional capacity alongside privately hosted infrastructure.
LABUSA is an AWS customer and operator rather than a reseller, and claims no partnership tier or certification here. What it brings is operating experience with these services in a hybrid estate it also runs privately. The wider managed infrastructure service sets out the full scope, and the Azure equivalent is in Microsoft Azure Managed Services.