Modernizing Cloud Access: Replacing Bastion Hosts with AWS CloudShell VPC Environments
Ashish Kasaudhan
AWS Ambassador & Community Builder, 46x Certification, Cloud-Native & Platform Engineering Expert | Kubernetes, Docker, CI/CD, & Automation Specialist | DevOps, FinOps, SecOps, & GitOps Professional | Multi Cloud Expert.
Introduction
As the world increasingly moves toward cloud computing, organizations are striving to adopt the best security practices, especially when it comes to accessing resources hosted in the cloud. Typically, a best practice involves creating a 2- or 3-tier architecture, where the frontend resides in a public subnet (often behind load balancers) and the backends are secured in a private subnet. This setup ensures that no end-user or potential hacker can directly access instances in the private subnet.
In line with security advancements, companies are increasingly adopting a Zero Trust policy for resource access. Infrastructure as Code (IaC) is also becoming the norm, allowing resource management through code pipelines. However, as platform engineers, SREs, or DevOps professionals, we all recognize that there are times when direct access to instances is necessary to debug issues.
Historically, to solve this problem, we have relied on a jumpbox or bastion host—a dedicated instance placed in a public subnet. These instances are fortified with security configurations, patching, and necessary tools. Once logged into a bastion host, we could access resources hosted in private subnets, such as EC2 instances or RDS databases.
While this approach has been effective and still serves its purpose, the evolution of cloud services has introduced more robust and streamlined solutions. One such offering is AWS CloudShell, which has VPC access capabilities. This service allows secure access to resources hosted in a private subnet without the need for a traditional bastion or jump box host.
With AWS CloudShell, the question arises: do we really need Bastion or jumpbox hosts anymore?
CloudShell's seamless integration with VPCs enables you to securely access privately hosted resources, potentially rendering the traditional approach obsolete.
Comparison Between AWS CloudShell Standard and AWS CloudShell VPC Environments
In this Blog, we will see how we can use Cloudshell with vpc capabilities to access AWS resources hosted in the private subnet.
Prerequisites:
1- AWS Account Access
2- An IAM User
3- IAM permissions:
AWSCloudShellFullAccess: Provides users with full access to AWS CloudShell and its features.
AWSRDSAccess
AWSEC2Access
·????? ec2:DescribeVpcs
·????? ec2:DescribeSubnets
·????? ec2:DescribeSecurityGroups
·????? ec2:DescribeDhcpOptions
·????? ec2:DescribeNetworkInterfaces
·????? ec2:CreateTags
·????? ec2:CreateNetworkInterface
·????? ec2:CreateNetworkInterfacePermission
·????? ec2:DeleteNetworkInterface
These permissions are essential for creating and managing VPC environments within CloudShell.
4- Existing VPC
5- Resources in Private Subnet. For this blog, we will access an RDS database.
Creating AWS CloudShell VPC Environments
1. Access the CloudShell Console:
- Navigate to the CloudShell console page.
- Click on the + icon and select Create VPC Environment from the dropdown menu.
2. Set Up Your VPC Environment:
- On the Create a VPC Environment page, enter a name for your VPC environment in the Name box.
- From the Virtual Private Cloud (VPC) dropdown list, select the VPC you want to use.
- In the Subnet dropdown list, choose the subnet where you want the VPC environment to reside.
- From the Security Group dropdown list, select one or more security groups to assign to your VPC environment.
3. Create the VPC Environment:
- Click Create to establish your VPC environment.
4. (Optional) Review Your VPC Environment:
领英推荐
- If desired, select Actions and then choose View Details to review the details of your newly created VPC environment.
- The IP address of your VPC environment will be displayed in the command line prompt.
Access RDS From CloudShell:
RDS Details:
It's An Mysql RDS running in the us-west2 region in a private subnet and public access is disabled.
We will initiate a Telnet session to the RDS endpoint from a non-VPC CloudShell environment and review the results.
To install telnet in a cloud shell session run the following command and then perform telnet.
# sudo yum install telnet -y
# telnet rds-endpoint-details port number
example: telnet rds-cloudshell.us-west2.amazonaws.com 3306
As you can see, Our telnet is not able to get a response from RDS as its on a private subnet.
2. Try With AWS CloudShell VPC Environments:
Create a vpc access-based cloud shell, as described above in this document.
We will initiate a Telnet session to the RDS endpoint from a VPC CloudShell environment and review the results.
To install telnet in a cloud shell session run the following command and then perform telnet.
# sudo yum install telnet -y
# telnet rds-endpoint-details port number
example: telnet rds-cloudshell.us-west2.amazonaws.com 3306
As demonstrated, we successfully connected to the RDS on port 3306 from a VPC-based CloudShell session.
This highlights the advantage of using a VPC-based CloudShell. I encourage you to try it in your own environment to experience the benefits firsthand. I'm confident you'll find it incredibly useful."
Security Features and Access Locked Using IAM:
You can leverage a variety of security features in CloudShell, which AWS provides by default. To learn more about these features, visit the following page:
Limitations of AWS CloudShell VPC Environments:
1. VPC Environment Limits: Each IAM principal can create a maximum of two VPC environments.
2. Security Group Limits: You can assign up to five security groups to a VPC environment.
3. File Upload/Download Restrictions: The CloudShell upload and download options in the Actions menu are not available for VPC environments. However, you can upload or download files using other CLI tools if the VPC environment has internet access.
4. Ephemeral Storage: VPC environments do not support persistent storage. All data and home directory contents are deleted when the active environment session ends.
5. Internet Connectivity: Your CloudShell environment can only connect to the internet if it is located in a private VPC subnet with appropriate internet access configurations.
Conclusion
In a rapidly evolving cloud landscape, where security and efficiency are paramount, AWS CloudShell with VPC-based access offers a modern solution that redefines how we manage and interact with private cloud resources. By eliminating the need for traditional bastion or jump hosts, it simplifies access to VPC resources while enhancing security through tighter network controls and adherence to Zero Trust principles.
For DevOps professionals, SREs, and platform engineers, this service is a game-changer. It provides a secure, integrated environment that streamlines the process of managing and troubleshooting resources within a VPC. With AWS CloudShell VPC-based access, you can now perform all necessary tasks directly within your private network, reducing exposure to public networks and improving your organization’s overall security posture.
As cloud technology continues to advance, embracing tools like VPC-based CloudShell will be essential for staying ahead in both security and operational efficiency. Whether you’re maintaining infrastructure, deploying applications, or debugging issues, CloudShell’s VPC integration offers a robust and secure way to manage your cloud environment, making it an indispensable tool in your cloud toolkit.
Follow me on Linkedin:
Blog And Articles link: