Tag Archives: organizational unit

Amazon AppStream 2.0 Launch Recap – Domain Join, Simple Network Setup, and Lots More

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/amazon-appstream-2-0-launch-recap-domain-join-simple-network-setup-and-lots-more/

We (the AWS Blog Team) work to maintain a delicate balance between coverage and volume! On the one hand, we want to make sure that you are aware of as many features as possible. On the other, we don’t want to bury you in blog posts. As a happy medium between these two extremes we sometimes let interesting new features pile up for a couple of weeks and then pull them together in the form of a recap post such as this one.

Today I would like to tell you about the latest and greatest additions to Amazon AppStream 2.0, our application streaming service (read Amazon AppStream 2.0 – Stream Desktop Apps from AWS to learn more). We launched GPU-powered streaming instances just a month ago and have been adding features rapidly; here are some recent launches that did not get covered in individual posts at launch time:

  • Microsoft Active Directory Domains – Connect AppStream 2.0 streaming instances to your Microsoft Active Directory domain.
  • User Management & Web Portal – Create and manage users from within the AppStream 2.0 management console.
  • Persistent Storage for User Files – Use persistent, S3-backed storage for user home folders.
  • Simple Network Setup – Enable Internet access for image builder and instance fleets more easily.
  • Custom VPC Security Groups – Use VPC security groups to control network traffic.
  • Audio-In – Use microphones with your streaming applications.

These features were prioritized based on early feedback from AWS customers who are using or are considering the use of AppStream 2.0 in their enterprises. Let’s take a quick look at each one.

Domain Join
This much-requested feature allows you to connect your AppStream 2.0 streaming instances to your Microsoft Active Directory (AD) domain. After you do this you can apply existing policies to your streaming instances, and provide your users with single sign-on access to intranet resources such as web sites, printers, and file shares. Your users are authenticated using the SAML 2.0 provider of your choice, and can access applications that require a connection to your AD domain.

To get started, visit the AppStream 2.0 Console, create and store a Directory Configuration:

Newly created image builders and newly launched fleets can then use the stored Directory Configuration to join the AD domain in an Organizational Unit (OU) that you provide:

To learn more, read Using Active Directory Domains with AppStream 2.0 and follow the Setting Up the Active Directory tutorial. You can also learn more in the What’s New.

User Management & Web Portal
This feature makes it easier for you to give new users access to the applications that you are streaming with AppStream 2.0 if you are not using the Domain Join feature that I described earlier.

You can create and manage users, give them access to applications through a web portal, and send them welcome emails, all with a couple of clicks:

AppStream 2.0 sends each new user a welcome email that directs them to a web portal where they will be prompted to create a permanent password. Once they are logged in they are able to access the applications that have been assigned to them.

To learn more, read Using the AppStream 2.0 User Pool and the What’s New.

Persistent Storage
This feature allows users of streaming applications to store files for use in later AppStream 2.0 sessions. Each user is given a home folder which is stored in Amazon Simple Storage Service (S3) between sessions. The folder is made available to the streaming instance at the start of the session and changed files are periodically synced back to S3. To enable this feature, simply check Enable Home Folders when you create your next fleet:

All folders (and the files within) are stored in an S3 bucket that is automatically created within your account when the feature is enabled. There is no limit on total file storage but we recommend that individual files be limited to 5 gigabytes.

Regular S3 pricing applies; to learn more about this feature read about Persistent Storage with AppStream 2.0 Home Folders and check out the What’s New.

Simple Network Setup
Setting up Internet access for your image builder and your streaming instances was once a multi-step process. You had to create a Network Address Translation (NAT) gateway in a public subnet of one of your VPCs and configure traffic routing rules.

Now, you can do this by marking the image builder or the fleet for Internet access, selecting a VPC that has at least one public subnet, and choosing the public subnet(s), all from the AppStream 2.0 Console:

To learn more, read Network Settings for Fleet and Image Builder Instances and Enabling Internet Access Using a Public Subnet and check out the What’s New.

Custom VPC Security Groups
You can create VPC security groups and associate them with your image builders and your fleets. This gives you fine-grained control over inbound and outbound traffic to databases, license servers, file shares, and application servers. Read the What’s New to learn more.

You can use analog and USB microphones, mixing consoles, and other audio input devices with your streaming applications. Simply click on Enable Microphone in the AppStream 2.0 toolbar to get started. Read the What’s New to learn more.

Available Now
All of these features are available now and you can start using them today in all AWS Regions where Amazon AppStream 2.0 is available.


PS – If you are new to AppStream 2.0, try out some pre-installed applications. No setup needed and you’ll get to experience the power of streaming applications first-hand.

