Architecture guidelines and decisions 

This section will provides a brief overview of the AWS services typically used for SAP workloads and some of the key points to understand when designing your architecture for hosting SAP on AWS. If you are already familiar with these AWS services, you can skip this section.

Regions and Availability Zones

The AWS Global Infrastructure consists of AWS Regions and Availability Zones (AZs). For more details on the AWS Global Infrastructure, see Regions and Availability Zones.

Regions

AWS has a global footprint and ensures that customers are served across the world. AWS maintains multiple Regions in North America, South American, Europe, Asia Pacific, and the Middle East.

An AWS Region is a collection of AWS resources in a geographic area. Each Region is isolated and independent. For a list of Region names and codes, see Regional endpoints.

Regions provide fault tolerance, stability, and resilience. They enable you to create redundant resources that remain available and unaffected in the unlikely event of an outage.

AWS Regions consist of multiple Availability Zones (AZs), typically 3. An Availability Zone is a fully isolated partition of the AWS infrastructure. It consists of discrete data centers housed in separate facilities, with redundant power, networking, and connectivity.

You retain complete control and ownership over the AWS Region in which your data is physically located, making it easy to meet Regional compliance and data residency requirements.

Availability Zones

Availability Zones (AZs) enable customers to operate production applications and databases that are more highly available than would be possible from a single data center. Distributing your applications across multiple zones provides the ability to remain resilient in the face of most failure modes, including natural disasters or system failures.

Each Availability Zone can be multiple data centers. At full scale, it can contain hundreds of thousands of servers. They are fully isolated partitions of the AWS global infrastructure. With its own powerful infrastructure, an Availability Zone is physically separated from any other zones. There is a distance of several kilometers, although all are within 100 km (60 miles of each other). This distance provides isolation from the most common disasters that could affect data centers (i.e. floods, fire, severe storms, earthquakes, etc.).

All Availability Zones (AZs) within a Region are interconnected with high-bandwidth and low-latency networking, over fully redundant and dedicated metro fiber. This ensures high-throughput, low-latency networking between zones. The network performance is sufficient to accomplish synchronous replication between zones. 

AWS Availability Zones (AZs) enable our customers to run their applications in a highly-available manner. To be highly available, an application needs to run in more than one location simultaneously with the exact same data, thus allowing for a seamless fail over with minimal downtime, in the event of a disaster.

Services

Our general policy is to deliver AWS services, features, and instance types to all AWS Regions within 12 months of general availability, based on customer demand, latency, data sovereignty, and other factors. You can share your interest for local Region delivery, request service roadmap information, or gain insight on service interdependency (under NDA) by contacting your AWS sales representative. 

Due to the nature of the service, some AWS services are delivered globally rather than Regionally, such as Route 53, Amazon Chime, Amazon WorkDocs, Amazon WorkMail, WorkSpaces, and Amazon WorkLink. 

Other services, such as Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Block Store (Amazon EBS) are zonal services. When you create an Amazon EC2 or Amazon EBS resource for launch, you need to specify the required Availability Zone within a Region. 

Selecting the AWS Regions

When selecting the AWS Region(s) for your SAP environment deployment, you should consider the following:

• Proximity to on-premises data centers, systems, and end users to minimize network latency.

• Data residency and compliance requirements.

• Availability of the AWS products and services that you plan to use in the Region. For more details, see Region Table .

• Availability of the Amazon EC2 instance types that you plan to use in the Region. For more details, see Amazon EC2 Instance Types for SAP.

• Pricing variation between different AWS Regions. For more details, see SAP on AWS Pricing and Optimization guide . 

Multi-Region considerations

When deploying across multiple Regions, an important consideration is the associated cost and management effort for core services required in each Region such as networking, security, and audit services.

Network latency

If you decide on a multiple Region approach, you should consider the impact of any increase in the network latency to the secondary Region from your on-premises locations.

Cross-Regional data transfer

