DEV Community: Andres Figueroa

EC2 Lab: Launching an Instance in a Private Subnet (Private Access)

Andres Figueroa — Tue, 09 Dec 2025 00:23:52 +0000

Think of EC2 as your personal engine room in the cloud. It’s where ideas stop being just code on your laptop and become running workloads that power your architecture.

With EC2 you don’t just “launch servers”—you decide how powerful they are, where they live, and how they connect. In a private subnet, your instances are shielded from the internet, accessible only through secure channels like bastion hosts or AWS Systems Manager Session Manager.

Whether you’re running sensitive databases, internal services, or backend applications, EC2 private instances give you the control and protection to keep your workloads humming quietly behind the scenes.

📌 Public Subnet? Your app is visible to the world.
📌 Private Subnet? Your workloads stay protected, humming quietly behind the scenes.

Stage 1: Define Tags and Select OS

Step 1: In the Name and tags section, define:
-Name: VM-Project-Private
-Project: demo

📌 Tags help with auditing, cost tracking, and resource organization.

Step 2: In Application and OS Images, select:

Amazon Linux 2023 Kernel 6.1 AMI
Architecture: 64-bit (x86)

📌 Amazon Linux is optimized for AWS, with extended support and solid performance.

Stage 2: Instance Type and Key Pair

Step 3: Choose the instance type:
t3.micro → 2 vCPUs, 1 GiB RAM, Free Tier eligible

📌 Ideal for testing or lightweight workloads.

Step 4: Select an existing PEM key pair:

-Name: vm-demo-project
-Type: RSA
-Format: .pem (compatible with OpenSSH)

📌 This existing key pair will be used for SSH access if needed. Make sure you keep the .pem file stored securely.

Stage 3: Network and Security Configuration (Private)

Step 5: Select your custom VPC:
-VPC ID: VPC-Demo-Project
-Subnet: subnet-b-private-project (20.0.4.0/24, zone us-east-1a)
-Public IP: Disabled

📌 The instance will be placed in a private subnet, without direct internet access.

Step 6: Configure the Security Group:
Name: demo-project-private
Rule: Nothing. Because it allow SSH only from the bastion host or via AWS Systems Manager Session.

📌 Secure access is restricted. No direct exposure to the internet.

Stage 4: Storage Configuration

Step 7: Configure the root volume:
-Type: gp3
-Size: 8 GiB
-IOPS: 3000
-Encryption: Enabled (recommended for private workloads)

📌 gp3 offers solid performance and is Free Tier eligible.

Stage 5: IAM Role and Advanced Settings

Step 8: Assign an IAM role:

AmazonSSMRoleForInstancesQuickSetup

📌 Allows secure access via AWS Systems Manager (SSM) without SSH keys or public IPs.

Step 9: Configure advanced settings:
- Hostname: IP-based
- DNS: IPv4 enabled
- Metadata: version V2 with token required

📌 Modern and secure configuration for automated management.

Stage 6: Review and Launch

Step 10: In the summary screen, review:
- AMI: Amazon Linux 2023
- Instance type: t3.micro
- Storage: 8 GiB
- Security Group: private access only

📌 Everything is ready to launch the instance.

Step 11: Once checks are complete.

📌 The instance enters “initializing” state, which typically lasts 30 seconds to 2 minutes.

-Confirm the instance is in Running state.

-Upon review, I noticed that the public IP is not enabled since the instance is running in private mode

Step 12. Connect via Session Manager

Click Connect.
In the connection options, select Session Manager.
Click Connect again.

📌 No public IP or SSH key is required — the connection is tunneled securely through SSM.

Step 13: Confirm the Session
-A terminal window opens directly in the AWS Console.
-By default, you are logged in as the default system user (e.g., ssm-user).
-If needed, you can elevate privileges:
sudo su
-Now you are operating as root inside the private EC2 instance.

Advantages of SSM over Public SSH:
-No public IP exposure → Reduces attack surface.
-No need to manage SSH keys → Access is controlled via IAM policies.
-Auditing and logging → All sessions can be logged in CloudWatch or S3.
-Granular permissions → Restrict who can start sessions.

🧠 Final Reflection
Using Session Manager is the recommended way to connect to private EC2 instances. It eliminates the need for bastion hosts or open SSH ports, while providing secure, auditable, and role‑based access.

👉 This complements your earlier tutorial on public EC2 access. Now you can publish this as the “EC2 Private” continuation post, showing best practices for secure architectures.