Use CloudFormation StackSets to Provision Resources Across Multiple AWS Accounts and Regions

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/

AWS CloudFormation helps AWS customers implement an Infrastructure as Code model. Instead of setting up their environments and applications by hand, they build a template and use it to create all of the necessary resources, collectively known as a CloudFormation stack. This model removes opportunities for manual error, increases efficiency, and ensures consistent configurations over time.

Today I would like to tell you about a new feature that makes CloudFormation even more useful. This feature is designed to help you to address the challenges that you face when you use Infrastructure as Code in situations that include multiple AWS accounts and/or AWS Regions. As a quick review:

Accounts – As I have told you in the past, many organizations use a multitude of AWS accounts, often using AWS Organizations to arrange the accounts into a hierarchy and to group them into Organizational Units, or OUs (read AWS Organizations – Policy-Based Management for Multiple AWS Accounts to learn more). Our customers use multiple accounts for business units, applications, and developers. They often create separate accounts for development, testing, staging, and production on a per-application basis.

Regions – Customers also make great use of the large (and ever-growing) set of AWS Regions. They build global applications that span two or more regions, implement sophisticated multi-region disaster recovery models, replicate S3, Aurora, PostgreSQL, and MySQL data in real time, and choose locations for storage and processing of sensitive data in accord with national and regional regulations.

This expansion into multiple accounts and regions comes with some new challenges with respect to governance and consistency. Our customers tell us that they want to make sure that each new account is set up in accord with their internal standards. Among other things, they want to set up IAM users and roles, VPCs and VPC subnets, security groups, Config Rules, logging, and AWS Lambda functions in a consistent and reliable way.

Introducing StackSet
In order to address these important customer needs, we are launching CloudFormation StackSet today. You can now define an AWS resource configuration in a CloudFormation template and then roll it out across multiple AWS accounts and/or Regions with a couple of clicks. You can use this to set up a baseline level of AWS functionality that addresses the cross-account and cross-region scenarios that I listed above. Once you have set this up, you can easily expand coverage to additional accounts and regions.

This feature always works on a cross-account basis. The master account owns one or more StackSets and controls deployment to one or more target accounts. The master account must include an assumable IAM role and the target accounts must delegate trust to this role. To learn how to do this, read Prerequisites in the StackSet Documentation.

Each StackSet references a CloudFormation template and contains lists of accounts and regions. All operations apply to the cross-product of the accounts and regions in the StackSet. If the StackSet references three accounts (A1, A2, and A3) and four regions (R1, R2, R3, and R4), there are twelve targets:

  • Region R1: Accounts A1, A2, and A3.
  • Region R2: Accounts A1, A2, and A3.
  • Region R3: Accounts A1, A2, and A3.
  • Region R4: Accounts A1, A2, and A3.

Deploying a template initiates creation of a CloudFormation stack in an account/region pair. Templates are deployed sequentially to regions (you control the order) to multiple accounts within the region (you control the amount of parallelism). You can also set an error threshold that will terminate deployments if stack creation fails.

You can use your existing CloudFormation templates (taking care to make sure that they are ready to work across accounts and regions), create new ones, or use one of our sample templates. We are launching with support for the AWS partition (all public regions except those in China), and expect to expand it to to the others before too long.

Using StackSets
You can create and deploy StackSets from the CloudFormation Console, via the CloudFormation APIs, or from the command line.

Using the Console, I start by clicking on Create StackSet. I can use my own template or one of the samples. I’ll use the last sample (Add config rule encrypted volumes):

I click on View template to learn more about the template and the rule:

I give my StackSet a name. The template that I selected accepts an optional parameter, and I can enter it at this time:

Next, I choose the accounts and regions. I can enter account numbers directly, reference an AWS organizational unit, or upload a list of account numbers:

I can set up the regions and control the deployment order:

I can also set the deployment options. Once I am done I click on Next to proceed:

I can add tags to my StackSet. They will be applied to the AWS resources created during the deployment:

The deployment begins, and I can track the status from the Console:

I can open up the Stacks section to see each stack. Initially, the status of each stack is OUTDATED, indicating that the template has yet to be deployed to the stack; this will change to CURRENT after a successful deployment. If a stack cannot be deleted, the status will change to INOPERABLE.

After my initial deployment, I can click on Manage StackSet to add additional accounts, regions, or both, to create additional stacks:

Now Available
This new feature is available now and you can start using it today at no extra charge (you pay only for the AWS resources created on your behalf).


PS – If you create some useful templates and would like to share them with other AWS users, please send a pull request to our AWS Labs GitHub repo.