AWS provides several methods of data transfer between Regions. These methods are relevant when designing an SAP Architecture for disaster recovery. You should consider any data residency requirements when transferring data to another AWS Region, the costs associated with the data transfer (cross-Region peering and/or Amazon S3 replication), and storage in the secondary Region. 

Tier 0 services

When using an AWS Region, there are a number of Tier 0 services that you need before deploying an SAP workload. These include DNS, Active Directory, and/or LDAP as well as any AWS or ISV-provided security and compliance products and services.

AWS accounts

While there is no one-size-fits-all answer for how many AWS accounts a particular customer should have, most organizations want to create more than one AWS account. Multiple accounts provide the highest level of resource and billing isolation. 

In the context of SAP workloads, it is common for customers to deploy the Production environment in a separate AWS account. It helps isolate the production environment from the rest of the SAP landscape.

AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Organizations includes account management and consolidated billing capabilities. It enables you to better meet the budgetary, security, and compliance needs of your business. As an administrator of an organization, you can create accounts in your organization and invite existing accounts to join the organization.

AWS Landing Zone is a solution that helps customers more quickly set up a secure, multi-account AWS environment based on AWS best practices. You can save time by automating the setup of an environment for running secure and scalable workloads while implementing an initial security baseline through the creation of core accounts and resources. It also provides a baseline environment to get started with a multi-account architecture, AWS Identity and Access Management, governance, data security, network design, and logging.

Note: The AWS Landing Zone solution is delivered by AWS Solutions Architects or Professional Services consultants to create a customized baseline of AWS accounts, networks, and security policies.

Consider using the AWS Landing Zone solution if you are looking to set up a configurable landing zone with rich customization options through custom add-ons such as, Active Directory, and change management through a code deployment and configuration pipeline.

AWS Control Tower provides the easiest way to set up and govern a secure, compliant, multi-account AWS environment based on best practices established by working with thousands of enterprises. With AWS Control Tower, your distributed teams can provision new AWS accounts quickly. Meanwhile your central cloud administrators will know that all accounts are aligned with centrally established, company-wide compliance policies. 

Consider using the AWS Control Tower to set up a new AWS environment based on a landing zone with pre-configured blueprints. You can interactively govern your accounts with pre-configured guardrails. 

Compute

Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the Amazon Web Services (AWS) cloud. An Amazon EC2 instance is launched in a specific Availability Zone within a specified Amazon Virtual Private Cloud (Amazon VPC).

When the Amazon EC2 instances are deployed across two or more Availability Zones within a single Region then AWS offers an SLA of 99.99%.

Instance types

A range of Amazon EC2 instance types are supported by SAP. When selecting the instance type for your SAP workload, you should consider which tiers allow flexibility on the instance used (application tier). Also consider which tiers will require the use of a specific instance type (database tier) based on compute, memory, storage throughput, and license compliance requirements.

For the tiers with specific instance type requirements and without flexibility to change during a failure scenario, consider having a capacity reservation using Reserved Instances or On-Demand Capacity Reservations within the required Availability Zones and Regions where the instance will run. This approach is called static stability. For more information, see Static stability using Availability Zones.

Reserved Instances

Reserved Instances provide significant savings on your Amazon EC2 costs compared to on-demand instance pricing. Reserved Instances are not physical instances. They are a billing discount applied to the use of On-Demand Instances in your account. To avail the discount benefit, these on-demand instances must match certain attributes, such as instance type and Region.

When you deploy Amazon EC2 across multiple Availability Zones for high availability, we recommend that you use zonal Reserved Instances. In addition to the savings over the on-demand instance pricing, a zonal Reserved Instance provides a capacity reservation in the specified Availability Zone. This ensures that the required capacity is readily available as and when you need it.

For billing purposes, the consolidated billing feature of AWS Organizations treats all of the accounts in the organization as one account. This means that all accounts in the organization can receive the hourly cost benefit of Reserved Instances that are purchased by any other account.

Savings Plans

Savings Plans is a flexible pricing model that provides savings of up to 72% on your AWS compute usage. It offers lower prices on Amazon EC2 instance usage, regardless of instance family, size, tenancy or AWS Region. The Savings Plan model also applies to AWS Fargate and AWS Lambda usage.