Public EC2 SSH Access with MobaXterm: Step‑by‑Step Guide

Andres Figueroa — Mon, 08 Dec 2025 22:36:07 +0000

Connecting to an EC2 instance doesn’t have to be complicated. This tutorial walks you through how to establish a secure SSH connection to a public EC2 instance using MobaXterm, with clear steps and best practices.

Overview:
- Goal: Connect via SSH to an EC2 instance with a public IP using a .pem key in MobaXterm.
- Approach: Simple steps, no CLI required — perfect for demos or quick tests.
- Best practices: Security group rules and correct username depending on the AMI.

Step‑by‑Step with MobaXterm
Step 1. Open MobaXterm Launch MobaXterm (Portable or installed) to access the main panel.

Step 2. Create a new session Click Session → SSH to start configuring the connection.

Step 3. Configure host and user
- Host: Enter the EC2 public IP or Elastic IP.
- Username: Use the correct AMI user (e.g., ec2-user for Amazon Linux, ubuntu for Ubuntu).

Step 4. Load the private key (.pem)

Check Use private key and select your .pem file.

- Tip: MobaXterm usually accepts .pem directly. If not, convert to .ppk with PuTTYgen.

Step 5. Name the session (optional) In Bookmark settings, give the session a descriptive name (e.g., “EC2‑Prod‑VA”).

Step 6. Accept the host fingerprint On first connection, MobaXterm will show the host key fingerprint. Click Accept to trust the server.

Step 7. Connect and verify Click OK/Connect. Once inside, run whoami and hostname to confirm access.

Quick Troubleshooting

Permission denied (publickey): Check the correct SSH Username and ensure the .pem matches the instance key pair.
Timeout: Verify port 22 is open in the Security Group and that the instance has a public IP.
Wrong user: Adjust the username according to the AMI.

Best Practices

Restrict port 22 to your IP only — avoid 0.0.0.0/0 in production.
Use Elastic IPs for stable addressing.
Name your sessions in MobaXterm for clarity across environments.

✅ With these steps, connecting to a public EC2 instance using MobaXterm is straightforward, secure, and repeatable for demos or production environments.

⚠️ Note on Public EC2 Instances
Connecting to a public EC2 instance is useful for demos and quick tests, but it’s not recommended for production. Public IPs expose your server directly to the internet, which increases security risks if not managed properly.

✅ Best Practice: Use private subnets, bastion hosts, or AWS Systems Manager Session Manager for secure access.

👉 In my next post, I’ll cover how to connect to an EC2 Private Instance, following best practices for secure architectures.

AWS Interconnect (Preview): Private Multicloud Connectivity Between AWS and Google Cloud

Andres Figueroa — Mon, 08 Dec 2025 17:30:00 +0000

🌐 AWS has just introduced Interconnect (Preview), a service that allows you to link workloads between AWS and Google Cloud through private, fast, and secure connections, without the need for physical hardware or complex router configurations.

🔹 Direct connectivity through AWS’s global private network
🔹 Built-in security with MACsec encryption
🔹 Full visibility with latency, packet loss, and bandwidth metrics in CloudWatch
🔹 Initial availability in us-east-1 and us-west-2 (Azure support coming in 2026)

💡 Key benefit: During the Public Preview phase, AWS offers a 1 Gbps private connection at no cost, making it easy to test and validate the service before moving to production.

This is a great opportunity for companies operating in multiple clouds to simplify management, reduce infrastructure complexity, and ensure enterprise-grade security.

Amazon EC2: Launching Your First Instance from the Console (Public Access)

Andres Figueroa — Sun, 16 Nov 2025 02:27:50 +0000

Think of EC2 as your personal engine room in the cloud. It’s where ideas stop being just code on your laptop and become running applications, websites, or services that anyone can reach.
With EC2 you don’t just “launch servers”—you gain the freedom to choose how powerful they are, where they live, and how they connect. Whether you need a tiny test machine or a fleet of high‑performance instances, EC2 scales with you.

📌 Public subnet? Your app is out there, visible to the world.
📌 Private subnet? Your workloads stay protected, humming quietly behind the scenes.

EC2 Lab: Stages and Detailed Steps with Visual Explanations

Stage 1: Define Tags and Select OS

Step 1: In the Name and tags section, you define:
-Name: VM-Project
-Project: demo

📌 Tags help with auditing, cost tracking, and resource organization.

Step 2: In Application and OS Images, you select:
-Amazon Linux 2023 Kernel 6.1 AMI
-Architecture: 64-bit (x86)

