[ceejayoz]

If you're big enough that switching regions in the console is a regular pain, you're probably big enough to just automate stuff via the APIs.

[grif-fin]

This maybe a fact but not an excuse for poor user experience.

[ceejayoz]

AWS initially launched API-only. At any significant scale, it's simply not intended to be managed via the console.

[grif-fin]

I found visualization very much helpful when complexity rises. APIs stays powerful but do not support a human admin for monitoring and server setups (including IAM users, Services, Tasks, Clusters, Launching EC2 instances, ECR setup for docker, AIM, Loadbalancing, Security groups, Roles etc all multiplied to X regions).

[ceejayoz]

Again, if you're large enough to be in multiple regions, all of this should be configured via the APIs using a configuration management system of some sort.

Ansible, for example, can easily manage stuff like security groups (http://docs.ansible.com/ansible/ec2_group_module.html) , load balancing (http://docs.ansible.com/ansible/ec2_elb_lb_module.html), IAM users and roles (http://docs.ansible.com/ansible/iam_module.html), etc., and it does them in repeatable, auditable, version-controllable, self-documenting fashion.

[grif-fin]

" if you're large enough to be in multiple regions, all of this should be configured via the APIs"

Is the suggestion to recreate what Amazon Console has done (using APIs) in every large organisation using AWS because Amazon Console is not good enough?

[tomcart]

No, treat your infrastructure as code. Define it programatically, version it, have a standard, automated process for recreating it.

If you're using AWS then Cloudformation (maybe with an abstraction like troposphere), will do what you need.

If you are pressing the big blue 'launch instance' button, you are doing it wrong.

[vacri]

I'm not sure what a console that performs the current tasks and spans multiple regions at once would look like, or that it would make things feel simpler.

What's your suggestion for improving the UX?

[grif-fin]

Extending the UX with "the current tasks and spans multiple regions at once" is definitely NOT the right way.

I believe the current sub-categorizing of services:

API Gateway, AppStream, AWS IoT, Certificate Manager, CloudFormation, CloudFront, CloudSearch, CloudTrail, CloudWatch, CodeCommit, CodeDeploy, CodePipeline, Cognito, Config, Data Pipeline, Device Farm, Direct Connect, Directory Service, DMS, DynamoDB, EC2, EC2 Container Service, Elastic Beanstalk, Elastic File System, Elastic Transcoder, ElastiCache, Elasticsearch Service, EMR, GameLift, Glacier, IAM, Inspector, Kinesis, Lambda, Machine Learning, Mobile Analytics, Mobile Hub, OpsWorks, RDS, Redshift, Route 53, S3, Service Catalog, SES, Snowball, SNS, SQS, Storage Gateway, SWF, Trusted Advisor, VPC, WAF, WorkDocs, WorkMail, WorkSpaces.

is not helpful and confusing for new users. This is because all the mentioned services are a mix of dependent (e.g. ECS depends on EC2), independent(e.g. IAM & EC2), security, services acting like plugins.

The documents for all of these services can be a sequel novel. If you have been with AWS since 2012 you may have gradually been updated by each service that was getting blindly added but for a new user or a startup aiming to setup something or test the scalability of their application ASAP it is a nightmare.

The other day I found out (in a hard way) that you cannot launch an EC2 instance with an AWS container agent from the default launch page but you need to go to the launch page via the document link which puts extra parameters in the url...

Having said all that I believe the improvement needs to be more fundamental than couple of bullet points.