Savings Plans offer significant savings over on-demand, just like the Amazon EC2 Reserved Instances, in exchange for a commitment to use a specific amount of compute power (measured in $/hour) for a one- or three-year period.

On-Demand Capacity Reservations

On-Demand Capacity Reservations enable you to reserve capacity for your Amazon EC2 instances in a specific Availability Zone for any duration. This gives you the ability to create and manage Capacity Reservations independently, with the billing discounts offered by Savings Plans or Regional Reserved Instances. You can create Capacity Reservations at any time, you ensure that you always have access to Amazon EC2 capacity when you need it, for as long as you need it. You can create Capacity Reservations at any time, without entering into a one-year or three-year term commitment, and the capacity is available immediately. When you no longer need the reservation, we recommend that you cancel the Capacity Reservation to stop incurring charges for it.

Instance Family Availability across Availability Zones

Certain Amazon EC2 instance families (for example, X1 and High Memory) are not available across all Availability Zones within a Region. You should confirm the instance types required for your SAP workload and check if they are available in your target Availability Zones.

Amazon EC2 auto recovery

Amazon EC2 auto recovery is an Amazon EC2 feature that automatically recovers the instance within the same Availability Zone, if it becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair.

You can enable auto recovery for Amazon EC2 instances by creating an Amazon CloudWatch alarm which monitors the instance status. Examples of problems that cause system status checks to fail include:

• Loss of network connectivity

• Loss of system power

• Software issues on the physical host

• Hardware issues on the physical host that impact network reachability

Though it typically takes under 15 minutes for a failed instance to restart, Amazon EC2 auto recovery does not offer an SLA. Therefore, if the recovery of the application that's running on the failed host is critical (for example, SAP Database or SAP Central Services), you should consider using clustering across two Availability Zones to help ensure high availability. 

High Memory Bare Metal Dedicated Hosts

Amazon EC2 High Memory Instances are specifically designed to run large in-memory databases, such as SAP HANA. High Memory Bare Metal instances are available on Amazon EC2 Dedicated Hosts on a one- or three-year reservation.

High Memory instances support Dedicated Host Recovery. Host recovery automatically restarts your instances on a new replacement host if failures are detected on your Dedicated Host. Host recovery reduces the need for manual intervention and lowers the operational burden in case of an unexpected Dedicated Host failure.  

We recommend a second-High Memory instance in a different Availability Zone of your chosen Region to protect against zone failure.

Amazon EC2 maintenance

When AWS maintains the underlying host for an instance, it schedules the instance for maintenance. There are two types of maintenance events:

• During network maintenance, scheduled instances lose network connectivity for a brief period of time. Normal network connectivity to your instance is restored after maintenance is complete.

• During power maintenance, scheduled instances are taken offline for a brief period, and then rebooted. When a reboot is performed, all of your instance's configuration settings are retained.

Additionally, we frequently upgrade our Amazon EC2 fleet with many patches and upgrades being applied to instances transparently. However, some updates require a short reboot. Reboots such as these should be infrequent but necessary to apply upgrades that strengthen our security, reliability, and operational performance.

There are two kinds of reboots that can be required as part of Amazon EC2 scheduled maintenance:

• Instance reboots are reboots of your virtual instance and are equivalent to an operating system reboot.

• System reboots require reboots of the underlying physical server hosting an instance.

You can view any upcoming scheduled events for your instances in the AWS Management Console or using the API tools or command line.

If you do not take any action, the impact on your instance is the same in both cases: during your scheduled maintenance window your instance will experience a reboot that in most cases takes a few minutes.

Alternatively, you can migrate your instance to a new host by performing a stop and start on your instance. For more information, see Stop and start your instance. You can automate an immediate stop and start in response to a scheduled maintenance event.

Networking

Amazon Virtual Private Cloud and subnets

