A multi-account AWS environment creates strong isolation, but isolation alone does not eliminate the need for common infrastructure. Teams still need DNS, identity integration, networking, security tooling, observability, artifact repositories, directory services, automation, and sometimes centralized data services. A shared-services architecture provides those capabilities without collapsing every workload back into one account.
The design challenge is deciding what should be centralized, what should remain inside workload accounts, and how consumers reach a shared capability without inheriting unnecessary privilege or failure dependencies. This is a core organizational-complexity problem for SAP-C02-level architecture.
Centralize only capabilities that benefit from common ownership
A service is a good shared-services candidate when one team can operate it more consistently, duplication adds little value, and consumers benefit from a standard interface. Examples can include directory integrations, DNS resolver infrastructure, transit networking, package or container repositories, central monitoring, patch content, certificate services, and platform automation.
Do not centralize merely to make the diagram look tidy. A shared database for unrelated applications, for example, can couple release schedules, permissions, and failure domains unnecessarily. Workload-specific resources are often safer inside the workload account where ownership and blast radius remain clear.
The architectural test is whether centralization improves security, consistency, cost, or operability enough to justify the dependency. If not, keep the capability local and standardize it through automation instead.
Classify each candidate as a control-plane service, data-plane service, or shared state. Control-plane functions such as account vending can often tolerate short interruptions, while shared DNS or network transit may sit directly in an application data path. The availability and change model should reflect that difference.
Use dedicated infrastructure and shared-services accounts
AWS multi-account guidance recommends foundational accounts for functions such as networking, security, and shared services. A Shared Services account can host centralized IT capabilities, while a Network account can own transit gateways, shared VPC components, IP address management, and connectivity. Separating these functions limits the permissions any one operations team requires.
One giant “shared” account can become a new monolith. As the platform grows, separate services according to trust boundary and operational ownership. Identity infrastructure and developer tooling may have different administrators and incident consequences. Multiple shared-service accounts are reasonable when they create meaningful isolation.
Keep the organization management account out of this role. It should not host ordinary shared workloads simply because it has visibility across the organization.
Use delegated administration for AWS services when available so operational teams can manage organization-wide capabilities from purpose-built member accounts. This reduces routine use of the management account and aligns permissions with the team that actually owns the platform function.
Choose between resource sharing and service consumption
Not every shared capability is exposed the same way. AWS Resource Access Manager can share supported resources such as subnets, Transit Gateway resources, Route 53 Resolver rules, and other services across accounts. In other cases, workloads consume a service endpoint over the network, call an API, assume a role, read from a repository, or subscribe to an event stream.
Resource sharing can reduce duplication while preserving account-level ownership of workloads. However, consumers may become dependent on central configuration. Define who is allowed to change the shared resource and how those changes are communicated. A subnet shared to many accounts, for example, gives a central network team significant influence over workload connectivity.
Prefer interfaces that expose the minimum capability required. Sharing an entire administrative account is not a service interface. Use resource policies, RAM, VPC endpoints, APIs, or well-scoped cross-account roles instead.
Version those interfaces. A shared service can break consumers by changing a DNS name, route, API schema, certificate chain, artifact location, or permission requirement. Publish deprecation windows and compatibility expectations so central teams do not surprise dozens of workload owners with one platform change.
Build network connectivity around explicit trust zones
AWS Transit Gateway is a common hub for connecting multiple VPCs, VPNs, and Direct Connect attachments. Central ownership can simplify routing, inspection, and hybrid connectivity, but routing tables should preserve segmentation between workloads. A hub should not turn every VPC into one flat network.
Define which environments can communicate, which traffic must pass through inspection, and which services are exposed through private endpoints. Separate production, non-production, partner, and management paths where their trust levels differ. The software-defined networking principle of centralized policy with programmable control is useful conceptually, but the AWS implementation still depends on concrete route tables, attachments, security groups, network ACLs, and inspection architecture.
Network teams should publish connectivity patterns as products. Workload teams need predictable ways to request an attachment, route, endpoint, or inspection exception without editing central network resources directly.
Address allocation is another shared concern. Central IPAM and subnet standards reduce overlap that can block peering, Transit Gateway routing, acquisitions, and hybrid connectivity. Reserve address space according to growth and environment so teams do not consume whatever CIDR looks convenient at deployment time.
Centralize DNS without creating hidden coupling
Hybrid and multi-account environments often need common DNS resolution. Route 53 Resolver inbound and outbound endpoints, resolver rules, private hosted zones, and sharing mechanisms can connect AWS namespaces with on-premises DNS. Centralization reduces duplicate forwarding infrastructure and helps enforce consistent resolution paths.
DNS design should document ownership of each namespace, forwarding direction, split-horizon behavior, and failure handling. A wildcard forwarding rule can create surprising dependencies or loops. Shared resolver rules should be versioned and tested because one change can affect many accounts.
Understanding records and naming remains valuable; an AAAA record and IPv6 DNS example shows how apparently small DNS details affect reachability. Enterprise shared DNS needs the same precision at larger scale.
Expose identity services without distributing long-lived credentials
Workforce access should normally be centralized through IAM Identity Center and federated identity rather than replicated IAM users in every account. Applications and automation should use roles and workload identities appropriate to the service. Shared services that need to operate in consumer accounts can assume narrowly scoped cross-account roles instead of storing permanent access keys.
Directory services may be centralized when multiple workloads need the same corporate identity source, but network connectivity and failure modes must be understood. A dependency on one directory or connector can affect many applications, so deploy for the required availability and monitor authentication paths.
Separate the identity used to administer the shared service from the identities used by consumers. A developer who can publish an artifact should not automatically be able to reconfigure the central identity integration.
For machine-to-machine consumption, document trust at both ends. The shared service should authenticate the workload identity, while the workload should verify the service endpoint and certificate or signing identity. Cross-account connectivity without mutual trust validation can turn a central platform into an attractive impersonation target.
Operate shared observability as a platform, not a log dump
Central monitoring can aggregate metrics, logs, traces, security findings, and dashboards across accounts. The platform should define common metadata such as account, environment, application, owner, and Region so events remain understandable outside the source account. Cross-account observability must preserve tenant boundaries where teams should not see one another’s sensitive data.
Use central services for enterprise-wide signals while leaving teams enough local access to troubleshoot their own workloads. Overcentralization can slow incident response if every query requires a ticket to a platform team. Provide self-service views, scoped query permissions, and clear escalation paths.
The CloudTrail and CloudWatch distinction helps separate audit evidence from operational observability. Shared platforms often need both, but with different retention and access policies.
Design shared CI/CD and artifact services for tenant isolation
Organizations often centralize artifact repositories, container registries, source connections, deployment tooling, or reusable pipelines. Shared CI/CD can standardize security scanning and release controls, but the execution roles used by pipelines must remain isolated by workload. A compromise in one project should not grant deployment access to every account.
Prefer short-lived role assumption and workload-specific permissions. Keep artifacts immutable where appropriate, sign or verify important packages, and record provenance from source commit through build and deployment. The shared service owns the platform; application teams own what they publish and deploy.
Capacity and quota planning matters because a central service can become a bottleneck. High-volume builds, image pulls, or dependency downloads should be tested at organization scale rather than assumed to behave like a single-team repository.
Price the dependency and plan its failure modes
Shared services create economies of scale, but they also create shared failure. Define service-level objectives, support ownership, maintenance windows, backup, and recovery for each central capability. A DNS resolver, transit network, directory, or artifact repository can affect dozens of applications simultaneously.
Use redundant architectures where the business impact warrants them and avoid dependencies on a single Availability Zone or appliance. Test failure scenarios from the consumer perspective. The shared-service team may see healthy infrastructure while a workload cannot resolve names, assume a role, or reach a required endpoint.
Allocate costs transparently. Some services can be centrally funded; others should be chargeback or showback according to usage. Cost visibility discourages uncontrolled consumption and gives platform teams evidence for capacity planning.
Every shared service needs a clear interface: what it provides, who can consume it, expected availability, request process, security responsibilities, logging, quotas, versioning, and how breaking changes are handled. This turns the service from tribal infrastructure into a platform product.
Certification paths reflect some of these layers. ANS-C01 is closely related to the networking and hybrid-connectivity side, while SAA-C03 covers the foundational design choices that workload architects consume. The professional architect must connect those capabilities across organizational boundaries.
Shared services succeed when they reduce duplication without erasing isolation. Keep account ownership clear, expose narrow interfaces, automate onboarding, monitor dependency health, and make failure boundaries visible. The result is a platform that allows hundreds of accounts to reuse enterprise capabilities without becoming one enormous account in disguise.
Review demand periodically. If one shared service becomes too critical or too diverse, split it before operational ownership becomes ambiguous. If a service is barely used, retire it instead of maintaining central infrastructure for architectural symmetry. Platform portfolios should evolve just like application portfolios.
Consumer onboarding should be automated and reversible. A new account might need route attachments, resolver rules, observability destinations, artifact permissions, identity assignments, backup policies, and security integrations. Represent those steps as idempotent automation with a clear offboarding path. Manual onboarding makes the shared platform slower and leaves stale trust when a workload moves or is retired.
Resource sharing through AWS Resource Access Manager works well when consumers can use a centrally owned resource directly, but not every capability is a shareable resource. Some platforms are better exposed through APIs, private endpoints, event buses, queues, or service catalogs. Choose the consumption model that preserves ownership and least privilege instead of forcing all shared services into one technical pattern.
Network architecture should also make east-west dependencies observable. A transit design can connect many accounts efficiently, yet broad routing can make the trust model difficult to see. Use route tables, segmentation, security controls, and inspection according to the communication policy, and maintain an inventory of which consumer networks can reach each shared endpoint. Connectivity should be granted because a dependency exists, not because both accounts happen to attach to the same transit layer.
DNS is especially sensitive because names hide dependencies. Central resolver rules and private hosted-zone associations can simplify hybrid resolution, but they can also create outages that look like application failures. Track zone ownership, forwarding rules, split-horizon behavior, delegation, and the change process for shared namespaces. Test both successful and failed resolution from representative consumer accounts.
For repositories and artifact platforms, define a promotion model. Development teams may publish into a project namespace while production accounts consume only signed or approved versions. Replication across Regions or accounts should preserve provenance and immutability requirements. The platform should be able to answer who published an artifact, what source produced it, what scanning occurred, and which workloads deployed it.
Shared services also need capacity isolation. One consumer should not exhaust a resolver, proxy, build system, directory, or logging pipeline for everyone else. Understand service quotas and downstream limits, apply per-tenant controls where possible, and monitor saturation by consumer. A centralized service without fair-use controls can turn a local traffic spike into an organization-wide incident.
Change management should separate backward-compatible improvements from breaking platform changes. Publish supported interfaces and versions, provide migration windows, and test changes with representative consumers before broad rollout. Teams will build automation around the shared service; undocumented behavior can become an accidental contract even when the platform team never intended it.
Ownership boundaries must remain clear during incidents. The shared-service team should publish health and dependency information, while workload teams remain responsible for their application behavior and local configurations. Joint runbooks should define who investigates first, what telemetry is exchanged, and when to fail over or bypass a central dependency. Clear roles prevent every outage from becoming a multi-team escalation with no accountable owner.
Some capabilities should remain decentralized by design. A service with highly workload-specific release cadence, data sensitivity, or failure tolerance may create more coordination cost than value when centralized. The objective is not maximum consolidation; it is deliberate reuse where common ownership improves security, reliability, cost, or developer experience without destroying workload autonomy.
Revisit those decisions as scale, regulation, and team maturity change.