📌 Amazon Linux is optimized for AWS, with extended support and solid performance.

Stage 2: Instance Type and Key Pair

Step 3: You choose the instance type:
-t3.micro → 2 vCPUs, 1 GiB RAM, Free Tier eligible

📌 Ideal for testing or lightweight workloads.

Step 4: You create a new PEM key pair:
-Name: vm-demo-project
-Type: RSA
-Format: .pem (compatible with OpenSSH)

📌 This key is required for SSH access. Store it securely.

Stage 3: Network and Security Configuration

Step 5: You select your custom VPC:
-VPC ID: VPC-Demo-Project
-Subnet: subnet-a-public-project (20.0.1.0/24, zone us-east-1a)
-Public IP: enabled

📌 The instance will be placed in a public subnet with internet access.

Step 6: You configure the Security Group:
-Name: demo-project
-Rule: allow SSH from your IP (38.255.158.79/32)

📌 Secure remote access restricted to your IP.

Stage 4: Storage Configuration

Step 7: You configure the root volume:
-Type: gp3
-Size: 8 GiB
-IOPS: 3000
-Encryption: not enabled

📌 gp3 offers solid performance and is Free Tier eligible.

Stage 5: IAM Role and Advanced Settings

Step 8: You assign an IAM role:
-AmazonSSMRoleForInstancesQuickSetup

📌 Allows secure access via AWS -Systems Manager (SSM) without SSH keys.

Step 9: You configure advanced settings:
-Hostname: IP-based
-DNS: IPv4 enabled
-Termination protection: disabled
-Metadata: version V2 with token required

📌 Modern and secure configuration for automated management.

Stage 6: Review and Launch

Step 10: In the summary screen, you review:
-AMI: Amazon Linux 2023
-Instance type: t3.micro
-Storage: 8 GiB
-Security Group: newly created

📌 Everything is ready to launch the instance.

Step 11: You click Launch instance.

📌 The instance enters “initializing” state, which typically lasts 30 seconds to 2 minutes.

Stage 7: Validation and Monitoring

Step 12: The instance appears as Running:
-Name: VM-Project
-ID: i-0f467eccaf0dfe8a0
-Zone: us-east-1a
-State: Initializing

📌 The instance is active but still completing health checks.

Step 13: Once checks are complete:
-Status: 3/3 checks passed

📌 The instance is fully operational.

🧠 Final Reflection
Amazon EC2 is where your architecture comes to life. It’s not just a server—it’s your design running, scaling, and responding in real time. From public-facing apps to private workloads, EC2 is the pulse of your cloud.

AWS VPC: Security and Control from Scratch

Andres Figueroa — Sat, 15 Nov 2025 13:59:15 +0000

VPC Lab: Practical Fundamentals of Cloud Networking

Virtual Private Clouds (VPCs) are the heart of any architecture on AWS.
They are not just virtual networks: They are the foundation of the security, control, and scalability of your solutions.

In this lab, you will learn to design and deploy a VPC from scratch, understanding each architectural decision and its impact on cost, security, and performance.

VPC Lab: Practical Fundamentals of Cloud Networking

🔐Stage 1: From the AWS console, click on VPC to start building a new network.

Step 1: From the AWS console, click on VPC to start building a new network.

Step 2: Define the IPv4 CIDR block: 20.0.0.0/16.

Step 3: Configure public and private subnets across different Availability Zones:
-Public Subnet A → Zone us-east-1a → 20.0.1.0/24
-Public Subnet B → Zone us-east-1b → 20.0.2.0/24
-Private Subnet A → Zone us-east-1a → 20.0.4.0/24
-Private Subnet B → Zone us-east-1b → 20.0.3.0/24

📌 This establishes the foundation of your network, with a clear separation between public and private resources.

🔐Stage 2: Tagging and Governance

Step 4: Create tags such as Owner, Project, etc.

📌 Tags are essential for auditing, cost tracking, and resource management.

🔐Stage 3: Initial Validation

Step 5: The wizard shows the creation process as successful.

Step 6: Review the public and private subnets created along with their IP ranges.

📌 You confirm that the basic infrastructure is active and available.

🔐Stage 4: Route Tables

Step 7: Open the Route Table for the public subnet.

📌 It has its own table named Public.

Step 8: Open the Route Table for the private subnet.

📌 Create a table named Private and associate it with the private subnets.

Note: This separates public and private traffic for better control.