An Amazon Virtual Private Cloud (Amazon VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.

When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block, for example, 10.0.0.0/16. This is the primary CIDR block for your VPC.

You can create a VPC within your chosen AWS Region and it will be available across all Availability Zones within that Region. 

To add a new subnet to your VPC, you must specify an IPv4 CIDR block for the subnet from the range of your VPC. You can specify the Availability Zone in which you want the subnet to reside. You can have multiple subnets in the same zone but a single subnet cannot span across multiple zones. 

To provide future flexibility, we recommend that your subnet and connectivity design support all of the available Availability Zones in your account within the Region, regardless of the number of zones that you initially plan to use within a Region.    

Latency across Availability Zones

All Availability Zones (AZs) are interconnected with high-bandwidth, low-latency networking, over fully redundant and dedicated metro fiber. This results in single-digit millisecond latency between resources in different Availability Zones in the same Region.

For high availability, we recommend deploying production SAP workloads across multiple Availability Zones, including the SAP Application Server Layer. If you have SAP transactions or batch jobs that involve significant database calls, we recommend that you run these transactions on SAP Application Servers located in the same Availability Zone as the database and that you use SAP Logon Groups (SMLG) for end users and batch server group (SM61) for background processing jobs. This ensures that latency-sensitive parts of the SAP workload run on the correct application servers.

On premises to AWS connectivity

You can connect to your VPC through a Site-to-Site virtual private network (VPN) or AWS Direct Connect from on premises. AWS Direct Connect provides and SLA of up to 99.99% and Site-to-Site VPN provides an SLA of 99.95% 

Site-to-Site VPN connections are to specific Regions. For Direct Connect-based connections, Direct Connect Gateway allows you to connect to multiple Regions. 

When establishing connectivity to AWS from on premises, ensure that you have resilient connections either through the use of multiple Direct Connect Links, multiple VPN connections, or a combination of the two. 

The AWS Direct Connect Resiliency Toolkit provides a connection wizard with multiple resiliency models. These models help you order dedicated connections to achieve your SLA objective.

VPC endpoints

A VPC endpoint privately connects your VPC to supported AWS services and VPC endpoint services powered by AWS PrivateLink. It doesn't require internet access via an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the AWS service. Traffic between your VPC and other services does not leave the Amazon network. 

VPC endpoints are available for all of the core AWS services cthat are required to support an SAP-based workload, including Amazon EC2 API, Amazon S3, and Amazon Elastic File System.

Cross-Region peering

Amazon Virtual Private Cloud (Amazon VPC) supports Inter-Region peering between two VPCs in different Regions. This can be used to allow network traffic, such as database replication traffic to flow between two Amazon EC2 instances in different Regions. Inter-Region peering incurs data transfer costs.

AWS Transit Gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPC) within an AWS Region to other VPCs in other AWS Regions and to on premises networks using AWS Direct Connect or VPN. Use of Transit Gateway will incur Transit Gateway costs. AWS Transit Gateway provides an SLA of 99.95% within a Region. 

Load balancing

Elastic Load Balancing supports four types of load balancing: Application Load Balancers, Network Load Balancers, Gateway Load Balancers, and Classic Load Balancers.

A Network Load Balancer can be used to support a high-availability deployment of SAP Web Dispatchers and/or SAP Central Services across multiple Availability Zones. For more details, see Overlay IP Routing with Network Load Balancer.

A load balancer serves as the single point of contact for clients. The load balancer distributes incoming traffic across multiple targets, such as Amazon EC2 instances. 

A listener checks for connection requests from clients, using the protocol and port that you configure, and forwards requests to a target group.

Each target group routes requests to one or more registered targets, such as Amazon EC2 instances, using the TCP protocol and the specified port number. You can configure health checks on a per target group basis. Health checks are performed on all targets registered to a target group that is specified in a listener rule for your load balancer. 

For TCP traffic, the Network Load Balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number. Each individual TCP connection is routed to a single target for the life of the connection. 

DNS

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. You can use Route 53 to perform three main functions in any combination: domain registration, DNS routing, and health checking. Route 53 offers an SLA of 100%. 

