DEV Community: Diego Mujica

Desmantelar Landing Zone en Control Tower

Diego Mujica — Sun, 28 Jan 2024 23:52:03 +0000

- Requisitos
- Desmantelar Landing Zone en Control Tower
- Pasos
- Troubleshooting:
- Configuración tras el desmantelamiento de una Landing zone:
- Antes de configurar una nueva Región de AWS.
- Links importantes:

Requisitos

Para poder realizar el desmantelamiento de los servicios de Control Tower, Vamos a necesitar un usuario con permisos de AdministratorAccess para acceder a todos los recursos que se encuentran en la cuenta management (Main).

Usuario de IAM con acceso programático.
Política atachada de AdministratorAccess.

Desmantelar Landing Zone en Control Tower

Si ya no desea utilizar AWS Control Tower o requiere migrar a otra region SSO + CT, la herramienta de desmantelamiento automático limpia los recursos asignados por AWS Control Tower. Para iniciar el proceso de desmantelamiento automatizado, vaya a Configuración de Landing Zone página, seleccione la pestaña de retirada y elija Landing Zone de desmantelamiento.

Pasos

Navega hasta la Configuración de Landing zone página en la consola de AWS Control Tower.
Elija Decommission your landing zone en la sección Decommission your landing zone.
Aparece un cuadro de diálogo en el que se explica la acción que está a punto de realizar, con un proceso de confirmación requerido. Para confirmar su intención de retirada, debe seleccionar todas las casillas y escribir la confirmación según lo solicitado. importante una vez iniciado, El proceso de retirada no se puede deshacer.
Si confirma su intención de desmantelar su zona de aterrizaje, se le redirigirá a la página de inicio de AWS Control Tower mientras se lleve a cabo el desmantelamiento. El proceso puede requerir hasta dos horas.
Cuando se haya desmantelado correctamente, debe eliminar los recursos restantes manualmente antes de configurar una nueva zona de aterrizaje desde la consola de AWS Control Tower. Estos recursos restantes incluyen algunos grupos específicos de Amazon S3, organizaciones yCloudWatchRegistra grupos de registros.

nota
_Estas acciones pueden tener consecuencias importantes para sus actividades de facturación y cumplimiento. Por ejemplo, si no se eliminan estos recursos, se pueden generar cargos inesperados.

Para obtener más información acerca de cómo eliminar recursos manualmente, consulte Acerca de la eliminación de recursos de AWS Control Control Control._

Si tiene la intención de configurar una nueva zona de aterrizaje en un nuevoAWSRegión, sigue este paso adicional. Introduzca el siguiente comando a través de la CLI:

`aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com`

Troubleshooting:

En el caso de presentar alguna inconsistencia, se deben ejecutar los siguentes comandos en la cli (reemplazar accout id y region con la que corresponda):

aws configservice delete-aggregation-authorization --authorized-account-id  --authorized-aws-region

Configuración tras el desmantelamiento de una Landing zone:

Después de retirar la zona de inicio, no podrá ejecutar correctamente la configuración de nuevo hasta que haya finalizado la limpieza manual. Además, sin la limpieza manual de estos recursos restantes, puede incurrir en cargos de facturación inesperados. Debe atender estas cuestiones:

La cuenta de administración de AWS Control Tower forma parte de AWS Control Tower OU raíz. Asegúrese de eliminar estas funciones y políticas de IAM de la cuenta de administración:
Roles:
AWSControlTowerAdmin
AWSControlTowerCloudTrailRole
AWSControlTowerStackSetRole
Políticas:
AWSControlTowerAdminPolicy
AWSControlTowerCloudTrailRolePolicy
AWSControlTowerStackSetRolePolicy

Puede que desee eliminar o actualizar la configuración existente de IAM Identity Center para AWS Control Tower antes de volver a subir una zona de aterrizaje, pero no es necesario que la elimine.