🔐Stage 5: Internet Gateway (IGW)

Step 9: Create an Internet Gateway (IGW) to enable internet access.

Step 10: Confirm the IGW was created successfully.

Step 11: In the Public route table, add a route:
Destination: 0.0.0.0/0
Target: the IGW you created

📌 Public subnets now have direct access to the internet.

🔐Stage 6: NAT Gateway

Step 12: For private subnets, you need controlled internet access.

Step 13: Create a NAT Gateway in a public subnet:
-Select the public subnet (us-east-1a or us-east-1b).
-Allocate and assign an Elastic IP.

Step 14: Confirm the NAT Gateway is created and available.

📌 The NAT Gateway allows private instances to reach the internet without being exposed.

🔐Stage 7: Configuring Private Routes

Step 15: In the Private route table, add a route:
-Destination: 0.0.0.0/0
-Target: the NAT Gateway you created.

Step 16: Save the changes and verify the new route is active.

📌 Private subnets now have secure outbound internet access.

🔐Stage 8: Final Validation

Step 17: Review the route tables:
-Public → local + IGW
-Private → local + NAT

Step 18: Confirm that all subnets are in Available state and correctly associated.

📌 Your architecture is complete: public for direct access, private for secure backend with controlled internet connectivity.

🌟 Conclusion
You’ve built a segmented and secure VPC with:
-Public and private subnets across two Availability Zones.
-An Internet Gateway for public subnet access.
-A NAT Gateway for controlled private subnet access.
-Separate and properly configured route tables.
-Tags for auditing and governance.

🧠 Final Reflection
Building a VPC with public and private subnets, an Internet Gateway, and a NAT Gateway is more than just a technical exercise—it’s about designing secure, scalable foundations for cloud workloads. By separating traffic flows and applying clear governance, you ensure resilience and control, while enabling your applications to grow with confidence.

IAM: Prioritizing Security Is More Than a Method

Andres Figueroa — Sun, 09 Nov 2025 04:16:04 +0000

Secure Creation of Root Account and IAM Administrator User in AWS

Delegating with Security: The Initial Flow in AWS IAM

This diagram is not just a set of technical steps. It reflects how to start properly in AWS: with intention, with security, and by following best practices.

Everything begins with the Root user, the master access that should never be used for daily operations. We protect it with MFA because it is the most sensitive point. Then, we delegate. We create a user called IAM-Administrator, who will actually manage the environment. Separated from Root, with well-defined privileges, and also with MFA enabled. Because even the most privileged users must operate under double verification.

This diagram represents a conscious decision: it’s not just about connecting, but about delegating with confidence, protecting our account, and auditing with clarity.

A secure architecture begins not with commands, but with criteria.

IAM Lab: Secure Creation of Root Account and IAM Administrator User in AWS

🔐Stage 1: Initial Setup of the Root Account

Step 1: Create a new Root account using a valid email.

https://signin.aws.amazon.com/signup?request_type=register

Step 2: Define secure credentials known only to the Root user.

Step 3: Select a payment plan (avoid the free plan to enable full access to services).

Step 4: Complete personal details for the Root account holder.

Step 5: Register a valid credit or debit card to activate the account.

Step 6: Verify identity via a code sent to the associated email.

Step 7: Once validated, access the billing console to confirm account activation.

🔐 Stage 2: Enabling MFA on the Root Account

Step 8: In the IAM console, notice the security alert recommending MFA activation. Select “Add MFA.”

Step 9: Choose the authentication method:

-Passkey or Security Key: A physical device connected via USB or NFC.
-Authenticator App: A mobile app (e.g., Google Authenticator) that generates temporary codes.
-Hardware TOTP Token: A physical key that displays one-time codes offline.

In this lab, we select Authenticator App.

Step 10: Scan the QR code with the Authenticator app and enter the temporary codes.

Step 11: Confirm successful MFA activation on the Root account.

👤 Stage 3: Creating the IAM Administrator User

Step 12: Create a new IAM user to delegate administration, following the principle of not operating directly with Root.

Step 13: Assign the name IAM-Administrator to the new user.

Step 14: Attach the AdministratorAccess policy, granting full permissions over AWS services.

Step 15: Add tags for traceability and governance, for example:
-Owner: Root
-Project: Administrator
-MFAEnabled: Yes

Step 16: Confirm successful creation of the IAM Administrator user.

En otra ventana posterior, nos enfocaremos en el Usuario Administrator.