Amazon Route 53 Resolver provides a set of features that enable bi-directional querying between on premises and AWS over private connections.

Storage

Object storage

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. Amazon S3 is a Regional service across all Availability Zones within a Region and is designed for 99.999999999% (11 9's) of durability and an SLA of 99.9%.

To protect against data loss, you can perform backups (such as database backups or file backups) to Amazon S3. Additionally, Amazon EBS Snapshots and Amazon Machine Images (AMIs) are stored in Amazon S3. 

Amazon S3 Replication enables automatic, asynchronous copying of objects across Amazon S3 buckets. Buckets that are configured for object replication can be owned by the same AWS account or by different accounts. 

Amazon S3 replication

You can replicate objects between the same or different AWS Regions.

• Cross-Region replication (CRR) is used to copy objects across Amazon S3 buckets in different AWS Regions.

• Same-Region replication (SRR) is used to copy objects across Amazon S3 buckets in the same AWS Region.

Cross-Region replication incurs the following costs:

• Data Transfer charges for the data transferred between the first and second AWS Regions

• Amazon S3 charges for the data stored in Amazon S3 in the two different AWS Regions

Additionally, you can enable Amazon S3 Replication Time Control with cross-Region replication. Amazon S3 Replication Time Control (Amazon S3 RTC) helps you meet compliance or business requirements for data replication and provides visibility into Amazon S3 replication times. Amazon S3 RTC replicates most objects that you upload to Amazon S3 in seconds, and 99.99 percent of those objects within 15 minutes. 

Amazon S3 RTC incurs the following costs in addition to the costs listed above for cross-Region replication:

• Amazon S3 RTC Management Feature - priced per GB

• Amazon CloudWatch Amazon S3 Metrics - priced by number of metrics

Same-Region replication incurs the following costs:

• Charges for the data stored in Amazon S3 

Block storage

Amazon Elastic Block Store (Amazon EBS) provides block level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes behave like raw, unformatted block devices. You can mount these volumes as devices on your instances. You can create a file system on top of these volumes or use them in any way that you would use a block device (like a hard drive). You can dynamically change the configuration of a volume that's attached to an instance.

Amazon EBS volumes are placed in a specific Availability Zone where they are automatically replicated to protect you from the failure of a single component. All Amazon EBS volume types offer durable snapshot capabilities and are designed for 99.999% availability per volume  and 99.99% service availability with Multi-AZ configuration. The use of a database replication capability, block level replication solution or Amazon EBS Snapshots is required to provide durability of the SAP data stored on Amazon EBS across multiple Availability Zones.

Amazon EBS volumes are designed for an annual failure rate (AFR) of between 0.1% - 0.2%, where failure refers to a complete or partial loss of the volume, depending on the size and performance of the volume. This makes Amazon EBS volumes 20 times more reliable than typical commodity disk drives, which fail with an AFR of around 4%. For example, if you have 1,000 Amazon EBS volumes running for 1 year, you should expect 1 to 2 will have a failure. 

Amazon EBS offers a number of different volume types. It must be used for the SAP database-related data, General Purpose SSD (gp2) or Provisioned IOPS SSD (io1) must be used. The throughput and IOPS requirement will determine if gp2 or io1 is required.  

Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1) volume to up to 16 AWS Nitro-based instances that are in the same Availability Zone. You can attach multiple Multi-Attach enabled volumes to an instance or set of instances. Each instance to which the volume is attached has full read and write permission to the shared volume. Multi-Attach enabled volumes do not support I/O fencing. I/O fencing protocols control write access in a shared storage environment to maintain data consistency. Your applications must provide write ordering for the attached instances to maintain data consistency.

Amazon EBS snapshots

You can back up the data on your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. This minimizes the time required to create the snapshot and saves on storage costs by not duplicating data. When you delete a snapshot, only the data unique to that snapshot is removed. Each snapshot contains all of the information that is needed to restore your data (from the moment when the snapshot was taken) to a new Amazon EBS volume.