Puede que desee eliminar la VPC creada por AWS Control Tower.
La configuración falla si las direcciones de correo electrónico especificadas para las cuentas de registro o auditoría están asociadas a una cuenta existenteAWScuenta. Puede cerrar elAWScuentas o usa diferentes direcciones de correo electrónico para volver a configurar una zona de destino. Como alternativa, puede reutilizar estas cuentas compartidas existentes, con la función que le permite traer sus propias cuentas de registro y auditoría. Para obtener más información, consulte Consideraciones a la hora de incorporar las cuentas de registro o de seguridad existentes.
La configuración falla si ya existen buckets de Amazon S3 con los siguientes nombres reservados en la cuenta de registro:

`aws-controltower-logs-{accountId}-{region} (utilizado para el bucket de registro).`

`aws-controltower-s3-access-logs-{accountId}-{region} (utilizado para el bucket de acceso de registro).`

Debe cambiar el nombre o quitar estos buckets o usar una cuenta diferente para la cuenta de registro.

La configuración falla si la cuenta de administración tiene el grupo de registro existente,aws-controltower/CloudTrailLogs, enCloudWatchRegistros. Debe cambiar el nombre o quitar el grupo de registro.

Antes de configurar una nueva Región de AWS.

Si tiene la intención de configurar una nueva zona de aterrizaje en un nuevo AWSRegión, sigue estos pasos adicionales.

Introduzca el siguiente comando a través de la CLI:


`aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com`

Consideraciones

Organizatios es un servicio Global
Control Tower es un servicio regional
AWS IAM Identity Center es un servicio regional
No esta disponible en Sao Pablo
Una vez que se despliega, las cuentas se crean SIEMPRE desde Control Tower.
Si hay un SSO existente en otra region, se debe migrar a la region que se desea utilizar primero.
al crear una landing zone de la accout factory o landing zone acelerator el alias del correo no debe superar los 64 caracteres.
Permisson Set tiene un limite de 32 caracteres.

Pre requisitos

1 - un ticket y pedir el siguiente incremento de limites:

Service limit increase para un mínimo de 10 AWS accounts en AWS Organizations

Service limit increase para un mínimo de 50 AWS CloudFormation StackSets

2 - Solicitar 2 cuentas de correo, una para la Log Archive Account y otra para la Audit Account

DRP Windows Server with AWS DRS (Elastic Disaster Recovery)

Diego Mujica — Wed, 19 Jul 2023 17:31:13 +0000

Descripción
Este documento fue confeccionando con el fin de poder compartir el conocimiento adquirido mientras se ponía a prueba las capacidades de recuperación ante desastres de la herramienta AWS Elastic Disaster Recovery (DRS).

¿Qué es Elastic Disaster Recovery?
Es una solución de AWS que minimiza el tiempo de inactividad y pérdida de datos con una recuperación rápida y confiable de las aplicaciones locales y basadas en la nube mediante almacenamiento asequible, computo mínimo y recuperación puntual.
Puede aumentar la resiliencia de TI cuando utiliza AWS Elastic Disaster Recovery para replicar aplicaciones locales o basadas en la nube que se ejecutan en sistemas operativos compatibles.
Use la Consola de administración de AWS para configurar los ajustes de replicación y lanzamiento, monitorear la replicación de datos y lanzar instancias para simulacros o recuperación.
Configure AWS Elastic Disaster Recovery en sus servidores de origen para iniciar la replicación segura de datos. Sus datos se replican en una subred del área de preparación en su cuenta de AWS, en la región de AWS que seleccione. El diseño del área de preparación reduce los costos mediante el uso de almacenamiento asequible y recursos informáticos mínimos para mantener la replicación continua.
Puede realizar pruebas no disruptivas para confirmar que la implementación está completa. Durante el funcionamiento normal, mantenga la preparación supervisando la replicación y ejecutando periódicamente simulacros de recuperación y conmutación por recuperación sin interrupciones. AWS Elastic Disaster Recovery convierte automáticamente sus servidores para que arranquen y se ejecuten de forma nativa en AWS cuando lanza instancias para simulacros o recuperación. Si necesita recuperar aplicaciones, puede lanzar instancias de recuperación en AWS en cuestión de minutos, utilizando el estado del servidor más actualizado o un momento anterior. Una vez que sus aplicaciones se ejecutan en AWS, puede optar por mantenerlas allí o puede iniciar la replicación de datos en su sitio principal cuando se resuelva el problema. Puede volver a su sitio principal cuando esté listo.