🔑 Stage 4: Access and Configuration of the IAM Administrator User

Step 17: Sign in with the new IAM Administrator user.

Step 18: Set a secure password that complies with AWS guidelines.

Step 19: Confirm successful login with the new credentials.

Step 20: Access the IAM service to continue security configuration.

Step 21: Notice the alert recommending MFA activation for the IAM user.

Step 22: Repeat the MFA activation process using the Authenticator app.

Step 23: Scan the QR code and enter the generated temporary codes.

Step 24: Confirm successful MFA activation for the IAM Administrator user.

Step 25: Validate that the user complies with the established security policies.

Step 26: Verify that the IAM Administrator user was created correctly from the Root account and is ready to operate securely.

🧠 Final Reflection

This flow not only follows AWS security best practices, but also establishes a solid foundation for any cloud architecture.
Delegating, protecting, and tagging are actions that define a conscious architect.

Is the Cloud a Solution or a Hidden Risk?

Andres Figueroa — Wed, 29 Oct 2025 22:25:39 +0000

From my perspective, when AWS and Azure fail almost at the same time, we realize that the cloud also has gray days.

🔴** Is the cloud a solution or a hidden risk?**

In less than 10 days, two tech giants faced outages that disrupted critical services worldwide:

On October 20: AWS experienced a major disruption in the US-EAST-1 region due to DNS issues, impacting EC2, Lambda, DynamoDB, and other key services.

On October 29: Azure suffered an outage in its Front Door service, affecting Microsoft 365, Xbox, Intune, and even banks like BCP and Interbank in Peru.

🤔 These incidents force us to rethink how we view the cloud. We are so focused on the cloud solving our problems that we forget to** design for when it fails**. It’s not enough to build scalable architectures or pay for “High Availability.”

✍ What we need is a resilience mindset—where distributed architecture, fault tolerance, and disaster recovery are part of the design, not just a patch.

💡 So, what are we doing to prepare for the inevitable? Do we still believe that “everything in the cloud” is enough? Or should we start talking about fault-tolerant architectures, automated recovery, multi-regional distribution, and real continuity testing?

The cloud is not the final destination—it’s part of the journey. And like any journey, it can have interruptions.ticles/mb34ouwkltktxrab8tti.png)

𝐖𝐡𝐲 𝐰𝐨𝐮𝐥𝐝 𝐚 𝐜𝐥𝐨𝐮𝐝 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭 𝐠𝐨 𝐛𝐚𝐜𝐤 𝐭𝐨 𝐭𝐡𝐞 𝐛𝐞𝐠𝐢𝐧𝐧𝐢𝐧𝐠?

Andres Figueroa — Sun, 07 Sep 2025 06:57:30 +0000

After some time working on cloud architectures and implementations in AWS, leading projects in regulated sectors, I made a decision that might seem contradictory: Going Back to the Beginning. Yes, I chose to revisit my foundations through the AWS Certified Cloud Practitioner.

Not because of a lack of technical knowledge. Not because of external pressure. But for something deeper: to reorganize my experience, reconnect with core concepts, and translate what I know into a language that resonates with those just starting out.

Along the way, I’ve discovered that:

Understanding basic services like IAM from scratch pushes me to reassess cloud security with clarity.
Reviewing virtual machines, storage, and databases helps me teach through real-world examples, not jargon.
Studying Pricing and Billing connects me with FinOps and strategic decision-making.

Going back to the beginning isn’t a step backward. It’s rebuilding with purpose, humility, and a vision for impact.

I’m exploring this path through the end of the year, sharing whatever comes up: hands-on practices, open reflections, and insights I find useful.

If you’re starting out in AWS, or if you’re reorganizing your own cloud journey, maybe something I share will be helpful.

There’s no fixed schedule or big promises. Just a genuine desire to build from what’s real. And if I pause at any point, that too will be part of the process. Because this isn’t about perfection—maybe it’s about honest evolution.

AWS en la vida Real - Primeros Pasos: RAM & Transit Gateway

Andres Figueroa — Sun, 02 Oct 2022 05:43:52 +0000

Hola a todos

En este blog, tiene como finalidad entender el funcionamiento del Transit Gateway AWS que nos permite realizar comunicación entre cuentas diferentes utilizando el servicio de RAM, en la cuenta Master con la finalidad de centralizar la comunicación con las cuentas secundarias.

Por ende, es importante conocer el flujo de comunicación que realizaremos paso a paso para comprender el procedimiento.