Amazon EBS Snapshots can be copied (replicated) to a different Region and/or shared with a different AWS Account. 

Copying Snapshots across Regions incurs the following costs:

• Data Transfer charges for the data transferred between the first and second AWS Regions

• Amazon EBS Snapshot charges for the data stored in Amazon S3 in the two different AWS Regions

Restoring snapshots

New volumes created from existing Amazon EBS snapshots load lazily in the background. This means that after a volume is created from a snapshot, there is no need to wait for all of the data to transfer from Amazon S3 to your Amazon EBS volume before your attached instance can start accessing the volume and all its data. 

This preliminary action takes time and can significantly increase the latency of I/O operations. If your instance accesses data that hasn't yet been loaded, the volume immediately downloads the requested data from Amazon S3, and then continues loading the rest of the volume data in the background.

Fast snapshot restore

Amazon EBS fast snapshot restore enables you to create a volume from a snapshot that is fully-initialized at creation. This eliminates the latency of I/O operations on a block when it is accessed for the first time. Volumes created using fast snapshot restore instantly deliver all of their provisioned performance. To use fast snapshot restore, enable it for specific snapshots in specific Availability Zones. Fast Snapshot Restore is charged in Data Services Unit-Hours (DSUs) for each zone in which it is enabled. DSUs are billed per minute with a 1-hour minimum.

File storage

Amazon EFS

Amazon Elastic File System (Amazon EFS) provides scalable NFS version 4 based file storage for use with Linux-based Amazon EC2 (Windows-based Amazon EC2 instances do not support Amazon EFS). The service is designed to be highly scalable, available, and durable. Amazon EFS file systems store data and metadata across multiple Availability Zones in an AWS Region. Amazon EFS offers an SLA of 99.99%.

Amazon EFS file systems can be shared across accounts and VPCs within the same Region or a different Region, enabling Amazon EFS to be an ideal choice for SAP global file system (/sapmnt) and SAP transport directory (/usr/sap/trans).

AWS DataSync supports Amazon EFS to Amazon EFS transfer between Regions and different AWS Accounts, allowing the replication of key SAP file based data across Regions. AWS Backup can also be used to replicate backups of Amazon EFS file systems across Regions.

Amazon FSx

Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system. Amazon FSx offers an SLA of 99.9% and supports both Single-AZ and Multi-AZ File Systems. 

With Single-AZ file systems, Amazon FSx automatically replicates your data within an Availability Zone, continuously monitors for hardware failures and automatically replaces infrastructure components in the event of a failure. Amazon FSx also takes highly durable backups of your file system daily using Windows’ Volume Shadow Copy Service that are stored in Amazon S3. You can take additional backups at any point.

Multi-AZ file systems support all the availability and durability features of Single-AZ file systems. In addition, they are designed to provide continuous availability to data, even when an Availability Zone is unavailable. In a Multi-AZ deployment, Amazon FSx automatically provisions and maintains a standby file server in a different zone. Any changes written to disk in your file system are synchronously replicated across Availability Zones to the standby.

Amazon FSx File systems can be shared across Accounts and VPCs within the same Region or a different Region, enabling Amazon FSx to be used not only for the SAP Global File System but also the SAP Transport Directory.

Additionally, Amazon FSx can also be used for providing Continuously Available (CA) File Shares for Microsoft SQL Server. 

Monitoring and audit

Amazon CloudWatch

Amazon CloudWatch is a monitoring and observability service built for DevOps engineers, developers, site reliability engineers (SREs), and IT managers. CloudWatch provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health. CloudWatch collects monitoring and operational data in the form of logs, metrics, and events, providing you with a unified view of AWS resources, applications, and services that run on AWS and on-premises servers. You can use CloudWatch to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.

AWS CloudTrail

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. This event history simplifies security analysis, resource change tracking, and troubleshooting. In addition, you can use CloudTrail to detect unusual activity in your AWS accounts. These capabilities help simplify operational analysis and troubleshooting.