Cloud Based Platforms

AWS operations differ from other providers in naming, service boundaries, and tooling defaults. The patterns below capture what is useful to remember without reaching for the console. Account Structure AWS uses accounts as the hard isolation boundary. Use separate accounts for production, non-production, shared services, security, and sandbox. Organization-level SCPs enforce guardrails before IAM comes into play. Key differences from other clouds: account is also a billing boundary. some services (CloudTrail, Config) are per-account by default and must be aggregated. VPCs are regional, not global. IAM roles are global, but trust policies reference specific accounts. EKS Cluster Operations An EKS cluster needs a VPC with at least two subnets in different AZs, an IAM role with AmazonEKSClusterPolicy, and a node group with an instance profile. The control plane is managed, but the node group lifecycle and CNI configuration still require operational attention. ...

Cloud platform organization is an operational control, not just a billing structure. The account or project boundary should make it obvious who owns the workload, what environment it belongs to, which policies apply, and how blast radius is contained. Operating Model Use separate top-level containers for production, non-production, shared services, security, and sandbox work. The exact cloud terms differ across AWS accounts, Azure subscriptions, and Google Cloud projects, but the principle is the same: production should not share an administrative or network boundary with experiments. ...

Cloud guardrails should prevent common mistakes without turning the platform into a ticket queue for every change. The platform team should define the default network, identity, logging, and policy controls that every environment inherits. Networking Network design should make approved communication easy and accidental exposure difficult. Baseline expectations: private networks by default. explicit ingress and egress paths. separate production and non-production routing. documented CIDR allocation. centralized DNS ownership. no unmanaged public endpoints. IAM IAM should be group-based, role-based, and reviewable. ...

Cloud operations become easier when provider differences are documented as patterns, not rediscovered during incidents. The useful pattern is to separate provider-specific commands from provider-neutral operating expectations. Pattern Categories Document patterns by discipline: identity and access. network routing and exposure. compute lifecycle. storage and backup. Kubernetes integration. observability and audit logging. cost and capacity review. incident response. For each provider, keep the same structure so operators can compare behavior quickly. ...

GCP organizes resources into projects, which are lighter and more numerous than AWS accounts. This changes how isolation, IAM, and networking are approached. Project Structure A GCP project is the primary boundary for resources, IAM, and billing. Use separate projects for production, non-production, shared services, and sandbox work. Key differences from other providers: projects belong to a hierarchy: organization -> folder -> project. IAM policies are inherited from parent nodes in the hierarchy. service accounts are project-scoped but can be shared across projects. VPCs are global, not regional. projects have a quota and API enablement surface that must be managed. GKE Cluster Operations GKE offers three modes: Autopilot, Standard (regional), and Standard (zonal). Regional clusters are the recommended default for production because the control plane and nodes are replicated across zones. ...