Primero, comenzaremos a conocer el diagrama de cuentas AWS a través de un diagrama simple:

CUENTA AWS MASTER:

Transit Gateway:
Crearemos el nuevo servicio de TGW para la comunicación entre VPC's y cuentas diferentes:

Una vez creada, configuraremos el servicio de RAM agregando la opción de Transit Gateway para que se vea reflejado dicho servicio en las cuentas secundarias

Para finalizar, daremos clic en "Create Resource Share"

Al momento de la creación, se debe esperar que se termine de asociar a la cuenta A para su aprobación.

Inicio de Proceso para la aprobación de la Cuenta A:

Cuenta A:
AWS Resource Access Manager:

Invitación de la cuenta Master:

Aprobación:

Transit Gateway:
Se visualiza el Transit Gateway de Master dentro de la Cuenta A

Volvemos a la cuenta Master para la visualización de la creación de la nueva comunicación:

Listo !! Primera comunicación con la cuenta A. Ahora vayamos con la cuenta B.

Editamos en el mismo RAM de la cuenta Master, con la finalidad de agregar a la cuenta B

Una vez terminada de actualizar, se espera la aprobación de la cuenta B

Veamos en la cuenta B:
Resource Access Manager

Aprobación

Listo !

Volvemos a la cuenta Master:
Se visualizan que ambas cuentas ya estan aprobadas y listas para la comunicación

CONFIGURACION DE TRANSIT GATEWAY ATTACHMENTS DE AMBAS CUENTAS SECUNDRIAS A y B:

Comenzamos en la cuenta A, con la finalidad de agregar su VPC en la cuenta Master, para poder realizar la comunicación bidireccional con la cuenta B:

Entraremos al servicio de Transit Gateway Attachments:

Se visualiza el Transit Gateway ID del Master:

Daremos clic en "Create transit gateway attachment".

Volvemos a la cuenta Master para su aprobación:

Aprobado la cuenta A en Master:

A continuación de la misma forma se realizará la Cuenta B:

Crearemos el Atacchment:

Se visualiza el Transit Gateway ID del Master:

Pendiente para la aprobación del Master:

Volvemos al Master para la aprobación de la cuenta B:

Se visualiza que se ha aprobado la cuenta B:

Tener en cuenta que se visualizan en la Tabla de Ruta Master del Transit Gateway, una vez generan las configuraciones, automáticamente se generan en sus rutas:

A continuación, finaliza la configuración de Transit Gateway del Master en conjunto con la cuenta A y Cuenta B para la comunicación bidireccional.

VALIDACION DE PRUEBA DE SERVIDORES EC2 PARA AMBAS CUENTAS SECUNDARIAS PARA REALIZAR LA COMUNICACIÓN:

CUENTA A:
VPC : 172.17.0.0/16
VPC : 172.18.0.0/16

La mejor prueba que puedes realizar, es creando 2 Instancias Privadas Ec2(AMI Linux 2) entre ambas cuentas secundarias con la finalidad de realizar la comunicación entre IP's Privadas.

Para realizar dicha comunicación, se debe realizar 2 pasos importantes:
-Tabla de Rutas de las Subredes Privadas
-Security Groups de la Instancia Privada (Ec2)

A continuación, procederemos a configurar en las Tablas de Rutas de los subnets y Security Groups de ambas cuentas A y B

CUENTA A:
Tabla de Ruta de la Subnet Privada donde estará asociada la Instancia Ec2, en este caso, solo estaríamos agregando la IP de la VPC de la Cuenta B.

De la misma forma se agrega en el Security Group de la Instancia, para realizar la comunicación.

*Es suficiente elegir el Tipo SSH con puerto 22 para realizar el comando Telnet.

A continuación, se visualiza la instancia Ec2 Privada. Es importante habilitar el Rol de SSM para poder conectarnos de forma segura:

CUENTA B:
Tabla de Ruta de la Subnet Privada donde estará asociada la Instancia Ec2, en este caso, solo estaríamos agregando la IP de la VPC de la Cuenta A.

De la misma forma se agrega en el Security Group de la Instancia, para realizar la comunicación.

A continuación, se visualiza la instancia Ec2 Privada. Es importante habilitar el Rol de SSM para poder conectarnos de forma segura:

RESULTADOS DE LA VALIDACIÓN:

Se realizan prueba de Telnet entre ambas IP's Privadas de las Instancias Ec2:

CUENTA A ----> CUENTA B

CUENTA B ------> CUENTA A