Building a Secure and Scalable Enterprise Landing Zone on AWS with DXC’s Multi-Account Strategy
By Farook Babu Anwar Sadiq, Irfan Saherwardi, and Stanley Antony Raj Mariaraj – DXC Technology
By Prakash K M and Charles Christopher – DXC Technology
By Dhiraj Thakur – AWS
Multi-account strategy is an architectural pattern in which your workloads and services are distributed across multiple accounts.
Using a multi-account strategy enables a well-architected platform that’s scalable and secure. It’s an Amazon Web Services (AWS) best practice that offers several business benefits, such as improving system reliability, providing workload isolation to reduce blast radius, improving agility, enabling autonomy, and improving billing and cost allocation.
Building a multi-account architecture involves technical and business decisions to be made across account structure, security, and access management, in accordance with your organization’s policies.
Consider the following questions when designing your multi-account architecture:
- Does your organization require isolation to minimize blast radius?
- Do you require administrative isolation between business units and teams?
- Do you have different teams with different responsibilities, access, and resource needs?
- Does your organization need to separate items at billing level across business units and teams?
- Do you have workloads with specific security requirements?
This post walks you through the thought process and frameworks DXC Technology adopts in building a secure, resilient, and scalable enterprise landing zone to support your business journey on AWS. This includes design decisions, network, security and monitoring baseline, backup and restore strategy, and deployment strategy.
DXC Technology is an AWS Premier Tier Services Partner and Managed Service Provider (MSP) with over 4,000 AWS certified resources to help customers harness the power of innovation and drive their business transformations.
AWS Conceptual Architecture
The following figure shows the technology stack which is used by DXC as reference architecture. It depicts compute, network, internet connectivity, security, identity and access management (IAM), and governance layers, as well as the respective entities within that.
Figure 1 – AWS conceptual architecture.
It has also storage, backup and restore, high availability (HA) and disaster recovery (DR), monitoring and management, infrastructure automation, and application services, which covers entire stack of cloud platform services.
Figure 2 – More conceptual architecture.
These design decisions will help you create a secure, scalable, and well-performing network architecture on AWS. Design decisions are based on the guiding principles with a landing zone, which is a well-architected, multi-account AWS environment that’s scalable and secure as base, and other principles depicted in the following diagram.
Figure 3 – Architectural guiding principles.
When designing your infrastructure on AWS, there are several important decisions to consider to ensure optimal performance, security, and cost-effectiveness. Here are some key design decisions to keep in mind:
- Choosing the right AWS region
- Architecting for high availability
- Security and access control
- Scalability and elasticity
- Data storage and database selection
- Network design and connectivity
- Cost optimization
- Monitoring and logging
Solution Design Approach
Below are the phases of solutioning—starting with a statement of work (SOW) and going through solution design workshops, finalizing the design, and having smooth implementation using agile methodology. The following figure shows the design thinking and agile print execution model.
Figure 4 – Agile print execution model.
You can see the flow or phased approach adapted for solutioning and execution by DXC teams. Project initiation starts from releasing SOW documenting project requirements, which gets verified and refined during team solution design workshops with various stakeholders and goes into architecture finalization and detailed project planning for successful implementation.
Figure 5 – Phased approach for solutioning.
AWS Landing Zone
The DXC landing zone is a well-architected, multi-account AWS environment that’s a starting point from which you can deploy workloads and applications. It provides a baseline to get started with multi-account architecture, identity and access management, governance, data security, network design, and logging.
Following are considerations made while designing a landing zone:
- Well-defined landing zone to manage multi-account strategy meeting small, medium, and enterprise customers
- Account democratization
- Policy-driven governance (preventive and detective)
- Single control and management plane
- Application-centric and archetype-neutral
- Align AWS-native design and roadmaps
- Security and data protection
- Scalable design
- Cost optimized design
- Design aligned with AWS Well-Architected Framework
- Fully managed using code
The DXC landing zone is a configured environment in line with the AWS Well-Architected Framework and centrally managed services with added features.
Requirements for the landing zone include:
- AWS Organizations account
- Shared services account
- Log archive account
- Security account
- Account baseline
- Security baseline
- Network baseline
- Modular and well structured
Landing Zone Reference Architecture
The DXC reference architecture diagram below depicts at a high-level the various areas associated with the solution that DXC uses for client deployment.
Figure 6 – Landing Zone reference architecture.
For multi-region deployments, if a customer’s environment is spread across regions for a large implementation, then the same architecture as above would apply but with each region having its own independent management virtual private cloud (VPC).
Separating management VPCs per region is a common practice in AWS architecture for several reasons, including regional resilience, reduced network latency, and compliance, as well as data sovereignty, network segmentation and isolation, scalability and performance, and localized resource access.
Figure 7 – Multi-region deployment.
The customer environment will be built in the selected AWS region while designing cloud services for AWS. DXC will use an environment with a “single tenancy” approach with each organization being specific to the customer with separate access boundaries. The benefit of having a dedicated and isolated environment is better security and access control with reduced complexity.
With this approach, there will be a DXC management VPC hosted in a dedicated organizational shared services account. The management VPC will be lightweight and host Bastion Hosts. AWS Transit Gateway-VPC attachments will be used to interconnect VPCs.
AWS CloudFormation templates will be used for orchestration across all landing zones. Each VPC will have a public and private subnet spread across two AWS Availability Zones (AZs). Inter-VPC traffic flows will be governed by a mixture of Network Access Control lists (NACLs) and Transit Gateway routing rules.
Figure 8 – Network baseline.
Amazon VPC Design
Design your Amazon VPC to create an isolated network environment for your resources. Consider the IP address range for your VPC and subnet design to effectively segment and manage your network.
- Subnet configuration
- Network availability
- Routing and internet connectivity
- Security and access control
- Network monitoring and troubleshooting
- Hybrid connectivity
- Distributed denial-of-service (DDoS) protection
- Network performance optimization
For compliance and data privacy, ensure your network design complies with relevant compliance standards and data privacy regulations.
Following are considerations which needs to be made while designing VPC:
- Standard VPC structure: A consistent VPC structure for shared services and business applications can be customized for specific requirements.
- AWS Transit Gateway: Highly available, fully managed central router that can be used to interconnect VPCs, on-premises data centers, and other public clouds.
- Elastic Load Balancing: Serves multiple roles in an enterprise environment and is used for high availability. In hub-and-spoke models, a public-facing load balancer bridges traffic from internet to private servers hosted in application VPCs.
- AWS Network Firewall: Stateful, fully managed network firewall and intrusion detection and prevention service for Amazon VPC. You can filter egress and ingress traffic coming from an internet gateway, Network Access Translation (NAT) gateway, or over virtual private network (VPN) or AWS Direct Connect.
- AWS Firewall Manager: Security management service which allows you to centrally configure and manage firewall rules across all accounts and applications in AWS Organizations.
- AWS WAF: Web application firewall that helps protect web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources.
- Amazon Route 53: Highly available and scalable cloud domain name service (DNS) web service.
Disaster Recovery, Backup, and Restore
Implementing a disaster recovery, backup, and restore strategy within a landing zone architecture involves incorporating various AWS services and best practices. Here’s a step-by-step approach to implementing these strategies:
- Define recovery objectives
- Multi-region deployment
- Data replication
- Backup strategy
- Backup storage
- Backup encryption
- Restore processes
- Disaster recovery testing
- Monitoring and alerting
- Documentation and training
Disaster recovery strategies available in AWS are broadly categorized into four approaches, ranging from low cost to low complexity.
Figure 8 – Disaster recovery strategies.
DXC Cloud Services for AWS utilizes Amazon CloudWatch for the real-time monitoring of AWS Cloud resources. It primarily monitors the health, performance, and usage of AWS services that are used by a client.
The following resources will be monitored:
- Amazon Elastic Compute Cloud (Amazon EC2) instances
- Amazon Elastic Block Store (Amazon EBS) volumes
- Elastic Load Balancing
- Amazon Relational Database Services (Amazon RDS)
Monitoring will be configured using standard and custom metrics.
The solution includes a security baseline that can be used as a starting point for establishing and implementing a customized account security baseline. By default, the initial security baseline includes AWS CloudTrail, AWS Config, Amazon GuardDuty, and AWS Security Hub.
- AWS CloudTrail: One trail is created in each account and configured to send logs to a centrally managed Amazon Simple Storage Service (Amazon S3) bucket in the log archive account, and to CloudWatch Logs in the local account for local operations. Logs are protected by encrypting using AWS Key Management Service (AWS KMS).
- AWS Config: AWS Config is enabled, and account configuration log files are stored in a centrally managed S3 bucket in the log archive account.
- AWS Config Rules: Enabled for monitoring AWS services.
- AWS IAM: Consistent identity and access management is used to configure an IAM password policy.
- AWS KMS: All data at rest gets encrypted using KMS key.
- Cross-account access: Restricted cross-account access is configured to audit and provide emergency security administrative access to customer landing zone accounts from the security account.
- Amazon VPC: A well-designed virtual private cloud configures the initial network for an account. Interconnecting all VPCs like a wide-area network (WAN) networking using AWS Transit Gateway.
- AWS CloudWatch notifications: CloudWatch alarms and events are configured to send a notification on root account login, console sign-in failures, and API authentication failures within an account.
- Amazon GuardDuty: GuardDuty is configured to view and manage any threat findings in the member account.
- AWS Security Hub: Customer cloud security posture will be managed through AWS Security Hub integrating AWS Config, Amazon GuardDuty, Amazon CloudWatch, and Falcon CrowdStrike.
While Control Tower automates creation of a new landing zone with predefined blueprints (such as AWS IAM Identity Center for directory and access), the AWS Landing Zone solution provides a configurable setup of a landing zone with rich customization options through custom add-ons:
- AWS Control Tower and AWS Service Catalog
- CI/CD, AWS CDK, and AWS CloudFormation
- CI/CD, AWS CDK, and Terraform
Following are the governance considerations:
- Account factory automates provisioning of new accounts.
- Preventive and detective guardrails.
- Mandatory and optional guardrails.
- Identity management using AWS IAM Identity Center.
- Log archive provides centralized logging from AWS CloudTrail and AWS Config.
- Cross-account security audits using AWS IAM and IAM Identity Center.
- Centralized security notifications.
- Continuous visibility into your AWS environment.
Designing governance in your AWS environment involves making decisions on how to establish policies, controls, and processes to ensure compliance, security, and effective management of resources. Here are some key design decisions related to governance:
- Account structure
- Identity and access management
- Security controls
- Compliance and auditing
- Resource tagging
- Cost allocation and budgeting
- Change management and version control
- Incident response and remediation
- Training and documentation
- Continuous monitoring and auditing
In this post, we described the framework and different architecture components DXC Technology adopts in building a secure, resilient, and scalable enterprise landing zone to support your business journey on AWS.
The framework helps an organization to quickly and easily set up multi-account architecture on AWS. Ultimately, a multi-account AWS environment enables you to use the cloud to move faster and build differentiated products and services, all while ensuring you do so in secure, scalable, and resilient manner.
DXC’s multi-account strategy helps create separate billable items across business units, functional teams, or individual users.
DXC Technology – AWS Partner Spotlight
DXC Technology is an AWS Premier Tier Services Partner that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.