It’s time to plan your 2018 AWS re:Invent schedule! This will be our team’s fourth re:Invent, so we’ve put together some tips for planning out your conference experience.
First up, if you have not yet registered for re:Invent, do that now! Tickets sold out last year, so don’t wait.
Choose Your Sessions in Advance
The key to a great AWS re:Invent schedule is to plan in advance. The essential part of this planning is to register for sessions in advance. There will be a session registration open date, which has not yet been announced for 2018. When that date is released, though, put it on your calendar and reserve some time for registration – it can be competitive and sessions fill up quickly. Last year, session registration opened on October 19, so expect a similar date this year.Update: reserved seating goes live on October 11th at 1 PM eastern/ 10 AM Pacific! Mark your calendar!
What you can get started with today is reading through the re:Invent agenda and, especially, the immense event catalog. Note the sessions you’re interested in. Here are some tips to keep in mind:
Focus – what do you most hope to gain at re:Invent? You can sort sessions based on subject areas and industries – would a “focus path” help you gain more out of your experience?
Value of In-Person vs. Session Videos – Many sessions will be online afterward, so prioritize sessions with an element that is more valuable in person – that may be chalk talks, workshops, and others with interactive elements. You’ll be able to watch any sessions you missed and catch up on the information on others with videos. This can put you more at ease and let you have some fun while in Vegas.
Travel time – This won’t be the first or the last time you hear this, but it’s worth saying again: the re:Invent campus is big. HUGE. Plan your schedule accordingly, with as few travel periods up and down The Strip as possible. If there are multiple sessions you’re interested in at the same time, prioritize ones with the least travel time. You should also plan to arrive to sessions early.
Once dates, times, and locations have been announced for sessions, we recommend putting them into your calendar for a clean visual of your day, and reminders. Once it’s available, you’ll be able to view your AWS re:Invent schedule in the mobile app, along with maps and more.
Set Aside Time for the Expo Hall
Make sure you plan on time to visit the expo hall! Actually, there are now two expos – the main one at The Venetian and another at the Aria.
The Welcome Reception from 4-7 PM on Monday is a great time to visit the expo and kick off your re:Invent experience with food, drinks, and giveaways. However, it will be crowded. You’ll want to come back again later in the week to check out vendor products and services, chat with vendors whose products you already use, get swag, and enter drawings. The expo is open from 8 AM – 6 PM Tuesday, 10 AM – 6 PM Wednesday, and 10 AM – 4 PM Thursday.
You won’t be disappointed by the swag. Just search #reinventswag for examples — sponsors go all out. By the way, if you’re aiming to maximize swag, definitely stop by after lunch on Thursday. Sponsors will practically beg you to take stuff off their hands so they don’t have to ship it home. You can grab toys, stickers, and keychains for your kids, or build an entire wardrobe of t-shirts and socks for yourself.
And of course, stop by and visit ParkMyCloud at the Venetian expo, booth #1709! Mention this post and we’ll hook you up with some secret bonus swag.
(Also, what secret bonus swag would you want? Asking for a friend…)
Activities and Parties
Round out your Vegas experience with some partying! The great thing about a conference like this is that you can often drink your way through for free, courtesy of vendors with bigger marketing budgets than mine. Outside of Tuesday’s pub crawl, many parties require you to register ahead of time, so keep an eye on your email for invitations. You’ll want to bookmark this list of 2018 re:Invent parties. As of this writing, it’s a bit sparse, but check out last year’s party list for an idea of the multitude of options to come.
Obviously, you don’t want to miss re:Play, the centerpiece of the conference (you know, besides the keynotes.) More free food, drink, an EDM concert, retro arcade, laser escape room, drone obstacle course, climbing wall, dodgeball, bounce castle, archery tag, and/or whatever else they come up with for this year.
Or venture out beyond the conference hall walls and try your luck or catch a show – it’s hard to be bored in Vegas.
Do you have any other tips for planning the perfect AWS re:Invent schedule? Let us know in the comments. Cheers, and see you there!
In the world of infrastructure as code, the biggest divide seems to come in the war between Hashicorp’s Terraform vs. CloudFormation in AWS. Both tools can help you deploy new cloud infrastructure in a repeatable way, but have some pretty big differences that can mean the difference between a smooth rollout or a never ending battle with your tooling. Let’s look at some of the similarities and some of the differences between the two.
While the tools have some very unique features, they also share some common aspects. In general, both CloudFormation and Terraform help you provision new AWS resources from a text file. This means you can iterate and manage the entire infrastructure stack the same as you would any other piece of code. Both tools are also declarative, which means you define what you want the end goal to be, rather than saying how to get there (such as with tools like Chef or Puppet). This isn’t necessarily a good or bad thing, but is good to know if you’re used to other config management tools.
Unique Characteristics of CloudFormation
One of the biggest benefits of using CloudFormation is that it is an AWS product, which means it has tighter tie-ins to other AWS services. This can be a huge benefit if you’re all-in on AWS products and services, as this can help you maximize your cost-effectiveness and efficiency within the AWS ecosystem. CloudFormation also makes use of either YAML or JSON as the format for your code, which might be familiar to those with dev experience. Along the same lines, each change to your infrastructure is a changeset from the previous one, so devs will feel right at home.
There are some additional tools available around CloudFormation, such as:
Stacker – for handling multiple CloudFormation stacks simultaneously
Troposphere -if you prefer python for creating your configuration files
Sceptre – for organizing CloudFormation stacks into environments
Unique Characteristics of Terraform
Just as being an AWS product is a benefit of CloudFormation if you’re in AWS, the fact that Terraform isn’t affiliated with any particular cloud makes it much more suited for multi-cloud and hybrid-cloud environments, and of course, for non-AWS clouds. There are Terraform modules for almost any major cloud or hypervisor in the Terraform Registry, and you can even write your own modules if necessary.
Terraform treats all deployed infrastructure as a state, with any subsequent changes to any particular piece being an update to the state (unlike the changesets mentioned above for CloudFormation). This means you can keep the state and share it, so others know what your stack should look like, and also means you can see what would change if you modify part of your configuration before you actually decide to do it. The Terraform configuration files are written in HCL (Hashicorp Configuration Language), which some consider easier to read than JSON or YAML.
The good news is that if you’re trying to decide between Terraform vs. CloudFormation, you can’t really go wrong with either. Both tools have large communities with lots of support and examples, and both can really get the job done in terms of creating stacks of resources in your environments. They are both also free, with CloudFormation having no costs (aside from the infrastructure that gets created) and Terraform being open-source while offering a paid Enterprise version for additional collaboration and governance options. Each has their pros and cons, but using either one will help you scale up your infrastructure and manage it all as code.
The AWS free tier is a great way to get started using Amazon Web Services — it can be a great boost to individuals, startups, and small businesses. In fact, the AWS free tier was essential to getting ParkMyCloud off the ground when we launched. But of course, this program has limits on what you can use without being charged.
The AWS free tier is designed to give you the AWS experience without the cost, but that also comes with limitations on instance types, storage, hours, and how often you can call operations each month. Of course, all good things must come to an end. If you’ve outgrown the free tier option and are ready to experience the full benefits of AWS, there are a few things you can do to make sure you’re getting the most out of being a paying AWS customer.
#1 Set spending limits
The first thing to consider when your 12 months on forgoing the AWS free tier expire option is the most obvious difference – cost versus no cost. You’re paying for cloud services now, so ensure that you don’t pay more than you intend to.
Use AWS Budgets to create custom cost and usage budgets that notify you when you exceed (or are about to exceed) your budgeted amount. Track budgets by the month, quarter, or year, with custom start and end dates. You can also track costs by services, account, tags, and more, receiving alerts directly to your email or through the Simple Notification Service.
With AWS Budgets, you can also set custom utilization targets for reserved instances including Amazon EC2 instances, Amazon RDS, Amazon Redshift, and Amazon ElastiCache, receiving alerts whenever your usage drops below your set utilization target. To get started with creating and tracking budgets, start from the AWS Budgets dashboard or the Budgets API.
#2 Optimize resource usage
Next, you need to ensure that that budget is only going toward resources you actually need – so cost optimization should be a top priority. You might be overpaying by leaving instances running during non-production times, when you don’t need them. Scheduling stop/start times with automation is an easy way to integrate cost control outside of the AWS free tier.
#3 Set sizing limits
Yet another caveat of cost optimization is right sizing. Besides making sure your instances are turned off when not in use, you should also make a practice of only using as much as you need at a given time, and that’s where right sizing comes into play. Size your workloads according to performance and capacity requirements, both initially and on an ongoing basis to ensure that resources do not end up underused or idle. AWS suggests that you use CloudWatch metrics to get a full view of your environment, and make a habit of right sizing once per month to keep the process smooth, ensure that you’re monitoring costs and keeping track of your billing and usage over time.
As your infrastructure grows, it’s important to manage your AWS resources with an effective tagging strategy. Tagging gives you the ability to attach custom metadata to instances, images, and more. Resources can be categorized by owner, purpose, or environment, helping you stay organized, improve visibility, and keep costs in check.
A good tagging strategy gives you a more accurate model for chargeback and showback and better insight in your usage and spend, but it’s up to you to enforce quality of tagging. Soft enforcement gives users notifications when policies are not followed, and hard enforcement automatically removes resources that are not tagged to align with company standard. According to AWS, organizations that use hard enforcement have a better time ensuring that quality of tagging is enforced.
Scheduling, right sizing, budget limits, and tagging are all methods of keeping costs optimized after you switch from the AWS free tier to a paid, full-service option. But what do all of these practices have in common? Governance. Clear policies and processes to keep usage, capacity requirements, and billing in check are all part of cloud and cost management, and should remain an ongoing priority as you continue using AWS or any cloud service provider.
Alibaba Cloud is growing at an amazing rate, recently claiming to have overtaken both Google and IBM as the #3 public cloud provider globally, and certainly the #1 provider in China. Many sites and services hosted outside China are accessible from within China, but can suffer high latency and potentially lost functionality if their web interface requires interaction with blocked social media systems. As such, it is no surprise that a number of our (non-Chinese) customers have expressed interest in actually running virtual machine Alibaba instances in China. In this blog we are going to outline the process…and give an alternate plan.
General Process to Run Alibaba Instances in China
The steps to roll-out a deployment on Alibaba in mainland China are relatively clear:
Establish a “legal commercial entity” in Mainland China.
Select what services you want to run on Alibaba Cloud
Apply for Internet Content Provider (ICP) certification
The first three steps are described in more detail below.
Establish a Legal Commercial Entity
Or putting it another way – you need to have an office in China. This can range from an actual office with your own employees, to a Joint Venture, which is a legal LLC between your organization and an established Chinese company. If your service is more informational in nature and is not actually selling anything via the service, then this can be relatively easy, taking only a couple weeks (at least for the legal side), though you will still need to find a Joint Venture partner and make the deal worth their while financially. For commerce or trade-related services, the complexity, time requirements, and costs start going up significantly.
What to run on Alibaba Cloud
There is a decision-point here, as there is one set of rules for Alibaba-hosted web/app servers, and additional rules for everything else. Base virtual machines, databases and other such core IT building blocks require the ICP registration described below, plus “real-name registration”, where a passport is needed to actually confirm the identity of whomever is purchasing the resource. If all you need is a web server, then you can skip this step. In either case, some of the filing requirements involve having a server and/or DNS record prepared in order to complete the later steps. A web site does not need to be completely finished until launch, but a placeholder may be needed.
Internet Content Provider (ICP) certification
There are two flavors of ICP certification:
A “simple” ICP Filing – which is the bare minimum needed for informational websites that are not directly generating revenue.
ICP Commercial Filing – This starts with getting an approved ICP Filing, and then also includes a Commercial License that must be obtained a province/municipality in China. In some cases, this appears to be related to which Alibaba region you are using, and even the physical location of your public IP address.
Many references recommend finding an experienced consultant to guide you through these processes, and it is easy to see why!
OK…WAY too much work. What is Plan B?
The other way to run Alibaba instances in China is to host your site or services in Hong Kong. All of the rules described above apply to “Mainland China”, which does not include Hong Kong. Taiwan is also not included in Mainland China, but Hong Kong has the advantage of being better connected to the rest of China. If the main problem you are trying to solve is to reduce latency to your site for China-based customers, Hong Kong is the closest you can get without actually being there, and Alibaba appears to do a pretty good job optimizing the Hong Kong experience. No local office or legal filings required!
Once you are all set up: Optimize your Costs!
After your instances are set up, make sure you’re optimizing Alibaba costs. Our Mainland China-based customers using Alibaba have confirmed that ParkMyCloud is able to access the Alibaba APIs from our US-based servers – so you can go ahead and try it out.
Earlier this week we discussed ways to improve cloud automation through tagging. Today, I want to extend the conversation to look at how one ParkMyCloud user is applying tagging best practices to improve their cloud governance.
The company we talked to — they’re in media, so let’s call them MediaCorp — has about 10,000 employees, which means the Cloud Engineering team has several hundred cloud users to manage, with a combined 100+ AWS accounts and more than 5,000 active AWS resources. The only way they can maintain security and cost control in a cloud environment of this magnitude is through automated governance. Here’s how they do it.
Tagging Best Practices #1: Always Tag
MediaCorp has a strict policy: every AWS resource must have the same set of five tags attached to it:
team — essential to establishing ownership of the resource, both for maintenance and for billing
environment — knowing whether the resource is for production, staging, or QA has implications for on/off schedules
application — MediaCorp uses this as a trigger for Chef Cookbooks, but can also apply to billing
expiration date — Any non-production resource has a stated expiration date to prevent orphaned resources
cost center — The finance department has internal billing codes for all IT resources
How does MediaCorp ensure that all resources are tagged?
Tagging Best Practices #2: Automated Compliance
The key is to use automated rules to enforce that every resource has the five required tags — this is where ParkMyCloud’s policy engine comes into play. MediaCorp has a set of policies set up to check for the five tags. If a resource is missing any, the resource is immediately put on an “always parked” schedule and moved to a team (a way to group instances in ParkMyCloud) specifically for mistagged resources.
When this happens, the Cloud Engineering team gets an email and a Slack notification, so they can track down the creator of the offending resource and correct the process that created it.
Tagging Best Practices #3: Optimize Workflows
Now the tags themselves come into play. MediaCorp uses their five-tag system for three main purposes:
Configuration management: as mentioned above, they use tags as the trigger for Chef cookbooks, and of course the same applies to Puppet Modules, or Ansible Playbooks.
CI/CD: MediaCorp uses Jenkins to provision cloud resources, so they use tags to associate build and deployment servers with their corresponding repository and build number, for both automated and manual development tasks.
Cost control: the “environment” tag determines what parking schedule is applied to each resource. Production resources run 24×7, of course, while “dev” or “test” resources are put on a schedule to park 7:00 PM – 7:00 AM and on weekends. (Users can always log in to override these schedules if needed.)
Conclusion: Tagging is Worth the Effort
It may at first seem unnecessarily harsh to automatically park any resource that doesn’t have proper tags applied, but this process is what allows MediaCorp to keep a well-governed, cost-controlled infrastructure. You can always adapt their use case to your own needs by simply moving resources to another team and notifying that action is needed, without changing the state or schedule on the resource.
Either way, with a rigorous application of tagging best practices in place, you can automate governance and improve your workflows.