Desktop and Application Streaming
Manage Aurora databases using an AppStream 2.0 Elastic fleet
Customers are migrating from commercial databases to open-source databases on AWS like Amazon Aurora PostgreSQL and Amazon Aurora MySQL. As a best practice, customers configure these databases to be running in a private subnet within an Amazon VPC. When database administrators (DBA) have to perform admin activities on these databases they log in to a bastion instance and run admin related activities on the database. Bastion instances are additional instances that customers have to manage, update, and secure.
Organizations use AWS managed services to reduce the undifferentiated heavy lifting of managing operating systems and applications. Customers can concentrate their efforts on activities that drive value for the business. For customers that need SSH or RDP access to their private instances, Amazon EC2 Instance Connect (EIC) Endpoint, allows you to connect securely to your instances and other VPC resources from the internet.
With managed database services AWS like Amazon Aurora PostgreSQL and Amazon Aurora MySQL, customers will still need to manage, maintain, and secure their EC2-based bastion instances that host their database administration tools. In this blog post we discuss running tools like DBeaver, on Amazon AppStream 2.0 Elastic fleets to provide a consistent experience for running admin related activities on Aurora databases.
Architecture
Elastic fleets are a serverless fleet type that lets you stream applications to your end users from an AWS-managed pool of streaming instances. Administrators no longer need to predict usage, create or manage scaling polices, or create images. Elastic fleets are optimized for use cases with sporadic usage patterns such as software trials, training, and sales demos, or converting a desktop application to a software as a service delivery model.
Elastic fleet streaming instances rely on applications that are installed to Virtual Hard Disks (VHD) stored in an Amazon Simple Storage Service (S3) bucket in your account. When your users choose their applications to launch, a new Elastic fleet streaming instance is created, the virtual hard drive is downloaded and assigned to the Elastic fleet to start streaming applications to your users. You no longer need to create scaling policies, or create and manage any AppStream 2.0 images. The pool of streaming instances is managed by AppStream 2.0.
The solution consists of:
- An Amazon VPC with multiple public subnets and multiple private subnets.
- An Aurora database provisioned in private subnets
- An AppStream 2.0 Elastic fleet configured to run its instances in the private subnet.
Pre-requisites
Based on the architecture defined above, the following AWS services will be required as pre-requisites.
- A VPC with two private subnets, and two public subnets.
- An Aurora PostgreSQL Serverless V2 database in private subnet.
- An Amazon S3 bucket. The S3 bucket must have a bucket policy which allows access to the AppStream 2.0 service. See S3 Bucket Permissionsfor more details. NOTE: Currently, S3 buckets configured to use server-side encryption with customer-provided encryption keys (SSE-C) are not supported for Elastic fleets. If you require encryption at rest for your S3 objects, server-side encryption with Amazon S3-managed encryption keys (SSE-S3) is an option that will work for Elastic fleets.
- An AWS Identity and Access Management (IAM) user or role with sufficient permission to upload objects to your S3 bucket, create app blocks, applications and to associate an application with your Elastic fleet in AppStream 2.0. See Using AWS Managed Policies and Linked Roles to Manage Administrator Access to AppStream 2.0 Resourcesin the Administration Guide.
- An Amazon Linux EC2 instance, Amazon Linux AppStream 2.0 image builder, or Amazon Linux WorkSpace to create the VHD.
- An Amazon Linux 2 based Elastic fleet with a security groups that allows access to Aurora PostgreSQL. You may need to modify your DB subnet groups.
Walkthrough
In this article you will complete the following tasks:
- Configure the VHD
- Configure the Elastic fleet
- Stream the application
- Clean up resources no longer needed
Step 1: Configure the VHD
This section describes how to setup the applications using AppStream 2.0 Elastic Fleets. To access the database set up DBeaver, which is an open-source database tool. You use the Amazon Linux 2 operating system. Similar steps can be followed to install any other tools on Amazon Linux 2.
- Follow the instructions in Create the VHD to create, initialize and mount your virtual hard disk (VHD) file. You’ll need to perform these steps from an Amazon Linux 2 EC2 instance, Amazon Linux AppStream 2.0 image builder, or Amazon Linux WorkSpaces. Use the following parameters while completing these steps:
- File name: dbeaver.img
- VHD size: 1024 megabytes (1G)
- Mounting location: /mnt/dbeaver-vhd
- When your VHD is mounted, download the application executables. Only the application components will be used in the VHD. Copy the extracted application folder to the mounted directory. After copying, unmount the local folder. The contents of the application are now stored in the VHD file.
wget https://dbeaver.io/files/dbeaver-ce-latest-linux.gtk.x86_64.tar.gz tar -xvf dbeaver-ce-latest-linux.gtk.x86_64.tar.gz sudo cp -R dbeaver/ /mnt/dbeaver-vhd sudo umount /mnt/dbeaver-vhd
- AppStream 2.0 uses a setup script you provide to manage and mount the downloaded VHD object. Use this setup script to mount your VHD, install other dependencies, or make any configuration changes necessary to the streaming instance. Create a file called mount-script-dbeaver.sh with the following content. AppStream 2.0 will use this script to create a local directory in the launched AppStream 2.0 Elastic fleet and mount the VHD image.
#!/bin/bash sudo mkdir /opt/dbeaver sudo mount -t auto -o loop /opt/appstream/AppBlocks/dbeaver/dbeaver.img /opt/dbeaver
- Upload the mount script, VHD, and to the Amazon S3 bucket that was created during pre-requisites.
- Replace <<APPSTREAM-FLEET-BUCKET>> in the following commands with name of the S3 bucket.
#!/bin/bash aws s3 cp mount-script-dbeaver.sh s3://<>/dbeaver/mount-script-dbeaver.sh aws s3 cp dbeaver.img s3://<>/dbeaver/dbeaver.img aws s3 cp dbeaver/dbeaver.png s3://<>/dbeaver/icon.png
Step 2: Configure the Elastic fleet
In this step you will create an app block, application, and Elastic fleet.
- Follow the instructions in Create the App Block Resource with the following parameters.
- For Name, enter dbeaver.
- For Virtual hard disk object in S3, choose img you uploaded in step 1.
- For Setup script object in S3, choose img you uploaded in step 1.
- For Setup script executable, choose /opt/appstream/AppBlocks/dbeaver/mount-script-dbeaver.sh
- Follow the instructions in to create a the application resource with the following parameters.
- For Name, enter dbeaver.
- For Application executable launch path, enter /opt/dbeaver/dbeaver/dbeaver.
- For Supported operating systems (OS) choose Amazon Linux 2.
- For Supported instance families choose General Purpose.
- For App block, choose dbeaver.
- Follow the instructions in manage applications associated to an Elastic fleet to add dbeaver and provide users with access to the stack.
Step 3: Stream the application
When users authenticate, they will see Dbeaver in their application catalog. Once the application is launched, you can configure the endpoint and credentials for the Aurora database to access and perform DBA activities.
Choose PostgreSQL as the database and enter the database credentials.
- URL: This is the database endpoint. Refer to viewing the endpoints for an Aurora cluster.
- Username: Username of the database.
- Password: Database password
The above example uses long term database credentials for managing the Aurora databases from AppStream 2.0 Elastic fleets. You can follow the same approach to manage databases using IAM database authentication with Aurora databases.
Step 4: Clean up resources no longer needed.
If you no longer need the solution deployed, follow the instructions in this step to clean up the resources.
- Disassociate fleet from stack, then delete the stack.
- Stop the fleet. Disassociate the assigned application from the fleet. Then delete the fleet.
- Delete the application and app block.
- Delete any objects (VHD files, icons and mount scripts) you uploaded to your S3 bucket.
Conclusion
In this blog, you learned how to use AppStream 2.0 Elastic fleets to provide a consistent experience for running admin related activities on Aurora databases. With Elastic fleets, you no longer have to deploy, manage, and secure additional bastion hosts to access your databases in a private subnet.
Elastic fleets streaming instances rely on applications that are installed on a virtual hard disk. You no longer need to create and manage images or create scaling polices.
To learn more about using Elastic fleets as bastion hosts visit use Elastic fleets and Linux for inexpensive, secure bastion hosts in Amazon AppStream 2.0 blog.
Abhishek Jawali is a Enterprise Solutions Architect based in Bengaluru, India. He enables customers modernize their applications and build cloud native systems to achieve their business goals. He specializes in the area of Containers, Microservices, Serverless and DevOps. | |
Sathish Kumar Prabakaran is an Enterprise Solution Architect with AWS, supporting Global Strategic customers. He comes with 20 years of industry experience in Infrastructure, Application, Security, DevOps, IT service management, and Support disciplines. His specialties include Containers, AWS Networking, Security, and Application Modernization. | |
Mayur is a Sr. Solutions Architect within the Global Financial Services vertical, having worked with AWS for 4 years and accumulating a total of 19 years of experience in the IT industry. He is a developer at heart and loves to drive customer use cases for various architecture patterns. Mayur also provides customers with reference architecture blueprints and sample code snippets. Strong believer of Day 1 philosophy, he is based in Pune India. |