Instalación VM Onpremise
Para este demo empleamos una instancia creada en una máquina local con Hyper-v como hipervisor. (sistema operativo a usar es una versión de Trial de Windows Server 2019)
Al comenzar la instalación, nos pide generar un usuario, para esto nos autenticamos con la cuenta example.usuario@dominio.com perteneciente a un dominio de Azure AD.

IAM Policy
Mientras se realiza la instalación del sistema operativo y las actualizaciones de seguridad necesarias, nos dirigimos a la consola de AWS para agregar la política necesaria (AWSElasticDisasterRecoveryAgentInstallationPolicy) la cual nos permitirá instalar el agente y comenzar la replicación con la herramienta AWS DRS.

Instalación del Agente DRS
Una vez terminadas las actualizaciones de seguridad de nuestra VM procedemos a descargar el agente; en este caso utilizaremos: https://aws-elastic-disaster-recovery-us-east-1.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe
Al seguir los pasos que indica la documentación, nos pedirá especificar la región donde utilizaremos AWS RDS, nuestra Access key y securty Access key de nuestro usuario que ya cuenta con la política necesaria para este fin.

Ejecutamos la sincronización con DRS, esta puede variar según los recursos que tenga VM, espacio usado en storage y ancho de banda del origen.

Proceso de Recuperación

Una vez terminada la replicación ejecutamos una prueba de recuperación.

Una vez terminada la replicación:
Nos dirigimos al panel de administración de EC2 y agregamos una Elastic IP para poder acceder. Posterior a esto agregamos la creamos las reglas nescesarias en el Security Group, luego de esto podemos establecer la conexión por medio del cliente RDP (para producción se recomienda usar AWS System Mangeger Fleet manager), pero al momento de autenticarnos con el usuario y contraseña de AZURE AD nos indica que no son correctos y no permite acceder a la instancia.
Lo extraño es que las credenciales funcionan en la VM sin problemas.

Troubleshooting

Borramos todo lo relacionado a la instancia en el panel de administración de AWS DRS, una vez realizado esto nos dirigimos la VM Onpremise y habilitamos el usuario Administrador local que viene desactivado por defecto en Windows, abrimos un terminal de PowerShell como administrador utilizamos los siguientes comandos: Net user administrador /active:yes y luego el siguiente comando: control userpasswords2 para reestablecer la contraseña, reiniciamos el VM y procedemos a iniciarla con el usuario creado.
Ejecutamos nuevamente la instalación del agente para comenzar la replicación y ejecutamos los mismos pasos mencionados anteriormente.

Esta vez con el usuario Administrador podemos arrancar la instancia EC2 sin problemas en AWS.

AWS Organizatios Service control policies (SCPs)

Diego Mujica — Tue, 04 Jul 2023 02:09:09 +0000

¿Qué son las SCPs? Las políticas de control de servicios (SCP) son un tipo de política de organización que puede utilizar para administrar permisos en su organización. Las políticas de control de servicios (SCP) ofrecen un control central sobre los máximos permisos disponibles para todas las cuentas de su organización. Las políticas de control de servicios le ayudan a garantizar que sus cuentas se mantengan dentro de las directrices de control de acceso de su organización. Las SCP solo están disponibles en las organizaciones que tienen todas las características habilitadas. Las SCP no están disponibles si su organización ha habilitado únicamente las características de facturación unificada. Para obtener instrucciones sobre cómo habilitar SCP, consulte Habilitar y deshabilitar tipos de política.

Las SCP por sí solas no son suficientes para conceder permisos a las cuentas de la organización. Una SCP no concede permisos. Una SCP define una barandilla, o establece límites, en las acciones que el administrador de la cuenta puede delegar a los usuarios de IAM y roles en las cuentas afectadas. El administrador aún debe adjuntar Políticas basadas en identidad o políticas basadas en recursos a los usuarios o roles de IAM, o a los recursos de sus cuentas para conceder permisos realmente. Los permisos efectivos son la intersección lógica entre lo que permite la SCP y lo que permite la IAM y las políticas basadas en recursos.

Ejemplos de SCP

SCP Para denegar Classic ELB
Archivo Deny-classic-ELB.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllClassicELB",
      "Effect": "Deny",
      "Action": [
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
        "elasticloadbalancing:CreateLoadBalancerPolicy"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

SCP para crear instancia EC2 con Keypair

Archivo ec2-without-keypair.json:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CustomGuardrails",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateKeyPair"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/AWSControlTowerExecution",
                        "arn:aws:iam::*:role/AWSAFTExecution"
                    ]
                }
            }
        },
        {
            "Sid": "GRNewInstanceWithKeyPair",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "ec2:KeyPairName": "false"
                }
            }
        }
    ]
}

Amazon Connect with Terraform deploy.

Diego Mujica — Mon, 03 Jul 2023 20:48:14 +0000

Amazon Connect

¿Qué es Amazon Connect?

Amazon Connect es un centro de contacto en la nube de pago por uso. No hay tarifas mínimas obligatorias, compromisos a largo plazo o cargos de licencias iniciales, y los precios no se basan en la capacidad máxima, los puestos de agente ni el mantenimiento; solo paga po lo que usa. Amazon Connect ofrece capacidad para su centro de contacto y espacio de trabajo de los agentes, entre los que la previsión, planificación de capacidad, programación y campañas salientes, así como la voz, conversación, tareas, Perfiles de clientes, Contact Lens, ID de voz, Wisdom, casos y guías.

Nivel gratuito de AWS

Como parte del nivel gratuito de AWS, puede comenzar a utilizar Amazon Connect de manera gratuita.

Durante los primeros 12 meses de la implementación inicial del centro de contacto en la nube de Amazon Connect en cualquier región, recibirá:

90 minutos al mes de uso del servicio Amazon Connect
Un número de marcación interna directa (DID) del país en el que se encuentra la región de AWS
30 minutos al mes de llamadas DID entrantes
30 minutos al mes de llamadas salientes realizadas a números en el país en el que se encuentra la región de AWS

Para las regiones de EE. UU., también recibe:

Un número gratuito de EE. UU.
30 minutos al mes de llamadas entrantes gratuitas realizadas desde EE. UU.

Por ejemplo, si crea su instancia en la región Asia-Pacífico (Sídney), obtiene un número DID de Australia, recibe 30 minutos de llamadas DID entrantes a ese número y puede usar Amazon Connect para hacer 30 minutos de llamadas salientes a números de Australia.

Otras capacidades de Amazon Connect que también forman parte del nivel gratuito durante su primer año incluyen:

500 mensajes al mes del chat de Amazon Connect
100 tareas al mes con Amazon Connect
1000 perfiles de cliente al mes con Perfiles de clientes de Amazon Connect
90 minutos al mes para llamadas de audio con Amazon Connect Contact Lens
500 mensajes al mes para mensajes de chat con Amazon Connect Contact Lens
180 transacciones por mes con Amazon Connect Voice ID, repartidas de manera equitativa entre inscripciones, autenticación y detección de fraude
90 días de uso gratuito de previsión, planificación de capacidad y programación de Amazon Connect al activar la característica por primera vez

Despliegue de instancia de Connect con 3 Contact Flow

Este repositorio contiene los archivos necesarios para desplegar una instancia de Connect en AWS, junto con 3 flujos de contacto (Contact Flow), una tabla DynamoDB y una función Lambda.

Recursos desplegados en este manifiesto:

Instancia de Connect
3 Contact Flow
Tabla DynamoDB
Función Lambda

Solución - Diagrama:

Probado con:

Ambiente	Aplicación	Versión
WSL2 Ubuntu 20.04	Terraform	v1.4.6
WSL2 Ubuntu 20.04	aws-cli	v2.7.9

Procedimiento de implementación:

Antes de desplegar los recursos, asegúrate de tener los siguientes archivos en el directorio:

main.tf
provider.tf
default.auto.tfvars
variable.tf

A continuación, proporciona la siguiente información en cada archivo:

Archivo main.tf:

# Create Instace Connect
module "lambda" {
  source      = "./module/lambda"
  table_name  = var.table_name
  name_prefix = var.name_prefix
  lambda_name = var.lambda_name
}

