# 17. Evalúe los patrones de arquitectura de SAP con un enfoque en la rentabilidad
**¿Cómo se incorporan las consideraciones de costos en la evaluación de los patrones de arquitectura de SAP?** A la hora de tomar decisiones sobre la arquitectura, verifique que se comprendan totalmente las consecuencias en los costos como parte de las consideraciones de diseño.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/design-principle-17.html)
# Práctica recomendada 17.1: evalúe su uso de las ofertas de servicios administrados por SAP
Según el modelo de responsabilidad compartida de AWS, el cliente tiene la responsabilidad de administrar sus cargas de trabajo de SAP en AWS. De manera opcional, se puede emplear un proveedor de servicio para administrar las cargas de trabajo de SAP en AWS. A la hora de evaluar a un proveedor de servicio, es preciso que la responsabilidad de la administración de costos iniciales y continuos se delegue correctamente y que se trate como un proceso continuo.
Varios socios de AWS prestan servicios para la implementación y la operación de su infraestructura SAP. El alcance y la madurez de los servicios prestados varían para cada socio. Estos tipos de servicios pueden aportar eficiencias, por ejemplo, apoyo centralizado o servicios de implementación automatizados. Pueden reducir sus costos generales y deben evaluarse según los requisitos específicos de su negocio. Evalúe las competencias en AWS de los socios, incluidos [los socios de SAP Consulting Competency](https://aws.amazon.com/sap/partner-solutions/) y de la AWS Partner Network (APN, red de socios de AWS).
**Sugerencia 17.1.1: entienda los roles y responsabilidades relacionados con el control de costos**
Distintas ofertas de servicios administrados poseen modelos de costos diferentes para cubrir la infraestructura, el otorgamiento de licencias y los servicios. Decida en dónde recae la responsabilidad del control de costos. Se pueden hacer las siguientes preguntas como parte de este proceso.
+ Responda estas preguntas sobre los costos del proveedor:
+ ¿Dependen de un porcentaje del gasto en infraestructura?
+ ¿Dependen de un Total Cost of Ownership (TCO, costo total de propiedad) acordado?
+ ¿Tienen un tamaño a medida (pequeño, mediano, grande)? ¿Se ha implementado un proceso de control de cambios adecuado para garantizar que los costos estén controlados y se comprendan?
+ ¿La visibilidad y la transparencia de los costos de infraestructura son suficientes?
+ ¿La administración de costos limita la innovación y flexibilidad?
**Sugerencia 17.1.2: convenga un enfoque para la administración y optimización de costos con todas las partes**
Al evaluar las distintas ofertas de servicios administrados disponibles, se debe comprender el enfoque del socio de los servicios administrados con respecto a la administración de costos. ¿Cómo pueden trabajar juntos para llevar adelante una optimización de costos continua para su organización?
Esta evaluación debe incluir un proceso regular de revisión. También se puede beneficiar de incentivos, como un modelo de recompensas compartido, que aliente al socio a tomar la iniciativa para que las dos partes obtengan beneficios financieros de los ahorros de costos alcanzados.
# Práctica recomendada 17.2: evalúe las características de costos de su patrón de arquitectura de aplicaciones SAP
Mientras diseña la arquitectura de su infraestructura SAP, tenga en cuenta el costo del número de componentes de infraestructura y también su tamaño y ubicación. Al establecer los requisitos empresariales de la solución y reconocer el riesgo y las oportunidades de optimización, puede obtener importantes ahorros de costos.
**Sugerencia 17.2.1: revise los patrones de instalación de SAP seleccionados**
Para cada aplicación SAP, defina la naturaleza de su patrón de implementación: independiente, distribuido o de alta disponibilidad. Seleccione el modelo arquitectónico que ofrece el mejor equilibro entre costos y características de fiabilidad para satisfacer los requisitos de su empresa. Un método útil es cuantificar el costo que significaría una interrupción de su empresa y trabajar a partir de ese punto. Compare el riesgo de un error individual que afecte la disponibilidad con el costo de reducir ese riesgo.
Además, considere si su arquitectura tiene la flexibilidad de implementar un ajuste de tamaño correcto. Se pueden ahorrar costos con la concesión de licencias de sistemas operativos y con el almacenamiento y la administración de múltiples servidores de aplicaciones en un solo host. A nivel de las aplicaciones, existen diversos tamaños de instancias con un alto grado de especificidad para la CPU y la memoria y cuyos precios son casi invariables en las familias de instancias compatibles. La implementación de instancias más pequeñas puede ofrecer más opciones para la reutilización de instancias y el escalado basado en cargas de trabajo.
Evalúe los grupos lógicos y considere el efecto de combinar componentes, sistemas (SID) o infraestructuras. ¿Estas actividades incrementarían la complejidad operativa y disminuirían la fiabilidad?
+ Documentación de AWS: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
+ SAP Lens [fiabilidad]: [Principios de diseño de fiabilidad](reliability.md)
+ AWS Well-Architected Framework [fiabilidad]: [Pilar de fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
**Sugerencia 17.2.2: evalúe las excepciones para el uso de tenencias múltiples o el alojamiento de varias bases de datos en un solo host**
En la mayoría de las bases de datos, ajuste el tamaño de cada sistema de forma independiente y aproveche el ajuste flexible del tamaño de las instancias para cumplir los requisitos de los sistemas. En algunos casos, es conveniente desviarse de esa recomendación por cuestiones de costos. Por ejemplo:
+ Cuando un componente basado en HANA requiere menos memoria que la instancia de EC2 más pequeña disponible, considere utilizar [contenedores de bases de datos de multiinquilinos de SAP HANA](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/623afd167e6b48bf956ebb7f2142f058.html). Cuando el alojamiento se lleva a cabo con otros componentes, se posibilita el uso eficiente de los recursos de computación.
+ Cuando se utilizan modelos de licencias de bases de datos basadas en núcleos para bases de datos relacionales, incluidas Oracle y SQL Server.
+ Cuando se tienen aplicaciones que están estrechamente acopladas o pueden acoplarse de esa manera para cumplir con requisitos de tiempo de disponibilidad (uptime) y dependencias de versiones. Esto incluye herramientas de administración (por ejemplo, Solution Manager y SAP HANA Cockpit) y algunas opciones de SAP NetWeaver Gateway Deployment (Fiori y ECC).
**Sugerencia 17.2.3: evalúe el uso del patrón de instalación de un solo host para los sistemas que no requieren resiliencia y escalabilidad**
Para las aplicaciones o entornos individuales, debe considerar las ventajas de un modelo de alojamiento único. Esta acción puede ayudar a ahorrar costos del sistema operativo, de la duplicación de almacenamiento, de licencias de software y de servicios administrados. Entre algunas opciones de arquitectura frecuentes, especialmente para las infraestructuras que no son de producción, se encuentran las siguientes:
+ Alojamiento simultáneo de bases de datos, aplicaciones y servicios centrales de SAP
+ Base de datos separada (para minimizar la concesión de licencias de bases de datos). Consulte [optimización de costos] [Práctica recomendada 18.3: evalúe el efecto de la concesión de licencias y las opciones de optimización](best-practice-18-3.md) .
+ Aplicación combinada y servicios centrales de SAP
**Sugerencia 17.2.4: elija la región más rentable que satisfaga sus requisitos**
Las principales razones para seleccionar una región de SAP son la proximidad, la residencia de los datos y la disponibilidad de los servicios. Para las implementaciones donde hay una opción, tenga presente que cada región de AWS ofrece precios basados en las condiciones del mercado local, por lo que los precios de servicio de AWS son distintos en cada región. Repase las diferencias de precios y su efecto potencial.
**Sugerencia 17.2.5: aplique arquitecturas que pueden escalarse en caso de error**
Los mecanismos de recuperación y la elasticidad de la nube permiten un diseño en el que los recursos redundantes no deben estar activos y al 100 % de su capacidad. Si los requisitos de su negocio permiten un RTO o RPO más flexible, considere los siguientes puntos.
En el caso de las bases de datos, tenga en cuenta lo siguiente:
+ Si sus RPO lo permiten, considere un nodo de base de datos secundario o de respaldo que no requiera una capacidad de computación equivalente para aplicar cambios con respecto al nodo principal. Teniendo en cuenta el efecto del tiempo de recuperación, contemple las ventajas en los costos de implementar una instancia más pequeña o compartida para su nodo secundario y escálelo verticalmente cuando se requiera. Si se utiliza una instancia más pequeña, se mantiene una relación 1:1 entre las instancias primarias y secundarias del sistema. Una arquitectura de instancias compartidas agrupa la base de datos secundaria con una base de datos del sistema no duplicada en una sola instancia. En caso de error, el sistema no duplicado debe detenerse antes de que pueda ocurrir una adquisición. De esta manera, aumenta el RTO.
+ Si utiliza una instancia más pequeña para la base de datos de SAP HANA secundaria, desactive la carga previa de memoria para permitir una huella de memoria menor en el respaldo y reducir los costos. SAP calcula los requisitos de memoria en el documento de ayuda para [el uso del sistema secundario](https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.05/en-US/9d62b8108063497f9d6aab08902b2e04.html).
+ Documentación de SUSE: [SAP HANA System Replication Scale-Up - Cost Optimized Scenario \$1 SUSE (Escalado vertical de la replicación de sistemas SAP HANA: ejemplo con optimización de costos \$1 SUSE)](https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-CostOpt-12/index.html)
+ Si su RTO y sus requisitos de resiliencia lo permiten, considere enfoques de creación de copias de seguridad de datos y registros que utilicen almacenamiento Multi-AZ (como Amazon FSx, Amazon EFS o Amazon S3). Estos enfoques permiten la protección geográfica de datos sin requerir recursos secundarios redundantes. En caso de error, se pueden crear recursos secundarios bajo demanda y restaurarlos rápidamente desde las copias de seguridad de ubicaciones transversales y almacenamiento de registros.
+ Blog de SAP on AWS: [How to use snapshots to create an automated recovery procedure for SAP ASE databases (Cómo utilizar instantáneas para crear un procedimiento de recuperación automatizado para las bases de datos de SAP ASE)](https://aws.amazon.com/blogs/awsforsap/how-to-use-snapshots-to-create-an-automated-recovery-procedure-for-sap-ase-databases/)
En el caso de la aplicación, tenga en cuenta lo siguiente:
+ [La recuperación de instancias de AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) consiste en el uso de una alarma de CloudWatch para supervisar una instancia de Amazon EC2. Recupera automáticamente la instancia si queda inhabilitada debido a un error de hardware preexistente. Evalúe si las situaciones de error cubiertas proporcionan protección suficiente.
+ En las situaciones en las que el servidor de una aplicación debe recrearse rápidamente, entre algunas de las opciones, se encuentran las instancias de EC2 que se aprovisionan, pero no se ejecutan, las AMI con plantillas, la replicación de almacenamiento con servidores de pruebas frecuentes o la infraestructura como código.
**Sugerencia 17.2.6: considere el costo de la capacidad de computación mínima durante un error**
Distribuir los componentes de SAP en varias AZ puede reducir los costos incurridos para las reservas de capacidad en caso de error. Al distribuir componentes en varias AZ, se evita la necesidad de tener capacidad de exceso porque ya tiene parte de su carga de trabajo diseminada geográficamente. Esta medida minimiza el impacto en caso de un error de la AZ.
Por ejemplo, si el 100 % de capacidad es un requisito de disponibilidad para las situaciones de error incluida la pérdida de una AZ, en vez de aprovisionar el 200 % de capacidad en dos AZ, aprovisione el 150 % de capacidad en tres.
![\[SAP production account with three availability zones, each hosting application and database instances.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/images/example-three-availability-zone-architecture.png)
**Sugerencia 17.2.7: evalúe el uso de opciones de recuperación basadas solo en almacenamiento**
En general en AWS, recomendamos la replicación de bases de datos en lugar de la replicación de almacenamiento para garantizar la protección del rango más amplio de situaciones de error. En el caso de la capa de la aplicación o de las instancias menos críticas, se puede reducir costos mediante una solución de DR que utilice replicación de almacenamiento sin computación. También minimiza la complejidad asociada con la administración de cambios.
+ Documentación de AWS: [CloudEndure Disaster Recovery: Amazon Web Services](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ Documentación de SAP: [CloudEndure Disaster Recovery for SAP Applications (CloudEndure Disaster Recovery para aplicaciones SAP)](https://d1.awsstatic.com/products/CloudEndure/Disaster_Recovery_for_SAP_Applications.pdf)
+ Documentación de AWS: [Replicación de las copias de seguridad automatizadas en otra región de AWS - Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html)
**Sugerencia 17.2.8: entender los costos relacionados con las redes**
Los clientes de SAP suelen requerir una conexión segura entre la red en las instalaciones y Amazon VPC. Mediante el uso de una conexión de Direct Connect del tamaño adecuado o una conexión VPN o ambas, es posible cumplir los requisitos de rendimiento y fiabilidad a la par que se reducen costos.
Los costos de transferencia de datos varían según la región, la VPC y el diseño de la AZ. Evalúe de qué manera la distribución y la replicación de sus componentes de SAP se pueden optimizar sin comprometer la fiabilidad.
Por ejemplo, si dos sistemas que transfieren grandes cantidades de datos están en ubicaciones separadas, considere el efecto en los costos de transferencia de datos.
+ Documentación de AWS: [Precios de las instancias bajo demanda de Amazon EC2 - Amazon Web Services](https://aws.amazon.com/ec2/pricing/on-demand/)
+ Documentación de AWS: [Architecture Patterns - General SAP Guides (Modelos de arquitectura: guías generales de SAP)](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html)
Puede encontrar más guías en el pilar de costo del plan de revisión de Well-Architected Framework [para la transferencia de datos, en el pilar de optimización de costos](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/plan-for-data-transfer.html) .
# Práctica recomendada 17.3: comprenda los requisitos empresariales para tomar decisiones de diseño optimizadas en costos según el entorno
Optimice los costos de cada sistema o entorno de manera individual según sus características distintivas. Considere la capacidad, el rendimiento, la fiabilidad y las horas de operación para cumplir los requisitos de la empresa. En el caso de los entornos o aplicaciones que son menos críticos para la experiencia de los usuarios finales o procesos empresariales, minimice el almacenamiento, la computación y las horas de operación para reducir costos. Equilibre los ahorros de costos de una configuración reducida con los requisitos operativos para pruebas o soporte.
**Sugerencia 17.3.1: evalúe si los entornos no productivos necesitan una copia completa de los datos de producción**
Tener copias completas de los datos de producción en entornos distintos al de producción influirá considerablemente en los costos de almacenamiento y computación. Considere minimizar la cantidad de copias de datos de producción mientras continúa cumpliendo los requisitos de pruebas. Entre algunas de las opciones para minimizar los costos de almacenamiento de datos en entornos que no son de producción, se incluyen las siguientes:
+ Utilice menos capacidad de almacenamiento para los sistemas de desarrollo y prueba.
+ Utilice herramientas de segmentación de datos para escindir un subconjunto de datos de prueba más pequeño en sistemas no productivos.
+ Considere utilizar copias de producción transitorias. Estas copias se pueden crear bajo demanda y sacar de servicio rápidamente o archivarse, una vez finalizada la necesidad comercial o prueba.
+ Evalúe si la recomendación de SAP para las bases de datos de SAP HANA de retener el 50 % de memoria de trabajo es necesaria en sistemas que no son de producción.
**Sugerencia 17.3.2: evalúe si los entornos que no son de producción siempre deben tener el mismo rendimiento que los de producción**
Es probable que los sistemas que no son de producción y algunos sistemas de soporte tengan un conjunto menor de usuarios, gestionen volúmenes de transacciones menores o tengan requisitos de tiempo de respuesta flexibles. Considere lo siguiente:
+ Reduzca el SAPS de su carga de trabajo mediante el uso de tipos de instancias de EC2 más pequeñas.
+ Utilice menos servidores de aplicaciones.
+ Utilice tipos de almacenamiento en Amazon EBS de menor costo; por ejemplo, `gp3` en lugar de `io2` .
+ Utilice características de rendimiento reducidas para los volúmenes de sistemas que no son de producción; por ejemplo, 3000 IOPS en vez de 10 000 IOPS.
+ La elasticidad de la nube significa que puede escalar verticalmente los recursos de prueba que no son de producción que requieren un rendimiento similar al de producción, como pruebas de carga o de escalado.
**Sugerencia 17.3.3: evalúe si los entornos que no son de producción necesitan las mismas horas de operación que los de producción**
Los entornos que no son de producción, como los sistemas de prueba, formación y entornos aislados, pueden requerir menos horas de operación que los de producción. Considere las zonas horarias y las horas laborables de sus equipos de soporte para determinar si es necesario que todos los sistemas estén disponibles a toda hora, todos los días. Use esta información para seleccionar el modelo de precios más bajo.
Por ejemplo, ejecutar su sistema de formación de SAP 40 horas a la semana con un modelo de precios bajo demanda (\$123 % de tiempo de disponibilidad [uptime]) será más barato que ejecutarlo siempre al 100 % con una instancia reservada de 3 años o Savings Plan.
**Sugerencia 17.3.4: evalúe si los entornos que no son de producción necesitan constantemente la misma fiabilidad que los de producción**
Elija la arquitectura más rentable para satisfacer los requisitos de fiabilidad individuales de cada sistema. Consulte [fiabilidad] [Práctica recomendada 10.1: convenga las metas de disponibilidad de la carga de trabajo de SAP que se alinean con sus requisitos comerciales](best-practice-10-1.md) . Puede encontrar más guías en el [Pilar de fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) de AWS Well-Architected Framework.
Cuando se implementa una arquitectura similar a una de producción solo para fines de prueba, considere con qué frecuencia dicha arquitectura debe asemejarse a una de producción. Si se requiere una alta disponibilidad de la base de datos en un entorno que no es de producción para pruebas de fiabilidad o rendimiento, puede elegir desconectar o reducir verticalmente la instancia secundaria fuera de las ventanas de prueba para ahorrar costos.
Se pueden obtener beneficios de costos a través del uso de la automatización y de los precios bajo demanda para los entornos que no requieren un rendimiento similar al de un entorno de producción en todo momento.
**Sugerencia 17.3.5: evalúe los requisitos de la empresa para los sistemas secundarios, incluidos los sistemas heredados y de apoyo**
Si hay entornos que sirven solo para referencia o poseen un rol empresarial menos crítico, evalúe los requisitos de tiempo de disponibilidad (uptime), rendimiento y fiabilidad necesarios y compárelos con los de los sistemas de producción centrales.
Por ejemplo, es posible que deba mantenerse un sistema de ERP heredado para fines de referencia respecto a una conversión de la aplicación anterior o reestructura comercial. Para optimizar los costos de este sistema, se pueden ejecutar las instancias de EC2 solo cuando sea necesario, con lo que solo se paga por el almacenamiento en Amazon EBS. Una solución más rentable podría ser archivar el sistema mediante copias de seguridad en Amazon S3 y Amazon S3 Glacier.
# Práctica recomendada 17.4: revise el tamaño, la granularidad y las últimas instancias de EC2 disponibles para los componentes de SAP
Las instancias de EC2 más pequeñas proporcionan mayor flexibilidad de costos en las cargas de trabajo de SAP. Presentan opciones para el escalado horizontal que permiten deshabilitar la computación cuando no se utiliza o escalarla verticalmente solo durante los picos de carga. Adoptar un tamaño de instancia de EC2 coherente en el nivel de la aplicación lo ayudará a maximizar los beneficios de los compromisos con la instancia reservada y Savings Plans en todas las cargas de trabajo. Tenga en cuenta las instancias más recientes de AWS certificadas por SAP. También es aconsejable evaluar el impacto operativo, los costos de licencia, el soporte, el intercambio y la reutilización de cada componente.
**Sugerencia 17.4.1: evalúe los beneficios de costos de varios servidores de aplicaciones más pequeños para proporcionar flexibilidad**
En muchas cargas de trabajo de SAP, los servidores de aplicaciones se pueden diseñar para que sean inmutables. Tener una configuración estándar del servidor de la aplicación, que se escala en sentido horizontal replicando la unidad de base, brinda opciones para conseguir unidades repetibles uniformes. Las ventajas son la reutilización, la utilización de computación, las reservas y la automatización. En la evaluación, deben tenerse en cuenta los requisitos por unidad, como la concesión de licencias de sistemas operativos, la duplicación de almacenamiento y los costos administrativos.
Considere lo siguiente:
+ Blog de SAP on AWS: [DevOps for SAP – Driving Innovation and Lowering Costs](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/) .
+ Blog de SAP on AWS: [Using AWS to allow SAP Application Auto Scaling (Uso de AWS para permitir el escalado automático de aplicaciones SAP)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
**Sugerencia 17.4.2: evalúe los beneficios de costos de una configuración de escalado horizontal de SAP HANA si es compatible**
Las cargas de trabajo de SAP OLAP se pueden implementar [tanto en configuraciones de escalado](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/a165e192ba374c2a8b17566f89fe8419.html) vertical como horizontal. SAP recomienda aplicar un escalado vertical en lugar de uno horizontal para reducir la complejidad operativa; sin embargo; las implementaciones de escalado horizontal pueden aplicarse a cargas de trabajo de SAP HANA analíticas o nativas más grandes, que requieren un poder de computación significativo (SAPS).
En ciertos casos, S/4HANA también es compatible con la configuración de escalado horizontal, pero con restricciones. Consulte la nota de SAP [2408419 SAP S/4HANA - Multi-Node Support (SAP S/4HANA: compatibilidad multinodo)](https://launchpad.support.sap.com/#/notes/2408419) [Se necesita acceso al portal de SAP].
Para decantarse por el escalado vertical u horizontal, tenga en cuenta los siguientes aspectos:
+ [Los tamaños de la instancia de EC2 certificada](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23;v:105) que están disponibles para el escalado vertical u horizontal.
+ El costo por GiB de memoria de una instancia de EC2 para cada familia de instancias. Las instancias de EC2 suelen tener un costo más alto por GiB que las instancias más pequeñas.
+ La complejidad adicional y los costos operativos de administrar la distribución de datos en las implementaciones del escalado horizontal. Consulte la nota de SAP [2081591 FAQ: SAP HANA Table Distribution (Preguntas frecuentes: distribución de tablas en SAP HANA)](https://launchpad.support.sap.com/#/notes/2081591) [Se necesita acceso al portal de SAP]
# Práctica recomendada 17.5: considere utilizar la capacidad bajo demanda para mejorar la eficiencia de costos
El modelo de precios bajo demanda es adecuado para las cargas de trabajo de SAP que requieren menos horas de operación, proyectos de corto plazo, experimentación o capacidad ampliada durante períodos cortos (por ejemplo, en pruebas de rendimiento). Determine en qué parte puede utilizar los precios bajo demanda en su arquitectura de SAP.
**Sugerencia 17.5.1: evalúe el uso de la modalidad bajo demanda para los sistemas SAP que requieren operar menos de 24 horas al día, los siete días de la semana**
Con base en el punto de equilibrio entre el uso de un modelo de precios bajo demanda y de otro tipo, (Consulte [fiabilidad] [Práctica recomendada 18.1: conozca las opciones de pago y compromisos disponibles para Amazon EC2](best-practice-18-1.md) ), evalúe si el modelo bajo demanda proporciona el costo más bajo. Como parte de esta evaluación, considere el compromiso general del Savings Plan.
Los casos de uso más comunes son los sistemas que no son de producción y que no se necesitan fuera de horarios comerciales extendidos o los experimentos comerciales de corto plazo, como actualizaciones de períodos de POC.
+ Blog de SAP on AWS: [Automate Start or Stop of Distributed SAP HANA systems using AWS Systems Manager](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
**Sugerencia 17.5.2: evalúe las opciones de escalado programadas o dinámicas para los picos de carga**
La capacidad bajo demanda generalmente se utiliza en cargas de trabajo de SAP durante los picos, cuando los requisitos de capacidad alcanzan un máximo por un tiempo breve. Considere lo siguiente:
+ Utilice el escalado del servidor de la aplicación SAP en función de un cronograma para los picos conocidos de patrones de uso, como picos de fin de mes, de fin de año o estacionales.
+ Utilice un escalado dinámico del nivel de la aplicación si la ocurrencia de los picos le es menos conocida y sea necesario escalar en función de la carga del usuario en tiempo real. Explore los mecanismos compatibles con SAP que proporcionan la administración y los controles requeridos.
**Nota:** Al evaluar el escalado dinámico del nivel de la aplicación, tenga en cuenta las repercusiones que traería a las conexiones de los usuarios y a los trabajos en lote si un servidor de la aplicación SAP se apagara en vista de que los componentes de SAP poseen estado. Las herramientas de AWS, SAP y las desarrolladas por socios de la APN pueden servir para cumplir este requisito.
+ Documentación de AWS: [Referencia de acciones de Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)
+ Documentación de SAP: [SAP Landscape Management](https://www.sap.com/products/landscape-management.html)
+ Blog de SAP on AWS: [Using AWS to enable SAP Application Auto Scaling](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
# Práctica recomendada 17.6: evalúe los beneficios de costos y el efecto de los servicios y soluciones compartidos
Cuando varios sistemas SAP requieren la misma función, una opción rentable puede ser centralizar la administración y los costos utilizando las soluciones existentes, compartiendo los componentes o ambas alternativas. La supervisión, las copias de seguridad y la conectividad son funciones frecuentes que se pueden administrar dentro del límite de la cuenta de AWS o en una cuenta exclusiva. La estandarización, la reducción de la duplicación y la reducción de la complejidad disminuyen los costos.
Busque maneras apropiadas de compartir recursos para reducir costos sin abandonar el aislamiento adecuado y sin presentar dependencias que podrían afectar las operaciones.
**Sugerencia 17.6.1: evalúe el beneficio de costos de una configuración 1 a 1 frente a una de 1 a varios para cada servicio compartido**
Un modelo estándar para las infraestructuras SAP consiste en aislar las cargas de trabajo que no son de producción y las de producción en cuentas separadas como parte de una estrategia de múltiples cuentas. Este puede ser un límite lógico para algunos servicios. Considere la complejidad y los costos operativos en cada situación, incluidos los límites de administración que refuerzan la segmentación y el impacto del costo de transferencia de datos entre las regiones, AZ, VPC o cuentas.
En un diseño de múltiples cuentas, algunos servicios de AWS se pueden alojar de manera centralizada y es posible acceder a ellos mediante varias aplicaciones y cuentas siguiendo un diseño de “ejes y radios” a fin de ahorrar costos. Estos son algunos de los servicios:
+ VPC exclusiva con puerta de enlace NAT para todo el tráfico saliente de las VPC radiales
+ Modelo centralizado para los equilibradores de red y los dispensadores web
+ Amazon EFS o Amazon FSx compartidos para los transportes y otras necesidades de intercambio de archivos
**Sugerencia 17.6.2: evalúe las situaciones en las que la reutilización de los servicios existentes puede reducir los costos**
Esta sugerencia se aplica a una serie de niveles:
+ Cuando AWS presta servicios, a menudo se minimizan los costos generales y se trabaja con precios basados en el consumo. Algunos ejemplos son Amazon EFS, AWS Backint for SAP HANA y AWS Backup.
+ Su negocio debe contar con un estándar aplicable a toda la empresa para algunas funciones (por ejemplo, copia de seguridad de la empresa), que debe utilizarse para la uniformidad operativa y la economía de la escala.
+ Las soluciones de socios de la APN pueden estar disponibles en AWS Marketplace o se pueden incorporar con un modelo Bring Your Own License (BYOL, traer licencia propia) según las demandas específicas de su negocio.
+ Las imágenes de máquinas de AWS Marketplace incluidas en la licencia pueden ayudar a reducir los costos iniciales. En esta situación, deben considerarse las restricciones de licencias porque podrían afectar la flexibilidad de la solución al restringir la portabilidad en distintos tipos de instancias.
**Sugerencia 17.6.3: conozca los efectos de usar enfoques de creación, de compra o de código abierto**
Más allá de si la solución es de AWS o de un socio de la APN, existen diferentes grados en lo que respecta a la creación propia, el código abierto y los productos adquiridos y listos para usarse. Algunos ejemplos son soluciones de copia de seguridad, soluciones de alta disponibilidad y soluciones de almacenamiento compartido.
Para decidirse por un enfoque de creación propia o el uso de una solución de código abierto, considere los siguientes elementos:
+ Acuerdos de nivel de servicio
+ Habilidades requeridas para crear y mantener el producto
+ Efecto comercial de un corte del servicio
Además, debe evaluar los modelos comerciales disponibles para las soluciones que desea comprar en función de los requisitos específicos de su negocio y la funcionalidad que provee cada solución. Considere los términos de los modelos comerciales; por ejemplo, los cargos por derecho de uso frente a los cargos de pago por uso y cómo se calculan dichos cargos.
# Práctica recomendada 17.7: evalúe los beneficios de costos de la automatización
Un beneficio posible de adoptar la automatización en AWS es la mejora de la eficiencia y la productividad, que puede traducirse en menores costos para su organización.
**Sugerencia 17.7.1: evalúe las eficiencias de la automatización de las compilaciones**
Automatizar el proceso de compilación mediante el uso de la infraestructura como código conlleva eficiencias de costos que pueden mejorar su tiempo de comercialización y productividad. Las ventajas en cuanto a la calidad, uniformidad, repetibilidad y capacidad de recuperación que aportan las prácticas recomendadas de DevOps deben ser analizadas en contexto, ya que suponen una inversión inicial alta en el desarrollo de procesos de automatización.
Trabajar con los servicios profesionales de AWS o un socio de AWS para aprovechar su experiencia puede reducir el esfuerzo general.
AWS Launch Wizard para SAP permite acelerar las implementaciones de SAP con la automatización. Es un servicio que lo guía en los procesos de ajuste de tamaño, configuración e implementación de las aplicaciones SAP HANA en AWS de conformidad con las prácticas recomendadas de SAP. El servicio está disponible sin ningún costo adicional, con el soporte de AWS.
+ Documentación de AWS: [Infraestructura como código](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ Documentación de AWS: [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ Blog de SAP on AWS: [AWS for SAP DevOps (AWS para SAP DevOps)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**Sugerencia 17.7.2: evalúe las eficiencias de la automatización para las operaciones**
A fin de reducir el costo y el esfuerzo manual de las tareas repetitivas, investigue cómo se pueden utilizar las herramientas de AWS y de terceros para automatizar la ejecución y la supervisión de las operaciones. Considere lo siguiente:
+ Servicio de AWS: [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
Puede encontrar más guías en [excelencia operativa] [Práctica recomendada 3.6: utilice la automatización para realizar operaciones de la infraestructura SAP](best-practice-3-6.md) .