The demand for media content continues to explode. The media and entertainment sector has shown no signs of slowing down despite the challenges and restrictions of implementing remote collaboration rendered essential by the pandemic.
The emergence of solutions like Amazon Studio in the Cloud and Nimble Studio is now enabling content creation studios to function at full throttle entirely on the cloud. In this article, we at TrackIt have decided to explore the various benefits of Studio in the Cloud and Nimble Studio that our clients are experiencing and also shed some light on the most common challenges readers may encounter when implementing this solution.
Contents
About Amazon Studio in the Cloud (Previously Nimble Studio)
Amazon Studio in the Cloud and Nimble Studio is an AWS service that allows creative studios to function entirely on the cloud. Studio in the Cloud and Nimble Studio enables studios to edit and produce visual effects animation, and studio-quality interactive content from start to finish. With access to virtual workstations, high-speed storage, and scalable render capacity, companies leveraging Studio in the Cloud and Nimble Studio can significantly accelerate content creation by rapidly onboarding and collaborating with artists located around the world.
Why Companies Should Choose Studio in the Cloud and Nimble Studio
Rapid Deployment
Studio in the Cloud and Nimble Studio enables companies to get their content creation pipelines up and running within hours. Studio in the Cloud and Nimble Studio’s automation capabilities along with its pre-built Amazon Machine Images (AMIs) help accelerate the process of setting up virtual workstations, storage and render farms.
Scalability
Studio in the Cloud and Nimble Studio automatically configures and deploys AWS services to ensure that they match a company’s ever-evolving business requirements. This provides content creators with the flexibility they need to rapidly add new artists to projects and execute new creative strategies without having to worry about provisioning more workstations or storage.
Remote Work Friendly
Companies leveraging Studio in the Cloud and Nimble Studio can onboard artists located remotely within minutes and also provide them with access to the latest software and hardware technologies.
Simple & Straightforward Pricing
Estimating costs when setting up virtual workstations can be confusing. Studio in the Cloud and Nimble Studio offers a simple and straightforward by-the-hour pricing structure that includes, without extra charges, all the underlying virtual workstation elements such as AWS EC2 and Elastic Block Store (EBS), as well as egress charges from pixel streaming the remote video display stream.
Enhanced Collaboration Between Artists
Studio in the Cloud and Nimble Studio simplifies the process of adding new users, granting permissions, and sharing data between artists.
Secure
Studio in the Cloud and Nimble Studio enables companies to build their creative studios on the globally-trusted and secure Amazon Web Services infrastructure.
Challenges & Workarounds
Challenge #1: Ensuring data persistence knowing that Amazon Nimble Workstations have a defined lifecycle
Following a recent update, Amazon Studio in the Cloud and Nimble Studio workstations now have a defined lifecycle that can be controlled using the AWS SDK. However, defined lifecycles can pose a problem when organizations want to ensure data persistence.
For instance, if a Studio in the Cloud and Nimble Studio workstation remains in the “Ready” state for longer than 11.5 hours, the machine automatically changes the workstation’s state to “Stopped”. Once in the “Stopped” state, data can only be stored for up to 4 days after which the session will be terminated and the data lost.
This challenge can be resolved by implementing a script that automatically restarts the session to ensure that data isn’t lost. Readers can refer to the following article published by the TrackIt team on the resolution of this issue: https://medium.com/trackit/how-to-make-aws-nimble-workstation-persistent-7f6af4899e8f
Challenge #2: EBS volume limitation (500 GB)
Some companies require workstations with more than 500 GB of storage to accommodate cache data. Studio in the Cloud and Nimble Studio users get an error when they try to attach an Amazon Machine Image (AMI) to the studio that reverses more than 500 GB of EBS volume. This error is not quota-related and since the resource is not created by the studio builder it is not possible to change this limit.
Solution
Users can choose to redirect the cache to an FSx for Windows file server for storage.
Challenge #3: Build/Migrating the Studio to a specific Local Zone (Los Angeles, for example)
Studio in the Cloud and Nimble Studio users usually prefer to have their studio in a Local Zone to ensure optimal performance.
For instance, users located in Los Angeles would want their studios to be in the LA Local Zone. However, this configuration is not something that’s available to them by default when they launch their studios. Users need to opt-in to the specific Local Zone that they wish to use (us-west-2-lax-1a and us-west-2-lax-1a in the example below). The opt-in can be done at this link.
For users that have not yet deployed a studio, the Los Angeles Local Zone (us-west-2-lax-1a and us-west-2-lax-1b) will be immediately available on the Studio Builder once the opt-in request is approved. Users can then simply select the Zone they prefer and proceed normally with the creation.
If a user already has a studio in production, this process becomes more complex and requires the manual migration of the following resources:
- Workstations Subnet
Instructions to migrate this resource
A new subnet must be created for the workstations in the new Local Zone. Users need to be mindful about not using the same names (suggestion: add the suffix “-LAx”) or overlapping CIDR (Classless Inter-Domain Routing). Users should attach the Route Table and the ACL of the original subnet and after that, check all ACLs for references to the old subnet and replicate but now pointing to the new CIDR.
- Filesystem
Instructions to migrate this resource
The same steps cited above should be followed for the Filesystem subnet and then a new FSx should be created with the same settings as the pre-existing one, except for the different subnet (the newly created Filesystem-LAx) and Availability Zone (us-west-2-lax-1a or b) chosen. Users should attach the new FSx to their Studio in Studio Resources, also taking the old one as a parameter, and then activating it in the desired Launch Profiles. Users can then start a session in a profile with both FSx filesystems attached and move the data from one to the other.
- Active Directory Policies
Instructions to migrate this resource
To make sure that user data is not lost between sessions, it is necessary to update a specific Active Directory policy responsible for Roaming Profiles. This is done through Group Policy Management. Users should look for their studio in the options and then take this path: “Domain → <<your studio name>> → Roaming Profile Users”. This should open a new window. Select “Computer Configuration → Policies → Administrative templates → System → User profiles”. Users should right-click on “Set roaming profile path for all users logging in onto this computer” and select edit, then change the pointing from the old FSx to the new one. Once this process is completed successfully, the old FSx can be deleted to realize monetary savings.
The final step is to create a new Launch Profile in L.A. In Nimble’s Launch Profiles tab. Users should select the profile they want to migrate, click on Actions and Copy. They should then remove the old FSx filesystem, link the profile to the new subnet, and voilà, their studio is migrated to LA!
Notes for readers:
- If your studio is new and there is not much to be lost in FSx and AD, the possibility to delete and build again can be considered
- Don’t forget to tag all the resources created in the step above! If one day you decide to delete your studio, what was created manually will be left behind so it is good to keep them in check
Challenge #4: Compatibility issues with Adobe Substance 3D version 2019
By default, Studio in the Cloud and Nimble Studio images currently come with Windows Server 2019. This can result in some compatibility issues with Adobe Substance Painter 3D, which is used by many content creation studios. To avoid these issues, users have two options:
- Creating a Linux image for Adobe Substance Painter 3D
- Create a Windows Server 2022 image from scratch
The first option is easier (and faster) since the Linux AMI is available for free on the marketplace and is ready to use. For the second option, everything needs to be built from scratch, from the DCV client to the Deadline install process (if required), all while making sure that every Studio in the Cloud and Nimble Studio requirement is met. The TrackIt team might explore this process in detail in another article.
Challenge #5: Inability to request multiple instance types when creating a render fleet using spot request with Studio in the Cloud and Nimble Studio Builder
By default, the Studio in the Cloud and Nimble Studio Builder script only allows setting up a render fleet using a single instance type.
Having a single instance type requested in the spot request can be problematic as it can greatly reduce the chances of getting spot instances, leading to instance shortages.
Solution: By updating the Studio in the Cloud and Nimble Studio Builder script we were able to address the issue as shown in the screenshot below. When launching the Studio builder, developers have to choose “Exit to command line”.
In this instance, there should be a file: ~/studio_builder/renderfarm/compute_tier.py. Edit it with nano (the default text editor in Linux). At the beginning of the file, the following block should be imported:https://medium.com/media/9ea7253d1e829c429924fdc2c9d6acb1Imported Block from Compute_Tier.py
Add “SpotFleetAllocationStrategy,” anywhere between the parenthesis.
Next search for a block of code that looks like this:https://medium.com/media/6ff97bab0199ac7c5554ae08e2592f19Spot Fleet Configuration Code
At the line “instance_types=[instance_type]”, replace “[instance_type]” with “[InstanceType(“<instance type name>”)]”. Note that you can specify multiple instance types by separating the InstanceType with a comma. For example:https://medium.com/media/f052b47780d238e91f11447b645251ddExample of Instance Configuration
At the end of this block (before the closing parenthesis), add the following line:https://medium.com/media/e3ac50dc882637b306c9f52e80d94387Allocation Strategy Configuration
Save the file and re-launch Studio in the Cloud and Nimble Studio Builder by running the “studio_builder” command. Choose “Update and/or edit your studio”, and validate every question. The questions should contain the previous answers by default. When you reach the Deadline render farm questions, select “No, I want to keep my existing farm”, then “Keep”. Choose “No” for “Would you like to add another fleet?”, “y” to validate the settings and finally “UPDATE MY STUDIO” to start the update.
At the end of the CloudFormation update, the render fleet should now use all the instances you specified in the line “instance_types”
Challenge #6: Premature termination of render fleet boot sequences by the Studio in the Cloud and Nimble Studio Builder
Under certain specific circumstances where the AMI used exceeds a certain size, the render fleet deployed by Studio in the Cloud and Nimble Studio Builder does not allocate enough time for the AWS workers to complete their boot sequence and thus kills them before they start working on tasks.
Solution: Developers can manually edit a lambda function to increase the minimum duration before considering an instance as unhealthy. For example, this issue can be fixed by editing the “LostNodeGatherer” Lambda function. At the beginning of the function, there is a constant (FIFTEEN_MINUTES_IN_SECONDS) that is defined at 900 seconds (15 minutes). The value of this constant is changed to 1800 (30 minutes), which provides sufficient time for the instances to come alive and send their first health check.
Challenge #7: Creating a multi-region Studio in the Cloud and Nimble Studio deployment
For clients wishing to deploy multiple Studios in the Cloud and Nimble Studios in different regions, the major problem is that AWS doesn’t currently support the creation of multiple studios on the same account.
Solution: Users can create multiple AWS accounts, one for each region. Once the multiple studios are created, two things need to be addressed: Active Directory and FSx.
For Active Directory, AWS already provides a way to replicate a directory between multiple regions (replication) but since Studio in the Cloud and Nimble Studio users are forced to use AWS SSO (Single Sign-On), they cannot use the replicated directory.
A possible workaround is to manually handle the replication using a trust relationship ( a means for Active Directory to share information with another directory). Implementing this workaround requires the creation of a VPC peering between the accounts enabling the directories to be connected to each other. For instance, if we were to consider two directories A and B, a trust relationship needs to be created that allows directory A to read data from directory B, and vice versa. With this approach, one of the directories should be considered as the primary (or master) and the others should be considered as secondary (or mirror) directories. New accounts should only be created on the primary directory for data synchronization purposes.
For FSx, users could create one FSx server in each account and keep the FSx servers in sync using AWS DataSync. Once again, one of these servers should be the master and the others, the mirrors.
An Easy-to-Deploy, Scalable, and Cost-Effective Solution that Nevertheless Comes With Its Own Challenges
Designed to help content creation studios function at their best entirely on the cloud, Amazon Studio in the Cloud and Nimble Studio is the ideal solution for companies looking for an easy-to-deploy, cost-effective, and scalable cloud platform that enables creative teams to collaborate and work with artists located remotely. As with any solution one may choose to implement, Studio in the Cloud and Nimble Studio comes with its own set challenges and limitations — some of which we have mentioned and suggested solutions to in this article.
Lastly, companies and studios looking for assistance in implementing Studio in the Cloud and Nimble Studio can opt to work with a recognized AWS Advanced Consulting Partner like TrackIt to build a solution that’s tailored to their needs.
About TrackIt
TrackIt is an international AWS cloud consulting, systems integration, and software development firm headquartered in Marina del Rey, CA.
We have built our reputation on helping media companies architect and implement cost-effective, reliable, and scalable Media & Entertainment workflows in the cloud. These include streaming and on-demand video solutions, media asset management, and archiving, incorporating the latest AI technology to build bespoke media solutions tailored to customer requirements.
Cloud-native software development is at the foundation of what we do. We specialize in Application Modernization, Containerization, Infrastructure as Code and event-driven serverless architectures by leveraging the latest AWS services. Along with our Managed Services offerings which provide 24/7 cloud infrastructure maintenance and support, we are able to provide complete solutions for the media industry.