module "connect" {
  source                   = "./module/connect"
  aws_profile              = var.aws_profile
  aws_region               = var.aws_region
  identity_management_type = var.identity_management_type
  instance_alias           = var.instance_alias
  name_user                = var.name_user
  password_user            = var.password_user
  first_name               = var.first_name
  last_name                = var.last_name
  country_code             = var.country_code
  name_prefix              = var.name_prefix
  phone_type               = var.phone_type
  type_contactflow         = var.type_contactflow
  lambda_arn               = module.lambda.lambda_arn
  lambda_name              = var.lambda_name

  depends_on = [module.lambda]
}

Archivoprovider.tf:

# AWS provider version definition
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

#Provider for the network account
provider "aws" {
  region  = var.aws_region
  profile = var.aws_profile
}

Archivo default.auto.tfvars:

#Variable Generales
aws_profile              = "connect"
aws_region               = "us-east-1"
name_prefix              = "First-Release"
project-tags = {
  DeployBy   = "example",
  Enviroment = "Dev"
}

#Variable Connect
instance_alias           = "example-demo-connect-terraform"
name_user                = "connect"
password_user            = "Password123"
first_name               = "FirstName"
last_name                = "LastName"
country_code             = "AR" ## https://countrycode.org/
phone_type               = "SOFT_PHONE"      ## otras opciones (DESK_PHONE)
identity_management_type = "CONNECT_MANAGED" ## Otra opciones (SAML, EXISTING_DIRECTORY)
type_contactflow         = "CONTACT_FLOW"    ## Otras opciones (CUSTOMER_QUEUE, CUSTOMER_HOLD, CUSTOMER_WHISPER, AGENT_HOLD, AGENT_WHISPER, OUTBOUND_WHISPER, AGENT_TRANSFER, QUEUE_TRANSFER )

#Variable Dynamo y lambda
table_name               = "pedidos_y_facturas"
lambda_name              = "Lambda-valicacion-flow"

Archivo variable.tf:

variable "aws_profile" {
  description = "[REQUERIDO] Profile utilizado para realizar el despliegue."
  type        = string
}

variable "aws_region" {
  description = "[REQUERIDO] El AWS Region para implementar los recursos."
  type        = string
}

variable "identity_management_type" {
  description = "[REQUERIDO] Tipo de gestión de identidad adjunto a la instancia."
}

variable "instance_alias" {
  description = "[REQUERIDO] Alias de la instancia de Connect."
  type        = string
}

variable "name_user" {
  description = "[REQUERIDO] Nombre para la creación de usuario."
  type        = string
}

variable "password_user" {
  description = "[REQUERIDO] Contraseña para la creación de usuario."
  type        = string
}

variable "first_name" {
  description = "[REQUERIDO] Nombre del usuario."
  type        = string
}

variable "last_name" {
  description = "[REQUERIDO] Apellido del usuario."
  type        = string
}

variable "country_code" {
  description = "[REQUERIDO] Código telefónico del país."
  type        = string
}

variable "name_prefix" {
  description = "[REQUERIDO] Prefijo del nombre."
  type        = string
}

variable "phone_type" {
  description = "[REQUERIDO] Tipo de número de teléfono."
  type        = string
}

variable "type_contactflow" {
  description = "[REQUERIDO] Tipo de flujo de contacto."
  type        = string
}

variable "table_name" {
  description = "[REQUERIDO] Nombre de la tabla de DynamoDB."
}

variable "lambda_name" {
  description = "[REQUERIDO] Nombre de la función Lambda."
  type        = string
}

# Variables de Etiquetas #
variable "project-tags" {
  type    = map(string)
  default = {}
}

Ubicado en el directorio donde se crearon los archivos antes mencionados, iniciamos nuestro proyecto y desplegamos el manifiesto de la siguiente forma:

terraform init     = Inicializamos terraform
terraform fmt      = Para darle formato a los archivos
terraform validate = Validamos que no tengamos alguna inconsistencia en los recursos
terraform plan     = Realizamos un plan para verificar los recursos a desplegar
terraform apply    = Realizamos ya el despliegue de los recursos

authors:

👩‍💻 Hermes Vargas
👩‍💻 Diego Mujica