{"id":4664,"date":"2022-07-08T09:42:34","date_gmt":"2022-07-08T07:42:34","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=4664"},"modified":"2023-04-26T09:55:29","modified_gmt":"2023-04-26T07:55:29","slug":"landing-zone-on-aws-design-strategies-and-best-practices","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/landing-zone-on-aws-design-strategies-and-best-practices\/","title":{"rendered":"Landing Zone on AWS:\u00a0 design strategies and best practices"},"content":{"rendered":"\n

In the previous article<\/a>, we explained what a Landing Zone is and focused on some basic notions on how to approach this topic.<\/p>\n\n\n\n

In this article, we will analyze and detail the aspects on which a Landing Zone should be built and which AWS services to leverage.<\/p>\n\n\n\n

Let\u2019s dive deep into the core aspects of a well-designed Landing Zone.<\/p>\n\n\n\n

Organization<\/h2>\n\n\n\n

The first argument that must be considered concerns the accounts structure – aka the Organization – which, as specified by Conway’s Law<\/a>, must reflect the company’s organizational structure. This means that different teams have both their own responsibilities and different resource needs.<\/p>\n\n\n\n

This is where the AWS Organizations<\/strong> service comes into play. It allows us to organize accounts by scope, create Organizational Units (OUs), simplify the allocation of costs, and automate the creation of new Accounts. An account is the only way to separate costs at the billing level. Multiple accounts help separate generated billing volumes between business units, functional teams, or individual users.<\/p>\n\n\n\n

The multi-account strategy leads to the highest level of resource and security isolation. As appropriate, the isolation must also take place at the data level.<\/p>\n\n\n\n

Isolating data stores into accounts limits the number of people who can access and manage that data store by helping to comply with the General Data Protection Regulation (GDPR).<\/p>\n\n\n\n

The first step on the path that leads us to a correct configuration is to create two macro groups of accounts: the Foundational<\/strong> ones and those dedicated to Products and Workloads<\/strong>.<\/p>\n\n\n\n

The Foundational<\/strong> accounts are dedicated to the structure teams and designed to meet the company’s needs.<\/p>\n\n\n\n

For Product and Workloads<\/strong>, it is convenient to create OUs grouping products into accounts according to development environments (from Dev to Production), as well as OUs dedicated to hosting environments or accounts dedicated to structure\u2019s workload groups. Different business units or products may have different purposes and processes.<\/p>\n\n\n\n

Not to be underestimated is the presence of default service quotas in AWS accounts. Separating workloads into different accounts prevents them from consuming limits and helps streamline business processes.<\/p>\n\n\n

\n
\"Landing<\/figure><\/div>\n\n\n

Identity and Access Management<\/h3>\n\n\n\n

The principle of least privileges<\/strong> is the mantra of those who manage access and permissions to infrastructures or parts of them. Respecting this principle means reducing the blast radius in the case of malicious subtraction of access rights to the Cloud environment.<\/p>\n\n\n\n

This principle must not lead to overhead in management, thus implying the need for centralized management of credentials.<\/p>\n\n\n\n

In the AWS scenario, it is possible to create resources both through the web console and through the use of Authenticated REST APIs. Therefore, the possibility of automating our actions through these APIs emphasizes even more how current the management of access credentials is.<\/p>\n\n\n\n

Also, Practices such as Multi-Factor Authentication<\/strong>, automatic rotation of credentials<\/strong>, a strong password policy<\/strong>, and restricted authorization must certainly be implemented.<\/p>\n\n\n\n

With regards to authentication<\/strong> and authorization<\/strong>, AWS offers several possibilities: from the use of AWS IAM<\/strong> to the possibility of integrating the corporate Identity Provider (IdP)<\/strong> with AWS SSO<\/strong>. These services allow both centralized access management and the compliance with all the security practices described above.<\/p>\n\n\n\n

For console access, it is possible to create a landing page that allows to select our credentials and, perhaps, have a client that helps us manage our everyday programmatic accesses.<\/p>\n\n\n\n

In addition to the centralized authorization and authentication management services, some tools can come to the rescue to help users to be efficient and effective in these daily steps. For example, Leapp<\/a><\/strong> is the tool we use every day to fulfill this need: it is an open-source tool used to manage the access credentials to Cloud environments in a secure and automated way.<\/p>\n\n\n\n

Networking<\/h2>\n\n\n\n

The reachability of the Cloud environment is fundamental. From the connections of business users or collaborators to the connections of our external users, such as integrators or public users.<\/p>\n\n\n\n

First of all, it is necessary to structure the subnetting of private networking by defining the CIDRs<\/strong> to be assigned to the various virtual networks present in the different accounts defined in the Organizations section. In this phase, it is important to avoid overlapping<\/strong> to avoid running into complicated scenarios in terms of implementation and management. Centralizing your endpoints and controlling their routes is important to ease connections’ management and creation.<\/p>\n\n\n\n

Virtual Networks are defined through the service AWS VPC<\/strong>, and they should be configured taking into account some critical aspects like the Provider\u2019s physic infrastructure and the infrastructures\u2019 availability requirements. Internet connectivity is delivered by the managed Internet Gateway<\/strong> and AWS Managed NAT Gateways implementation.<\/strong><\/p>\n\n\n\n

AWS Transit Gateway<\/strong> is another essential service in the AWS ecosystem for connecting different environments. It enables centralized management and set up of connections – both physically via Direct Connect<\/strong> and virtually – leveraging on AWS SiteToSite Managed VPN. AWS SiteToSite Managed<\/strong> VPN<\/strong> allows connections to company on-prem environments and data centers, and to partners, customers or system integrators. AWS Transit Gateway also allows inter-VPC connections.<\/p>\n\n\n\n

It is common for companies to have users accessing remotely to virtual networks on a daily basis from all around the world. In this case, implementing a VPN Dial Up<\/strong> by taking advantage of AWS Client VPN<\/strong> and its integration with Transit Gateway should be taken into account.<\/p>\n\n\n\n

DNS and domains management is another aspect that a properly designed Landing Zone can manage to govern. AWS Route 53<\/strong> and its peculiarities such as DNS Resolver can be used to manage both private, and public domains and determine which records are resolved from specific networks.<\/p>\n\n\n\n

Security <\/h2>\n\n\n\n

Today, security practices affect IT as a whole. For these reasons, it should be integrated into every aspect and methodology, as already happened with DevSecOps<\/strong> (security applied to DevOps practices).<\/p>\n\n\n\n

Traceability<\/strong>, in-transit<\/strong> and at-rest data protection<\/strong>, and implementation of isolation<\/strong> and identity principles<\/strong> are particularly critical foundational aspects on which a well-design Landing Zone should rely on. Speaking about isolation and identity, a careful design of the organization and centralized users management make it easy to comply with best practices.<\/p>\n\n\n\n

As already explained, the AWS Cloud is based on authenticated APIs (used by the console itself). AWS CloudTrail<\/strong> is able to track each API call and consolidate all the logs in a single place.<\/p>\n\n\n\n

The inbound traffic can be routed through centralized handling of rules in AWS WAF<\/strong>, the web firewall managed by the provider.<\/p>\n\n\n\n

Security groups and Network ACL, instead, help to get more granular control over communication protocols and specific connections between networks. These tools allow to determine which communications between users and company workloads are licit.<\/p>\n\n\n\n

Regardless of the just mentioned features, it is a good rule to encrypt all public communications over the internet. Managing SSL certificates connected to our domains from a single point undoubtedly ease their control and distribution.<\/p>\n\n\n\n

Governance e Compliance<\/h2>\n\n\n\n

While Governance<\/strong> identifies the roles and responsibilities of those who are in charge of making decisions, the Compliance<\/strong> refers to a set of regulatory requirements, legislation, procedures, and codes of conduct applied to a company.<\/p>\n\n\n\n

As each organization has its own policies, it must be able to implement controls also in a Cloud environment easily. The introduction of these rules, anyway, should still ensure a certain space for DevOps to act and operate freely according to specific guardrails.<\/p>\n\n\n\n

As described in a few paragraphs above, using security best practices is essential to secure every company procedure. Data, for example, should always be encrypted at-rest. It must be ensured an effective way to verify that workloads remain compliant over time. Another important standard to enforce is preventing unintended firewall rules that could expose infrastructures to risks. Exposing known vulnerabilities protocols is one of the most common examples.  <\/p>\n\n\n\n

We can rely on the AWS Config service to automatically apply all the rules we went through and implement remediations. <\/p>\n\n\n\n

Although AWS offers many services designed for different goals, companies usually leverage on a specific subset of them. The same goes for the global regions in which to deploy new workloads. Service Control Policies<\/strong> allow organizations to define guardrails and prevent this kind of unwanted actions.<\/p>\n\n\n\n

Recommended checks also include a classification of the resources placed in each AWS environment. To achieve this, tagging strategies are the only choice. Tags enable effective costs sharing and provide the possibility to manage permissions on ABAC<\/strong> (Attribute-based Access Control) base. In addition, Tag Policies allow resource tagging enforcement and centralized tag management.<\/p>\n\n\n\n

Any company should also define the deprovisioning practices for unused resources to reduce complexity and simplify cost attribution, analysis, and understanding.<\/p>\n\n\n\n

Costs control<\/h2>\n\n\n\n

Organizations need an easy and immediate way to access AWS billing information<\/strong>, including a summary of expenses<\/strong>, a breakdown of all service costs<\/strong> incurred by accounts within the organization, along with discounts <\/strong>and credits<\/strong>.<\/p>\n\n\n\n

\u200b\u200bBoth invoices consolidation (consolidated billing) and adequate guardrails provisioning are fundamental for keeping control over costs, governance, and security. AWS enables organizations to balance freedom and control by enabling granular user permission governance.<\/p>\n\n\n\n

Making informed decisions requires complete, near real-time visibility of costs and usage information. AWS provides tools for organizing resources as needed and viewing and analyzing cost and usage data in a single pane. As well as centrally controlling costs, real-time cost information can be provided to all the different teams. Detailed, allocable cost data allow teams to gain visibility and information to report spending.<\/p>\n\n\n\n

AWS Cost Explorer<\/strong> provides an easy-to-use interface that allows you to view, analyze, and manage AWS costs and usage over time. AWS Budget<\/strong> is used to set custom budgets to track costs and usage from the simplest to the most complex use cases.<\/p>\n\n\n\n

Disaster Recovery<\/h2>\n\n\n\n

\u201cEverything fails all the time\u201d<\/em> – Werner Vogel. <\/p>\n\n\n\n

Failures are just around the corner. Designing with failure in mind is the key to building resilient infrastructures. For this reason, Disaster Recovery<\/strong> is a strategy that has to be considered from the very beginning of the Landing Zone design process. <\/p>\n\n\n\n

The typologies of disasters that can happen in the Cloud, and widely speaking, are divided into three groups:<\/p>\n\n\n\n